unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: joaotavora@gmail.com, dgutov@yandex.ru
Cc: 54488@debbugs.gnu.org
Subject: bug#54488: 29.0.50; move-to-column/overlay-related regression in latest master, perhaps 28?
Date: Tue, 22 Mar 2022 16:31:39 +0200	[thread overview]
Message-ID: <834k3qf48k.fsf@gnu.org> (raw)
In-Reply-To: <835yo6f5tu.fsf@gnu.org> (message from Eli Zaretskii on Tue, 22 Mar 2022 15:57:17 +0200)

> Date: Tue, 22 Mar 2022 15:57:17 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 54488@debbugs.gnu.org, dgutov@yandex.ru
> 
> I think I see the problem.  Stay tuned.

I definitely see a problem with display strings with embedded
newlines, but I don't think I understand how it affects your use case.

Try this simple recipe:

  emacs -Q
  M-: (overlay-put (make-overlay 91 100) 'display "FOOBAR\nBAZQUUX") RET

You should then see this in *scratch (I indented by 2 columns, so it
stands out):

  ;; This buffer is for text that is not saved, and for Lisp evaluation.
  ;; To create a fileFOOBAR
  BAZQUUXt it with C-x C-f and enter text in its buffer.

(with the "FOOBAR\nBAZQUUX" part intangible, i.e. you cannot put the
cursor inside).

Now go to the 't' at the end of "BAZQUUXt" and type "C-x =".  In Emacs
28 and earlier you will see "column=28", in Emacs 29 you will see
"column=32".  This is because Emacs 28 ignores the display string and
examines only the buffer text, which is "covered" by the display
property.  By contrast, Emacs 29 ignores the "covered" buffer text
(since it's invisible on display) and examines only the characters of
the display string.  Since the newline has a width of zero, we get 9
columns between "file" and "t with" in Emacs 28, but 13 in Emacs 29.

So yes, Emacs 29 behaves differently, but the important part is that
both Emacs 28 and Emacs 29 are wrong: the _real_ column at 't' is 7
(columns are zero-based).  IOW, both Emacs 28 and Emacs 29 fail to
account for the fact that the newline inside the display string resets
the column to zero.

I could perhaps come up with a solution for that, and have the above
snippet correctly return 7 as the column.  But I don't see how this
will help company-mode and/or Eglot, since the value returned by Emacs
28 makes no more sense than the value returned by Emacs 29.

So I need your help with understanding what exactly fails in the
original use case, due to this change.  Specifically, how does the
code involved in this use move-to-column/current-column when there are
display strings with embedded newlines around?

TIA





  reply	other threads:[~2022-03-22 14:31 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21  6:54 bug#54488: 29.0.50; move-to-column/overlay-related regression in latest master, perhaps 28? João Távora
2022-03-21 12:32 ` Eli Zaretskii
2022-03-21 16:37   ` João Távora
2022-03-21 17:05     ` Eli Zaretskii
2022-03-21 21:59       ` João Távora
2022-03-21 23:14         ` Dmitry Gutov
2022-03-22  9:48           ` João Távora
2022-03-22 12:16             ` Eli Zaretskii
2022-03-22 13:57               ` Eli Zaretskii
2022-03-22 14:31                 ` Eli Zaretskii [this message]
2022-03-22 14:54                   ` João Távora
2022-03-22 15:22                     ` Eli Zaretskii
2022-03-22 16:06                       ` João Távora
2022-03-22 16:53                         ` Eli Zaretskii
2022-03-22 21:05                           ` João Távora
2022-03-22 23:55                             ` Dmitry Gutov
2022-03-23  1:11                               ` João Távora
2022-03-23  3:39                                 ` Eli Zaretskii
2022-03-23 10:10                                   ` João Távora
2022-03-23 11:08                                     ` João Távora
2022-03-23 14:21                                       ` Eli Zaretskii
2022-03-24 15:01                                         ` João Távora
2022-03-24 15:29                                           ` Eli Zaretskii
2022-03-24 16:03                                             ` João Távora
2022-03-24 16:59                                               ` Eli Zaretskii
2022-03-23  3:34                               ` Eli Zaretskii
2022-03-23  3:29                             ` Eli Zaretskii
2022-03-23 10:04                               ` João Távora
2022-03-23 13:23                                 ` Eli Zaretskii
2022-03-24 14:54                                   ` João Távora
2022-03-22 12:33             ` Dmitry Gutov
2022-03-22 13:50               ` João Távora

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=834k3qf48k.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=54488@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    --cc=joaotavora@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).