GNU bug report logs - #13623
24.3.50; Redisplay issue with transient-mark-mode

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13623 in the body.
You can then email your comments to 13623 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lawrence Mitchell <wence <at> gmx.li>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Redisplay issue with transient-mark-mode
Date: Sun, 03 Feb 2013 22:05:15 +0000

When using word or sexp marking commands, the active region does not
always get highlighted.

emacs -Q
M-<
M-@ # note how ";; This" is selected, and highlighted in region-face
M-@ # ";; This buffer" is selected, however, " buffer" is not highlighted

Pressing C-l at this point, correctly shows the highlighted region.

This is with:

commit e6762a6d2dc65d3201c03d5995686112483dc4ff
Merge: 4ba48d0 6840160
Author: dancol <at> dancol.org <>
Date:   Sun Feb 3 09:02:56 2013 -0800

    Daniel Colascione 2013-02-03 
    * emacs.c: Use execvp, not execv, when DAEMON_MUST_EXEC

I'd previously updated and built on the 19th of January:

commit c5a8149837c5ed53655d4383dea3b8f29374b266
Author: Glenn Morris <rgm <at> gnu.org>
Date:   Sat Jan 19 18:40:49 2013 -0800

    * lisp-mode.el (emacs-lisp-mode-map): Add native profiler menu entries.


Which didn't demonstrate this behaviour, if that happens to help with
tracking the issue down.

Cheers,
Lawrence

In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2)
 of 2013-02-01 on e4300lm
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
System Description:	Ubuntu 12.04.1 LTS

