GNU bug report logs - #54488
29.0.50; move-to-column/overlay-related regression in latest master, perhaps 28?

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: 54488 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: bug#54488: 29.0.50; move-to-column/overlay-related regression in latest master, perhaps 28?
Date: Mon, 21 Mar 2022 14:32:15 +0200

> From: João Távora <joaotavora <at> gmail.com>
> Date: Mon, 21 Mar 2022 06:54:46 +0000
> Cc: dgutov <at> yandex.ru
> 
> In short, it seems that in the presence of the overlays created by
> company-mode and in presence of a narrowing, the move-to-column function
> does not function the way it used to.

Yes.

> Eglot uses 'move-to-column' to go that precise place and highlight the
> warning.
> 
> In Emacs 27.2, move-to-column is unaffected by previous company-mode
> overlays, even if the current line is being co-used visually by the
> overlay.  It moves to the right buffer position.
> 
> In Emacs master, this isn't true.  It seems to be confounded by the
> company-mode overlay and moves to eob, _beyond the narrowing_, which
> eventually breaks Eglot with a backtrace such as this one:

Emacs 29 has a fix for an old bug, whereby current-column etc. didn't
take display strings and overlays into account; now they do.

Of course, it could be that this fix introduced a bug in some
not-so-simple situations, so I'd appreciate if you could show a simple
recipe to reproduce the problem without the need of firing up
company-mode and/or Eglot.

Previous Next

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