bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32921: emacsclient obeys Xresources even when launched with -nw


From: Eli Zaretskii
Subject: bug#32921: emacsclient obeys Xresources even when launched with -nw
Date: Wed, 18 May 2022 16:02:54 +0300

> Cc: 32921@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 18 May 2022 14:38:33 +0200
> 
> Dimitrios Apostolou <jimis@gmx.net> writes:
> 
> > I have set the Xresource *reverseVideo to true, and as expected emacs
> > reverses the colours when launched under X, and does not when launched
> > with -nw thus keeping the terminal colour selections.
> >
> > However emacsclient obeys the Xresources even when launched with
> > -nw. This leads to colour reversal in text mode, which is unwanted
> > since the xterm has already been configured as desired.
> 
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
> 
> This behaviour is still present in Emacs 29.  This seems to be stemming
> from this:
> 
>   ;; Check the reverseVideo resource.
>   (let ((case-fold-search t))
>     (let ((rv (x-get-resource "reverseVideo" "ReverseVideo")))
>       (if (and rv
>              (string-match "^\\(true\\|yes\\|on\\)$" rv))
>         (setq default-frame-alist
>               (cons '(reverse . t) default-frame-alist)))))
> 
> in term/x-win.el -- it sets reverse for all new frames, so when the -nw
> frame appears, it also gets reverted (which isn't what we want, I
> think).
> 
> If I just remove this, then everything still works fine (and the -nw
> client problem disappears), because:
> 
> (defun x-handle-reverse-video (frame parameters)
>   "Handle the reverse-video frame parameter and X resource.
> `x-create-frame' does not handle this one."
>   (when (cdr (or (assq 'reverse parameters)
>                (let ((resource (x-get-resource "reverseVideo"
>                                                "ReverseVideo")))
> 
> So it's always handled anyway, and the default-frame-alist setting is
> just counter-productive, I think?
> 
> Does anybody see any possible negative consequences of just removing
> that code from x-win.el?

Which sequence of calls ends up calling x-handle-reverse-video, and
what is the trigger for that sequence of calls?

(These kinds of changes in code that was there for decades give me the
creeps.)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]