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#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline Date: Sun, 01 Oct 2023 11:51:08 +0300 Message-ID: <83r0me914z.fsf@gnu.org> References: <83zg15z0a8.fsf@gnu.org> <99a86a00-20d8-446f-336a-1f405e07d59f@gmail.com> <834jjdyp6b.fsf@gnu.org> <67dcfd75-204d-f2ae-9a76-6b4eaec67197@gmail.com> <83bkdja8d2.fsf@gnu.org> <000f4e25-a432-57ce-9aaf-140dcfbd73eb@gmail.com> <83a5t3a7fu.fsf@gnu.org> <40ca88d3-e25d-e24f-6a54-5a5fc6c6f136@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="39127"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 66216@debbugs.gnu.org To: Herman =?UTF-8?Q?G=C3=A9za?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 01 10:52:05 2023 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 1qmsBI-0009nX-SN for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Oct 2023 10:52:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qmsB1-0000IS-3V; Sun, 01 Oct 2023 04:51:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qmsB0-0000IK-48 for bug-gnu-emacs@gnu.org; Sun, 01 Oct 2023 04:51:46 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qmsAz-0008L1-SL for bug-gnu-emacs@gnu.org; Sun, 01 Oct 2023 04:51:45 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qmsBF-0000Y3-Mw for bug-gnu-emacs@gnu.org; Sun, 01 Oct 2023 04:52: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: Sun, 01 Oct 2023 08:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66216 X-GNU-PR-Package: emacs Original-Received: via spool by 66216-submit@debbugs.gnu.org id=B66216.16961502952069 (code B ref 66216); Sun, 01 Oct 2023 08:52:01 +0000 Original-Received: (at 66216) by debbugs.gnu.org; 1 Oct 2023 08:51:35 +0000 Original-Received: from localhost ([127.0.0.1]:60539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmsAo-0000XI-HB for submit@debbugs.gnu.org; Sun, 01 Oct 2023 04:51:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34358) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmsAl-0000X1-PO for 66216@debbugs.gnu.org; Sun, 01 Oct 2023 04:51:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qmsAQ-0008DB-K7; Sun, 01 Oct 2023 04:51:10 -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=hdckSAtjLllHT0KjPgzy5jkv8peeVzFsyPrrPXByUIk=; b=GyfceLeOKKW3qGjiTqRZ YXowJ0UPWVidBTtbuQeh9W0CI8EcrAxa4of09Eryb7PhHmiL5Zy3h/+i6gYXb6TwZp5+yDA1+ElBp 2t1d5/d6YA6EDGmxH37udX9VDFaxRYbzf1aNZZZsSK6a1OquYzzr5Joya9PpNPedvysuPqmbCNquW +yxYmB7y5jD0i+57srY59ipEzyXguRDpgy5HWEZs8nuukGeYEfbA6KGNDJSgd8OFS5Pc6VcljlKUG W64HuVjkc962Wp4WdvKbNVfVLNSoJ+0eYP6tSCGQxRdk/Bltb2bgT7nXFY8k7/xUzI0agtuOKaTfS 2vuPskjKmWs1sQ==; In-Reply-To: <40ca88d3-e25d-e24f-6a54-5a5fc6c6f136@gmail.com> (message from Herman, =?UTF-8?Q?G=C3=A9za?= on Sat, 30 Sep 2023 21:15:49 +0200) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:271599 Archived-At: > Date: Sat, 30 Sep 2023 21:15:49 +0200 > Cc: 66216@debbugs.gnu.org > From: Herman, Géza > > > > On 9/30/23 19:37, Eli Zaretskii wrote: > >> > >> Then line numbers will be incorrect > > Why not? it depends on how the buffer text is generated, doesn't it? > This is an example of magit's default blame presentation mode: > http://www.mycpu.org/images/magit-blame.jpeg > > The header in front of each code chunk is an overlay. If we wanted to > implement this without overlays (just simple text lines with text > properties), then the headers will receive a line number, making the > original line number incorrect. I see no line numbers in the screenshot you posted. If you mean the line number displayed in the mode line, then this is just one way of showing line numbers, and it just happens to match the line numbers of the source file when overlay strings are used. Other methods of line number might not behave like that: for example, if you set display-line-numbers to the value 'visual', the "fake" newlines produced by overlays will be counted as legitimate lines, and the line counts will be wrong. My conclusion is that relying on line-number correspondence is fragile, and for best results the blame display should show the line numbers produced by Git. > >> and also the buffer won't be editable. > > That is easily made possible from Lisp, isn't it? > How? The optimal solution is to edit the original buffer right away, > just like how magit currently works. Maybe it's possible to sync between > the scratch and the original buffer somehow. But this solution is > awkward, and I'm sure it has a lot of pitfalls. Well, the built-in VC mode solves all those issues nicely without using any overlays. So it isn't as difficult as you seem to think. > > A Lisp program written for Emacs definitely _should_ consider > > limitations and restrictions of the Emacs infrastructure it uses, if > > it wants to present a convenient, efficient, and well-looking > > interface to the users. > Fair enough. Are these limitations documented? Those that are important are indeed documented. > Multiple-line overlays seem to work well in a lot of cases, several > packages use it. It is just there are some cases where they don't work > how one may expect. So one might think that such overlays are fully > supported, and these cases are just bugs that can be fixed without too > much work. Like I said, a simple solution is for Magit to override the default definition of scroll-up-line.