From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs 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 Message-ID: <83bkxweomr.fsf@gnu.org> References: <87bkxzdccp.fsf@gmail.com> <831qyvfpv4.fsf@gnu.org> <83fsnbfd72.fsf@gnu.org> <8735jbc6gj.fsf@gmail.com> <6095582d-7065-8089-e8c7-857f070f8ce2@yandex.ru> <87y212b9nt.fsf@gmail.com> <83a6difahu.fsf@gnu.org> <835yo6f5tu.fsf@gnu.org> <834k3qf48k.fsf@gnu.org> <87r16uavhm.fsf@gmail.com> <83zglidnbs.fsf@gnu.org> <83y212dj2w.fsf@gnu.org> <83mthhe3rp.fsf@gnu.org> <87fsn9f07t.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12040"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 54488@debbugs.gnu.org, dgutov@yandex.ru To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Mar 23 15:22:21 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nX1sT-0002y1-FY for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Mar 2022 15:22:21 +0100 Original-Received: from localhost ([::1]:35332 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nX1sS-0006Kx-72 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Mar 2022 10:22:20 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34550) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nX1sA-0006Km-8Z for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2022 10:22:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51521) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nX1s9-00029c-WC for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2022 10:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nX1s9-0001p5-Io for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2022 10:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Mar 2022 14:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54488 X-GNU-PR-Package: emacs Original-Received: via spool by 54488-submit@debbugs.gnu.org id=B54488.16480452796947 (code B ref 54488); Wed, 23 Mar 2022 14:22:01 +0000 Original-Received: (at 54488) by debbugs.gnu.org; 23 Mar 2022 14:21:19 +0000 Original-Received: from localhost ([127.0.0.1]:45418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nX1rS-0001ny-PV for submit@debbugs.gnu.org; Wed, 23 Mar 2022 10:21:19 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nX1rR-0001nl-Gb for 54488@debbugs.gnu.org; Wed, 23 Mar 2022 10:21:17 -0400 Original-Received: from [2001:470:142:3::e] (port=37300 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nX1rM-0001vh-5s; Wed, 23 Mar 2022 10:21:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=sUlQ/G36BBfJZ2cZtslIYtlSPghMNlH6we6fkeFc1qI=; b=FiB7fOsVzm9yqPhk7ts/ ZztfT1k8tYk5E2OCD5VL7sQ9HpmJ83Qcqg3/olV//W8HW21DMdpAB3nfPiBemqaHZNJVMz91Zqp5C sA1Nb3NNkmsrsBDFDA61fdnuUOuk5dIR2MECHpaOIZ/fNqB5HqOEaa0tOTknccwfh+ERbigIwNsf4 c3BGHRuwkjyArO3TKEqZmJMMbuQsg/MATpArvJXLnHDEetNOPUUMZEQ731J+PVWdsznp7U4D0PiZH UL23mFtYRT9fGLYRrUWcvwTHpjUrrjJcAz/KDtqnHDRw/zjsdJ7HC0FTcQ0ecwT+fSe7TPS3GQeCH 1iSyZudHXGLTlQ==; Original-Received: from [87.69.77.57] (port=4715 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nX1rL-0001B5-3e; Wed, 23 Mar 2022 10:21:11 -0400 In-Reply-To: (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Wed, 23 Mar 2022 11:08:55 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:228813 Archived-At: > From: João Távora > Date: Wed, 23 Mar 2022 11:08:55 +0000 > Cc: Dmitry Gutov , 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.