unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "João Távora" <joaotavora@gmail.com>
Cc: 54488@debbugs.gnu.org, dgutov@yandex.ru
Subject: bug#54488: 29.0.50; move-to-column/overlay-related regression in latest master, perhaps 28?
Date: Wed, 23 Mar 2022 16:21:00 +0200	[thread overview]
Message-ID: <83bkxweomr.fsf@gnu.org> (raw)
In-Reply-To: <CALDnm52DnDyVQK0nYZmNiEhtWqRjrWkdBodff8e+rfboed-+8w@mail.gmail.com> (message from João Távora on Wed, 23 Mar 2022 11:08:55 +0000)

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 23 Mar 2022 11:08:55 +0000
> Cc: Dmitry Gutov <dgutov@yandex.ru>, 54488@debbugs.gnu.org
> 
>  PS: I do invite you to read that old Eglot issue.  Since you're an
>  expert on coding system conversion, maybe you know of a better, faster
>  way to find the correct LSPish column in an Emacs buffer.  Maybe the
>  whole search idea is completely overwrought.
> 
> These issues may give additional context about the need for this particular
> move-to-column dance.
> 
> https://github.com/joaotavora/eglot/issues/125 (the one I gave you already) 
> https://github.com/joaotavora/eglot/issues/124 (the bug that prompted the 125 fix)
> https://github.com/joaotavora/eglot/issues/361 (an easier to grasp manifestation of the problem) 

I see that you had problems reconciling the LSP idea of "columns" with
that of Emacs.  If LSP indeed works in UTF-16 (I don't know, but I
have no reason to doubt that), then I think your solution is decent,
although actually encoding stuff could be overhead: after all, whether
a given codepoint takes 1 or 2 UTF-16 code units can be easily
established by looking at the codepoints themselves.  But that's an
optimization.

> But I still do think there was a regression in Emacs somewhere: I've described an
> unequivocal reproduction recipe, just not something that can be shared among us, 
> due to technical (or licensing) hurdles.

It is this single issue that puzzles me.  AFAIU, you are saying that
in some situation, calling move-to-column causes point to be set
outside of the current accessible region of the buffer, which I cannot
understand how it can happen.  Everything I tried yields the same
correct result: move-to-column always stops at the end of the
accessible portion of the buffer, no matter what ridiculously large
argument I pass to it.  And the change which we think caused this
problem just makes the column values for some situation smaller or
larger, that's all, so it "just" affects the argument to
move-to-column.





  reply	other threads:[~2022-03-23 14:21 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
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 [this message]
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=83bkxweomr.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).