GNU bug report logs -
#16822
24.3.50; show-paren-mode adds confusion to active region
Previous Next
Reported by: yynyygy <at> gmail.com
Date: Thu, 20 Feb 2014 07:45:02 UTC
Severity: minor
Tags: moreinfo, wontfix
Found in version 24.3.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16822 in the body.
You can then email your comments to 16822 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16822
; Package
emacs
.
(Thu, 20 Feb 2014 07:45:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
yynyygy <at> gmail.com
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 20 Feb 2014 07:45:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
When show-paren-mode is on, it adds confusion to the active
region. Suppose I have some text which is (hello),
1. I set the region to (hello and place the cursor on the left paren.
2. I set the region to (hello) and place the cursor on the left paren.
Note that in Case 1, the right paren is not part of the region while in
Case 2 it is. In the two cases above, I get exactly the same color on
the screen, then how can I distinguish between these two different
cases?
Compared to the more rational behavior of Emacs 24.3, I think the paren
which is part of the region should have the same color with the region
while the paren which is not part of the region can has matching paren
color. In this way, the user can tell which part is selected and which
part is not.
In GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.8.7)
of 2014-02-19 on gentoo
Windowing system distributor `The X.Org Foundation', version 11.0.11403000
Configured using:
`configure --prefix=/usr/local/emacs/'
Important settings:
value of $LC_COLLATE: C
value of $LC_CTYPE: zh_CN.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Messages
Minor modes in effect:
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
Recent input:
M-x r e p o <tab> r <tab> <return> M <backspace> s
h o w - p a r e n - m o d e SPC a d d SPC c o n f <backspace>
<backspace> <backspace> <backspace> <backspace> s SPC
c o n f u s i o C-g C-h f t r a n <tab> s <backspace>
i <tab> <return> C-x o C-n C-n C-n C-n C-n C-n C-n
C-l C-n C-n C-n C-n C-n C-n C-l C-n C-n C-n C-n C-l
C-n C-n C-n C-l C-n C-n C-n C-l q M-x r e C-g C-x b
<tab> <return> M-x r e p o <tab> r <tab> <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
Quit
Type C-x 1 to delete the help window, C-M-v to scroll help.
Quit
Making completion list... [2 times]
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils help-mode easymenu time-date china-util
tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16822
; Package
emacs
.
(Thu, 20 Feb 2014 17:45:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 16822 <at> debbugs.gnu.org (full text, mbox):
> When show-paren-mode is on, it adds confusion to the active
> region. Suppose I have some text which is (hello),
>
> 1. I set the region to (hello and place the cursor on the left paren.
> 2. I set the region to (hello) and place the cursor on the left paren.
>
> Note that in Case 1, the right paren is not part of the region while in
> Case 2 it is. In the two cases above, I get exactly the same color on
> the screen, then how can I distinguish between these two different
> cases?
>
> Compared to the more rational behavior of Emacs 24.3, I think the paren
> which is part of the region should have the same color with the region
> while the paren which is not part of the region can has matching paren
> color. In this way, the user can tell which part is selected and which
> part is not.
Well put.
Yes, it used to be the case that the region highlighting was used
to show clearly what text is in the region (each char), as specified
by the doc:
http://www.gnu.org/software/emacs/manual/html_node/elisp/Displaying-Faces.html
That policy was changed recently, introducing the behavior change
that you report. Now, other highlighting can take precedence
visually over region highlighting for various chars of the region.
Some people like the change. Some don't. Regression or improvement -
take your pick. (No, you cannot take your pick in practice, e.g.,
via customization. But you can at least make up your own mind.)
If you are interested, see bugs #15899, #16192, #15618, and this very
long emacs-devel thread:
http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01272.html
15899: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15899
16192: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16192
15618: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15618
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16822
; Package
emacs
.
(Thu, 20 Feb 2014 21:45:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 16822 <at> debbugs.gnu.org (full text, mbox):
> take your pick. (No, you cannot take your pick in practice, e.g.,
> via customization. But you can at least make up your own mind.)
Maybe not via M-x customize, indeed, but since it's now written in
Elisp, you definitely can change it in your ~/.emacs.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16822
; Package
emacs
.
(Thu, 15 Jul 2021 04:56:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 16822 <at> debbugs.gnu.org (full text, mbox):
yynyygy <at> gmail.com writes:
> When show-paren-mode is on, it adds confusion to the active
> region. Suppose I have some text which is (hello),
>
> 1. I set the region to (hello and place the cursor on the left paren.
> 2. I set the region to (hello) and place the cursor on the left paren.
>
> Note that in Case 1, the right paren is not part of the region while in
> Case 2 it is. In the two cases above, I get exactly the same color on
> the screen, then how can I distinguish between these two different
> cases?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16822
; Package
emacs
.
(Thu, 15 Jul 2021 05:00:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 16822 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
yynyygy <at> gmail.com writes:
> When show-paren-mode is on, it adds confusion to the active
> region. Suppose I have some text which is (hello),
>
> 1. I set the region to (hello and place the cursor on the left paren.
> 2. I set the region to (hello) and place the cursor on the left paren.
>
> Note that in Case 1, the right paren is not part of the region while in
> Case 2 it is. In the two cases above, I get exactly the same color on
> the screen, then how can I distinguish between these two different
> cases?
This is still the case in Emacs 28. Whether I put the mark after the
"o" or after the ")", and then go to the start of the line (in
*scratch*), I get this displayed:
[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
Perhaps the solution here is just to introduce a new face for parens
that are part of the region? Any opinions?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 15 Jul 2021 05:00:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16822
; Package
emacs
.
(Thu, 15 Jul 2021 06:54:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 16822 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Thu, 15 Jul 2021 06:59:21 +0200
> Cc: 16822 <at> debbugs.gnu.org
>
> yynyygy <at> gmail.com writes:
>
> > When show-paren-mode is on, it adds confusion to the active
> > region. Suppose I have some text which is (hello),
> >
> > 1. I set the region to (hello and place the cursor on the left paren.
> > 2. I set the region to (hello) and place the cursor on the left paren.
> >
> > Note that in Case 1, the right paren is not part of the region while in
> > Case 2 it is. In the two cases above, I get exactly the same color on
> > the screen, then how can I distinguish between these two different
> > cases?
>
> This is still the case in Emacs 28. Whether I put the mark after the
> "o" or after the ")", and then go to the start of the line (in
> *scratch*), I get this displayed:
> [...]
> Perhaps the solution here is just to introduce a new face for parens
> that are part of the region? Any opinions?
I admit that I don't understand the problem. Why should the display
be different in these two cases? It sounds like the (unspelled-out)
assumption is that showing the region is more important than showing
the (mis)matched parens? But if this is the assumption, then I don't
think I agree: show-paren-mode is for _temporary_ display of the
parens, so if it temporarily obscures the region, it's perfectly okay.
Adding a new face would bump into the problem of making sure the
colors of this new face are always visible and distinguishable from
the other two colors. I don't see how that could work reliably.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16822
; Package
emacs
.
(Thu, 15 Jul 2021 08:46:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 16822 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I admit that I don't understand the problem. Why should the display
> be different in these two cases? It sounds like the (unspelled-out)
> assumption is that showing the region is more important than showing
> the (mis)matched parens? But if this is the assumption, then I don't
> think I agree: show-paren-mode is for _temporary_ display of the
> parens, so if it temporarily obscures the region, it's perfectly okay.
>
> Adding a new face would bump into the problem of making sure the
> colors of this new face are always visible and distinguishable from
> the other two colors. I don't see how that could work reliably.
I was thinking that perhaps the region-blink-face would tweak the
foreground (while the normal only tweaks the background), so by merging
we'd see some difference.
But you're right -- it's hard to see what the use case here is, really,
beyond "it'd be nice". So I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) wontfix.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 15 Jul 2021 08:47:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
16822 <at> debbugs.gnu.org and yynyygy <at> gmail.com
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 15 Jul 2021 08:47:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 12 Aug 2021 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 229 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.