From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Alex Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Mar 2019 23:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 35058@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.155398911127652 (code B ref -1); Sat, 30 Mar 2019 23:39:01 +0000 Received: (at submit) by debbugs.gnu.org; 30 Mar 2019 23:38:31 +0000 Received: from localhost ([127.0.0.1]:37676 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hANYU-0007Bw-DX for submit@debbugs.gnu.org; Sat, 30 Mar 2019 19:38:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hANYR-0007Bj-K2 for submit@debbugs.gnu.org; Sat, 30 Mar 2019 19:38:28 -0400 Received: from lists.gnu.org ([209.51.188.17]:47110) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hANYM-0007HE-Ds for submit@debbugs.gnu.org; Sat, 30 Mar 2019 19:38:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56822) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hANYJ-0000MD-Ri for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2019 19:38:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hANYH-0007F6-UH for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2019 19:38:19 -0400 Received: from mail-pg1-x532.google.com ([2607:f8b0:4864:20::532]:35855) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hANYH-0007EY-JX for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2019 19:38:17 -0400 Received: by mail-pg1-x532.google.com with SMTP id 85so2923996pgc.3 for ; Sat, 30 Mar 2019 16:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:user-agent:mime-version :content-disposition; bh=L65zj1Q3MaDgGQwuiluBCFKCMs8CZTgg8sTBi5TI3sA=; b=e1QcB3tnjwvDCbIYTSp2Wqb3jWDXI22AzWB5HngglIsS8uoRtHDjGhwSC0/0Y44rDm ZaVOb1M10WVoHEu3KnOPXmSrOvoqrzoxRNciOe6qHSwaSVrfxSwkN/VXG6AiivI6vlHM aQSjWhKeTiGzBSVnRSvKFMGBbM3jFX8+kBll7+t0k9EsJ7EE4aqJprFVLavTbPFgsUT0 z/TRneiamGVvPbYZnoikxVldhrNQmW+sDAWnLQGEyyl3ZkJ+tQ6CnWfIzDWr8SV7wZiN jXefuBbxbU1Q3zxPQui4jC42JDsuJTLFayy3tb02GiidGOIQkV4L1P2w0/wOV8xdCcQK zzNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version:content-disposition; bh=L65zj1Q3MaDgGQwuiluBCFKCMs8CZTgg8sTBi5TI3sA=; b=Cx4CPMa1jHb/ZxhUkRWo7/yP+6wYomfhVR87qOVmuAg1+8yfyCTQszGlT2sDc9+D7j 91fsdDwwmwmJCwxh0acqQtWApNZKPt1jQ0Isg+cA3epmmY0cYe/KtRfhV8ciDmzxAmC3 mb6zIqgPtE5mPAyaTj6p+3F6VFf2PwGZhd7JOaPcSoRvtfJAU4YCEz3YHmpxi4g7qDjk psOCrU13KEDM/XLe5yA+3HVZesjvAlofwQHmyvDb4fGeIs/p7/hc4Ge3D4rBvH/31w/t iczQ0d6mvfQOtuf5me77XdLFdtqfb5MgxjA+C8NyMrhxFOhCpu7wWjNkIMNzG6nVdwCe DBpg== X-Gm-Message-State: APjAAAX1cUJxBWvVJgu4FyMO9uR1NFEO9yl1PxCLuL1nzYnsiojtHuxz Ibj3+uxeLyCtOPkq75UttyqLwAtu X-Google-Smtp-Source: APXvYqx5a0nDU26CspUQG0Vz37KzzyfRqTfYur9UL8YEFt8nIp7+quS1GRaOXlMgaj+JLc4xn1yFRw== X-Received: by 2002:a63:330e:: with SMTP id z14mr5659291pgz.4.1553989096372; Sat, 30 Mar 2019 16:38:16 -0700 (PDT) Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id i79sm10692090pfj.28.2019.03.30.16.38.14 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 30 Mar 2019 16:38:15 -0700 (PDT) From: Alex Date: Sat, 30 Mar 2019 17:38:16 -0600 Message-ID: <8736n4ndav.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Use-display-graphic-p-in-more-cases.patch X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::532 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >From b760955517f9c39b13353bdf5ae49f25fbadc66f Mon Sep 17 00:00:00 2001 From: Alexander Gramiak Date: Sat, 30 Mar 2019 16:53:11 -0600 Subject: [PATCH] Use display-graphic-p in more cases Also, flip the logic so that adding new graphical window systems does not need to touch as much code. * lisp/frame.el: * lisp/disp-table.el: * lisp/faces.el: Use display-graphic-p instead of explicit memq calls. * lisp/info.el (Info-fontify-node): * lisp/window.el (handle-select-window): Flip logic of memq. * lisp/simple.el (normal-erase-is-backspace-setup-frame): * lisp/emulation/cua-base.el (cua--init-keymaps): Simplify window-system checks. --- lisp/disp-table.el | 8 +++--- lisp/emulation/cua-base.el | 2 +- lisp/faces.el | 20 ++++++------- lisp/frame.el | 59 ++++++++++++++++---------------------- lisp/info.el | 2 +- lisp/simple.el | 4 +-- lisp/window.el | 2 +- 7 files changed, 43 insertions(+), 54 deletions(-) diff --git a/lisp/disp-table.el b/lisp/disp-table.el index 476c0cb986..a3e8892c51 100644 --- a/lisp/disp-table.el +++ b/lisp/disp-table.el @@ -176,7 +176,7 @@ standard-display-g1 "Display character C as character SC in the g1 character set. This function assumes that your terminal uses the SO/SI characters; it is meaningless for an X frame." - (if (memq window-system '(x w32 ns)) + (if (display-graphic-p) (error "Cannot use string glyphs in a windowing system")) (or standard-display-table (setq standard-display-table (make-display-table))) @@ -188,7 +188,7 @@ standard-display-graphic "Display character C as character GC in graphics character set. This function assumes VT100-compatible escapes; it is meaningless for an X frame." - (if (memq window-system '(x w32 ns)) + (if (display-graphic-p) (error "Cannot use string glyphs in a windowing system")) (or standard-display-table (setq standard-display-table (make-display-table))) @@ -276,7 +276,7 @@ standard-display-european (progn (standard-display-default (unibyte-char-to-multibyte 160) (unibyte-char-to-multibyte 255)) - (unless (or (memq window-system '(x w32 ns))) + (unless (display-graphic-p) (and (terminal-coding-system) (set-terminal-coding-system nil)))) @@ -289,7 +289,7 @@ standard-display-european ;; unless some other has been specified. (if (equal current-language-environment "English") (set-language-environment "latin-1")) - (unless (or noninteractive (memq window-system '(x w32 ns))) + (unless (or noninteractive (display-graphic-p)) ;; Send those codes literally to a character-based terminal. ;; If we are using single-byte characters, ;; it doesn't matter which coding system we use. diff --git a/lisp/emulation/cua-base.el b/lisp/emulation/cua-base.el index 302ef12386..461c4ea9aa 100644 --- a/lisp/emulation/cua-base.el +++ b/lisp/emulation/cua-base.el @@ -1238,7 +1238,7 @@ cua--init-keymaps ;; Cache actual rectangle modifier key. (setq cua--rectangle-modifier-key (if (and cua-rectangle-modifier-key - (memq window-system '(x))) + (eq window-system 'x)) cua-rectangle-modifier-key 'meta)) ;; C-return always toggles rectangle mark diff --git a/lisp/faces.el b/lisp/faces.el index ab6c384c80..fa526c3506 100644 --- a/lisp/faces.el +++ b/lisp/faces.el @@ -55,6 +55,7 @@ term-file-aliases :group 'terminals :version "25.1") +(declare-function display-graphic-p "frame" (&optional display)) (declare-function xw-defined-colors "term/common-win" (&optional frame)) (defvar help-xref-stack-item) @@ -1239,7 +1240,7 @@ read-face-attribute ;; explicitly in VALID, using color approximation code ;; in tty-colors.el. (when (and (memq attribute '(:foreground :background)) - (not (memq (window-system frame) '(x w32 ns))) + (not (display-graphic-p frame)) (not (member new-value '("unspecified" "unspecified-fg" "unspecified-bg")))) @@ -1833,7 +1834,7 @@ defined-colors The value may be different for frames on different display types. If FRAME doesn't support colors, the value is nil. If FRAME is nil, that stands for the selected frame." - (if (memq (framep (or frame (selected-frame))) '(x w32 ns)) + (if (display-graphic-p frame) (xw-defined-colors frame) (mapcar 'car (tty-color-alist frame)))) (defalias 'x-defined-colors 'defined-colors) @@ -1877,7 +1878,7 @@ color-defined-p If FRAME is omitted or nil, use the selected frame." (unless (member color '(unspecified "unspecified-bg" "unspecified-fg")) - (if (member (framep (or frame (selected-frame))) '(x w32 ns)) + (if (display-graphic-p frame) (xw-color-defined-p color frame) (numberp (tty-color-translate color frame))))) (defalias 'x-color-defined-p 'color-defined-p) @@ -1903,7 +1904,7 @@ color-values (cond ((member color '(unspecified "unspecified-fg" "unspecified-bg")) nil) - ((memq (framep (or frame (selected-frame))) '(x w32 ns)) + ((display-graphic-p frame) (xw-color-values color frame)) (t (tty-color-values color frame)))) @@ -1917,7 +1918,7 @@ display-color-p The optional argument DISPLAY specifies which display to ask about. DISPLAY should be either a frame or a display name (a string). If omitted or nil, that stands for the selected frame's display." - (if (memq (framep-on-display display) '(x w32 ns)) + (if (display-graphic-p display) (xw-display-color-p display) (tty-display-color-p display))) (defalias 'x-display-color-p 'display-color-p) @@ -1928,12 +1929,9 @@ display-grayscale-p "Return non-nil if frames on DISPLAY can display shades of gray. DISPLAY should be either a frame or a display name (a string). If omitted or nil, that stands for the selected frame's display." - (let ((frame-type (framep-on-display display))) - (cond - ((memq frame-type '(x w32 ns)) - (x-display-grayscale-p display)) - (t - (> (tty-color-gray-shades display) 2))))) + (if (display-graphic-p display) + (x-display-grayscale-p display) + (> (tty-color-gray-shades display) 2))) (defun read-color (&optional prompt convert-to-RGB allow-empty-name msg) "Read a color name or RGB triplet. diff --git a/lisp/frame.el b/lisp/frame.el index 6cb1247372..f5ad3152a0 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -974,7 +974,7 @@ select-frame-set-input-focus (select-frame frame norecord) (raise-frame frame) ;; Ensure, if possible, that FRAME gets input focus. - (when (memq (window-system frame) '(x w32 ns)) + (when (display-graphic-p frame) (x-focus-frame frame)) ;; Move mouse cursor if necessary. (cond @@ -1027,11 +1027,11 @@ suspend-frame "Do whatever is right to suspend the current frame. Calls `suspend-emacs' if invoked from the controlling tty device, `suspend-tty' from a secondary tty device, and -`iconify-or-deiconify-frame' from an X frame." +`iconify-or-deiconify-frame' from a graphical frame." (interactive) (let ((type (framep (selected-frame)))) (cond - ((memq type '(x ns w32)) (iconify-or-deiconify-frame)) + ((display-graphic-p display) (iconify-or-deiconify-frame)) ((eq type t) (if (controlling-tty-p) (suspend-emacs) @@ -1895,7 +1895,7 @@ display-graphic-p that use a window system such as X, and false for text-only terminals. DISPLAY can be a display name, a frame, or nil (meaning the selected frame's display)." - (not (null (memq (framep-on-display display) '(x w32 ns))))) + (not (memq (framep-on-display display) '(nil t pc)))) (defun display-images-p (&optional display) "Return non-nil if DISPLAY can display images. @@ -1933,12 +1933,9 @@ display-screens "Return the number of screens associated with DISPLAY. DISPLAY should be either a frame or a display name (a string). If DISPLAY is omitted or nil, it defaults to the selected frame's display." - (let ((frame-type (framep-on-display display))) - (cond - ((memq frame-type '(x w32 ns)) - (x-display-screens display)) - (t - 1)))) + (if (display-graphic-p display) + (x-display-screens display) + 1)) (declare-function x-display-pixel-height "xfns.c" (&optional terminal)) @@ -1953,12 +1950,9 @@ display-pixel-height refers to the pixel height for all physical monitors associated with DISPLAY. To get information for each physical monitor, use `display-monitor-attributes-list'." - (let ((frame-type (framep-on-display display))) - (cond - ((memq frame-type '(x w32 ns)) - (x-display-pixel-height display)) - (t - (frame-height (if (framep display) display (selected-frame))))))) + (if (display-graphic-p display) + (x-display-pixel-height display) + (frame-height (if (framep display) display (selected-frame))))) (declare-function x-display-pixel-width "xfns.c" (&optional terminal)) @@ -1973,12 +1967,9 @@ display-pixel-width refers to the pixel width for all physical monitors associated with DISPLAY. To get information for each physical monitor, use `display-monitor-attributes-list'." - (let ((frame-type (framep-on-display display))) - (cond - ((memq frame-type '(x w32 ns)) - (x-display-pixel-width display)) - (t - (frame-width (if (framep display) display (selected-frame))))))) + (if (display-graphic-p display) + (x-display-pixel-width display) + (frame-width (if (framep display) display (selected-frame))))) (defcustom display-mm-dimensions-alist nil "Alist for specifying screen dimensions in millimeters. @@ -2013,7 +2004,7 @@ display-mm-height refers to the height in millimeters for all physical monitors associated with DISPLAY. To get information for each physical monitor, use `display-monitor-attributes-list'." - (and (memq (framep-on-display display) '(x w32 ns)) + (and (display-graphic-p display) (or (cddr (assoc (or display (frame-parameter nil 'display)) display-mm-dimensions-alist)) (cddr (assoc t display-mm-dimensions-alist)) @@ -2034,7 +2025,7 @@ display-mm-width refers to the width in millimeters for all physical monitors associated with DISPLAY. To get information for each physical monitor, use `display-monitor-attributes-list'." - (and (memq (framep-on-display display) '(x w32 ns)) + (and (display-graphic-p display) (or (cadr (assoc (or display (frame-parameter nil 'display)) display-mm-dimensions-alist)) (cadr (assoc t display-mm-dimensions-alist)) @@ -2078,12 +2069,12 @@ display-planes If DISPLAY is omitted or nil, it defaults to the selected frame's display." (let ((frame-type (framep-on-display display))) (cond - ((memq frame-type '(x w32 ns)) - (x-display-planes display)) ((eq frame-type 'pc) 4) + ((memq frame-type '(nil t)) + (truncate (log (length (tty-color-alist)) 2))) (t - (truncate (log (length (tty-color-alist)) 2)))))) + (x-display-planes display))))) (declare-function x-display-color-cells "xfns.c" (&optional terminal)) @@ -2093,12 +2084,12 @@ display-color-cells If DISPLAY is omitted or nil, it defaults to the selected frame's display." (let ((frame-type (framep-on-display display))) (cond - ((memq frame-type '(x w32 ns)) - (x-display-color-cells display)) ((eq frame-type 'pc) 16) + ((memq frame-type '(nil t)) + (tty-display-color-cells display)) (t - (tty-display-color-cells display))))) + (x-display-color-cells display))))) (declare-function x-display-visual-class "xfns.c" (&optional terminal)) @@ -2110,13 +2101,13 @@ display-visual-class If DISPLAY is omitted or nil, it defaults to the selected frame's display." (let ((frame-type (framep-on-display display))) (cond - ((memq frame-type '(x w32 ns)) - (x-display-visual-class display)) + ((not frame-type) + 'static-gray) ((and (memq frame-type '(pc t)) (tty-display-color-p display)) 'static-color) (t - 'static-gray)))) + (x-display-visual-class display))))) (declare-function x-display-monitor-attributes-list "xfns.c" (&optional terminal)) @@ -2546,7 +2537,7 @@ blink-cursor-mode :init-value (not (or noninteractive no-blinking-cursor (eq system-type 'ms-dos) - (not (memq window-system '(x w32 ns))))) + (not (display-graphic-p)))) :initialize 'custom-initialize-delay :group 'cursor :global t diff --git a/lisp/info.el b/lisp/info.el index f2a064abb6..4954916969 100644 --- a/lisp/info.el +++ b/lisp/info.el @@ -4768,7 +4768,7 @@ Info-fontify-node ;; This is a serious problem for trying to handle multiple ;; frame types at once. We want this text to be invisible ;; on frames that can display the font above. - (when (memq (framep (selected-frame)) '(x pc w32 ns)) + (unless (memq (framep (selected-frame)) '(nil t)) (add-text-properties (1- (match-beginning 2)) (match-end 2) '(invisible t front-sticky nil rear-nonsticky t)))))) diff --git a/lisp/simple.el b/lisp/simple.el index f76f31ad14..6651ee2fc5 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -8682,7 +8682,7 @@ normal-erase-is-backspace-setup-frame (and (not noninteractive) (or (memq system-type '(ms-dos windows-nt)) (memq window-system '(w32 ns)) - (and (memq window-system '(x)) + (and (eq window-system 'x) (fboundp 'x-backspace-delete-keys-p) (x-backspace-delete-keys-p)) ;; If the terminal Emacs is running on has erase char @@ -8728,7 +8728,7 @@ normal-erase-is-backspace-mode (let ((enabled (eq 1 (terminal-parameter nil 'normal-erase-is-backspace)))) - (cond ((or (memq window-system '(x w32 ns pc)) + (cond ((or window-system (memq system-type '(ms-dos windows-nt))) (let ((bindings '(([M-delete] [M-backspace]) diff --git a/lisp/window.el b/lisp/window.el index b769be0633..b622debd51 100644 --- a/lisp/window.el +++ b/lisp/window.el @@ -9351,7 +9351,7 @@ handle-select-window ;; we might get two windows with an active cursor. (select-window window) (cond - ((or (not (memq (window-system frame) '(x w32 ns))) + ((or (memq (window-system frame) '(nil t pc)) (not focus-follows-mouse) ;; Focus FRAME if it's either a child frame or an ancestor ;; of the frame switched from. -- 2.21.0 From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Mar 2019 12:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alex Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.155403636419946 (code B ref 35058); Sun, 31 Mar 2019 12:47:01 +0000 Received: (at 35058) by debbugs.gnu.org; 31 Mar 2019 12:46:04 +0000 Received: from localhost ([127.0.0.1]:37839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAZqe-0005Be-2F for submit@debbugs.gnu.org; Sun, 31 Mar 2019 08:46:04 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:35713) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAZqZ-0005An-Ab for 35058@debbugs.gnu.org; Sun, 31 Mar 2019 08:46:02 -0400 Received: by mail-ed1-f66.google.com with SMTP id s39so5792633edb.2 for <35058@debbugs.gnu.org>; Sun, 31 Mar 2019 05:45:59 -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=N81TmQ67MxCSUMEQOTk0mgAuPnA5nor5eEwbSkmCu+Y=; b=c+D/jausst30kADJBwn+jhMpDeV4vn8HIB1YgwJbS4edKwHf3Qm+iN/Hku0bkPtjWs 30OnrQtnmbxQ0NznhvLkefWzB9E/gCYAzzqnH29Rj7ffCSYROEpR8iKN19F2TD7cfI7G PGy+mzT9syYfpV6lBkF74KDHuXhpweoGdoHu5xjaruS2P0LVp/MjuFPBpjBP8TtTp76Q O8xz2jMoK8/es4hvTrm4UWkyGz/POZmM5r/Lh4iPWV8k2Lo2lDrpk9E3AmFqHTRazlyU xXTpKpicaS8XWUiWtFoiBd4izgRu+ciFDmZXQsbkhxDX/8MBDQeXIXm0aPN8fvC9e4Es 7oaQ== 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=N81TmQ67MxCSUMEQOTk0mgAuPnA5nor5eEwbSkmCu+Y=; b=CfRMTnV+mF//dBc5qTue7n7vApkambHWA13XUwJOJ+/Mtg3wfXTKgeFGgcxxbpplBm sg2TAwQY4kYlVsuNra+ZSDGWYnQpHeesEztNjbR01iGLr4A52lixv9XqB3t81BwyLmAN qRidn+m6HIb2nB4LSl4hrpxCpvIWQxB88eAAiFMLj2QB/SozI+PFxB+zdQLdYa/uzSqX gSB8xpVqXgcJfPfzmS10Vc/JE1Wxhc4JU8TkIDKBN67SxrnBn/6puluU9Svmu6qXhvnz 04bsxSjd31cOFe3XDhhpwejxkJWX9wzE/LI0mlTxwdLgDkFYLftIS1yQEMAXZ9InLxhZ gN9A== X-Gm-Message-State: APjAAAVEf9qWVK38oTG3OmnvnGpIy1yXAuaKf/cWAsibIGPEyGeW2jDD r9YpohDWxStCWn20V/eqdQ295A== X-Google-Smtp-Source: APXvYqx9araCctDoL26S6ljDPGaJuseZC2slowafOq/vx9ECwUjyTdMKdYwpdCQthusSi3YmSUmOUg== X-Received: by 2002:a50:e610:: with SMTP id y16mr4742837edm.67.1554036353663; Sun, 31 Mar 2019 05:45:53 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:f786:805d:f4ab:1006]) by smtp.gmail.com with ESMTPSA id br19sm1344576ejb.48.2019.03.31.05.45.52 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sun, 31 Mar 2019 05:45:52 -0700 (PDT) From: "Basil L. Contovounesios" References: <8736n4ndav.fsf@gmail.com> Date: Sun, 31 Mar 2019 13:45:50 +0100 In-Reply-To: <8736n4ndav.fsf@gmail.com> (Alex's message of "Sat, 30 Mar 2019 17:38:16 -0600") Message-ID: <87k1gf9pq9.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Just a minor comment from me. Alex writes: > diff --git a/lisp/frame.el b/lisp/frame.el > index 6cb1247372..f5ad3152a0 100644 > --- a/lisp/frame.el > +++ b/lisp/frame.el > @@ -2078,12 +2069,12 @@ display-planes > If DISPLAY is omitted or nil, it defaults to the selected frame's display." > (let ((frame-type (framep-on-display display))) > (cond > - ((memq frame-type '(x w32 ns)) > - (x-display-planes display)) > ((eq frame-type 'pc) > 4) > + ((memq frame-type '(nil t)) > + (truncate (log (length (tty-color-alist)) 2))) > (t > - (truncate (log (length (tty-color-alist)) 2)))))) > + (x-display-planes display))))) > > (declare-function x-display-color-cells "xfns.c" (&optional terminal)) I suggest also changing (truncate (log (length (tty-color-alist)) 2)) to (logb (length (tty-color-alist))). Thanks, -- Basil From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Mar 2019 15:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alex Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.155404668019576 (code B ref 35058); Sun, 31 Mar 2019 15:38:01 +0000 Received: (at 35058) by debbugs.gnu.org; 31 Mar 2019 15:38:00 +0000 Received: from localhost ([127.0.0.1]:38418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAcX1-00055f-RI for submit@debbugs.gnu.org; Sun, 31 Mar 2019 11:38:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43581) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAcX0-00055S-7c for 35058@debbugs.gnu.org; Sun, 31 Mar 2019 11:37:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hAcWv-0006Bj-04; Sun, 31 Mar 2019 11:37:53 -0400 Received: from [176.228.60.248] (port=4568 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hAcWt-0004vK-Op; Sun, 31 Mar 2019 11:37:52 -0400 Date: Sun, 31 Mar 2019 18:37:57 +0300 Message-Id: <83tvfjgilm.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <8736n4ndav.fsf@gmail.com> (message from Alex on Sat, 30 Mar 2019 17:38:16 -0600) References: <8736n4ndav.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Alex > Date: Sat, 30 Mar 2019 17:38:16 -0600 > > >From b760955517f9c39b13353bdf5ae49f25fbadc66f Mon Sep 17 00:00:00 2001 > From: Alexander Gramiak > Date: Sat, 30 Mar 2019 16:53:11 -0600 > Subject: [PATCH] Use display-graphic-p in more cases Thanks for working on this. In general, most places where we don't use display-graphic-p do that for a reason, see the comments below. The general idea of display-graphic-p and other similar predicates and low-level APIs is that they hide these details from the callers, and their names explain themselves. This is why we have several predicates whose implementation is almost identical: each one of them is supposed to provide a test for a different kind of functionalities, even if currently the same frame types return non-nil from all of these predicates. The point is to allow easier changes in the future when additional frame types acquire capabilities they don't have today. We already had such episodes with the mouse and menus. But some of the places you found can indeed use display-graphic-p nowadays. > diff --git a/lisp/disp-table.el b/lisp/disp-table.el > index 476c0cb986..a3e8892c51 100644 > --- a/lisp/disp-table.el > +++ b/lisp/disp-table.el > @@ -176,7 +176,7 @@ standard-display-g1 > "Display character C as character SC in the g1 character set. > This function assumes that your terminal uses the SO/SI characters; > it is meaningless for an X frame." > - (if (memq window-system '(x w32 ns)) > + (if (display-graphic-p) > (error "Cannot use string glyphs in a windowing system")) > (or standard-display-table > (setq standard-display-table (make-display-table))) > @@ -188,7 +188,7 @@ standard-display-graphic > "Display character C as character GC in graphics character set. > This function assumes VT100-compatible escapes; it is meaningless for an > X frame." > - (if (memq window-system '(x w32 ns)) > + (if (display-graphic-p) > (error "Cannot use string glyphs in a windowing system")) > (or standard-display-table > (setq standard-display-table (make-display-table))) > @@ -276,7 +276,7 @@ standard-display-european > (progn > (standard-display-default > (unibyte-char-to-multibyte 160) (unibyte-char-to-multibyte 255)) > - (unless (or (memq window-system '(x w32 ns))) > + (unless (display-graphic-p) > (and (terminal-coding-system) > (set-terminal-coding-system nil)))) > > @@ -289,7 +289,7 @@ standard-display-european > ;; unless some other has been specified. > (if (equal current-language-environment "English") > (set-language-environment "latin-1")) > - (unless (or noninteractive (memq window-system '(x w32 ns))) > + (unless (or noninteractive (display-graphic-p)) > ;; Send those codes literally to a character-based terminal. > ;; If we are using single-byte characters, > ;; it doesn't matter which coding system we use. This part is fine by me. > diff --git a/lisp/emulation/cua-base.el b/lisp/emulation/cua-base.el > index 302ef12386..461c4ea9aa 100644 > --- a/lisp/emulation/cua-base.el > +++ b/lisp/emulation/cua-base.el > @@ -1238,7 +1238,7 @@ cua--init-keymaps > ;; Cache actual rectangle modifier key. > (setq cua--rectangle-modifier-key > (if (and cua-rectangle-modifier-key > - (memq window-system '(x))) > + (eq window-system 'x)) > cua-rectangle-modifier-key > 'meta)) > ;; C-return always toggles rectangle mark Not sure about this one: what does a modifier key have to do with GUI display? > diff --git a/lisp/faces.el b/lisp/faces.el > index ab6c384c80..fa526c3506 100644 > --- a/lisp/faces.el > +++ b/lisp/faces.el > @@ -55,6 +55,7 @@ term-file-aliases > :group 'terminals > :version "25.1") > > +(declare-function display-graphic-p "frame" (&optional display)) > (declare-function xw-defined-colors "term/common-win" (&optional frame)) > > (defvar help-xref-stack-item) > @@ -1239,7 +1240,7 @@ read-face-attribute > ;; explicitly in VALID, using color approximation code > ;; in tty-colors.el. > (when (and (memq attribute '(:foreground :background)) > - (not (memq (window-system frame) '(x w32 ns))) > + (not (display-graphic-p frame)) > (not (member new-value > '("unspecified" > "unspecified-fg" "unspecified-bg")))) > @@ -1833,7 +1834,7 @@ defined-colors > The value may be different for frames on different display types. > If FRAME doesn't support colors, the value is nil. > If FRAME is nil, that stands for the selected frame." > - (if (memq (framep (or frame (selected-frame))) '(x w32 ns)) > + (if (display-graphic-p frame) > (xw-defined-colors frame) > (mapcar 'car (tty-color-alist frame)))) > (defalias 'x-defined-colors 'defined-colors) > @@ -1877,7 +1878,7 @@ color-defined-p > > If FRAME is omitted or nil, use the selected frame." > (unless (member color '(unspecified "unspecified-bg" "unspecified-fg")) > - (if (member (framep (or frame (selected-frame))) '(x w32 ns)) > + (if (display-graphic-p frame) > (xw-color-defined-p color frame) > (numberp (tty-color-translate color frame))))) > (defalias 'x-color-defined-p 'color-defined-p) > @@ -1903,7 +1904,7 @@ color-values > (cond > ((member color '(unspecified "unspecified-fg" "unspecified-bg")) > nil) > - ((memq (framep (or frame (selected-frame))) '(x w32 ns)) > + ((display-graphic-p frame) > (xw-color-values color frame)) > (t > (tty-color-values color frame)))) > @@ -1917,7 +1918,7 @@ display-color-p > The optional argument DISPLAY specifies which display to ask about. > DISPLAY should be either a frame or a display name (a string). > If omitted or nil, that stands for the selected frame's display." > - (if (memq (framep-on-display display) '(x w32 ns)) > + (if (display-graphic-p display) > (xw-display-color-p display) > (tty-display-color-p display))) > (defalias 'x-display-color-p 'display-color-p) > @@ -1928,12 +1929,9 @@ display-grayscale-p > "Return non-nil if frames on DISPLAY can display shades of gray. > DISPLAY should be either a frame or a display name (a string). > If omitted or nil, that stands for the selected frame's display." > - (let ((frame-type (framep-on-display display))) > - (cond > - ((memq frame-type '(x w32 ns)) > - (x-display-grayscale-p display)) > - (t > - (> (tty-color-gray-shades display) 2))))) > + (if (display-graphic-p display) > + (x-display-grayscale-p display) > + (> (tty-color-gray-shades display) 2))) > > (defun read-color (&optional prompt convert-to-RGB allow-empty-name msg) > "Read a color name or RGB triplet. These are okay, I think. > diff --git a/lisp/frame.el b/lisp/frame.el > index 6cb1247372..f5ad3152a0 100644 > --- a/lisp/frame.el > +++ b/lisp/frame.el > @@ -974,7 +974,7 @@ select-frame-set-input-focus > (select-frame frame norecord) > (raise-frame frame) > ;; Ensure, if possible, that FRAME gets input focus. > - (when (memq (window-system frame) '(x w32 ns)) > + (when (display-graphic-p frame) > (x-focus-frame frame)) I don't see what display being GUI have to do with frame focus redirection. > @@ -1027,11 +1027,11 @@ suspend-frame > "Do whatever is right to suspend the current frame. > Calls `suspend-emacs' if invoked from the controlling tty device, > `suspend-tty' from a secondary tty device, and > -`iconify-or-deiconify-frame' from an X frame." > +`iconify-or-deiconify-frame' from a graphical frame." > (interactive) > (let ((type (framep (selected-frame)))) > (cond > - ((memq type '(x ns w32)) (iconify-or-deiconify-frame)) > + ((display-graphic-p display) (iconify-or-deiconify-frame)) > ((eq type t) > (if (controlling-tty-p) > (suspend-emacs) Likewise here: there's no reason apriori for any logical relation to exist between GUI display and iconifying/deiconifying a frame. > @@ -1895,7 +1895,7 @@ display-graphic-p > that use a window system such as X, and false for text-only terminals. > DISPLAY can be a display name, a frame, or nil (meaning the selected > frame's display)." > - (not (null (memq (framep-on-display display) '(x w32 ns))))) > + (not (memq (framep-on-display display) '(nil t pc)))) I prefer the current variant, as it shows the frame types explicitly. Doing that for frames that are NOT something means people will have problems looking up these dependencies when they need to. > (defun display-images-p (&optional display) > "Return non-nil if DISPLAY can display images. > @@ -1933,12 +1933,9 @@ display-screens > "Return the number of screens associated with DISPLAY. > DISPLAY should be either a frame or a display name (a string). > If DISPLAY is omitted or nil, it defaults to the selected frame's display." > - (let ((frame-type (framep-on-display display))) > - (cond > - ((memq frame-type '(x w32 ns)) > - (x-display-screens display)) > - (t > - 1)))) > + (if (display-graphic-p display) > + (x-display-screens display) > + 1)) > > (declare-function x-display-pixel-height "xfns.c" (&optional terminal)) > > @@ -1953,12 +1950,9 @@ display-pixel-height > refers to the pixel height for all physical monitors associated > with DISPLAY. To get information for each physical monitor, use > `display-monitor-attributes-list'." > - (let ((frame-type (framep-on-display display))) > - (cond > - ((memq frame-type '(x w32 ns)) > - (x-display-pixel-height display)) > - (t > - (frame-height (if (framep display) display (selected-frame))))))) > + (if (display-graphic-p display) > + (x-display-pixel-height display) > + (frame-height (if (framep display) display (selected-frame))))) > > (declare-function x-display-pixel-width "xfns.c" (&optional terminal)) > > @@ -1973,12 +1967,9 @@ display-pixel-width > refers to the pixel width for all physical monitors associated > with DISPLAY. To get information for each physical monitor, use > `display-monitor-attributes-list'." > - (let ((frame-type (framep-on-display display))) > - (cond > - ((memq frame-type '(x w32 ns)) > - (x-display-pixel-width display)) > - (t > - (frame-width (if (framep display) display (selected-frame))))))) > + (if (display-graphic-p display) > + (x-display-pixel-width display) > + (frame-width (if (framep display) display (selected-frame))))) > > (defcustom display-mm-dimensions-alist nil > "Alist for specifying screen dimensions in millimeters. > @@ -2013,7 +2004,7 @@ display-mm-height > refers to the height in millimeters for all physical monitors > associated with DISPLAY. To get information for each physical > monitor, use `display-monitor-attributes-list'." > - (and (memq (framep-on-display display) '(x w32 ns)) > + (and (display-graphic-p display) > (or (cddr (assoc (or display (frame-parameter nil 'display)) > display-mm-dimensions-alist)) > (cddr (assoc t display-mm-dimensions-alist)) > @@ -2034,7 +2025,7 @@ display-mm-width > refers to the width in millimeters for all physical monitors > associated with DISPLAY. To get information for each physical > monitor, use `display-monitor-attributes-list'." > - (and (memq (framep-on-display display) '(x w32 ns)) > + (and (display-graphic-p display) > (or (cadr (assoc (or display (frame-parameter nil 'display)) > display-mm-dimensions-alist)) > (cadr (assoc t display-mm-dimensions-alist)) > @@ -2078,12 +2069,12 @@ display-planes > If DISPLAY is omitted or nil, it defaults to the selected frame's display." > (let ((frame-type (framep-on-display display))) > (cond > - ((memq frame-type '(x w32 ns)) > - (x-display-planes display)) > ((eq frame-type 'pc) > 4) > + ((memq frame-type '(nil t)) > + (truncate (log (length (tty-color-alist)) 2))) > (t > - (truncate (log (length (tty-color-alist)) 2)))))) > + (x-display-planes display))))) > > (declare-function x-display-color-cells "xfns.c" (&optional terminal)) > > @@ -2093,12 +2084,12 @@ display-color-cells > If DISPLAY is omitted or nil, it defaults to the selected frame's display." > (let ((frame-type (framep-on-display display))) > (cond > - ((memq frame-type '(x w32 ns)) > - (x-display-color-cells display)) > ((eq frame-type 'pc) > 16) > + ((memq frame-type '(nil t)) > + (tty-display-color-cells display)) > (t > - (tty-display-color-cells display))))) > + (x-display-color-cells display))))) > > (declare-function x-display-visual-class "xfns.c" (&optional terminal)) > > @@ -2110,13 +2101,13 @@ display-visual-class > If DISPLAY is omitted or nil, it defaults to the selected frame's display." > (let ((frame-type (framep-on-display display))) > (cond > - ((memq frame-type '(x w32 ns)) > - (x-display-visual-class display)) > + ((not frame-type) > + 'static-gray) > ((and (memq frame-type '(pc t)) > (tty-display-color-p display)) > 'static-color) > (t > - 'static-gray)))) > + (x-display-visual-class display))))) > > (declare-function x-display-monitor-attributes-list "xfns.c" > (&optional terminal)) I prefer not to change these. These APIs are the lowest level of testing for the respective features, so I prefer them to show explicitly on what types of frames we support them and how. Adding indirection through display-graphic-p doesn't help here, because these interfaces are siblings of display-graphic-p. > @@ -2546,7 +2537,7 @@ blink-cursor-mode > :init-value (not (or noninteractive > no-blinking-cursor > (eq system-type 'ms-dos) > - (not (memq window-system '(x w32 ns))))) > + (not (display-graphic-p)))) Why would we want to connect blinking cursor with GUI displays? These two are unrelated. > diff --git a/lisp/info.el b/lisp/info.el > index f2a064abb6..4954916969 100644 > --- a/lisp/info.el > +++ b/lisp/info.el > @@ -4768,7 +4768,7 @@ Info-fontify-node > ;; This is a serious problem for trying to handle multiple > ;; frame types at once. We want this text to be invisible > ;; on frames that can display the font above. > - (when (memq (framep (selected-frame)) '(x pc w32 ns)) > + (unless (memq (framep (selected-frame)) '(nil t)) > (add-text-properties (1- (match-beginning 2)) (match-end 2) > '(invisible t front-sticky nil rear-nonsticky t)))))) Not sure here, but if this about fonts, then display-multi-font-p is a better test. > diff --git a/lisp/simple.el b/lisp/simple.el > index f76f31ad14..6651ee2fc5 100644 > --- a/lisp/simple.el > +++ b/lisp/simple.el > @@ -8682,7 +8682,7 @@ normal-erase-is-backspace-setup-frame > (and (not noninteractive) > (or (memq system-type '(ms-dos windows-nt)) > (memq window-system '(w32 ns)) > - (and (memq window-system '(x)) > + (and (eq window-system 'x) > (fboundp 'x-backspace-delete-keys-p) > (x-backspace-delete-keys-p)) > ;; If the terminal Emacs is running on has erase char > @@ -8728,7 +8728,7 @@ normal-erase-is-backspace-mode > (let ((enabled (eq 1 (terminal-parameter > nil 'normal-erase-is-backspace)))) > > - (cond ((or (memq window-system '(x w32 ns pc)) > + (cond ((or window-system > (memq system-type '(ms-dos windows-nt))) > (let ((bindings > '(([M-delete] [M-backspace]) normal-erase-is-backspace-mode is entirely unrelated to display being GUI, so I don't think this is right. > diff --git a/lisp/window.el b/lisp/window.el > index b769be0633..b622debd51 100644 > --- a/lisp/window.el > +++ b/lisp/window.el > @@ -9351,7 +9351,7 @@ handle-select-window > ;; we might get two windows with an active cursor. > (select-window window) > (cond > - ((or (not (memq (window-system frame) '(x w32 ns))) > + ((or (memq (window-system frame) '(nil t pc)) > (not focus-follows-mouse) > ;; Focus FRAME if it's either a child frame or an ancestor > ;; of the frame switched from. This is again a reversion of logic which I think is a change for the worse. Thanks. From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Alex Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Apr 2019 04:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.155409214932593 (code B ref 35058); Mon, 01 Apr 2019 04:16:01 +0000 Received: (at 35058) by debbugs.gnu.org; 1 Apr 2019 04:15:49 +0000 Received: from localhost ([127.0.0.1]:38744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAoMO-0008Tc-9M for submit@debbugs.gnu.org; Mon, 01 Apr 2019 00:15:48 -0400 Received: from mail-pl1-f174.google.com ([209.85.214.174]:44914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAoML-0008TP-PK for 35058@debbugs.gnu.org; Mon, 01 Apr 2019 00:15:46 -0400 Received: by mail-pl1-f174.google.com with SMTP id g12so3798517pll.11 for <35058@debbugs.gnu.org>; Sun, 31 Mar 2019 21:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=/iWBnlAWHi+7/LDERHMf/GH1WODSpha9To2zpvW9L4E=; b=BYDp5Ws2uIS0jgb+Bmkil2DtfOruMEQo+HBcX1joBc/LQ81JaLkWxrIVJxDdf9eIEA BSpbcIoRvGWzun6/S474jbA2ox7qO0pFBZi1G/XTEYLWgszX0w5oipBT1jule+hlakop lQDQSsPPzvLKBbZXHRuXVZ9tjUuL/Q/MQWch3eJewOHlOxiClQtStiQxEHGxeIauPGEa p/yCSMUR3LT3JqwflzuIECDIsC9CFybwcy2res50H78+UYWjW218m5iCF61LYRMZ7Mra ROwoDHUxjJEgFFzNOJD570pWkEp/9wik/3mS8a7diuQsmGWV6m6j4HVF3D44KFSlTgyP WUoA== 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=/iWBnlAWHi+7/LDERHMf/GH1WODSpha9To2zpvW9L4E=; b=jg6rScxJhXlvXW9uYkSCGVcNahe4wdWiC1y6czC/HRtzFjaan75Qu9qh+qvIOUSSIV rhnslE0e8NAziWI1kmI3aF/w2cZ/EydEa3fSjMRsZ+XLmrSUwv21uZgXAqTnyPI1Wb0i eHAxeBMcaQ5H2brjcqtu9T9e2vVF623exEDpGhleWX0uyJ7f511DtKVSBoz2iI5jFsF6 OduP/JQXcndHuMDNKluDxXmGnnL0m/hwp9pJzKaIeMbnlR1GJjv4XPAZ+9ERhCEwTtNQ ZjvJQcp9NPoZp/KDsTpIOsjgsH7hoMGsI9BtKMpWY9AFJaCDtgDd3r9z7WysCiyOaVwX AhqQ== X-Gm-Message-State: APjAAAWrELWLU5NCx1XGMYoWQ5Sd9rOXUd9Tt82vvTGCwvvZSkEf62X0 K4jbsoJ52iTuZwobDvm+zgyRLroW X-Google-Smtp-Source: APXvYqw25EXqAlGF9wT29WI5Lb0NSSH6ly+4Nqn5o/Q5QDJFlRiUVKCDHYVg5rznfIGBLfBKZeQb/A== X-Received: by 2002:a17:902:7794:: with SMTP id o20mr15410070pll.189.1554092139365; Sun, 31 Mar 2019 21:15:39 -0700 (PDT) Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id i126sm12173603pfb.15.2019.03.31.21.15.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 31 Mar 2019 21:15:38 -0700 (PDT) From: Alex References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> Date: Sun, 31 Mar 2019 22:15:35 -0600 In-Reply-To: <83tvfjgilm.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 31 Mar 2019 18:37:57 +0300") Message-ID: <875zry9x94.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> diff --git a/lisp/emulation/cua-base.el b/lisp/emulation/cua-base.el >> index 302ef12386..461c4ea9aa 100644 >> --- a/lisp/emulation/cua-base.el >> +++ b/lisp/emulation/cua-base.el >> @@ -1238,7 +1238,7 @@ cua--init-keymaps >> ;; Cache actual rectangle modifier key. >> (setq cua--rectangle-modifier-key >> (if (and cua-rectangle-modifier-key >> - (memq window-system '(x))) >> + (eq window-system 'x)) >> cua-rectangle-modifier-key >> 'meta)) >> ;; C-return always toggles rectangle mark > > Not sure about this one: what does a modifier key have to do with GUI > display? I wasn't sure either (I merely noticed the useless memq), but I just checked the documentation of cua-rectangle-modifier-key, which states: On non-window systems, always use the meta modifier. So I changed the eq call to display-graphics-p. Is it okay to follow the docstring here? >> diff --git a/lisp/frame.el b/lisp/frame.el >> index 6cb1247372..f5ad3152a0 100644 >> --- a/lisp/frame.el >> +++ b/lisp/frame.el >> @@ -974,7 +974,7 @@ select-frame-set-input-focus >> (select-frame frame norecord) >> (raise-frame frame) >> ;; Ensure, if possible, that FRAME gets input focus. >> - (when (memq (window-system frame) '(x w32 ns)) >> + (when (display-graphic-p frame) >> (x-focus-frame frame)) > > I don't see what display being GUI have to do with frame focus > redirection. The x-focus-frame here is the GUI-specific code related to frame focus that calls x_focus_frame, which is only defined when HAVE_WINDOW_SYSTEM is defined. This is one of the procedures that I'm planning to rename with a gui prefix, so I believe display-graphic-p makes sense here. >> @@ -1027,11 +1027,11 @@ suspend-frame >> "Do whatever is right to suspend the current frame. >> Calls `suspend-emacs' if invoked from the controlling tty device, >> `suspend-tty' from a secondary tty device, and >> -`iconify-or-deiconify-frame' from an X frame." >> +`iconify-or-deiconify-frame' from a graphical frame." >> (interactive) >> (let ((type (framep (selected-frame)))) >> (cond >> - ((memq type '(x ns w32)) (iconify-or-deiconify-frame)) >> + ((display-graphic-p display) (iconify-or-deiconify-frame)) >> ((eq type t) >> (if (controlling-tty-p) >> (suspend-emacs) > > Likewise here: there's no reason apriori for any logical relation to > exist between GUI display and iconifying/deiconifying a frame. What would (de)iconifying be in non-GUI displays? If there is indeed no logical relation, then what about a new display-iconifiable-p that is made an alias? >> @@ -1895,7 +1895,7 @@ display-graphic-p >> that use a window system such as X, and false for text-only terminals. >> DISPLAY can be a display name, a frame, or nil (meaning the selected >> frame's display)." >> - (not (null (memq (framep-on-display display) '(x w32 ns))))) >> + (not (memq (framep-on-display display) '(nil t pc)))) > > I prefer the current variant, as it shows the frame types explicitly. > Doing that for frames that are NOT something means people will have > problems looking up these dependencies when they need to. I'm not sure how much of a problem that would be if the return values of framep-on-display were listed in its docstring, but I guess it's not really an issue leaving this one alone. >> (defun display-images-p (&optional display) >> "Return non-nil if DISPLAY can display images. >> @@ -1933,12 +1933,9 @@ display-screens >> "Return the number of screens associated with DISPLAY. >> DISPLAY should be either a frame or a display name (a string). >> If DISPLAY is omitted or nil, it defaults to the selected frame's display." >> - (let ((frame-type (framep-on-display display))) >> - (cond >> - ((memq frame-type '(x w32 ns)) >> - (x-display-screens display)) >> - (t >> - 1)))) >> + (if (display-graphic-p display) >> + (x-display-screens display) >> + 1)) >> >> (declare-function x-display-pixel-height "xfns.c" (&optional terminal)) >> >> @@ -1953,12 +1950,9 @@ display-pixel-height >> refers to the pixel height for all physical monitors associated >> with DISPLAY. To get information for each physical monitor, use >> `display-monitor-attributes-list'." >> - (let ((frame-type (framep-on-display display))) >> - (cond >> - ((memq frame-type '(x w32 ns)) >> - (x-display-pixel-height display)) >> - (t >> - (frame-height (if (framep display) display (selected-frame))))))) >> + (if (display-graphic-p display) >> + (x-display-pixel-height display) >> + (frame-height (if (framep display) display (selected-frame))))) >> >> (declare-function x-display-pixel-width "xfns.c" (&optional terminal)) >> >> @@ -1973,12 +1967,9 @@ display-pixel-width >> refers to the pixel width for all physical monitors associated >> with DISPLAY. To get information for each physical monitor, use >> `display-monitor-attributes-list'." >> - (let ((frame-type (framep-on-display display))) >> - (cond >> - ((memq frame-type '(x w32 ns)) >> - (x-display-pixel-width display)) >> - (t >> - (frame-width (if (framep display) display (selected-frame))))))) >> + (if (display-graphic-p display) >> + (x-display-pixel-width display) >> + (frame-width (if (framep display) display (selected-frame))))) >> >> (defcustom display-mm-dimensions-alist nil >> "Alist for specifying screen dimensions in millimeters. >> @@ -2013,7 +2004,7 @@ display-mm-height >> refers to the height in millimeters for all physical monitors >> associated with DISPLAY. To get information for each physical >> monitor, use `display-monitor-attributes-list'." >> - (and (memq (framep-on-display display) '(x w32 ns)) >> + (and (display-graphic-p display) >> (or (cddr (assoc (or display (frame-parameter nil 'display)) >> display-mm-dimensions-alist)) >> (cddr (assoc t display-mm-dimensions-alist)) >> @@ -2034,7 +2025,7 @@ display-mm-width >> refers to the width in millimeters for all physical monitors >> associated with DISPLAY. To get information for each physical >> monitor, use `display-monitor-attributes-list'." >> - (and (memq (framep-on-display display) '(x w32 ns)) >> + (and (display-graphic-p display) >> (or (cadr (assoc (or display (frame-parameter nil 'display)) >> display-mm-dimensions-alist)) >> (cadr (assoc t display-mm-dimensions-alist)) >> @@ -2078,12 +2069,12 @@ display-planes >> If DISPLAY is omitted or nil, it defaults to the selected frame's display." >> (let ((frame-type (framep-on-display display))) >> (cond >> - ((memq frame-type '(x w32 ns)) >> - (x-display-planes display)) >> ((eq frame-type 'pc) >> 4) >> + ((memq frame-type '(nil t)) >> + (truncate (log (length (tty-color-alist)) 2))) >> (t >> - (truncate (log (length (tty-color-alist)) 2)))))) >> + (x-display-planes display))))) >> >> (declare-function x-display-color-cells "xfns.c" (&optional terminal)) >> >> @@ -2093,12 +2084,12 @@ display-color-cells >> If DISPLAY is omitted or nil, it defaults to the selected frame's display." >> (let ((frame-type (framep-on-display display))) >> (cond >> - ((memq frame-type '(x w32 ns)) >> - (x-display-color-cells display)) >> ((eq frame-type 'pc) >> 16) >> + ((memq frame-type '(nil t)) >> + (tty-display-color-cells display)) >> (t >> - (tty-display-color-cells display))))) >> + (x-display-color-cells display))))) >> >> (declare-function x-display-visual-class "xfns.c" (&optional terminal)) >> >> @@ -2110,13 +2101,13 @@ display-visual-class >> If DISPLAY is omitted or nil, it defaults to the selected frame's display." >> (let ((frame-type (framep-on-display display))) >> (cond >> - ((memq frame-type '(x w32 ns)) >> - (x-display-visual-class display)) >> + ((not frame-type) >> + 'static-gray) >> ((and (memq frame-type '(pc t)) >> (tty-display-color-p display)) >> 'static-color) >> (t >> - 'static-gray)))) >> + (x-display-visual-class display))))) >> >> (declare-function x-display-monitor-attributes-list "xfns.c" >> (&optional terminal)) > > I prefer not to change these. These APIs are the lowest level of > testing for the respective features, so I prefer them to show > explicitly on what types of frames we support them and how. Adding > indirection through display-graphic-p doesn't help here, because these > interfaces are siblings of display-graphic-p. If all graphical displays support these features currently, and if it's reasonable to presume that any new graphical display types would also support them, then I don't see why it would be a problem to use display-graphics-p in these cases. If the unexpected occurs, then there would only be a few definitions to change at most. For example, is it really wrong to presume that all graphical displays can retrieve pixel height/width? >> @@ -2546,7 +2537,7 @@ blink-cursor-mode >> :init-value (not (or noninteractive >> no-blinking-cursor >> (eq system-type 'ms-dos) >> - (not (memq window-system '(x w32 ns))))) >> + (not (display-graphic-p)))) > > Why would we want to connect blinking cursor with GUI displays? These > two are unrelated. The definition of blink-cursor mode states: This command is effective only on graphical frames. On text-only terminals, cursor blinking is controlled by the terminal." So it seems reasonable to use display-graphic-p here. >> diff --git a/lisp/info.el b/lisp/info.el >> index f2a064abb6..4954916969 100644 >> --- a/lisp/info.el >> +++ b/lisp/info.el >> @@ -4768,7 +4768,7 @@ Info-fontify-node >> ;; This is a serious problem for trying to handle multiple >> ;; frame types at once. We want this text to be invisible >> ;; on frames that can display the font above. >> - (when (memq (framep (selected-frame)) '(x pc w32 ns)) >> + (unless (memq (framep (selected-frame)) '(nil t)) >> (add-text-properties (1- (match-beginning 2)) (match-end 2) >> '(invisible t front-sticky nil rear-nonsticky t)))))) > > Not sure here, but if this about fonts, then display-multi-font-p is a > better test. Is multi-font equivalent to supporting invisible text? If so, then I'll use that and (or ... (eq window-system 'pc)). >> diff --git a/lisp/simple.el b/lisp/simple.el >> index f76f31ad14..6651ee2fc5 100644 >> --- a/lisp/simple.el >> +++ b/lisp/simple.el >> @@ -8682,7 +8682,7 @@ normal-erase-is-backspace-setup-frame >> (and (not noninteractive) >> (or (memq system-type '(ms-dos windows-nt)) >> (memq window-system '(w32 ns)) >> - (and (memq window-system '(x)) >> + (and (eq window-system 'x) >> (fboundp 'x-backspace-delete-keys-p) >> (x-backspace-delete-keys-p)) >> ;; If the terminal Emacs is running on has erase char >> @@ -8728,7 +8728,7 @@ normal-erase-is-backspace-mode >> (let ((enabled (eq 1 (terminal-parameter >> nil 'normal-erase-is-backspace)))) >> >> - (cond ((or (memq window-system '(x w32 ns pc)) >> + (cond ((or window-system >> (memq system-type '(ms-dos windows-nt))) >> (let ((bindings >> '(([M-delete] [M-backspace]) > > normal-erase-is-backspace-mode is entirely unrelated to display being > GUI, so I don't think this is right. The docstring of normal-erase-is-backspace-mode mentions window-system several times, so I don't see the issue. >> diff --git a/lisp/window.el b/lisp/window.el >> index b769be0633..b622debd51 100644 >> --- a/lisp/window.el >> +++ b/lisp/window.el >> @@ -9351,7 +9351,7 @@ handle-select-window >> ;; we might get two windows with an active cursor. >> (select-window window) >> (cond >> - ((or (not (memq (window-system frame) '(x w32 ns))) >> + ((or (memq (window-system frame) '(nil t pc)) >> (not focus-follows-mouse) >> ;; Focus FRAME if it's either a child frame or an ancestor >> ;; of the frame switched from. > > This is again a reversion of logic which I think is a change for the > worse. Would it be okay to forward-declare display-graphic-p and use it here as well? From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Apr 2019 05:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alex Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.15540961056608 (code B ref 35058); Mon, 01 Apr 2019 05:22:01 +0000 Received: (at 35058) by debbugs.gnu.org; 1 Apr 2019 05:21:45 +0000 Received: from localhost ([127.0.0.1]:38768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hApOC-0001iV-El for submit@debbugs.gnu.org; Mon, 01 Apr 2019 01:21:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41258) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hApOA-0001iI-Uy for 35058@debbugs.gnu.org; Mon, 01 Apr 2019 01:21:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hApO5-0008RU-OX; Mon, 01 Apr 2019 01:21:37 -0400 Received: from [176.228.60.248] (port=3748 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hApO5-000802-73; Mon, 01 Apr 2019 01:21:37 -0400 Date: Mon, 01 Apr 2019 08:21:46 +0300 Message-Id: <83a7hagv11.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <875zry9x94.fsf@gmail.com> (message from Alex on Sun, 31 Mar 2019 22:15:35 -0600) References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Alex > Cc: 35058@debbugs.gnu.org > Date: Sun, 31 Mar 2019 22:15:35 -0600 > > >> (if (and cua-rectangle-modifier-key > >> - (memq window-system '(x))) > >> + (eq window-system 'x)) > >> cua-rectangle-modifier-key > >> 'meta)) > >> ;; C-return always toggles rectangle mark > > > > Not sure about this one: what does a modifier key have to do with GUI > > display? > > I wasn't sure either (I merely noticed the useless memq), but I just > checked the documentation of cua-rectangle-modifier-key, which states: > > On non-window systems, always use the meta modifier. > > So I changed the eq call to display-graphics-p. Is it okay to follow the > docstring here? No, not IMO. Doc strings can change because their purpose is documentation that's useful to users and programmers, whereas the issue in hand is ease of future maintenance. Let me tell more about this. These functions were written when TTY frames were made to support faces (colors) during Emacs 21 development. When we started using Emacs 21 on TTYs, we found out that various color-related features didn't work since they were conditioned by window-system values, because someone assumed that only GUI frames can ever support colors. The easy solution was to remove the condition, but then it turned out that many other places had code conditioned on window-system which had nothing to do with colors or faces. So a simple removal was not possible; moreover, careful auditing of each and every use of window-system was needed to decide, on a per-case basis, which was and which wasn't related to faces, something that wasn't always obvious, because some conditions were added ad-hoc, to prevent code from calling functions undefined in a build --without-x. We then decided to factor all uses of window-system into several classes and replace the uses of window-system by the proper predicates whose _names_ will clearly tell what is the feature being tested. That's when these display-* functions were written, and that's why the use of window-system (the variable) was deprecated. I would like to keep using these functions according to the above logic, so that when we add support for new capabilities on non-GUI frames, we will not need to hunt for tricky conditions all over the code, not again. However, as you found out, some of the places still use window-system. At the time, they were left alone, mostly because it sounded gross to invent additional display-* functions which would have only one or two callers. We could do this now, if we consider it important to get rid of more uses of window-system or framep; I still think it would be gross, but won't object if others think otherwise. But let's not blindly use display-graphics-p to mean "anything that currently only happens on a GUI frame", because that's not what it stands for. It stands for features that can _only_ be ever true on GUI displays, and can _never_ be implemented on any text-mode frame, and only for features for which there's no other display-* function that is more focused, like display-multi-font-p. > >> diff --git a/lisp/frame.el b/lisp/frame.el > >> index 6cb1247372..f5ad3152a0 100644 > >> --- a/lisp/frame.el > >> +++ b/lisp/frame.el > >> @@ -974,7 +974,7 @@ select-frame-set-input-focus > >> (select-frame frame norecord) > >> (raise-frame frame) > >> ;; Ensure, if possible, that FRAME gets input focus. > >> - (when (memq (window-system frame) '(x w32 ns)) > >> + (when (display-graphic-p frame) > >> (x-focus-frame frame)) > > > > I don't see what display being GUI have to do with frame focus > > redirection. > > The x-focus-frame here is the GUI-specific code related to frame focus > that calls x_focus_frame, which is only defined when HAVE_WINDOW_SYSTEM > is defined. This is one of the procedures that I'm planning to rename > with a gui prefix, so I believe display-graphic-p makes sense here. See above: I could envision a feature that moves focus to a TTY frame as well, some day. > >> @@ -1027,11 +1027,11 @@ suspend-frame > >> "Do whatever is right to suspend the current frame. > >> Calls `suspend-emacs' if invoked from the controlling tty device, > >> `suspend-tty' from a secondary tty device, and > >> -`iconify-or-deiconify-frame' from an X frame." > >> +`iconify-or-deiconify-frame' from a graphical frame." > >> (interactive) > >> (let ((type (framep (selected-frame)))) > >> (cond > >> - ((memq type '(x ns w32)) (iconify-or-deiconify-frame)) > >> + ((display-graphic-p display) (iconify-or-deiconify-frame)) > >> ((eq type t) > >> (if (controlling-tty-p) > >> (suspend-emacs) > > > > Likewise here: there's no reason apriori for any logical relation to > > exist between GUI display and iconifying/deiconifying a frame. > > What would (de)iconifying be in non-GUI displays? The display (i.e. the terminal) could be a GUI one, but a frame it shows could be a TTY frame, for example if you use a terminal emulator such as xterm. We all do that all the time. > If there is indeed no logical relation, then what about a new > display-iconifiable-p that is made an alias? As I said above, I consider that slightly gross, but I won't object to introducing such functions. > > I prefer not to change these. These APIs are the lowest level of > > testing for the respective features, so I prefer them to show > > explicitly on what types of frames we support them and how. Adding > > indirection through display-graphic-p doesn't help here, because these > > interfaces are siblings of display-graphic-p. > > If all graphical displays support these features currently, and if it's > reasonable to presume that any new graphical display types would also > support them, then I don't see why it would be a problem to use > display-graphics-p in these cases. If the unexpected occurs, then there > would only be a few definitions to change at most. I hope you now understand my motivation better. IME, deciphering those "few" definitions is not really trivial, especially when they are used slightly inconsistently through the sources. Making the conditions explicit goes a small step in the direction of making that job easier. > For example, is it really wrong to presume that all graphical displays > can retrieve pixel height/width? > > >> @@ -2546,7 +2537,7 @@ blink-cursor-mode > >> :init-value (not (or noninteractive > >> no-blinking-cursor > >> (eq system-type 'ms-dos) > >> - (not (memq window-system '(x w32 ns))))) > >> + (not (display-graphic-p)))) > > > > Why would we want to connect blinking cursor with GUI displays? These > > two are unrelated. > > The definition of blink-cursor mode states: > > This command is effective only on graphical frames. On text-only > terminals, cursor blinking is controlled by the terminal." That's the _current_ situation. But what would preclude the xterm developers, say, from adding a way of controlling that? Nothing in particular, I'd say. > >> ;; This is a serious problem for trying to handle multiple > >> ;; frame types at once. We want this text to be invisible > >> ;; on frames that can display the font above. > >> - (when (memq (framep (selected-frame)) '(x pc w32 ns)) > >> + (unless (memq (framep (selected-frame)) '(nil t)) > >> (add-text-properties (1- (match-beginning 2)) (match-end 2) > >> '(invisible t front-sticky nil rear-nonsticky t)))))) > > > > Not sure here, but if this about fonts, then display-multi-font-p is a > > better test. > > Is multi-font equivalent to supporting invisible text? The comment above talks about fonts; I didn't read the code well enough to understand what it's about. Maybe display-multi-font-p is a better predicate here, not sure. > > normal-erase-is-backspace-mode is entirely unrelated to display being > > GUI, so I don't think this is right. > > The docstring of normal-erase-is-backspace-mode mentions window-system > several times, so I don't see the issue. I hope now you understand my motivation better. > >> diff --git a/lisp/window.el b/lisp/window.el > >> index b769be0633..b622debd51 100644 > >> --- a/lisp/window.el > >> +++ b/lisp/window.el > >> @@ -9351,7 +9351,7 @@ handle-select-window > >> ;; we might get two windows with an active cursor. > >> (select-window window) > >> (cond > >> - ((or (not (memq (window-system frame) '(x w32 ns))) > >> + ((or (memq (window-system frame) '(nil t pc)) > >> (not focus-follows-mouse) > >> ;; Focus FRAME if it's either a child frame or an ancestor > >> ;; of the frame switched from. > > > > This is again a reversion of logic which I think is a change for the > > worse. > > Would it be okay to forward-declare display-graphic-p and use it here as > well? Not IMO, because this is again about selection with a mouse, something that can (and is) supported on some TTY frames. We could use the hypothetical display-iconifiable-p (but we should then find a better name, something about selecting/raising frames perhaps). Thanks. From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Apr 2019 14:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii , Alex Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.15541291543346 (code B ref 35058); Mon, 01 Apr 2019 14:33:02 +0000 Received: (at 35058) by debbugs.gnu.org; 1 Apr 2019 14:32:34 +0000 Received: from localhost ([127.0.0.1]:39796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAxzG-0000rt-C0 for submit@debbugs.gnu.org; Mon, 01 Apr 2019 10:32:34 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:45974) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAxzD-0000rd-Db for 35058@debbugs.gnu.org; Mon, 01 Apr 2019 10:32:32 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x31EUoWT180264; Mon, 1 Apr 2019 14:32:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=OCX64iOvw4wg6mftBtAY4jgOFQ9xzxTlrD+f0FlUmM0=; b=FXT9LdWuvIqPynZnHxgSuwlReXdU1pjXYQz6CTP2teHOZ/0Q/gxPVzMF6JO7XUZwAgC5 C33PdrRYa0Zor2GXL+VZZTcqxhCKHGW5qFN/jeGX0U5Q++Kl+VLFNan+yh+LdfkqAKDb j05Kxtnz5yjOsyj1mqZT0afdzG00QmFdZBlS0v5ZfAJLla+Uo8xudmDiBNKJJGB2LKef lDt9TEKqAr2d8DR8e0j4gZ7R7/r50LwpCU6qPSylY0CxeAtOsmteXR5JnNgSacyLebw9 i7cq5BAv5Yn7kZ6sMNUO3cKa8MTNlZUFWZZ0hACM+Znv6OWeW4/BsTo2mg43+AE4uMWC xw== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2rhyvsye57-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 01 Apr 2019 14:32:25 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x31EWOm1017988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 1 Apr 2019 14:32:24 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x31EWOZh017699; Mon, 1 Apr 2019 14:32:24 GMT MIME-Version: 1.0 Message-ID: <558890e4-a519-48ec-8e9d-36d829a5c089@default> Date: Mon, 1 Apr 2019 07:32:23 -0700 (PDT) From: Drew Adams References: <<8736n4ndav.fsf@gmail.com>> <<83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com>> <<83a7hagv11.fsf@gnu.org>> In-Reply-To: <<83a7hagv11.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4822.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9214 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904010099 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a great description, Eli. I hope it or similar is recorded somewhere in code or code-related artifacts, not just in mail threads. It can also help users to know some of this (the rationale). That isn't so important now perhaps, as things like `display-multi-font-p' are just aliased. But it could be more important later. BTW, where would the intended meaning of such functions be recorded now? Currently their doc is just the doc of `display-graphic-p', as they are aliased. (Could/should they have their own doc strings now, even if the behavior is currently just `display-graphic-p'?) From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Alex Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Apr 2019 17:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.155422472230724 (code B ref 35058); Tue, 02 Apr 2019 17:06:01 +0000 Received: (at 35058) by debbugs.gnu.org; 2 Apr 2019 17:05:22 +0000 Received: from localhost ([127.0.0.1]:41510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBMqg-0007zU-6Y for submit@debbugs.gnu.org; Tue, 02 Apr 2019 13:05:22 -0400 Received: from mail-pg1-f170.google.com ([209.85.215.170]:46562) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBMqe-0007zH-G1 for 35058@debbugs.gnu.org; Tue, 02 Apr 2019 13:05:21 -0400 Received: by mail-pg1-f170.google.com with SMTP id q1so6861425pgv.13 for <35058@debbugs.gnu.org>; Tue, 02 Apr 2019 10:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version; bh=qSpEStvPN9xd8tstbS9uK3BtB4mAji4+YR6oRLJJaMY=; b=SPUJz5rvN2oFtdX47uY6lNs9tOWrRBUldppeTbrP3CcTUe17ocK/lnLv2Ud+Rqzifn Z0R6mtSRU3JMXntBaXaTAGmZxqSvSE9uVuWE5AJrGiw499jkIXcHGOFh5oMX15fSOwgL 5oQxOHm/ZcnrjQc/CCLucj2QBT9KeQkrx/sVYy6Qx6lNCHNKMqS3/Cz4uF/Q/VZxLl/4 u/eUm5/fXX5WtnjJ59iLHcGZRPiKCdagq4BtpVTip26ADCqF7/UmLHNt33U1f18g5IZJ mn+dx69wnjk4H9z+o3cHz4D/tcBRulM1MQu6Kika/tlAMh+jfzmBvDw0HvmLrqAOSbjM vlhQ== 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:in-reply-to:references :user-agent:date:message-id:mime-version; bh=qSpEStvPN9xd8tstbS9uK3BtB4mAji4+YR6oRLJJaMY=; b=rSzqg+pbNAjjCnIX4YwqKmGiso/3RfnzF45bn8rGYyPQH81vChYjlz9GpRwAJB0ZHV mKzXnMb652nf4lA4F4qnDuRVTwNyTTldz2atGuXgb1QRv4b4JNveLy2o/1kkUaZsrRyb j2OP4y5ZxANgEnFthuGcrRXjs8nO6zSwlVQgfSAMVX8CwcCQKf6T483RtkfmAS6qFWYr uinvd4iN4HbGywWDS+wG83qrONY/SGths68RMqaAxMN6Z0NdI66sZWRx6MSo9mNFqvOh rvO7IzV0WdGeTSp0GIlYFXKTDwzWtZeHBhFwzs8N9MyyzqARdrYuZ0mWH91Zv9fWwv6j 4IDw== X-Gm-Message-State: APjAAAWA+huZigC+9X5tbUrsoN95MQ/GcyQMGnYN6gJKkl8DWxx2iT++ ao2W2sHj79aGIcXZvlBPok6EXwj1 X-Google-Smtp-Source: APXvYqxYdg+lRisL9heNKmkBkQQNJc9/mpcOpmiSZ4aAnQXGUpCZJ88elo8TRoTbei/QUhen8Aavvg== X-Received: by 2002:a65:5ac3:: with SMTP id d3mr44709847pgt.168.1554224714288; Tue, 02 Apr 2019 10:05:14 -0700 (PDT) Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id l19sm16894197pff.1.2019.04.02.10.05.11 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 02 Apr 2019 10:05:12 -0700 (PDT) From: Alex In-Reply-To: <83a7hagv11.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 01 Apr 2019 08:21:46 +0300") References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> <83a7hagv11.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Date: Tue, 02 Apr 2019 11:05:09 -0600 Message-ID: <87d0m4pcca.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Alex >> Cc: 35058@debbugs.gnu.org >> Date: Sun, 31 Mar 2019 22:15:35 -0600 >> >> >> (if (and cua-rectangle-modifier-key >> >> - (memq window-system '(x))) >> >> + (eq window-system 'x)) >> >> cua-rectangle-modifier-key >> >> 'meta)) >> >> ;; C-return always toggles rectangle mark >> > >> > Not sure about this one: what does a modifier key have to do with GUI >> > display? >> >> I wasn't sure either (I merely noticed the useless memq), but I just >> checked the documentation of cua-rectangle-modifier-key, which states: >> >> On non-window systems, always use the meta modifier. >> >> So I changed the eq call to display-graphics-p. Is it okay to follow the >> docstring here? > > No, not IMO. Doc strings can change because their purpose is > documentation that's useful to users and programmers, whereas the > issue in hand is ease of future maintenance. Hmm, it seems that my terminal Emacs accepts the super modifier but not the hyper modifier; is this a bug in Emacs? Should I remove the window-system condition even if I can't get terminal Emacs to recognize the hyper key? > However, as you found out, some of the places still use window-system. > At the time, they were left alone, mostly because it sounded gross to > invent additional display-* functions which would have only one or two > callers. We could do this now, if we consider it important to get rid > of more uses of window-system or framep; I still think it would be > gross, but won't object if others think otherwise. But let's not > blindly use display-graphics-p to mean "anything that currently only > happens on a GUI frame", because that's not what it stands for. It > stands for features that can _only_ be ever true on GUI displays, and > can _never_ be implemented on any text-mode frame, and only for > features for which there's no other display-* function that is more > focused, like display-multi-font-p. Thanks for describing the history here. I don't think it's gross if there's only a couple callers; there could be more callers in the future and in 3rd-party code, and even if there weren't, a descriptive name should help better understanding of the code. >> >> @@ -2546,7 +2537,7 @@ blink-cursor-mode >> >> :init-value (not (or noninteractive >> >> no-blinking-cursor >> >> (eq system-type 'ms-dos) >> >> - (not (memq window-system '(x w32 ns))))) >> >> + (not (display-graphic-p)))) >> > >> > Why would we want to connect blinking cursor with GUI displays? These >> > two are unrelated. >> >> The definition of blink-cursor mode states: >> >> This command is effective only on graphical frames. On text-only >> terminals, cursor blinking is controlled by the terminal." > > That's the _current_ situation. But what would preclude the xterm > developers, say, from adding a way of controlling that? Nothing in > particular, I'd say. I agree that it's possible for the behaviour to be different eventually, but in the meantime display-graphic-p describes the current situation and intent better than the explicit memq does. If text-only terminals gain the ability to control this behaviour, then that's the time to remove the check, no? >> >> ;; This is a serious problem for trying to handle multiple >> >> ;; frame types at once. We want this text to be invisible >> >> ;; on frames that can display the font above. >> >> - (when (memq (framep (selected-frame)) '(x pc w32 ns)) >> >> + (unless (memq (framep (selected-frame)) '(nil t)) >> >> (add-text-properties (1- (match-beginning 2)) (match-end 2) >> >> '(invisible t front-sticky nil rear-nonsticky t)))))) >> > >> > Not sure here, but if this about fonts, then display-multi-font-p is a >> > better test. >> >> Is multi-font equivalent to supporting invisible text? > > The comment above talks about fonts; I didn't read the code well > enough to understand what it's about. Maybe display-multi-font-p is a > better predicate here, not sure. I believe it is, since it appears to be referring to the ***** that is visible below the Info title only in text-terminals. I've altered the patch to use display-multi-font-p. >> > normal-erase-is-backspace-mode is entirely unrelated to display being >> > GUI, so I don't think this is right. >> >> The docstring of normal-erase-is-backspace-mode mentions window-system >> several times, so I don't see the issue. > > I hope now you understand my motivation better. I believe so. I'd like to replace the memq with a descriptive name, but I'm not sure what to call it; display-ascii-encoding-p to denote that the display can not differentiate between, e.g., C-m and RET? >> >> diff --git a/lisp/window.el b/lisp/window.el >> >> index b769be0633..b622debd51 100644 >> >> --- a/lisp/window.el >> >> +++ b/lisp/window.el >> >> @@ -9351,7 +9351,7 @@ handle-select-window >> >> ;; we might get two windows with an active cursor. >> >> (select-window window) >> >> (cond >> >> - ((or (not (memq (window-system frame) '(x w32 ns))) >> >> + ((or (memq (window-system frame) '(nil t pc)) >> >> (not focus-follows-mouse) >> >> ;; Focus FRAME if it's either a child frame or an ancestor >> >> ;; of the frame switched from. >> > >> > This is again a reversion of logic which I think is a change for the >> > worse. >> >> Would it be okay to forward-declare display-graphic-p and use it here as >> well? > > Not IMO, because this is again about selection with a mouse, something > that can (and is) supported on some TTY frames. We could use the > hypothetical display-iconifiable-p (but we should then find a better > name, something about selecting/raising frames perhaps). display-multi-focus-p? But maybe that implies that it can focus on multiple frames simultaneously. What about using display-multi-frame-p? Could there be some system that allows multiple frames, but no way to select between them? From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Apr 2019 17:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alex Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.155422577632341 (code B ref 35058); Tue, 02 Apr 2019 17:23:02 +0000 Received: (at 35058) by debbugs.gnu.org; 2 Apr 2019 17:22:56 +0000 Received: from localhost ([127.0.0.1]:41522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBN7f-0008PZ-LL for submit@debbugs.gnu.org; Tue, 02 Apr 2019 13:22:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35253) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBN7e-0008PM-KC for 35058@debbugs.gnu.org; Tue, 02 Apr 2019 13:22:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBN7Z-0003F8-Aw; Tue, 02 Apr 2019 13:22:49 -0400 Received: from [176.228.60.248] (port=2638 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hBN7Y-0007wB-Gw; Tue, 02 Apr 2019 13:22:48 -0400 Date: Tue, 02 Apr 2019 20:23:00 +0300 Message-Id: <83ef6kfhjf.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87d0m4pcca.fsf@gmail.com> (message from Alex on Tue, 02 Apr 2019 11:05:09 -0600) References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> <83a7hagv11.fsf@gnu.org> <87d0m4pcca.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Alex > Cc: 35058@debbugs.gnu.org > Date: Tue, 02 Apr 2019 11:05:09 -0600 > > >> On non-window systems, always use the meta modifier. > >> > >> So I changed the eq call to display-graphics-p. Is it okay to follow the > >> docstring here? > > > > No, not IMO. Doc strings can change because their purpose is > > documentation that's useful to users and programmers, whereas the > > issue in hand is ease of future maintenance. > > Hmm, it seems that my terminal Emacs accepts the super modifier but not > the hyper modifier; is this a bug in Emacs? I don't know. What do you mean by "accept"? > Should I remove the window-system condition even if I can't get > terminal Emacs to recognize the hyper key? If it is very inconvenient to use hyper on text terminals, then I think we shouldn't require users to do that. > >> The definition of blink-cursor mode states: > >> > >> This command is effective only on graphical frames. On text-only > >> terminals, cursor blinking is controlled by the terminal." > > > > That's the _current_ situation. But what would preclude the xterm > > developers, say, from adding a way of controlling that? Nothing in > > particular, I'd say. > > I agree that it's possible for the behaviour to be different eventually, > but in the meantime display-graphic-p describes the current situation > and intent better than the explicit memq does. > > If text-only terminals gain the ability to control this behaviour, then > that's the time to remove the check, no? How will you know which tests to remove? If the predicate was named display-blink-cursor-p, then you'd know immediately, but if the predicate is display-graphic-p, you'd need to decide which of those to remove and which not to remove. These predicates exist to make the decision easy. > I believe so. I'd like to replace the memq with a descriptive name, but > I'm not sure what to call it; display-ascii-encoding-p to denote that > the display can not differentiate between, e.g., C-m and RET? You mean, C-m/RET on the one hand and [return] on the other, right? I think a new predicate could be beneficial, because the function keys are supported on some text terminals, for example on MS-Windows. How about display-function-keys-p? > > Not IMO, because this is again about selection with a mouse, something > > that can (and is) supported on some TTY frames. We could use the > > hypothetical display-iconifiable-p (but we should then find a better > > name, something about selecting/raising frames perhaps). > > display-multi-focus-p? But maybe that implies that it can focus on > multiple frames simultaneously. display-can-raise-frames-p or something. (But I'm not good with coming up with names.) > What about using display-multi-frame-p? Could there be some system > that allows multiple frames, but no way to select between them? Text terminals can support multiple frames, so display-multi-frame-p is not what we want here. From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Alex Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Apr 2019 17:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.15542278803802 (code B ref 35058); Tue, 02 Apr 2019 17:58:01 +0000 Received: (at 35058) by debbugs.gnu.org; 2 Apr 2019 17:58:00 +0000 Received: from localhost ([127.0.0.1]:41685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBNfb-0000zG-Vr for submit@debbugs.gnu.org; Tue, 02 Apr 2019 13:58:00 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:43858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBNfZ-0000z3-SI for 35058@debbugs.gnu.org; Tue, 02 Apr 2019 13:57:58 -0400 Received: by mail-pf1-f196.google.com with SMTP id c8so6745181pfd.10 for <35058@debbugs.gnu.org>; Tue, 02 Apr 2019 10:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=ucBuc6TLu51EuCLFvKZw/8kQ2f0ay0NQG+SPxVUsfjo=; b=I17FE1pmeyhzfBTk13gZvGJKG6DCsEATacfyN+ReRXCFngd71a6VxQc6uk55+Il/se dYnIbFsiC+zD5OmvLg1ria8h8grKE9CKkgOriLCPG/KNvrOFgdoDTNEP6GeePYl/Gg3K SV49R4iq0/VO3cPz7ZejSrt4WTUjhdPtedSQGpcWWMSC/Xe2wUDFKXLaF/c6J5isbuEo 16lNnChjpYDqNMzDY9vz8pbQvQ0UE7PW3WyeNs+DXUqdO3xrjMGqLlfh0pjcC0fJ2/vA x2JLIatl+DIuYyUbCBIBwS5iontNjc8m+aNIr6ZST+itQp3Z6KI2T3nsIHYQdlBfGscL uRqA== 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=ucBuc6TLu51EuCLFvKZw/8kQ2f0ay0NQG+SPxVUsfjo=; b=fYcdYOXmoBr2PNCOQ2H9PbhRIXDrs0KWq5lotgYUfuPJ3HpLX35Rc+Zx7ChCC/ctXz XCNmPFCkDyzPYbov7yDHtNRgWcz4Aoyvpz0iDlvysHEas0W/fiRLow4HdS8h0C//OjyC u+ghyy7zc4gwRwJ0ZVHkl79V07Tm66aTsgyCWDZMF2fKGxirAudHAW4VpUW68dB8ocRL 983xYqdQJpp05PcVSzwaLF7TTwCKY3UTGcpZC/FmexI2TLIxyM5a1p2BY73SxqpXjhYd NTN25AmVQU8KrShUnosmTpaEzBv1SZXwulvBqNuyLxEJYuIQ8fOjqzgYptxLUyXZOzhu 4phQ== X-Gm-Message-State: APjAAAVSKelxZbeIiwRHQmqli5pKwzOYd2+alQEqlYC/8wscFuiIJntX L7TpWywHbAXk5QZ2WFEkszsshxg8 X-Google-Smtp-Source: APXvYqzegycWwxVBnJVEyPuK5G8MdOZosK+Weo653wPxv91fxfBt0Bg3thaXieNxkHxqsNxx5ix+WA== X-Received: by 2002:a63:bd52:: with SMTP id d18mr43736184pgp.52.1554227871589; Tue, 02 Apr 2019 10:57:51 -0700 (PDT) Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id y12sm36836230pgq.64.2019.04.02.10.57.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 02 Apr 2019 10:57:49 -0700 (PDT) From: Alex References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> <83a7hagv11.fsf@gnu.org> <87d0m4pcca.fsf@gmail.com> <83ef6kfhjf.fsf@gnu.org> Date: Tue, 02 Apr 2019 11:57:50 -0600 In-Reply-To: <83ef6kfhjf.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Apr 2019 20:23:00 +0300") Message-ID: <878swsp9wh.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Alex >> Cc: 35058@debbugs.gnu.org >> Date: Tue, 02 Apr 2019 11:05:09 -0600 >> >> >> On non-window systems, always use the meta modifier. >> >> >> >> So I changed the eq call to display-graphics-p. Is it okay to follow the >> >> docstring here? >> > >> > No, not IMO. Doc strings can change because their purpose is >> > documentation that's useful to users and programmers, whereas the >> > issue in hand is ease of future maintenance. >> >> Hmm, it seems that my terminal Emacs accepts the super modifier but not >> the hyper modifier; is this a bug in Emacs? > > I don't know. What do you mean by "accept"? I can get terminal Emacs to recognize the super modifier (it shows up in C-h l as a `s-' prefix), but not the hyper modifier (all input is treated as if it wasn't used at all). Does the hyper modifier work for you in the terminal? In my GTK Emacs both modifiers work as expected. >> Should I remove the window-system condition even if I can't get >> terminal Emacs to recognize the hyper key? > > If it is very inconvenient to use hyper on text terminals, then I > think we shouldn't require users to do that. It wouldn't be a matter of requiring, but instead forcing the modifier back to 'meta if both in terminal Emacs and cua-rectangle-modifier-key is 'hyper. >> >> The definition of blink-cursor mode states: >> >> >> >> This command is effective only on graphical frames. On text-only >> >> terminals, cursor blinking is controlled by the terminal." >> > >> > That's the _current_ situation. But what would preclude the xterm >> > developers, say, from adding a way of controlling that? Nothing in >> > particular, I'd say. >> >> I agree that it's possible for the behaviour to be different eventually, >> but in the meantime display-graphic-p describes the current situation >> and intent better than the explicit memq does. >> >> If text-only terminals gain the ability to control this behaviour, then >> that's the time to remove the check, no? > > How will you know which tests to remove? If the predicate was named > display-blink-cursor-p, then you'd know immediately, but if the > predicate is display-graphic-p, you'd need to decide which of those to > remove and which not to remove. These predicates exist to make the > decision easy. In this case there is only one test to remove, which is clearly mentioned in the docstring. I suppose my point before about 3rd-party code would apply here too, so adding display-blink-cursor-p would make sense. >> I believe so. I'd like to replace the memq with a descriptive name, but >> I'm not sure what to call it; display-ascii-encoding-p to denote that >> the display can not differentiate between, e.g., C-m and RET? > > You mean, C-m/RET on the one hand and [return] on the other, right? I > think a new predicate could be beneficial, because the function keys > are supported on some text terminals, for example on MS-Windows. How > about display-function-keys-p? [return] is another example, but I believe C-m and RET can be different in graphical Emacs. In my config I do: (define-key input-decode-map "\C-m" [C-m]) This allows me to use the control modifier with m separate from both RET and [return], as `C-h c' on the return key outputs: RET (translated from ) runs the command newline However, doing the same in terminal Emacs makes the return key use my custom [C-m] prefix. This is an example of the behaviour the predicate should be covering. I'm not sure about display-function-keys-p. That would seem to imply behaviour surrounding the `Fn' key on many keyboards. I'm not good with names either, but if we can't find a good specific name, then what about a more generic name like display-full-keybindings-p or display-extra-keybindings-p where the docstring would describe the behaviour more thoroughly? >> > Not IMO, because this is again about selection with a mouse, something >> > that can (and is) supported on some TTY frames. We could use the >> > hypothetical display-iconifiable-p (but we should then find a better >> > name, something about selecting/raising frames perhaps). >> >> display-multi-focus-p? But maybe that implies that it can focus on >> multiple frames simultaneously. > > display-can-raise-frames-p or something. (But I'm not good with > coming up with names.) Not sure, perhaps display-can-change-focus-p? >> What about using display-multi-frame-p? Could there be some system >> that allows multiple frames, but no way to select between them? > > Text terminals can support multiple frames, so display-multi-frame-p > is not what we want here. If that's the case, then why is display-multi-frame-p currently an alias for display-graphic-p? From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Apr 2019 18:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alex Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.15542303867661 (code B ref 35058); Tue, 02 Apr 2019 18:40:01 +0000 Received: (at 35058) by debbugs.gnu.org; 2 Apr 2019 18:39:46 +0000 Received: from localhost ([127.0.0.1]:41699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBOK2-0001zV-HV for submit@debbugs.gnu.org; Tue, 02 Apr 2019 14:39:46 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54208) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBOK1-0001zJ-8u for 35058@debbugs.gnu.org; Tue, 02 Apr 2019 14:39:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45051) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBOJv-0005w8-Uc; Tue, 02 Apr 2019 14:39:40 -0400 Received: from [176.228.60.248] (port=3374 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hBOJv-0001pW-A2; Tue, 02 Apr 2019 14:39:39 -0400 Date: Tue, 02 Apr 2019 21:39:52 +0300 Message-Id: <838swsfdzb.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <878swsp9wh.fsf@gmail.com> (message from Alex on Tue, 02 Apr 2019 11:57:50 -0600) References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> <83a7hagv11.fsf@gnu.org> <87d0m4pcca.fsf@gmail.com> <83ef6kfhjf.fsf@gnu.org> <878swsp9wh.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Alex > Cc: 35058@debbugs.gnu.org > Date: Tue, 02 Apr 2019 11:57:50 -0600 > > >> Hmm, it seems that my terminal Emacs accepts the super modifier but not > >> the hyper modifier; is this a bug in Emacs? > > > > I don't know. What do you mean by "accept"? > > I can get terminal Emacs to recognize the super modifier (it shows up in > C-h l as a `s-' prefix), but not the hyper modifier (all input is > treated as if it wasn't used at all). That might mean your terminal is unable to _generate_ the modifier. What happens if you use the "C-x @ h" prefix, does it produce hyper-modified keys? > > If it is very inconvenient to use hyper on text terminals, then I > > think we shouldn't require users to do that. > > It wouldn't be a matter of requiring, but instead forcing the modifier > back to 'meta if both in terminal Emacs and cua-rectangle-modifier-key > is 'hyper. Sorry, I don't understand. Can you show how would you like to remove the condition? > > You mean, C-m/RET on the one hand and [return] on the other, right? I > > think a new predicate could be beneficial, because the function keys > > are supported on some text terminals, for example on MS-Windows. How > > about display-function-keys-p? > > [return] is another example, but I believe C-m and RET can be different > in graphical Emacs. In my config I do: > > (define-key input-decode-map "\C-m" [C-m]) > > This allows me to use the control modifier with m separate from both RET > and [return], as `C-h c' on the return key outputs: > > RET (translated from ) runs the command newline > > However, doing the same in terminal Emacs makes the return key use my > custom [C-m] prefix. This is an example of the behaviour the predicate > should be covering. I think [return] the function key is a much more frequent case for the distinction. TTY frames generally don't have function keys as symbols, they have escape sequences which we translate to function keys. > I'm not sure about display-function-keys-p. That would seem to imply > behaviour surrounding the `Fn' key on many keyboards. A doc string will explain what we mean. > >> What about using display-multi-frame-p? Could there be some system > >> that allows multiple frames, but no way to select between them? > > > > Text terminals can support multiple frames, so display-multi-frame-p > > is not what we want here. > > If that's the case, then why is display-multi-frame-p currently an alias > for display-graphic-p? I don't remember. But maybe I'm splitting hair here, and we can use this predicate for iconifying etc. as well. From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Alex Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Apr 2019 05:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.155426845927259 (code B ref 35058); Wed, 03 Apr 2019 05:15:02 +0000 Received: (at 35058) by debbugs.gnu.org; 3 Apr 2019 05:14:19 +0000 Received: from localhost ([127.0.0.1]:42033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBYE6-00075a-O3 for submit@debbugs.gnu.org; Wed, 03 Apr 2019 01:14:19 -0400 Received: from mail-pf1-f171.google.com ([209.85.210.171]:35381) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBYE5-00075N-2G for 35058@debbugs.gnu.org; Wed, 03 Apr 2019 01:14:18 -0400 Received: by mail-pf1-f171.google.com with SMTP id t21so7545340pfe.2 for <35058@debbugs.gnu.org>; Tue, 02 Apr 2019 22:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=dU8R5Outi9IwuOwBrzqJnDctui6S4zbsQE+Ix1EaTqI=; b=fNUUAdduAue/Lzt1rld2n9h9lamq8E9q+6Wk2Wor7FfEreaTmAlbe8wqWtQUfMXrx6 CBrYpQRZjV9avD3Dj8p+IRR9diMy3XAcoMke+RCo1CYmlmAwjJ57pAhoYEK3pWAmJb/4 jy+ryMxG1C8MgP2ENAKbZ3hiDQmpAOcBZTkMZ7yT6N8qandzG/4glKTSuswGDJhoofVe H0phmTdSvBDmtimg0rWbylRU9QdAiiVWvEyi+hx4hVpHGUhWiH2grw14F4bscJjPQNyj S2CbTemfnn5SiTW7EFV0uVSIjj3dzFQOT4AuLFky2TaJoVvGnwLSZ1qaXF9jOwp2l+EW gZVA== 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=dU8R5Outi9IwuOwBrzqJnDctui6S4zbsQE+Ix1EaTqI=; b=EEyCMFHmJ3XIw9veCs/bnDJl2uP1NqJCQtQ7thUeEvaW1Rm7xfKCpyqenAvXm/xOA9 HrRTyBenJGYsHbCV8lXFK/LveG0TYFkqQoV+/6EefQqZbOhqAOf4vN0jeQvJQjG9wsic Mg0v2n7iMUF34N7VZpyJhAEfPc88IA80w8P2UR68/3PidYtk0wpdtHaF0FBqhF+tRbr+ OIinobjzdFrKFAqh/PiPks9IKPgsE4BQ3U/Njx/bXnAoolfLIx5nFrZzyYr5pdNHOuu4 SbVubYlCZTbxCM3/2D9FrR9qHJ7+tF5H/HbsJtRq25DopCajkfAHwjhdSPjSbzbiFXIK UQ1Q== X-Gm-Message-State: APjAAAVw81fOGRJYe9F8QQfNt5/0K02r0FbGkfC/dh9aUMIHatjIZa0A Swndvb0OHocXCnUUACx5MHLflof4 X-Google-Smtp-Source: APXvYqwyZRJ0UYlnfhnrKS96S7rcIScDGC041dRmSUWB4pyfHQ1P+YAxVZajJujmzXA0U7LlIOAotQ== X-Received: by 2002:aa7:8b0c:: with SMTP id f12mr72557206pfd.154.1554268450591; Tue, 02 Apr 2019 22:14:10 -0700 (PDT) Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id f7sm36073648pga.56.2019.04.02.22.14.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 02 Apr 2019 22:14:09 -0700 (PDT) From: Alex References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> <83a7hagv11.fsf@gnu.org> <87d0m4pcca.fsf@gmail.com> <83ef6kfhjf.fsf@gnu.org> <878swsp9wh.fsf@gmail.com> <838swsfdzb.fsf@gnu.org> Date: Tue, 02 Apr 2019 23:14:06 -0600 In-Reply-To: <838swsfdzb.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Apr 2019 21:39:52 +0300") Message-ID: <87r2ajbrhd.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Alex >> Cc: 35058@debbugs.gnu.org >> Date: Tue, 02 Apr 2019 11:57:50 -0600 >> >> >> Hmm, it seems that my terminal Emacs accepts the super modifier but not >> >> the hyper modifier; is this a bug in Emacs? >> > >> > I don't know. What do you mean by "accept"? >> >> I can get terminal Emacs to recognize the super modifier (it shows up in >> C-h l as a `s-' prefix), but not the hyper modifier (all input is >> treated as if it wasn't used at all). > > That might mean your terminal is unable to _generate_ the modifier. > What happens if you use the "C-x @ h" prefix, does it produce > hyper-modified keys? You're right, and it does work with "C-x @ h". It seems that terminals supporting either super/hyper are rare (or nonexistent -- I tried a few popular ones to no avail). My terminal only happens to support super since someone hard-coded it to output "C-x @ s" with the super modifier specifically to support Emacs. >> > If it is very inconvenient to use hyper on text terminals, then I >> > think we shouldn't require users to do that. >> >> It wouldn't be a matter of requiring, but instead forcing the modifier >> back to 'meta if both in terminal Emacs and cua-rectangle-modifier-key >> is 'hyper. > > Sorry, I don't understand. Can you show how would you like to remove > the condition? I don't agree with my position in my last email since I found out that my terminal has a special workaround for 'super. Removing the condition would just mean always using cua-rectangle-modifier-key in cua--init-keymaps even if in a terminal: (setq cua--rectangle-modifier-key cua-rectangle-modifier-key) This would mean that terminal users that can't use super/hyper modifiers easily would might find it confusing, but the current behaviour is a bit confusing as is. >> > You mean, C-m/RET on the one hand and [return] on the other, right? I >> > think a new predicate could be beneficial, because the function keys >> > are supported on some text terminals, for example on MS-Windows. How >> > about display-function-keys-p? >> >> [return] is another example, but I believe C-m and RET can be different >> in graphical Emacs. In my config I do: >> >> (define-key input-decode-map "\C-m" [C-m]) >> >> This allows me to use the control modifier with m separate from both RET >> and [return], as `C-h c' on the return key outputs: >> >> RET (translated from ) runs the command newline >> >> However, doing the same in terminal Emacs makes the return key use my >> custom [C-m] prefix. This is an example of the behaviour the predicate >> should be covering. > > I think [return] the function key is a much more frequent case for the > distinction. TTY frames generally don't have function keys as > symbols, they have escape sequences which we translate to function > keys. Yeah, I'll agree that [return] is more common; I was just describing my usage of C-m (or [C-m]) here. Why do you only say that TTY frames _generally_ don't have function keys as symbols? >> I'm not sure about display-function-keys-p. That would seem to imply >> behaviour surrounding the `Fn' key on many keyboards. > > A doc string will explain what we mean. Right, but I still don't think the name is particularly great considering the common notion of function key (en.wikipedia.org/wiki/Function_key). How about display-symbol-keys-p (if TTY frames can't support symbols in key sequences)? From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Apr 2019 05:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alex Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.155426933828655 (code B ref 35058); Wed, 03 Apr 2019 05:29:01 +0000 Received: (at 35058) by debbugs.gnu.org; 3 Apr 2019 05:28:58 +0000 Received: from localhost ([127.0.0.1]:42041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBYSG-0007S4-A4 for submit@debbugs.gnu.org; Wed, 03 Apr 2019 01:28:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50955) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBYSD-0007Rr-C8 for 35058@debbugs.gnu.org; Wed, 03 Apr 2019 01:28:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48067) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBYS8-0001r1-5R; Wed, 03 Apr 2019 01:28:48 -0400 Received: from [176.228.60.248] (port=3489 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hBYS7-0007pG-2M; Wed, 03 Apr 2019 01:28:47 -0400 Date: Wed, 03 Apr 2019 08:29:01 +0300 Message-Id: <83pnq3ejxe.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87r2ajbrhd.fsf@gmail.com> (message from Alex on Tue, 02 Apr 2019 23:14:06 -0600) References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> <83a7hagv11.fsf@gnu.org> <87d0m4pcca.fsf@gmail.com> <83ef6kfhjf.fsf@gnu.org> <878swsp9wh.fsf@gmail.com> <838swsfdzb.fsf@gnu.org> <87r2ajbrhd.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Alex > Cc: 35058@debbugs.gnu.org > Date: Tue, 02 Apr 2019 23:14:06 -0600 > > >> > If it is very inconvenient to use hyper on text terminals, then I > >> > think we shouldn't require users to do that. > >> > >> It wouldn't be a matter of requiring, but instead forcing the modifier > >> back to 'meta if both in terminal Emacs and cua-rectangle-modifier-key > >> is 'hyper. > > > > Sorry, I don't understand. Can you show how would you like to remove > > the condition? > > I don't agree with my position in my last email since I found out that > my terminal has a special workaround for 'super. > > Removing the condition would just mean always using > cua-rectangle-modifier-key in cua--init-keymaps even if in a terminal: > > (setq cua--rectangle-modifier-key cua-rectangle-modifier-key) > > This would mean that terminal users that can't use super/hyper modifiers > easily would might find it confusing, but the current behaviour is a bit > confusing as is. I think the use case behind that condition is of a user who uses both GUI and TTY frames, and have cua-rectangle-modifier-key customized to something that doesn't easily work on TTY. Perhaps the right solution would be to have 2 separate defcustom's, one each for every frame type. > Why do you only say that TTY frames _generally_ don't have function > keys as symbols? Because there are exceptions, like the MS-Windows console. > How about display-symbol-keys-p (if TTY frames can't support symbols in > key sequences)? Fine with me, thanks. Although having 2 defcustom's might eliminate the need for the test and for the predicate. From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Alex Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Apr 2019 20:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.15543232051408 (code B ref 35058); Wed, 03 Apr 2019 20:27:02 +0000 Received: (at 35058) by debbugs.gnu.org; 3 Apr 2019 20:26:45 +0000 Received: from localhost ([127.0.0.1]:43275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBmT6-0000Md-Eq for submit@debbugs.gnu.org; Wed, 03 Apr 2019 16:26:45 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:36984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBmT3-0000ML-FT for 35058@debbugs.gnu.org; Wed, 03 Apr 2019 16:26:43 -0400 Received: by mail-pg1-f195.google.com with SMTP id e6so46109pgc.4 for <35058@debbugs.gnu.org>; Wed, 03 Apr 2019 13:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=T/+V8BaaNy/b61NuNF1PoxzI7t+4duOasG/7Bz3QS+A=; b=Ieh1kbLE3j79rZ1P0nBszyJeOrPxlir9Z1YiHardODXMr58N1aIlDCE3uVCh6afiJU hmp4DHGouWfozPO1Tsf/t7l3VLWv4bu0d/crzu/rIifffrS3sudILqqWiiECvz26POAM iWbJzlwTK2dLDo0owdRaJY4KczXKm5/AaiO1vbNahzHVDX2hIz6/jYG0lJvEpr+VV+eG Lw9vT9MQYW0YYh4YAaaIcc3SuNBLICoDzjG3JWzp01cezb0eQBfj22Z3jmSIYJ8C2Rop t9JbOESubpayxLyhqG4oXgyqFBHa6UCdS/GY9btfoAB02AaDHdUeLa3mHsv8+eHXty2Y W8fw== 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=T/+V8BaaNy/b61NuNF1PoxzI7t+4duOasG/7Bz3QS+A=; b=cpInPUENr+UJ1u0W2ELBVOaJQlrCLtHLQLAr89zTFX1ytRnL0EFfCzGGgf3RT3bBNd Kjw6ARGJWW7p6/WsPRAm+RlhqXyYiTGOrVkllIPBEIxAnCj9K4Xas0kFXgCrDHrnA107 KHRRgX3SnsPebWQBhyfKiohDIA1wixu08HYUx2PDulnn7WMrU7Q/RVBXJnnTT1CTSk/M IzR2pDHAAvOITzbotHl33Yh1Cb7ho4/52xd5geoaqvOMiE+eCNih/Jn9Ie9I4kEFqC8s d7sQ+fZy2JkD+nQwje+kDmoxDWrCqb4E1A+mXR2SRWC8L46YB8NTRxxA/ohQnWAC91lF XNhQ== X-Gm-Message-State: APjAAAWPqS2/elEhUasdEFzCJuJhqEMzzOz0Ge4x978Tz8LSZKC8t6EE GaCmiFuCkXoEqhKO6vsCTergxyNU X-Google-Smtp-Source: APXvYqzX86Qoahb18j7ckt/5VLsnpsazUj4G/xFQGfj780vmcwv2Y2jpimXwZ86eMvjt3ZuXvoVxrQ== X-Received: by 2002:a62:61c2:: with SMTP id v185mr1500159pfb.117.1554323195132; Wed, 03 Apr 2019 13:26:35 -0700 (PDT) Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id b16sm23659865pfo.168.2019.04.03.13.26.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 03 Apr 2019 13:26:33 -0700 (PDT) From: Alex References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> <83a7hagv11.fsf@gnu.org> <87d0m4pcca.fsf@gmail.com> <83ef6kfhjf.fsf@gnu.org> <878swsp9wh.fsf@gmail.com> <838swsfdzb.fsf@gnu.org> <87r2ajbrhd.fsf@gmail.com> <83pnq3ejxe.fsf@gnu.org> Date: Wed, 03 Apr 2019 14:26:30 -0600 In-Reply-To: <83pnq3ejxe.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 03 Apr 2019 08:29:01 +0300") Message-ID: <87h8be7s3t.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> From: Alex >> Cc: 35058@debbugs.gnu.org >> Date: Tue, 02 Apr 2019 23:14:06 -0600 >> >> >> > If it is very inconvenient to use hyper on text terminals, then I >> >> > think we shouldn't require users to do that. >> >> >> >> It wouldn't be a matter of requiring, but instead forcing the modifier >> >> back to 'meta if both in terminal Emacs and cua-rectangle-modifier-key >> >> is 'hyper. >> > >> > Sorry, I don't understand. Can you show how would you like to remove >> > the condition? >> >> I don't agree with my position in my last email since I found out that >> my terminal has a special workaround for 'super. >> >> Removing the condition would just mean always using >> cua-rectangle-modifier-key in cua--init-keymaps even if in a terminal: >> >> (setq cua--rectangle-modifier-key cua-rectangle-modifier-key) >> >> This would mean that terminal users that can't use super/hyper modifiers >> easily would might find it confusing, but the current behaviour is a bit >> confusing as is. > > I think the use case behind that condition is of a user who uses both > GUI and TTY frames, and have cua-rectangle-modifier-key customized to > something that doesn't easily work on TTY. Perhaps the right solution > would be to have 2 separate defcustom's, one each for every frame type. Okay, I did that below. >> How about display-symbol-keys-p (if TTY frames can't support symbols in >> key sequences)? > > Fine with me, thanks. Although having 2 defcustom's might eliminate > the need for the test and for the predicate. The 2 defcustom situation applies to the CUA code, not for normal-erase-is-backspace-mode (where display-symbol-keys-p is used). I've attached a patch series below (including the logb change Basil recommended). Are these okay to apply? The first patch does still use display-graphic-p in a few cases in frame.el for the predicates concerning pixel dimensions. Do you really want them to use memq instead? --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Use-display-graphic-p-and-display-multi-frame-p-in-m.patch >From a45ebab6020152a515dd92d04995e74ab52a6978 Mon Sep 17 00:00:00 2001 From: Alexander Gramiak Date: Wed, 3 Apr 2019 13:57:16 -0600 Subject: [PATCH 1/4] Use display-graphic-p and display-multi-frame-p in more cases * lisp/disp-table.el: * lisp/faces.el: * lisp/frame.el: * lisp/info.el (Info-fontify-node): * lisp/window.el (handle-select-window): Use display-graphic-p and display-multi-frame-p instead of explicit memq calls. --- lisp/disp-table.el | 14 ++++++------- lisp/faces.el | 20 +++++++++---------- lisp/frame.el | 50 +++++++++++++++++++--------------------------- lisp/info.el | 2 +- lisp/window.el | 4 +++- 5 files changed, 40 insertions(+), 50 deletions(-) diff --git a/lisp/disp-table.el b/lisp/disp-table.el index 476c0cb986..4a59750677 100644 --- a/lisp/disp-table.el +++ b/lisp/disp-table.el @@ -175,8 +175,8 @@ standard-display-ascii (defun standard-display-g1 (c sc) "Display character C as character SC in the g1 character set. This function assumes that your terminal uses the SO/SI characters; -it is meaningless for an X frame." - (if (memq window-system '(x w32 ns)) +it is meaningless for a graphical frame." + (if (display-graphic-p) (error "Cannot use string glyphs in a windowing system")) (or standard-display-table (setq standard-display-table (make-display-table))) @@ -186,9 +186,9 @@ standard-display-g1 ;;;###autoload (defun standard-display-graphic (c gc) "Display character C as character GC in graphics character set. -This function assumes VT100-compatible escapes; it is meaningless for an -X frame." - (if (memq window-system '(x w32 ns)) +This function assumes VT100-compatible escapes; it is meaningless +for a graphical frame." + (if (display-graphic-p) (error "Cannot use string glyphs in a windowing system")) (or standard-display-table (setq standard-display-table (make-display-table))) @@ -276,7 +276,7 @@ standard-display-european (progn (standard-display-default (unibyte-char-to-multibyte 160) (unibyte-char-to-multibyte 255)) - (unless (or (memq window-system '(x w32 ns))) + (unless (display-graphic-p) (and (terminal-coding-system) (set-terminal-coding-system nil)))) @@ -289,7 +289,7 @@ standard-display-european ;; unless some other has been specified. (if (equal current-language-environment "English") (set-language-environment "latin-1")) - (unless (or noninteractive (memq window-system '(x w32 ns))) + (unless (or noninteractive (display-graphic-p)) ;; Send those codes literally to a character-based terminal. ;; If we are using single-byte characters, ;; it doesn't matter which coding system we use. diff --git a/lisp/faces.el b/lisp/faces.el index ab6c384c80..fa526c3506 100644 --- a/lisp/faces.el +++ b/lisp/faces.el @@ -55,6 +55,7 @@ term-file-aliases :group 'terminals :version "25.1") +(declare-function display-graphic-p "frame" (&optional display)) (declare-function xw-defined-colors "term/common-win" (&optional frame)) (defvar help-xref-stack-item) @@ -1239,7 +1240,7 @@ read-face-attribute ;; explicitly in VALID, using color approximation code ;; in tty-colors.el. (when (and (memq attribute '(:foreground :background)) - (not (memq (window-system frame) '(x w32 ns))) + (not (display-graphic-p frame)) (not (member new-value '("unspecified" "unspecified-fg" "unspecified-bg")))) @@ -1833,7 +1834,7 @@ defined-colors The value may be different for frames on different display types. If FRAME doesn't support colors, the value is nil. If FRAME is nil, that stands for the selected frame." - (if (memq (framep (or frame (selected-frame))) '(x w32 ns)) + (if (display-graphic-p frame) (xw-defined-colors frame) (mapcar 'car (tty-color-alist frame)))) (defalias 'x-defined-colors 'defined-colors) @@ -1877,7 +1878,7 @@ color-defined-p If FRAME is omitted or nil, use the selected frame." (unless (member color '(unspecified "unspecified-bg" "unspecified-fg")) - (if (member (framep (or frame (selected-frame))) '(x w32 ns)) + (if (display-graphic-p frame) (xw-color-defined-p color frame) (numberp (tty-color-translate color frame))))) (defalias 'x-color-defined-p 'color-defined-p) @@ -1903,7 +1904,7 @@ color-values (cond ((member color '(unspecified "unspecified-fg" "unspecified-bg")) nil) - ((memq (framep (or frame (selected-frame))) '(x w32 ns)) + ((display-graphic-p frame) (xw-color-values color frame)) (t (tty-color-values color frame)))) @@ -1917,7 +1918,7 @@ display-color-p The optional argument DISPLAY specifies which display to ask about. DISPLAY should be either a frame or a display name (a string). If omitted or nil, that stands for the selected frame's display." - (if (memq (framep-on-display display) '(x w32 ns)) + (if (display-graphic-p display) (xw-display-color-p display) (tty-display-color-p display))) (defalias 'x-display-color-p 'display-color-p) @@ -1928,12 +1929,9 @@ display-grayscale-p "Return non-nil if frames on DISPLAY can display shades of gray. DISPLAY should be either a frame or a display name (a string). If omitted or nil, that stands for the selected frame's display." - (let ((frame-type (framep-on-display display))) - (cond - ((memq frame-type '(x w32 ns)) - (x-display-grayscale-p display)) - (t - (> (tty-color-gray-shades display) 2))))) + (if (display-graphic-p display) + (x-display-grayscale-p display) + (> (tty-color-gray-shades display) 2))) (defun read-color (&optional prompt convert-to-RGB allow-empty-name msg) "Read a color name or RGB triplet. diff --git a/lisp/frame.el b/lisp/frame.el index 6cb1247372..eb4ab22c71 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -974,7 +974,7 @@ select-frame-set-input-focus (select-frame frame norecord) (raise-frame frame) ;; Ensure, if possible, that FRAME gets input focus. - (when (memq (window-system frame) '(x w32 ns)) + (when (display-multi-frame-p frame) (x-focus-frame frame)) ;; Move mouse cursor if necessary. (cond @@ -1027,16 +1027,15 @@ suspend-frame "Do whatever is right to suspend the current frame. Calls `suspend-emacs' if invoked from the controlling tty device, `suspend-tty' from a secondary tty device, and -`iconify-or-deiconify-frame' from an X frame." +`iconify-or-deiconify-frame' from a graphical frame." (interactive) - (let ((type (framep (selected-frame)))) - (cond - ((memq type '(x ns w32)) (iconify-or-deiconify-frame)) - ((eq type t) - (if (controlling-tty-p) - (suspend-emacs) - (suspend-tty))) - (t (suspend-emacs))))) + (cond + ((display-multi-frame-p) (iconify-or-deiconify-frame)) + ((eq (framep (selected-frame)) t) + (if (controlling-tty-p) + (suspend-emacs) + (suspend-tty))) + (t (suspend-emacs)))) (defun make-frame-names-alist () ;; Only consider the frames on the same display. @@ -1933,12 +1932,9 @@ display-screens "Return the number of screens associated with DISPLAY. DISPLAY should be either a frame or a display name (a string). If DISPLAY is omitted or nil, it defaults to the selected frame's display." - (let ((frame-type (framep-on-display display))) - (cond - ((memq frame-type '(x w32 ns)) - (x-display-screens display)) - (t - 1)))) + (if (display-multi-frame-p display) + (x-display-screens display) + 1)) (declare-function x-display-pixel-height "xfns.c" (&optional terminal)) @@ -1953,12 +1949,9 @@ display-pixel-height refers to the pixel height for all physical monitors associated with DISPLAY. To get information for each physical monitor, use `display-monitor-attributes-list'." - (let ((frame-type (framep-on-display display))) - (cond - ((memq frame-type '(x w32 ns)) - (x-display-pixel-height display)) - (t - (frame-height (if (framep display) display (selected-frame))))))) + (if (display-graphic-p display) + (x-display-pixel-height display) + (frame-height (if (framep display) display (selected-frame))))) (declare-function x-display-pixel-width "xfns.c" (&optional terminal)) @@ -1973,12 +1966,9 @@ display-pixel-width refers to the pixel width for all physical monitors associated with DISPLAY. To get information for each physical monitor, use `display-monitor-attributes-list'." - (let ((frame-type (framep-on-display display))) - (cond - ((memq frame-type '(x w32 ns)) - (x-display-pixel-width display)) - (t - (frame-width (if (framep display) display (selected-frame))))))) + (if (display-graphic-p display) + (x-display-pixel-width display) + (frame-width (if (framep display) display (selected-frame))))) (defcustom display-mm-dimensions-alist nil "Alist for specifying screen dimensions in millimeters. @@ -2013,7 +2003,7 @@ display-mm-height refers to the height in millimeters for all physical monitors associated with DISPLAY. To get information for each physical monitor, use `display-monitor-attributes-list'." - (and (memq (framep-on-display display) '(x w32 ns)) + (and (display-graphic-p display) (or (cddr (assoc (or display (frame-parameter nil 'display)) display-mm-dimensions-alist)) (cddr (assoc t display-mm-dimensions-alist)) @@ -2034,7 +2024,7 @@ display-mm-width refers to the width in millimeters for all physical monitors associated with DISPLAY. To get information for each physical monitor, use `display-monitor-attributes-list'." - (and (memq (framep-on-display display) '(x w32 ns)) + (and (display-graphic-p display) (or (cadr (assoc (or display (frame-parameter nil 'display)) display-mm-dimensions-alist)) (cadr (assoc t display-mm-dimensions-alist)) diff --git a/lisp/info.el b/lisp/info.el index f2a064abb6..f3b413a2f9 100644 --- a/lisp/info.el +++ b/lisp/info.el @@ -4768,7 +4768,7 @@ Info-fontify-node ;; This is a serious problem for trying to handle multiple ;; frame types at once. We want this text to be invisible ;; on frames that can display the font above. - (when (memq (framep (selected-frame)) '(x pc w32 ns)) + (when (display-multi-font-p) (add-text-properties (1- (match-beginning 2)) (match-end 2) '(invisible t front-sticky nil rear-nonsticky t)))))) diff --git a/lisp/window.el b/lisp/window.el index b769be0633..b4f5ac5cc4 100644 --- a/lisp/window.el +++ b/lisp/window.el @@ -9314,6 +9314,8 @@ mouse-autoselect-window-select ;; autoselection. (mouse-autoselect-window-start mouse-position window))))) +(declare-function display-multi-frame-p "frame" (&optional display)) + (defun handle-select-window (event) "Handle select-window events." (interactive "^e") @@ -9351,7 +9353,7 @@ handle-select-window ;; we might get two windows with an active cursor. (select-window window) (cond - ((or (not (memq (window-system frame) '(x w32 ns))) + ((or (not (display-multi-frame-p)) (not focus-follows-mouse) ;; Focus FRAME if it's either a child frame or an ancestor ;; of the frame switched from. -- 2.21.0 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0002-Define-and-use-new-procedure-display-symbol-keys-p.patch >From 964a107264a14ffbda1f29f81e1b9b6e1b6d4f35 Mon Sep 17 00:00:00 2001 From: Alexander Gramiak Date: Wed, 3 Apr 2019 14:03:28 -0600 Subject: [PATCH 2/4] Define and use new procedure display-symbol-keys-p * lisp/frame.el (display-symbol-keys-p): Define. * lisp/simple.el (normal-erase-is-backspace-setup-frame): Use eq instead of memq. (normal-erase-is-backspace-mode): Use display-symbol-keys-p. --- lisp/frame.el | 8 ++++++++ lisp/simple.el | 7 ++++--- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/lisp/frame.el b/lisp/frame.el index eb4ab22c71..72b48c13de 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -1926,6 +1926,14 @@ display-selections-p (t nil)))) +(defun display-symbol-keys-p (&optional display) + "Return non-nil if DISPLAY supports symbol names as keys. +This means that, for example, DISPLAY can differentiate between +the keybinding RET and [return]." + (let ((frame-type (framep-on-display display))) + (or (memq frame-type '(x w32 ns pc)) + (memq system-type '(ms-dos windows-nt))))) + (declare-function x-display-screens "xfns.c" (&optional terminal)) (defun display-screens (&optional display) diff --git a/lisp/simple.el b/lisp/simple.el index 306df96766..857e0fc001 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -8690,7 +8690,7 @@ normal-erase-is-backspace-setup-frame (and (not noninteractive) (or (memq system-type '(ms-dos windows-nt)) (memq window-system '(w32 ns)) - (and (memq window-system '(x)) + (and (eq window-system 'x) (fboundp 'x-backspace-delete-keys-p) (x-backspace-delete-keys-p)) ;; If the terminal Emacs is running on has erase char @@ -8701,6 +8701,8 @@ normal-erase-is-backspace-setup-frame normal-erase-is-backspace) 1 0))))) +(declare-function display-symbol-keys-p "frame" (&optional display)) + (define-minor-mode normal-erase-is-backspace-mode "Toggle the Erase and Delete mode of the Backspace and Delete keys. @@ -8736,8 +8738,7 @@ normal-erase-is-backspace-mode (let ((enabled (eq 1 (terminal-parameter nil 'normal-erase-is-backspace)))) - (cond ((or (memq window-system '(x w32 ns pc)) - (memq system-type '(ms-dos windows-nt))) + (cond ((display-symbol-keys-p) (let ((bindings '(([M-delete] [M-backspace]) ([C-M-delete] [C-M-backspace]) -- 2.21.0 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0003-Define-and-use-new-alias-display-blink-cursor-p.patch >From 7e6a56a8ec549c9efc859184378a6619c1658c80 Mon Sep 17 00:00:00 2001 From: Alexander Gramiak Date: Wed, 3 Apr 2019 14:03:42 -0600 Subject: [PATCH 3/4] Define and use new alias display-blink-cursor-p display-graphic-p is not used in this case because it may be possible in the future for terminals to allow control over cursor blinking. For details, see bug#35058. * lisp/frame.el (blink-cursor-mode): Use display-blink-cursor-p. --- lisp/frame.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/frame.el b/lisp/frame.el index 72b48c13de..af89aecc3d 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -1905,6 +1905,7 @@ display-images-p (fboundp 'image-mask-p) (fboundp 'image-size))) +(defalias 'display-blink-cursor-p 'display-graphic-p) (defalias 'display-multi-frame-p 'display-graphic-p) (defalias 'display-multi-font-p 'display-graphic-p) @@ -2544,7 +2545,7 @@ blink-cursor-mode :init-value (not (or noninteractive no-blinking-cursor (eq system-type 'ms-dos) - (not (memq window-system '(x w32 ns))))) + (not (display-blink-cursor-p)))) :initialize 'custom-initialize-delay :group 'cursor :global t -- 2.21.0 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0004-Introduce-new-defcustom-for-terminal-CUA-rectangle-c.patch >From 9e52e01e03c2c4cf14700527808f683ce86e5c58 Mon Sep 17 00:00:00 2001 From: Alexander Gramiak Date: Wed, 3 Apr 2019 14:06:45 -0600 Subject: [PATCH 4/4] Introduce new defcustom for terminal CUA rectangle commands This allows a user to set a non-meta modifier for their terminal should his/her terminal support it. See bug#35058 for background on this change. * lisp/emulation/cua-base.el (cua-rectangle-terminal-modifier-key): New defcustom. * lisp/emulation/cua-base.el (cua--shift-control-x-prefix): Use new defcustom. --- lisp/emulation/cua-base.el | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/lisp/emulation/cua-base.el b/lisp/emulation/cua-base.el index 302ef12386..49e63c336f 100644 --- a/lisp/emulation/cua-base.el +++ b/lisp/emulation/cua-base.el @@ -427,7 +427,7 @@ cua-rectangle-mark-key (defcustom cua-rectangle-modifier-key 'meta "Modifier key used for rectangle commands bindings. -On non-window systems, always use the meta modifier. +On non-window systems, use `cua-rectangle-terminal-modifier-key'. Must be set prior to enabling CUA." :type '(choice (const :tag "Meta key" meta) (const :tag "Alt key" alt) @@ -435,6 +435,16 @@ cua-rectangle-modifier-key (const :tag "Super key" super)) :group 'cua) +(defcustom cua-rectangle-terminal-modifier-key 'meta + "Modifier key used for rectangle commands bindings in terminals. +Must be set prior to enabling CUA." + :type '(choice (const :tag "Meta key" meta) + (const :tag "Alt key" alt) + (const :tag "Hyper key" hyper) + (const :tag "Super key" super)) + :group 'cua + :version "27.1") + (defcustom cua-enable-rectangle-auto-help t "If non-nil, automatically show help for region, rectangle and global mark." :type 'boolean @@ -1237,10 +1247,9 @@ cua--shift-control-x-prefix (defun cua--init-keymaps () ;; Cache actual rectangle modifier key. (setq cua--rectangle-modifier-key - (if (and cua-rectangle-modifier-key - (memq window-system '(x))) + (if (eq (framep-on-display) t) cua-rectangle-modifier-key - 'meta)) + cua-rectangle-terminal-modifier-key)) ;; C-return always toggles rectangle mark (define-key cua-global-keymap cua-rectangle-mark-key 'cua-set-rectangle-mark) (unless (eq cua--rectangle-modifier-key 'meta) -- 2.21.0 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-lisp-frame.el-display-planes-Use-logb-over-truncate-.patch Content-Description: logb >From 641cbc50d5d260a50075a2eb012ebd4ff021f5ee Mon Sep 17 00:00:00 2001 From: Alexander Gramiak Date: Tue, 2 Apr 2019 11:14:18 -0600 Subject: [PATCH] * lisp/frame.el (display-planes): Use logb over truncate + log Suggested by Basil L. Contovounesios: https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-03/msg01052.html --- lisp/frame.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/frame.el b/lisp/frame.el index 6cb1247372..5d8addf3c0 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -2083,7 +2083,7 @@ display-planes ((eq frame-type 'pc) 4) (t - (truncate (log (length (tty-color-alist)) 2)))))) + (logb (length (tty-color-alist))))))) (declare-function x-display-color-cells "xfns.c" (&optional terminal)) -- 2.21.0 --=-=-=-- From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Apr 2019 07:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alex Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.155444940929863 (code B ref 35058); Fri, 05 Apr 2019 07:31:01 +0000 Received: (at 35058) by debbugs.gnu.org; 5 Apr 2019 07:30:09 +0000 Received: from localhost ([127.0.0.1]:45040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCJIe-0007la-SI for submit@debbugs.gnu.org; Fri, 05 Apr 2019 03:30:09 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52216) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCJIc-0007ke-4w for 35058@debbugs.gnu.org; Fri, 05 Apr 2019 03:30:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59200) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hCJIW-0004Nj-SQ; Fri, 05 Apr 2019 03:30:00 -0400 Received: from [176.228.60.248] (port=2475 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hCJIU-0007s5-TU; Fri, 05 Apr 2019 03:29:59 -0400 Date: Fri, 05 Apr 2019 10:29:43 +0300 Message-Id: <838swodi54.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87h8be7s3t.fsf@gmail.com> (message from Alex on Wed, 03 Apr 2019 14:26:30 -0600) References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> <83a7hagv11.fsf@gnu.org> <87d0m4pcca.fsf@gmail.com> <83ef6kfhjf.fsf@gnu.org> <878swsp9wh.fsf@gmail.com> <838swsfdzb.fsf@gnu.org> <87r2ajbrhd.fsf@gmail.com> <83pnq3ejxe.fsf@gnu.org> <87h8be7s3t.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Alex > Cc: 35058@debbugs.gnu.org > Date: Wed, 03 Apr 2019 14:26:30 -0600 > > I've attached a patch series below (including the logb change Basil > recommended). Are these okay to apply? Almost, we are close. See the remaining few comments below. > The first patch does still use display-graphic-p in a few cases in > frame.el for the predicates concerning pixel dimensions. Do you really > want them to use memq instead? For the display-* functions, yes, I'd like to leave their definitions explicit. > +(defun display-symbol-keys-p (&optional display) > + "Return non-nil if DISPLAY supports symbol names as keys. > +This means that, for example, DISPLAY can differentiate between > +the keybinding RET and [return]." > + (let ((frame-type (framep-on-display display))) > + (or (memq frame-type '(x w32 ns pc)) > + (memq system-type '(ms-dos windows-nt))))) Please add a comment here explaining that MS-Windows/MS-DOS terminals are an exception because they have built-in support for function keys. > --- a/lisp/faces.el > +++ b/lisp/faces.el > @@ -55,6 +55,7 @@ term-file-aliases > :group 'terminals > :version "25.1") > > +(declare-function display-graphic-p "frame" (&optional display)) Did you try to bootstrap with this? frame.el is loaded after faces.el. (There are more similar declarations in the patches with the same issues.) > --- a/lisp/emulation/cua-base.el > +++ b/lisp/emulation/cua-base.el > @@ -427,7 +427,7 @@ cua-rectangle-mark-key > > (defcustom cua-rectangle-modifier-key 'meta > "Modifier key used for rectangle commands bindings. > -On non-window systems, always use the meta modifier. > +On non-window systems, use `cua-rectangle-terminal-modifier-key'. > Must be set prior to enabling CUA." > :type '(choice (const :tag "Meta key" meta) > (const :tag "Alt key" alt) > @@ -435,6 +435,16 @@ cua-rectangle-modifier-key > (const :tag "Super key" super)) > :group 'cua) > > +(defcustom cua-rectangle-terminal-modifier-key 'meta > + "Modifier key used for rectangle commands bindings in terminals. > +Must be set prior to enabling CUA." > + :type '(choice (const :tag "Meta key" meta) > + (const :tag "Alt key" alt) > + (const :tag "Hyper key" hyper) > + (const :tag "Super key" super)) > + :group 'cua > + :version "27.1") This change should be called out in NEWS. The new display-* predicates should probably also be mentioned in NEWS. Thanks. From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Alex Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Apr 2019 16:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.155448214815248 (code B ref 35058); Fri, 05 Apr 2019 16:36:02 +0000 Received: (at 35058) by debbugs.gnu.org; 5 Apr 2019 16:35:48 +0000 Received: from localhost ([127.0.0.1]:46231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCRoh-0003xp-Mc for submit@debbugs.gnu.org; Fri, 05 Apr 2019 12:35:48 -0400 Received: from mail-pl1-f169.google.com ([209.85.214.169]:42970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCRof-0003xc-Hg for 35058@debbugs.gnu.org; Fri, 05 Apr 2019 12:35:46 -0400 Received: by mail-pl1-f169.google.com with SMTP id cv12so3300505plb.9 for <35058@debbugs.gnu.org>; Fri, 05 Apr 2019 09:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=shq9Oi2moqm9+O4KgjnWMnEESw3kziJDnuG/7ZOibLw=; b=AWDw7k6aMGod17Vox3Hg4SinHpYOZqzJ1sY01T8/vrYTY1D7ervEB567ndEeFbYa8v x3RryFHfsNxqydeihKZW4CWIBi0/yl0w41ssthlgBMTkK24mVfEqg9VIkfIjuS2AW5Vs IZHOfO7BX2rwbNnp8lqfie2QURByLDqaUPVDS+6BtpH5vbukuqmzqMJxW9/xRthugCbJ RrNEZRjE4BqotyqGlNFK3I2EQwSJVFiXP6puCBw697U/7Mlz2rxx/3fbbPlI7vjWzQYd Z8Irc6UELPiLTOcET0oSrvqJV0jD1vl/82B/LUQLb4ZpQ/0+pZYuVoPatgSKAxiQPDES accg== 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=shq9Oi2moqm9+O4KgjnWMnEESw3kziJDnuG/7ZOibLw=; b=GqD5ng8no3WcWm8O/6KybbecMpz7Huot0ZChTx3ncijlsueGGhaiQE9+imvKWyWJAz VOK+V5hwAL17s3ILEk9mITDdym4Zmjw+wuSbnBYZKqeC67S+88qCOptcwI8hzcbSAz5P 2gUsyTeAL/0Iaxg8iwPBp58AS7VcKu44DhUlwoaea3JmjMLzz0qs98NFYD51xRnMdYW+ BjrbFCpqnCuKQyj1XivmIrrxxtzaWQGP9eOI6mil/4ulDp44C41izqdM/gzYToKUueFH yiUjE22KDj6gRbHBWkHNyJ7tG4qG9wyi7j/xqNxkT1wm7qbMTxcULownBWjkDp8R0ORl G+kQ== X-Gm-Message-State: APjAAAVRPRzM7EypXlR2ch+tSUs+Z16Z00PRDy1TJa2Pk5qhJxSVBKQA +okxwTduML4NDnl8JQmOODWtp5rC X-Google-Smtp-Source: APXvYqxdIHKP6anmJi2JoUhywTRHRVoRwMyVAacXIm09rpEjKJ0Ck+MmHTKj04jJKYtZf1/Xz/7/cg== X-Received: by 2002:a17:902:2947:: with SMTP id g65mr13640987plb.258.1554482138901; Fri, 05 Apr 2019 09:35:38 -0700 (PDT) Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id u62sm45800003pfa.124.2019.04.05.09.35.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 05 Apr 2019 09:35:37 -0700 (PDT) From: Alex References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> <83a7hagv11.fsf@gnu.org> <87d0m4pcca.fsf@gmail.com> <83ef6kfhjf.fsf@gnu.org> <878swsp9wh.fsf@gmail.com> <838swsfdzb.fsf@gnu.org> <87r2ajbrhd.fsf@gmail.com> <83pnq3ejxe.fsf@gnu.org> <87h8be7s3t.fsf@gmail.com> <838swodi54.fsf@gnu.org> Date: Fri, 05 Apr 2019 10:35:33 -0600 In-Reply-To: <838swodi54.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 05 Apr 2019 10:29:43 +0300") Message-ID: <87k1g8csve.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> --- a/lisp/faces.el >> +++ b/lisp/faces.el >> @@ -55,6 +55,7 @@ term-file-aliases >> :group 'terminals >> :version "25.1") >> >> +(declare-function display-graphic-p "frame" (&optional display)) > > Did you try to bootstrap with this? frame.el is loaded after > faces.el. (There are more similar declarations in the patches with > the same issues.) Yes, I successfully bootstrapped, and the loading issue is why I added the declare-function calls. It seems to work fine. My usage of display-graphic-p appears to be different compared to the one in face-spec-reset-face, which apparently is run during bootstrap. >> --- a/lisp/emulation/cua-base.el >> +++ b/lisp/emulation/cua-base.el >> @@ -427,7 +427,7 @@ cua-rectangle-mark-key >> >> (defcustom cua-rectangle-modifier-key 'meta >> "Modifier key used for rectangle commands bindings. >> -On non-window systems, always use the meta modifier. >> +On non-window systems, use `cua-rectangle-terminal-modifier-key'. >> Must be set prior to enabling CUA." >> :type '(choice (const :tag "Meta key" meta) >> (const :tag "Alt key" alt) >> @@ -435,6 +435,16 @@ cua-rectangle-modifier-key >> (const :tag "Super key" super)) >> :group 'cua) >> >> +(defcustom cua-rectangle-terminal-modifier-key 'meta >> + "Modifier key used for rectangle commands bindings in terminals. >> +Must be set prior to enabling CUA." >> + :type '(choice (const :tag "Meta key" meta) >> + (const :tag "Alt key" alt) >> + (const :tag "Hyper key" hyper) >> + (const :tag "Super key" super)) >> + :group 'cua >> + :version "27.1") > > This change should be called out in NEWS. > > The new display-* predicates should probably also be mentioned in > NEWS. Okay, here's a new set of patches (excluding the same logb patch). --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Use-display-graphic-p-and-display-multi-frame-p-in-m.patch >From 3f476d5e827fc1e94a18101604838923a2a686c7 Mon Sep 17 00:00:00 2001 From: Alexander Gramiak Date: Wed, 3 Apr 2019 13:57:16 -0600 Subject: [PATCH 1/4] Use display-graphic-p and display-multi-frame-p in more cases * lisp/disp-table.el: * lisp/faces.el: * lisp/frame.el: * lisp/info.el (Info-fontify-node): * lisp/window.el (handle-select-window): Use display-graphic-p and display-multi-frame-p instead of explicit memq calls. --- lisp/disp-table.el | 14 +++++++------- lisp/faces.el | 20 +++++++++----------- lisp/frame.el | 19 +++++++++---------- lisp/info.el | 2 +- lisp/window.el | 4 +++- 5 files changed, 29 insertions(+), 30 deletions(-) diff --git a/lisp/disp-table.el b/lisp/disp-table.el index 476c0cb986..4a59750677 100644 --- a/lisp/disp-table.el +++ b/lisp/disp-table.el @@ -175,8 +175,8 @@ standard-display-ascii (defun standard-display-g1 (c sc) "Display character C as character SC in the g1 character set. This function assumes that your terminal uses the SO/SI characters; -it is meaningless for an X frame." - (if (memq window-system '(x w32 ns)) +it is meaningless for a graphical frame." + (if (display-graphic-p) (error "Cannot use string glyphs in a windowing system")) (or standard-display-table (setq standard-display-table (make-display-table))) @@ -186,9 +186,9 @@ standard-display-g1 ;;;###autoload (defun standard-display-graphic (c gc) "Display character C as character GC in graphics character set. -This function assumes VT100-compatible escapes; it is meaningless for an -X frame." - (if (memq window-system '(x w32 ns)) +This function assumes VT100-compatible escapes; it is meaningless +for a graphical frame." + (if (display-graphic-p) (error "Cannot use string glyphs in a windowing system")) (or standard-display-table (setq standard-display-table (make-display-table))) @@ -276,7 +276,7 @@ standard-display-european (progn (standard-display-default (unibyte-char-to-multibyte 160) (unibyte-char-to-multibyte 255)) - (unless (or (memq window-system '(x w32 ns))) + (unless (display-graphic-p) (and (terminal-coding-system) (set-terminal-coding-system nil)))) @@ -289,7 +289,7 @@ standard-display-european ;; unless some other has been specified. (if (equal current-language-environment "English") (set-language-environment "latin-1")) - (unless (or noninteractive (memq window-system '(x w32 ns))) + (unless (or noninteractive (display-graphic-p)) ;; Send those codes literally to a character-based terminal. ;; If we are using single-byte characters, ;; it doesn't matter which coding system we use. diff --git a/lisp/faces.el b/lisp/faces.el index ab6c384c80..fa526c3506 100644 --- a/lisp/faces.el +++ b/lisp/faces.el @@ -55,6 +55,7 @@ term-file-aliases :group 'terminals :version "25.1") +(declare-function display-graphic-p "frame" (&optional display)) (declare-function xw-defined-colors "term/common-win" (&optional frame)) (defvar help-xref-stack-item) @@ -1239,7 +1240,7 @@ read-face-attribute ;; explicitly in VALID, using color approximation code ;; in tty-colors.el. (when (and (memq attribute '(:foreground :background)) - (not (memq (window-system frame) '(x w32 ns))) + (not (display-graphic-p frame)) (not (member new-value '("unspecified" "unspecified-fg" "unspecified-bg")))) @@ -1833,7 +1834,7 @@ defined-colors The value may be different for frames on different display types. If FRAME doesn't support colors, the value is nil. If FRAME is nil, that stands for the selected frame." - (if (memq (framep (or frame (selected-frame))) '(x w32 ns)) + (if (display-graphic-p frame) (xw-defined-colors frame) (mapcar 'car (tty-color-alist frame)))) (defalias 'x-defined-colors 'defined-colors) @@ -1877,7 +1878,7 @@ color-defined-p If FRAME is omitted or nil, use the selected frame." (unless (member color '(unspecified "unspecified-bg" "unspecified-fg")) - (if (member (framep (or frame (selected-frame))) '(x w32 ns)) + (if (display-graphic-p frame) (xw-color-defined-p color frame) (numberp (tty-color-translate color frame))))) (defalias 'x-color-defined-p 'color-defined-p) @@ -1903,7 +1904,7 @@ color-values (cond ((member color '(unspecified "unspecified-fg" "unspecified-bg")) nil) - ((memq (framep (or frame (selected-frame))) '(x w32 ns)) + ((display-graphic-p frame) (xw-color-values color frame)) (t (tty-color-values color frame)))) @@ -1917,7 +1918,7 @@ display-color-p The optional argument DISPLAY specifies which display to ask about. DISPLAY should be either a frame or a display name (a string). If omitted or nil, that stands for the selected frame's display." - (if (memq (framep-on-display display) '(x w32 ns)) + (if (display-graphic-p display) (xw-display-color-p display) (tty-display-color-p display))) (defalias 'x-display-color-p 'display-color-p) @@ -1928,12 +1929,9 @@ display-grayscale-p "Return non-nil if frames on DISPLAY can display shades of gray. DISPLAY should be either a frame or a display name (a string). If omitted or nil, that stands for the selected frame's display." - (let ((frame-type (framep-on-display display))) - (cond - ((memq frame-type '(x w32 ns)) - (x-display-grayscale-p display)) - (t - (> (tty-color-gray-shades display) 2))))) + (if (display-graphic-p display) + (x-display-grayscale-p display) + (> (tty-color-gray-shades display) 2))) (defun read-color (&optional prompt convert-to-RGB allow-empty-name msg) "Read a color name or RGB triplet. diff --git a/lisp/frame.el b/lisp/frame.el index 6cb1247372..acf6a46716 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -974,7 +974,7 @@ select-frame-set-input-focus (select-frame frame norecord) (raise-frame frame) ;; Ensure, if possible, that FRAME gets input focus. - (when (memq (window-system frame) '(x w32 ns)) + (when (display-multi-frame-p frame) (x-focus-frame frame)) ;; Move mouse cursor if necessary. (cond @@ -1027,16 +1027,15 @@ suspend-frame "Do whatever is right to suspend the current frame. Calls `suspend-emacs' if invoked from the controlling tty device, `suspend-tty' from a secondary tty device, and -`iconify-or-deiconify-frame' from an X frame." +`iconify-or-deiconify-frame' from a graphical frame." (interactive) - (let ((type (framep (selected-frame)))) - (cond - ((memq type '(x ns w32)) (iconify-or-deiconify-frame)) - ((eq type t) - (if (controlling-tty-p) - (suspend-emacs) - (suspend-tty))) - (t (suspend-emacs))))) + (cond + ((display-multi-frame-p) (iconify-or-deiconify-frame)) + ((eq (framep (selected-frame)) t) + (if (controlling-tty-p) + (suspend-emacs) + (suspend-tty))) + (t (suspend-emacs)))) (defun make-frame-names-alist () ;; Only consider the frames on the same display. diff --git a/lisp/info.el b/lisp/info.el index f2a064abb6..f3b413a2f9 100644 --- a/lisp/info.el +++ b/lisp/info.el @@ -4768,7 +4768,7 @@ Info-fontify-node ;; This is a serious problem for trying to handle multiple ;; frame types at once. We want this text to be invisible ;; on frames that can display the font above. - (when (memq (framep (selected-frame)) '(x pc w32 ns)) + (when (display-multi-font-p) (add-text-properties (1- (match-beginning 2)) (match-end 2) '(invisible t front-sticky nil rear-nonsticky t)))))) diff --git a/lisp/window.el b/lisp/window.el index b769be0633..b4f5ac5cc4 100644 --- a/lisp/window.el +++ b/lisp/window.el @@ -9314,6 +9314,8 @@ mouse-autoselect-window-select ;; autoselection. (mouse-autoselect-window-start mouse-position window))))) +(declare-function display-multi-frame-p "frame" (&optional display)) + (defun handle-select-window (event) "Handle select-window events." (interactive "^e") @@ -9351,7 +9353,7 @@ handle-select-window ;; we might get two windows with an active cursor. (select-window window) (cond - ((or (not (memq (window-system frame) '(x w32 ns))) + ((or (not (display-multi-frame-p)) (not focus-follows-mouse) ;; Focus FRAME if it's either a child frame or an ancestor ;; of the frame switched from. -- 2.21.0 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0002-Define-and-use-new-alias-display-blink-cursor-p.patch >From 372299922bbff28d8fe19fffc6c784b390e13402 Mon Sep 17 00:00:00 2001 From: Alexander Gramiak Date: Wed, 3 Apr 2019 14:03:42 -0600 Subject: [PATCH 2/4] Define and use new alias display-blink-cursor-p display-graphic-p is not used in this case because it may be possible in the future for terminals to allow control over cursor blinking. For details, see bug#35058. * lisp/frame.el (blink-cursor-mode): Use display-blink-cursor-p. --- lisp/frame.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/frame.el b/lisp/frame.el index acf6a46716..cc8ca49b3b 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -1905,6 +1905,7 @@ display-images-p (fboundp 'image-mask-p) (fboundp 'image-size))) +(defalias 'display-blink-cursor-p 'display-graphic-p) (defalias 'display-multi-frame-p 'display-graphic-p) (defalias 'display-multi-font-p 'display-graphic-p) @@ -2545,7 +2546,7 @@ blink-cursor-mode :init-value (not (or noninteractive no-blinking-cursor (eq system-type 'ms-dos) - (not (memq window-system '(x w32 ns))))) + (not (display-blink-cursor-p)))) :initialize 'custom-initialize-delay :group 'cursor :global t -- 2.21.0 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0003-Define-and-use-new-procedure-display-symbol-keys-p.patch >From 6d171ce90f42f16f148fae87f083038cc95acf05 Mon Sep 17 00:00:00 2001 From: Alexander Gramiak Date: Wed, 3 Apr 2019 14:03:28 -0600 Subject: [PATCH 3/4] Define and use new procedure display-symbol-keys-p * lisp/frame.el (display-symbol-keys-p): Define. * lisp/simple.el (normal-erase-is-backspace-setup-frame): Use eq instead of memq. (normal-erase-is-backspace-mode): Use display-symbol-keys-p. --- etc/NEWS | 5 +++++ lisp/frame.el | 10 ++++++++++ lisp/simple.el | 7 ++++--- 3 files changed, 19 insertions(+), 3 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 7f6aeab73f..1e64c0f15f 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1226,6 +1226,11 @@ the 128...255 range, as expected. This allows to create and parent immediately a minibuffer-only child frame when making a frame. +*** New predicates 'display-blink-cursor-p' and 'display-symbol-keys-p'. +These predicates are to be preferred over 'display-graphic-p' when +testing for blinking cursor capability and the capability to have +symbols (e.g., [return], [tab], [backspace]) as keys respectively. + ** Tabulated List mode +++ diff --git a/lisp/frame.el b/lisp/frame.el index cc8ca49b3b..aa14e87d7b 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -1927,6 +1927,16 @@ display-selections-p (t nil)))) +(defun display-symbol-keys-p (&optional display) + "Return non-nil if DISPLAY supports symbol names as keys. +This means that, for example, DISPLAY can differentiate between +the keybinding RET and [return]." + (let ((frame-type (framep-on-display display))) + (or (memq frame-type '(x w32 ns pc)) + ;; MS-DOS and MS-Windows terminals have built-in support for + ;; function (symbol) keys + (memq system-type '(ms-dos windows-nt))))) + (declare-function x-display-screens "xfns.c" (&optional terminal)) (defun display-screens (&optional display) diff --git a/lisp/simple.el b/lisp/simple.el index 306df96766..857e0fc001 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -8690,7 +8690,7 @@ normal-erase-is-backspace-setup-frame (and (not noninteractive) (or (memq system-type '(ms-dos windows-nt)) (memq window-system '(w32 ns)) - (and (memq window-system '(x)) + (and (eq window-system 'x) (fboundp 'x-backspace-delete-keys-p) (x-backspace-delete-keys-p)) ;; If the terminal Emacs is running on has erase char @@ -8701,6 +8701,8 @@ normal-erase-is-backspace-setup-frame normal-erase-is-backspace) 1 0))))) +(declare-function display-symbol-keys-p "frame" (&optional display)) + (define-minor-mode normal-erase-is-backspace-mode "Toggle the Erase and Delete mode of the Backspace and Delete keys. @@ -8736,8 +8738,7 @@ normal-erase-is-backspace-mode (let ((enabled (eq 1 (terminal-parameter nil 'normal-erase-is-backspace)))) - (cond ((or (memq window-system '(x w32 ns pc)) - (memq system-type '(ms-dos windows-nt))) + (cond ((display-symbol-keys-p) (let ((bindings '(([M-delete] [M-backspace]) ([C-M-delete] [C-M-backspace]) -- 2.21.0 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0004-Introduce-new-defcustom-for-terminal-CUA-rectangle-c.patch >From 04766b452e895526f2ca196dad7cf05bab1e61ba Mon Sep 17 00:00:00 2001 From: Alexander Gramiak Date: Wed, 3 Apr 2019 14:06:45 -0600 Subject: [PATCH 4/4] Introduce new defcustom for terminal CUA rectangle commands This allows a user to set a non-meta modifier for their terminal should his/her terminal support it. See bug#35058 for background on this change. * lisp/emulation/cua-base.el (cua-rectangle-terminal-modifier-key): New defcustom. * lisp/emulation/cua-base.el (cua--shift-control-x-prefix): Use new defcustom. --- etc/NEWS | 6 ++++++ lisp/emulation/cua-base.el | 19 ++++++++++++++----- 2 files changed, 20 insertions(+), 5 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 1e64c0f15f..5c62daf2b9 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1247,6 +1247,12 @@ near the current column in Tabulated Lists (see variables +++ *** 'text-mode-variant' is now obsolete, use 'derived-mode-p' instead. +** CUA mode + +*** New defcustom 'cua-rectangle-terminal-modifier-key' +This defcustom is used instead of forcing the modifier key to +'meta in a terminal frame. + * New Modes and Packages in Emacs 27.1 diff --git a/lisp/emulation/cua-base.el b/lisp/emulation/cua-base.el index 302ef12386..105e1ab43d 100644 --- a/lisp/emulation/cua-base.el +++ b/lisp/emulation/cua-base.el @@ -427,7 +427,7 @@ cua-rectangle-mark-key (defcustom cua-rectangle-modifier-key 'meta "Modifier key used for rectangle commands bindings. -On non-window systems, always use the meta modifier. +On non-window systems, use `cua-rectangle-terminal-modifier-key'. Must be set prior to enabling CUA." :type '(choice (const :tag "Meta key" meta) (const :tag "Alt key" alt) @@ -435,6 +435,16 @@ cua-rectangle-modifier-key (const :tag "Super key" super)) :group 'cua) +(defcustom cua-rectangle-terminal-modifier-key 'meta + "Modifier key used for rectangle commands bindings in terminals. +Must be set prior to enabling CUA." + :type '(choice (const :tag "Meta key" meta) + (const :tag "Alt key" alt) + (const :tag "Hyper key" hyper) + (const :tag "Super key" super)) + :group 'cua + :version "27.1") + (defcustom cua-enable-rectangle-auto-help t "If non-nil, automatically show help for region, rectangle and global mark." :type 'boolean @@ -1237,10 +1247,9 @@ cua--shift-control-x-prefix (defun cua--init-keymaps () ;; Cache actual rectangle modifier key. (setq cua--rectangle-modifier-key - (if (and cua-rectangle-modifier-key - (memq window-system '(x))) - cua-rectangle-modifier-key - 'meta)) + (if (eq (framep (selected-frame)) t) + cua-rectangle-terminal-modifier-key + cua-rectangle-modifier-key)) ;; C-return always toggles rectangle mark (define-key cua-global-keymap cua-rectangle-mark-key 'cua-set-rectangle-mark) (unless (eq cua--rectangle-modifier-key 'meta) -- 2.21.0 --=-=-=-- From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Apr 2019 18:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alex Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.15544903552826 (code B ref 35058); Fri, 05 Apr 2019 18:53:02 +0000 Received: (at 35058) by debbugs.gnu.org; 5 Apr 2019 18:52:35 +0000 Received: from localhost ([127.0.0.1]:46299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCTx4-0000jW-T7 for submit@debbugs.gnu.org; Fri, 05 Apr 2019 14:52:35 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCTx1-0000jH-V3 for 35058@debbugs.gnu.org; Fri, 05 Apr 2019 14:52:32 -0400 Received: from fencepost.gnu.org ([209.51.188.10]:39886) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hCTwT-0001Ir-J4; Fri, 05 Apr 2019 14:52:19 -0400 Received: from [176.228.60.248] (port=4957 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hCTwR-00010D-LH; Fri, 05 Apr 2019 14:51:56 -0400 Date: Fri, 05 Apr 2019 21:51:43 +0300 Message-Id: <83k1g8b800.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87k1g8csve.fsf@gmail.com> (message from Alex on Fri, 05 Apr 2019 10:35:33 -0600) References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> <83a7hagv11.fsf@gnu.org> <87d0m4pcca.fsf@gmail.com> <83ef6kfhjf.fsf@gnu.org> <878swsp9wh.fsf@gmail.com> <838swsfdzb.fsf@gnu.org> <87r2ajbrhd.fsf@gmail.com> <83pnq3ejxe.fsf@gnu.org> <87h8be7s3t.fsf@gmail.com> <838swodi54.fsf@gnu.org> <87k1g8csve.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Alex > Cc: 35058@debbugs.gnu.org > Date: Fri, 05 Apr 2019 10:35:33 -0600 > > Okay, here's a new set of patches (excluding the same logb patch). Thanks, this LGTM, with a couple of nits: > +** CUA mode > + > +*** New defcustom 'cua-rectangle-terminal-modifier-key' Please add a period at the end of this sentence. > +This defcustom is used instead of forcing the modifier key to I'd say "allows to customize the modifier key ..." instead of "is used instead of ...". Also, please mark this entry with "---", as it doesn't need to be documented in any manuals. (The other NEWS entry as well.) From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Apr 2019 07:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Drew Adams Cc: 35058@debbugs.gnu.org, agrambot@gmail.com Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.155453514214158 (code B ref 35058); Sat, 06 Apr 2019 07:20:02 +0000 Received: (at 35058) by debbugs.gnu.org; 6 Apr 2019 07:19:02 +0000 Received: from localhost ([127.0.0.1]:46511 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCfbR-0003fy-9T for submit@debbugs.gnu.org; Sat, 06 Apr 2019 03:19:01 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50601) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCfbP-0003fm-3T for 35058@debbugs.gnu.org; Sat, 06 Apr 2019 03:18:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37242) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hCfbI-0007wp-0a; Sat, 06 Apr 2019 03:18:52 -0400 Received: from [176.228.60.248] (port=3075 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hCfbH-0002Vs-4W; Sat, 06 Apr 2019 03:18:51 -0400 Date: Sat, 06 Apr 2019 10:18:40 +0300 Message-Id: <83y34na9f3.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <558890e4-a519-48ec-8e9d-36d829a5c089@default> (message from Drew Adams on Mon, 1 Apr 2019 07:32:23 -0700 (PDT)) References: <<8736n4ndav.fsf@gmail.com>> <<83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com>> <<83a7hagv11.fsf@gnu.org>> <558890e4-a519-48ec-8e9d-36d829a5c089@default> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Date: Mon, 1 Apr 2019 07:32:23 -0700 (PDT) > From: Drew Adams > Cc: 35058@debbugs.gnu.org > > This is a great description, Eli. > > I hope it or similar is recorded somewhere in > code or code-related artifacts, not just in > mail threads. Thanks, I added commentary to frame.el, where these functions are defined. > BTW, where would the intended meaning of such > functions be recorded now? Currently their > doc is just the doc of `display-graphic-p', > as they are aliased. (Could/should they have > their own doc strings now, even if the behavior > is currently just `display-graphic-p'?) I don't think we have features to have separate doc strings for them, I hope the commentary I wrote is enough. From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Alex Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Apr 2019 05:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.155461393014180 (code B ref 35058); Sun, 07 Apr 2019 05:13:01 +0000 Received: (at 35058) by debbugs.gnu.org; 7 Apr 2019 05:12:10 +0000 Received: from localhost ([127.0.0.1]:47683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hD06D-0003gY-MS for submit@debbugs.gnu.org; Sun, 07 Apr 2019 01:12:09 -0400 Received: from mail-pl1-f176.google.com ([209.85.214.176]:38720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hD06A-0003fu-3Y; Sun, 07 Apr 2019 01:12:07 -0400 Received: by mail-pl1-f176.google.com with SMTP id f36so881331plb.5; Sat, 06 Apr 2019 22:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=9gFwTr1IcC1Zbzy8c1EGrrjFz9CELO1+ZpiT9eKn1kM=; b=eR/nbUsl96eQxCptFHPbwu4hS6buERmoZ6dzk7eFyCdZVMfutfMy7LEibJLWSMXeB2 41P//N+IDg0oOARZdFlBAk109FYb5mlhg1s9bKAS04zWGQG5nQfQasn2qUhRatbnwCTC 7zcNfIAG/9aumIV6cK/Pdc6dbtfMVxsJQ4heJ/GL3gf9nLSuidL2Mm1tJERY/H+BKfft Hj6CWfF/3pAuFuMle+qGbK5W1wA8h6mUSNb0kD14VMhPw10Eli4vlTVLnpJ5zlA3Z5dU BChWewLVNQ/1xH6+Ks7W9EZC6p3jUlhEu1jbeM4+MKDcu7ZvCmfHs5/YXGbFuPPetiux DbRg== 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=9gFwTr1IcC1Zbzy8c1EGrrjFz9CELO1+ZpiT9eKn1kM=; b=DaezjnGvxu4vQMGkJQ2Cw8FFKrGERKGBRE06fCEoeW+Yocua2rnmTnYAGBRjB4IB/w W1Z4o0M47QvzJJE3Ij9t2WbAUoYhPxcjUbc+x8NHEgxhD4rbXAlG2EUdK59d/+x7PjTI CtEntkvCN5FHyREFS1T7wTz4uy03qYs9kVC/mFdZIJk2186GBIyd950JbVaedvAUY2RD IwRp/3GtQdqDtIsh2zwD1eXXclybMJsV6DOWsXBrNXOILs01oAUDsK8/xNOJK9lZsgn8 BbyfWcJinPNQNLpBcr5Mtsjq1e+H+PuSPIFoPX+6nFYHLfdEdtj/0lICaByly14Z31Q9 5pdw== X-Gm-Message-State: APjAAAUXDchEFC9Z0hsl2K5xu51CEgaGNZG0xRD6VcJFkKigoFafcK84 40wdPXnjB8vw1iRo7A5sk3XCW/j/ X-Google-Smtp-Source: APXvYqxhndmOS+HT0vrDjbfYY9sU7vNomPxpGgTLnPRccytBAX6Ieqa7rY6HUXO5i0lBgGjOS0fn9w== X-Received: by 2002:a17:902:694c:: with SMTP id k12mr22713917plt.149.1554613919805; Sat, 06 Apr 2019 22:11:59 -0700 (PDT) Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id q81sm47345598pfi.102.2019.04.06.22.11.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 06 Apr 2019 22:11:59 -0700 (PDT) From: Alex References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> <83a7hagv11.fsf@gnu.org> <87d0m4pcca.fsf@gmail.com> <83ef6kfhjf.fsf@gnu.org> <878swsp9wh.fsf@gmail.com> <838swsfdzb.fsf@gnu.org> <87r2ajbrhd.fsf@gmail.com> <83pnq3ejxe.fsf@gnu.org> <87h8be7s3t.fsf@gmail.com> <838swodi54.fsf@gnu.org> <87k1g8csve.fsf@gmail.com> <83k1g8b800.fsf@gnu.org> Date: Sat, 06 Apr 2019 23:11:57 -0600 In-Reply-To: <83k1g8b800.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 05 Apr 2019 21:51:43 +0300") Message-ID: <87k1g6z9eq.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 35058 quit Okay, pushed as 8f6e479845..0c16bb5a39. From unknown Sat Sep 06 03:34:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35058: [PATCH] Use display-graphic-p in more cases Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Apr 2019 13:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35058 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Alex Cc: Eli Zaretskii , 35058@debbugs.gnu.org Received: via spool by 35058-submit@debbugs.gnu.org id=B35058.155464503314215 (code B ref 35058); Sun, 07 Apr 2019 13:51:02 +0000 Received: (at 35058) by debbugs.gnu.org; 7 Apr 2019 13:50:33 +0000 Received: from localhost ([127.0.0.1]:47859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hD8Br-0003hC-RW for submit@debbugs.gnu.org; Sun, 07 Apr 2019 09:50:33 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:57446) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hD8Bp-0003h3-MP for 35058@debbugs.gnu.org; Sun, 07 Apr 2019 09:50:30 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x37DoSGn006221; Sun, 7 Apr 2019 09:50:28 -0400 Received: by pastel.home (Postfix, from userid 20848) id E12AD6AD60; Sun, 7 Apr 2019 09:50:27 -0400 (EDT) From: Stefan Monnier Message-ID: References: <8736n4ndav.fsf@gmail.com> <83tvfjgilm.fsf@gnu.org> <875zry9x94.fsf@gmail.com> Date: Sun, 07 Apr 2019 09:50:27 -0400 In-Reply-To: <875zry9x94.fsf@gmail.com> (Alex's message of "Sun, 31 Mar 2019 22:15:35 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6519=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6519> : inlines <7048> : streams <1817973> : uri <2827783> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I wasn't sure either (I merely noticed the useless memq), but I just > checked the documentation of cua-rectangle-modifier-key, which states: > > On non-window systems, always use the meta modifier. > > So I changed the eq call to display-graphics-p. Is it okay to follow the > docstring here? IIUC the idea of this var is that many of the key-bindings cua-rectangle uses (when not using the meta modifier) are not properly handled by the vast majority of text-terminals (e.g. hitting C-RET will send Emacs the same events as just hitting RET). The meta modifier (which can be accessed as an ESC prefix when needed) doesn't suffer from the same problem. >>> - (when (memq (window-system frame) '(x w32 ns)) >>> + (when (display-graphic-p frame) >>> (x-focus-frame frame)) >> I don't see what display being GUI have to do with frame focus >> redirection. > The x-focus-frame here is the GUI-specific code related to frame focus > that calls x_focus_frame, which is only defined when HAVE_WINDOW_SYSTEM > is defined. This is one of the procedures that I'm planning to rename > with a gui prefix, so I believe display-graphic-p makes sense here. Arguably, the test should be removed and the function called unconditionally (or if it's not always defined, then the test should be (fboundp 'x-focus-frame)). > The definition of blink-cursor mode states: > This command is effective only on graphical frames. On text-only > terminals, cursor blinking is controlled by the terminal." I think this description is incorrect. blink-cursor-mode works just fine (under xterm at least), with the patch below. But I think this is not just a case of "it doesn't work": cursor-blinking can be configured in xterm independently from the application, so Emacs likely should just obey that choice, by default (whereas for GUI frames, Emacs is the only one who can decide it). Stefan diff --git a/lisp/frame.el b/lisp/frame.el index 6cb1247372..c7fe316c70 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -26,6 +26,7 @@ ;;; Code: (eval-when-compile (require 'cl-lib)) +(eval-when-compile (require 'subr-x)) ;For string-trim-right (cl-defgeneric frame-creation-function (params) "Method for window-system dependent functions to create a new frame. @@ -2480,14 +2481,34 @@ blink-cursor-timer-function (when (and (> blink-cursor-blinks 0) (<= (* 2 blink-cursor-blinks) blink-cursor-blinks-done)) (blink-cursor-suspend) - (add-hook 'post-command-hook 'blink-cursor-check))) + (add-hook 'post-command-hook #'blink-cursor-check)) + ;; FIXME: Under TTYs, apparently redisplay only obeys internal-show-cursor + ;; when there is something else to update on the screen. This is arguably + ;; a bug, but in the meantime we can circumvent it here by causing an + ;; artificial update which thus "forces" a cursor update. + (when (null window-system) + (let* ((message-log-max nil) + (msg (current-message)) + ;; Construct a dummy temp message different from the current one. + ;; This message usually flashes by too quickly to be visible, but + ;; occasionally it can be noticed, so make it "inconspicuous". + ;; Not too "inconspicuous", tho: just adding or removing a SPC at the + ;; end doesn't cause an update, for example. + (dummymsg (concat (if (> (length msg) 40) + (let ((msg (string-trim-right msg))) + (if (> (length msg) 2) + (substring msg 0 -2) + msg)) + msg) "-"))) + (message "%s" dummymsg) + (if msg (message "%s" msg) (message nil))))) (defun blink-cursor-end () "Stop cursor blinking. This is installed as a pre-command hook by `blink-cursor-start'. When run, it cancels the timer `blink-cursor-timer' and removes itself as a pre-command hook." - (remove-hook 'pre-command-hook 'blink-cursor-end) + (remove-hook 'pre-command-hook #'blink-cursor-end) (internal-show-cursor nil t) (when blink-cursor-timer (cancel-timer blink-cursor-timer) @@ -2506,15 +2527,7 @@ blink-cursor-suspend (defun blink-cursor--should-blink () "Determine whether we should be blinking. Returns whether we have any focused non-TTY frame." - (and blink-cursor-mode - (let ((frame-list (frame-list)) - (any-graphical-focused nil)) - (while frame-list - (let ((frame (pop frame-list))) - (when (and (display-graphic-p frame) (frame-focus-state frame)) - (setf any-graphical-focused t) - (setf frame-list nil)))) - any-graphical-focused))) + blink-cursor-mode) (defun blink-cursor-check () "Check if cursor blinking shall be restarted. @@ -2523,7 +2536,7 @@ blink-cursor-check `blink-cursor--should-blink' and returns its result." (let ((should-blink (blink-cursor--should-blink))) (when (and should-blink (not blink-cursor-idle-timer)) - (remove-hook 'post-command-hook 'blink-cursor-check) + (remove-hook 'post-command-hook #'blink-cursor-check) (blink-cursor--start-idle-timer)) should-blink))