Configured using:
 `configure --prefix=/home/lmitche4/Apps/emacs -C CFLAGS=-O0 -ggdb
 --no-create --no-recursion'

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-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
  line-number-mode: t
  transient-mark-mode: t

Message #8 received at 13623 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lawrence Mitchell <wence <at> gmx.li>, Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 13623 <at> debbugs.gnu.org
Subject: Re: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Mon, 04 Feb 2013 17:49:54 +0200

> From: Lawrence Mitchell <wence <at> gmx.li>
> Date: Sun, 03 Feb 2013 22:05:15 +0000
> 
> 
> When using word or sexp marking commands, the active region does not
> always get highlighted.
> 
> emacs -Q
> M-<
> M-@ # note how ";; This" is selected, and highlighted in region-face
> M-@ # ";; This buffer" is selected, however, " buffer" is not highlighted
> 
> Pressing C-l at this point, correctly shows the highlighted region.

Thanks, should be fixed now (revision 111673 on the trunk).

Dmitry, this bug and also 13626 were both caused by your changes in
revision 111647.  While the reason for the changes was to use non-Lisp
objects for some fields, several hunks in the changeset had no
relation whatsoever to that, and were highly questionable.  Example:

  -  /* If showing the region, and mark has changed, we must redisplay
  -     the whole window.  The assignment to this_line_start_pos prevents
  -     the optimization directly below this if-statement.  */
  -  if (((!NILP (Vtransient_mark_mode)
  -       && !NILP (BVAR (XBUFFER (w->buffer), mark_active)))
  -       != !NILP (w->region_showing))
  -      || (!NILP (w->region_showing)
  -         && !EQ (w->region_showing,
  -                 Fmarker_position (BVAR (XBUFFER (w->buffer), mark)))))
  -    CHARPOS (this_line_start_pos) = 0;

I don't understand why such non-trivial code is being dropped on the
floor without discussion.  And there were others like this in this
revision.

Please don't assume that any dropped code that is really needed will
cause bugs that will be immediately reported.  I've seen display bugs
that went unnoticed for months and even years.  In this case, we were
just lucky.

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lawrence Mitchell <wence <at> gmx.li>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Mon, 04 Feb 2013 17:20:21 +0000

Eli Zaretskii wrote:
>> From: Lawrence Mitchell <wence <at> gmx.li>
>> Date: Sun, 03 Feb 2013 22:05:15 +0000
>> Pressing C-l at this point, correctly shows the highlighted region.

> Thanks, should be fixed now (revision 111673 on the trunk).

[...]

Yes, works for me.

Cheers,
Lawrence
-- 
Lawrence Mitchell <wence <at> gmx.li>

Message #16 received at 13623-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lawrence Mitchell <wence <at> gmx.li>
Cc: 13623-done <at> debbugs.gnu.org
Subject: Re: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Mon, 04 Feb 2013 20:10:55 +0200

> From: Lawrence Mitchell <wence <at> gmx.li>
> Date: Mon, 04 Feb 2013 17:20:21 +0000
> 
> Eli Zaretskii wrote:
> >> From: Lawrence Mitchell <wence <at> gmx.li>
> >> Date: Sun, 03 Feb 2013 22:05:15 +0000
> >> Pressing C-l at this point, correctly shows the highlighted region.
> 
> > Thanks, should be fixed now (revision 111673 on the trunk).
> 
> [...]
> 
> Yes, works for me.

Thanks, closing.

Message #19 received at 13623 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lawrence Mitchell <wence <at> gmx.li>, 13623 <at> debbugs.gnu.org
Subject: Re: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Tue, 05 Feb 2013 08:54:05 +0400

On 02/04/2013 07:49 PM, Eli Zaretskii wrote:

> Dmitry, this bug and also 13626 were both caused by your changes in
> revision 111647.  While the reason for the changes was to use non-Lisp
> objects for some fields, several hunks in the changeset had no
> relation whatsoever to that, and were highly questionable.  Example:
>
>    -  /* If showing the region, and mark has changed, we must redisplay
>    -     the whole window.  The assignment to this_line_start_pos prevents
>    -     the optimization directly below this if-statement.  */
>    -  if (((!NILP (Vtransient_mark_mode)
>    -       && !NILP (BVAR (XBUFFER (w->buffer), mark_active)))
>    -       != !NILP (w->region_showing))
>    -      || (!NILP (w->region_showing)
>    -         && !EQ (w->region_showing,
>    -                 Fmarker_position (BVAR (XBUFFER (w->buffer), mark)))))
>    -    CHARPOS (this_line_start_pos) = 0;

Hm.  Although this is an obvious bug, are you sure that we must redisplay
the whole window even if the region doesn't span multiple lines? IIUC
it should be enough to redisplay the current line only.

Dmitry

Message #22 received at 13623 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lawrence Mitchell <wence <at> gmx.li>, 13623 <at> debbugs.gnu.org
Subject: Re: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Tue, 05 Feb 2013 16:07:47 +0400

[Message part 1 (text/plain, inline)]

On 02/05/2013 08:54 AM, Dmitry Antipov wrote:

> Hm.  Although this is an obvious bug, are you sure that we must redisplay
> the whole window even if the region doesn't span multiple lines? IIUC
> it should be enough to redisplay the current line only.

E.g. something like attached. This is the revert of 111673 plus special
treatment of single-line region.

Dmitry

[single_line_region.patch (text/plain, attachment)]

Message #25 received at 13623 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: wence <at> gmx.li, 13623 <at> debbugs.gnu.org
Subject: Re: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Tue, 05 Feb 2013 19:45:42 +0200

> Date: Tue, 05 Feb 2013 08:54:05 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> CC: Lawrence Mitchell <wence <at> gmx.li>, 13623 <at> debbugs.gnu.org
> 
> >    -  /* If showing the region, and mark has changed, we must redisplay
> >    -     the whole window.  The assignment to this_line_start_pos prevents
> >    -     the optimization directly below this if-statement.  */
> >    -  if (((!NILP (Vtransient_mark_mode)
> >    -       && !NILP (BVAR (XBUFFER (w->buffer), mark_active)))
> >    -       != !NILP (w->region_showing))
> >    -      || (!NILP (w->region_showing)
> >    -         && !EQ (w->region_showing,
> >    -                 Fmarker_position (BVAR (XBUFFER (w->buffer), mark)))))
> >    -    CHARPOS (this_line_start_pos) = 0;
> 
> Hm.  Although this is an obvious bug, are you sure that we must redisplay
> the whole window even if the region doesn't span multiple lines? IIUC
> it should be enough to redisplay the current line only.

As long as we don't restrict the 'region' face to a very small subset
of possible face customizations (e.g., just the background and the
foreground colors), and ignore the other attributes, an arbitrary face
change on one line might potentially affect many more lines in the
window.  E.g., try customizing the 'region' face to twice its normal
height.

And I'm not sure this is worth optimizing anyway: region changes are
relatively rare and almost always driven by user input, so I don't
think redisplay will become significantly faster as result of any
optimizations in this area.

Message #28 received at 13623 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: wence <at> gmx.li, 13623 <at> debbugs.gnu.org
Subject: Re: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Tue, 05 Feb 2013 19:46:38 +0200

> Date: Tue, 05 Feb 2013 16:07:47 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> CC: Lawrence Mitchell <wence <at> gmx.li>, 13623 <at> debbugs.gnu.org
> 
> > Hm.  Although this is an obvious bug, are you sure that we must redisplay
> > the whole window even if the region doesn't span multiple lines? IIUC
> > it should be enough to redisplay the current line only.
> 
> E.g. something like attached. This is the revert of 111673 plus special
> treatment of single-line region.

If you customize the font of 'region' face, you will see that
additional lines are affected anyway.

Message #31 received at 13623 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: wence <at> gmx.li, 13623 <at> debbugs.gnu.org
Subject: Re: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Wed, 06 Feb 2013 11:16:48 +0400

On 02/05/2013 09:45 PM, Eli Zaretskii wrote:

> As long as we don't restrict the 'region' face to a very small subset
> of possible face customizations (e.g., just the background and the
> foreground colors), and ignore the other attributes, an arbitrary face
> change on one line might potentially affect many more lines in the
> window.  E.g., try customizing the 'region' face to twice its normal
> height.

This looks terribly ugly, but works (at least, I don't see any glitches
while performing basic operations with the region).

> And I'm not sure this is worth optimizing anyway: region changes are
> relatively rare and almost always driven by user input, so I don't
> think redisplay will become significantly faster as result of any
> optimizations in this area.

I have a strong suspicion that this also applies to ~50% of xdisp.c
unless you're on 2400bps tty or remote X connection via 33600bps modem.

Dmitry

Message #34 received at 13623 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: wence <at> gmx.li, Eli Zaretskii <eliz <at> gnu.org>, 13623 <at> debbugs.gnu.org
Subject: Re: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Wed, 06 Feb 2013 09:31:44 -0500

>> And I'm not sure this is worth optimizing anyway: region changes are
>> relatively rare and almost always driven by user input, so I don't
>> think redisplay will become significantly faster as result of any
>> optimizations in this area.
> I have a strong suspicion that this also applies to ~50% of xdisp.c
> unless you're on 2400bps tty or remote X connection via 33600bps modem.

For my use case, the optimisations that matter are the ones that avoid
looking at the unmodified (and mostly all iconified) frames when I work
within a frame or switch between two frames (or maybe 3 at most: the
origin, the destination and the minibuffer-only frame).


        Stefan

Message #37 received at 13623 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: wence <at> gmx.li, Eli Zaretskii <eliz <at> gnu.org>, 13623 <at> debbugs.gnu.org
Subject: Re: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Wed, 06 Feb 2013 19:14:43 +0400

On 02/06/2013 06:31 PM, Stefan Monnier wrote:

> For my use case, the optimisations that matter are the ones that avoid
> looking at the unmodified (and mostly all iconified) frames when I work
> within a frame or switch between two frames (or maybe 3 at most: the
> origin, the destination and the minibuffer-only frame).

This is a question of splitting global state between frames because current
tricks like ++windows_or_buffers_changed effectively prevents single-frame
redisplay optimizations.  I have a few experimental patches with per-frame
fonts_changed_p and cursor_type_changed flags. Since font/cursor changes
are rare, the effect is negligible, but this opens the way towards more
interesting things. On the other side, I suspect that the most of users
are either 1) uses single-frame configuration or 2) uses reasonably modern
hardware where the complete redisplay (all frames) is faster than the period
between two keystrokes and so doesn't affect an editing experience.

Dmitry

Message #40 received at 13623 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: wence <at> gmx.li, 13623 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: Re: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Wed, 06 Feb 2013 20:04:17 +0200

> Date: Wed, 06 Feb 2013 19:14:43 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> CC: Eli Zaretskii <eliz <at> gnu.org>, wence <at> gmx.li, 13623 <at> debbugs.gnu.org
> 
> On the other side, I suspect that the most of users
> are either 1) uses single-frame configuration or 2) uses reasonably modern
> hardware where the complete redisplay (all frames) is faster than the period
> between two keystrokes and so doesn't affect an editing experience.

I doubt many users use only one frame.  I certainly don't, although my
usage patterns are pretty conservative, nowhere near Stefan's.

As for full redisplay: please remember that there are 2 aspects to
that: (1) on the xdisp.c level, which is device independent, and
(2) on the device-dependent xterm.c/w32term.c/nsterm.m etc. level.
Even if on the xdisp.c level we do a complete redisplay of a window,
update_frame and its subroutines compare the desired and the current
display and only redraw the lines that are different.  Therefore, you
could do a complete redisplay on xdisp.c level, and then redraw very
little or even nothing at all, even if your video hardware is 10 years
old.

I'm saying that because due to this 2-level optimization, the hardware
speed is rarely seen in Emacs.

Message #43 received at 13623 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: wence <at> gmx.li, 13623 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: Re: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Wed, 06 Feb 2013 20:23:04 +0200

> Date: Wed, 06 Feb 2013 19:14:43 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> CC: Eli Zaretskii <eliz <at> gnu.org>, wence <at> gmx.li, 13623 <at> debbugs.gnu.org
> 
> I have a few experimental patches with per-frame fonts_changed_p and
> cursor_type_changed flags. Since font/cursor changes are rare, the
> effect is negligible, but this opens the way towards more
> interesting things.

What exactly is the strategy of enabling per-frame redisplay
optimizations?  As you point out, font and cursor type changes are not
the important cost drivers.  The question is: what is?  IOW, how do
you know which changes affect what frames?

The current display engine does not try to optimize per-frame
redisplay (except on a TTY, but let's forget about that for a moment).
It tries to optimize per-window redisplay.  I don't see what's wrong
with this approach; in fact, I think for GUI frames it's better than
per-frame optimizations.  Therefore, I think we should improve
optimizations by more aggressively detecting windows that need not be
updated, instead of turning our attention to frames.

In any case, the first step towards any intelligent improvements in
redisplay optimizations would be to compile a list of use cases where
we currently give up and redisplay entire windows, and where this
thorough redisplay really matters, i.e. we can actually see and
measure the effect of this.

Another area of redisplay optimizations would be the infamous
very-long-lines use case.  (Personally, I think this one is the single
most important deficiency in the current display engine, by far more
important than any other display problem.)

Message #46 received at 13623 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: wence <at> gmx.li, Dmitry Antipov <dmantipov <at> yandex.ru>, 13623 <at> debbugs.gnu.org
Subject: Re: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Wed, 06 Feb 2013 15:30:12 -0500

> per-frame optimizations.  Therefore, I think we should improve
> optimizations by more aggressively detecting windows that need not be
> updated, instead of turning our attention to frames.

Agreed.

> In any case, the first step towards any intelligent improvements in
> redisplay optimizations would be to compile a list of use cases where
> we currently give up and redisplay entire windows, and where this

One case where I notice performance sucks is when the minibuffer is in
use (in my minibuffer-only frame), and I switch to another frame and try
to work there.


        Stefan

Message #49 received at 13623 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: wence <at> gmx.li, dmantipov <at> yandex.ru, 13623 <at> debbugs.gnu.org
Subject: Re: bug#13623: 24.3.50; Redisplay issue with transient-mark-mode
Date: Thu, 07 Feb 2013 05:41:19 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Dmitry Antipov <dmantipov <at> yandex.ru>,  wence <at> gmx.li,  13623 <at> debbugs.gnu.org
> One case where I notice performance sucks is when the minibuffer is in
> use (in my minibuffer-only frame), and I switch to another frame and try
> to work there.

I suggest to create a new bug report with a recipe to reproduce this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.