From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Herman@debbugs.gnu.org, =?UTF-8?Q?G=C3=A9za?= 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, 1 Oct 2023 14:10:07 +0200 Message-ID: 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> <83r0me914z.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32063"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Cc: 66216@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 01 14:11:07 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 1qmvHu-00080f-1r for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Oct 2023 14:11:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qmvHg-0006PS-BX; Sun, 01 Oct 2023 08:10:52 -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 1qmvHe-0006PG-Hh for bug-gnu-emacs@gnu.org; Sun, 01 Oct 2023 08:10:50 -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 1qmvHe-0002lD-9P for bug-gnu-emacs@gnu.org; Sun, 01 Oct 2023 08:10:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qmvHq-0000zI-Dl for bug-gnu-emacs@gnu.org; Sun, 01 Oct 2023 08:11:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Herman@debbugs.gnu.org, =?UTF-8?Q?G=C3=A9za?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Oct 2023 12:11:02 +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.16961622393761 (code B ref 66216); Sun, 01 Oct 2023 12:11:02 +0000 Original-Received: (at 66216) by debbugs.gnu.org; 1 Oct 2023 12:10:39 +0000 Original-Received: from localhost ([127.0.0.1]:60750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmvHR-0000yZ-Fh for submit@debbugs.gnu.org; Sun, 01 Oct 2023 08:10:38 -0400 Original-Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]:51312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qmvHM-0000yE-Hk for 66216@debbugs.gnu.org; Sun, 01 Oct 2023 08:10:33 -0400 Original-Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5346b64f17aso11853101a12.2 for <66216@debbugs.gnu.org>; Sun, 01 Oct 2023 05:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696162210; x=1696767010; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=4nk7xtGrhdUtM9pS+1C35+ZefGDMzUdDi4Y2vDPDVEA=; b=RmMXKxUD9Hf7wSv38isMvIAzQJxopA+fSFh4l1OnsHS56QtdQrgkQWtmQ4K1xuxG6E yaIzf6/ESRmhWBXhhaLfqUG3U++9Qj34lc5rSQ4ME5Jbu4iwzh4WKPY8WQV+JmYu7xkV vFU7vAsk7+3kOmp2VTTWDfrV168e0dlEegmDX+xQpffh0B/zvnu4vY7T4dFyPHYcrmi8 nGWvT8cJBs0QTocPT+IDP/MyOwKiMmsCwPXUyu9JuUfcnFA+7c5TQ1GAOgsYWi9HUzpF Z+1g7TIOq5stoBGP4CL9zIn7b+egSL0NuJ5WrueE0t3wVYbzHaTh/sMLDSF2zwj6pMsy H1Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696162210; x=1696767010; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4nk7xtGrhdUtM9pS+1C35+ZefGDMzUdDi4Y2vDPDVEA=; b=jItOIkLPpC8SaZBrAICWGVJr5yH54nKv1S8aMeXG7+O4whRQnCemCuykBc0YpXYhpT awN9m07orkOeJPt7ugKgPd/xn76dJUhxGdK3jhLhGBgBGnTaR68BrVQF7azEUf7f7Ulj Xfic7jZQW7Yu8lpRuObiHwgDRZELMYSdWYkB5bmj1rVbkVURnMxrrOzNMMZ3jgFTXSkQ +l64bS5pfO/WvYZCTmhlc8B6Rvd9Cw1wb09ylCpdMJGuJDLfVkxn/qNO3vYFuoRd1frH V33P1Z+vUVXtqtQbTgXhhKnB9rvoKiNvCs3dShVMVT0qSR+CiYWmcF8uTb/kwCT8uB7o 79kg== X-Gm-Message-State: AOJu0YyJx+sbyor/EqXifLgGRx2rh3t3DLecwFsDn91EtkDT9yWv/h9M JPnrlcNOaeO9cAmeA7Q7uNvX3/Bd4nY= X-Google-Smtp-Source: AGHT+IHbkQm8tUSoRDk2XknhdVrxVdggo5QjWXx6ILuzGP3KE4R7Xf60l75XzdP4ebjMLrla2Ky9DA== X-Received: by 2002:a50:ee81:0:b0:52c:164:efe5 with SMTP id f1-20020a50ee81000000b0052c0164efe5mr7406695edr.39.1696162209747; Sun, 01 Oct 2023 05:10:09 -0700 (PDT) Original-Received: from [192.168.8.4] (netacc-gpn-104-239-178.pool.yettel.hu. [91.104.239.178]) by smtp.gmail.com with ESMTPSA id dm3-20020a05640222c300b0053635409213sm4814057edb.34.2023.10.01.05.10.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Oct 2023 05:10:09 -0700 (PDT) Content-Language: sv-FI In-Reply-To: <83r0me914z.fsf@gnu.org> 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:271609 Archived-At: On 10/1/23 10:51, Eli Zaretskii wrote: > 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. Yes, I meant that. If I want to know the line number of a particular line, then I use the indicator on the modeline. I wouldn't use display-line-numbers with 'visual, because it may not tell this number. With your suggestion, it's not possible to tell the line number. With magit working with overlays, it is. It's not "just happens to match", but designed this way. To me, it's clear that using overlays for this problem is a better solution than using a separate buffer. So far, you didn't say a single thing for which using a separate buffer is better. You're just suggesting this as workaround for Emacs's limitation. But it's an inferior solution. In an ideal world, not every package (which use newline-containing overlays) should accomodate to Emacs's limitation, but Emacs would be fixed to handle newline-containing overlays better. Note: I know that Emacs is free, developed by volunteers, etc., I don't want to be sound like someone who tells how to develop Emacs. But in the long term, this is the forward-looking solution. I know, someone has to do it, it's a large investment. > 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. I haven't noticed any problems how magit-blame works in this regard. Magit just decorates the buffer. And Emacs should be able to tell for a particular line its line number. This should be the easiest part, as Emacs doesn't have to do anything special, just tell the line number of the point (ignoring all overlays). Why is it fragile? >> 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. Do you mean vc-annotate, or something else? Is it possible to edit the annotate buffer? And blame information put in a header above the code chunk, just like magit's? How can I achieve these? >> Fair enough. Are these limitations documented? > Those that are important are indeed documented. I'm not sure what's documented and what's not. But, I think the fact that Emacs has limitations around newline-containing overlays/display text-properties is important. So if this is not documented, then it should be. Just I alone discovered 3-4 problems with it. Emacs has limitations, the manual can have a subsection to list them with a short description. If this limitation was documented, this bug and our whole discussion may not exist, saving time for both of us. Not just now, but I had previous similar bug reports. But now I learned the hard way that if Emacs has a bug related to newline-containing overlays, I should not report it.