From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Renaming non-X x_* identifiers Date: Sat, 27 Apr 2019 12:37:52 +0100 Message-ID: <87a7gbznjj.fsf@tcd.ie> References: <87wokp4okn.fsf@gmail.com> <83ef6xpo6b.fsf@gnu.org> <0f4be9a6-6e09-f55d-9f58-2a15aef264cd@cs.ucla.edu> <837ecpplw8.fsf@gnu.org> <871s2w510a.fsf@gmail.com> <922F9B91-2E9E-45F6-BB96-66CAE5E9FB81@gnu.org> <87k1goqpnn.fsf@gmail.com> <83imw8nspc.fsf@gnu.org> <87ftrcqg5j.fsf@gmail.com> <83bm20nm62.fsf@gnu.org> <87d0men4jx.fsf@gmail.com> <83o95sisk7.fsf@gnu.org> <87mulcnui4.fsf@gmail.com> <83bm1si7lf.fsf@gnu.org> <87ef6ont03.fsf@gmail.com> <83a7hci44l.fsf@gnu.org> <87a7hcndtc.fsf@gmail.com> <831s2nhza8.fsf@gnu.org> <87d0lpvq6n.fsf_-_@gmail.com> <875zr0z00x.fsf@tcd.ie> <87o94snm91.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="27735"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Alex Gramiak Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 27 13:39:22 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hKLfs-00076b-HA for ged-emacs-devel@m.gmane.org; Sat, 27 Apr 2019 13:39:20 +0200 Original-Received: from localhost ([127.0.0.1]:59020 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hKLfr-0007sJ-Bj for ged-emacs-devel@m.gmane.org; Sat, 27 Apr 2019 07:39:19 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45793) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hKLeY-00074n-Cw for emacs-devel@gnu.org; Sat, 27 Apr 2019 07:37:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hKLeX-0006jF-DB for emacs-devel@gnu.org; Sat, 27 Apr 2019 07:37:58 -0400 Original-Received: from mail-ed1-x541.google.com ([2a00:1450:4864:20::541]:40491) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hKLeX-0006iD-1J for emacs-devel@gnu.org; Sat, 27 Apr 2019 07:37:57 -0400 Original-Received: by mail-ed1-x541.google.com with SMTP id d46so5275561eda.7 for ; Sat, 27 Apr 2019 04:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=mfFTe6rKH96+Sh75nkwDDgrQmkFBHNMtTbLz5ZS8yQU=; b=OChP/oJ/JvQttdEbMClrfmueTVCKv5e9KdRBPnN1EhavhXKWsPgdTFn4oUWYtrUKRr msrvkJxtLsrabZOs5cXVEq7eI/J4s6zKKN4vbb4hq8a7zlzXynXAhN5QZIwVdPGOIQWL 3Ca/MnOOPAxmDZa3swN7xpCXVj1VyyKk3DUtNWtCGTSH1azB2vfS3gnlmGE0eEGYl7Lx JRcfTMIVRuAB4CUuSD9ZKnPnxMLt2jPL4LsUxmXWW7tB7kIlzgQ//TuEfDV0Me2K+io4 jNJ3XcQpmqfxdb+31vZ8YQcgNn9EAKysq7d4Tt2u27jyoxXQrwmczElewYfmtgCGXsnI c6CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=mfFTe6rKH96+Sh75nkwDDgrQmkFBHNMtTbLz5ZS8yQU=; b=R1ML+RAdK/F+Ds6K+YEHd1I0vTRs/Mj7wb2mhnRAPg25tYAH1ol74th2rHZ5ju/l6/ cBmFkIuyKQoNjFxtwW5gpApOg4WNkDP8RDvf77E06ztc1l2WcG7INsQBKumVkuRRDqO/ mHHZEZUhuHd/l5Oo3mT9fc5j9FooNld2/aUB3kEGNCBNwPTdtjabPKdfO5D9dr1Q+DfN YZfi8RNVpgxwBRtUf6SXJVCSYGOSw3DORcGYyAAe7pJUntMKkBkHYYhIfXnQeBx5xcyy g3PBI/0PumFsCbvbOrFogmlOtJxojqcspoaCtHyvvBFReBzZovmIsD3+GbuzXtA7kjZJ kNlQ== X-Gm-Message-State: APjAAAVUoyrsYKfhTGhkRkTk67PQ3l2TpSpZF+/d4nCWSAFpfJvmIDkl ieCkpiAxlapEbZb3ct+bLDRvxw== X-Google-Smtp-Source: APXvYqy3KEsmn+U7K4GrNqaIZYCCidzwN7TrYoP/vHTbzZiGnrR6LMsvhzmLBKuLBUlsIG9gmzqryA== X-Received: by 2002:a17:906:3941:: with SMTP id g1mr2941031eje.168.1556365075132; Sat, 27 Apr 2019 04:37:55 -0700 (PDT) Original-Received: from localhost ([2a02:8084:20e2:c380:6fa:38d6:1fce:ddb3]) by smtp.gmail.com with ESMTPSA id b42sm5584859edd.83.2019.04.27.04.37.53 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sat, 27 Apr 2019 04:37:54 -0700 (PDT) In-Reply-To: <87o94snm91.fsf@gmail.com> (Alex Gramiak's message of "Fri, 26 Apr 2019 21:46:34 -0600") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::541 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235988 Archived-At: Alex Gramiak writes: > "Basil L. Contovounesios" writes: > >>> diff --git a/src/xdisp.c b/src/xdisp.c >>> index ae4c405b8d..11667d2735 100644 >>> --- a/src/xdisp.c >>> +++ b/src/xdisp.c >>> @@ -11592,9 +11592,8 @@ clear_garbaged_frames (void) >>> else >>> clear_current_matrices (f); >>> >>> -#if defined (HAVE_WINDOW_SYSTEM) && !defined (HAVE_NS) >>> - x_clear_under_internal_border (f); >>> -#endif /* HAVE_WINDOW_SYSTEM && !HAVE_NS */ >>> + if (FRAME_RIF (f)->clear_under_internal_border) >>> + FRAME_RIF (f)->clear_under_internal_border (f); >>> >>> fset_redisplay (f); >>> f->garbaged = false; >> >> This causes a segfault in 'emacs -nw' and emacsclient because >> FRAME_RIF (f) is NULL in tty frames such as the initial daemon frame. > > Sorry about the trouble. Somehow I didn't test using -nw with a > HAVE_WINDOW_SYSTEM build. It should be fixed now. Thanks for the quick fix! >> Is x_clear_under_internal_border not supposed to be run in tty frames? > > Previously it did, but each implementation of that procedure was a no-op > for tty frames. The issue is that FRAME_RIF procedures shouldn't be > called for tty frames; I didn't realize that FRAME_RIF was NULL for tty > frames instead of a blank struct. I wonder if that should be changed to > avoid this in the future? I'm always for consistency, but I'm not familiar enough with this area to know what drawbacks such a change may entail, or how much of the code relies on current behaviour. FWIW, here's the relevant commentary in termhooks.h: /* Window-based redisplay interface for this device (0 for tty devices). */ struct redisplay_interface *rif; I'm guessing setting it to NULL as opposed to initialising the struct is an optimisation for tty frames. As a side note, I chuckled at this commentary in an old version of dispnew.c: /* Current interface for window-based redisplay. Set from update_begin. A null value means we are not using window-based redisplay. */ /* XXX this variable causes frequent coredumps */ struct redisplay_interface *rif; -- Basil