From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Fix two bugs in removing bookmark fringe marks (bug#70019) Date: Sun, 21 Apr 2024 22:51:43 -0500 Message-ID: <87jzkqawc0.fsf@red-bean.com> References: <87r0f26ia6.fsf@red-bean.com> <87zftoq2fp.fsf@red-bean.com> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11552"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Emacs Developers , 70019@debbugs.gnu.org To: Dani Moncayo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 22 05:52:35 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rykjK-0002mF-Iw for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Apr 2024 05:52:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rykid-0000uz-B1; Sun, 21 Apr 2024 23:51:51 -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 1rykib-0000uq-JS for emacs-devel@gnu.org; Sun, 21 Apr 2024 23:51:49 -0400 Original-Received: from sanpietro.red-bean.com ([45.79.25.59]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rykiZ-0000rE-R0 for emacs-devel@gnu.org; Sun, 21 Apr 2024 23:51:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=red-bean.com; s=202005newsp; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Reply-To:References:In-Reply-To:Subject:Cc:To: From:Sender:Content-ID:Content-Description; bh=hG9WVaOR+BlO4zxjZZ3Rp9yVRRdql0Y3f5AAqvHLJY8=; t=1713757905; x=1714967505; b=iny2DThXUz8dw9eVq+V+b48EiS77fr54t2sAKgVBxFikcxLzO/1bhE1VvSkFNogIdL1sAKhT7ZZ YJdJ1sfXsi4+aIcjilaFsx2iCidNLrJIY97FV9ViUXlz2buP+0AD4vNj1mnCAdtu0qOig65JMQxEq wF1in+VTqWg4xD4iI01tem9dH9JaDNXfMH7/VFWXtLer0TDqg4MwxndmD8er1wpxpVYJlFlhTaPo6 G1iuhaQc0VA/UqOf2o/GKfwKSpHIxfBn8tcBrmKwd2PT+DCS5vozHa3exIekMZx4gmBoh9zD0nuCA lRJ9764wimPVQzeIA0Svtc9VniOF37RhzL5w==; Original-Received: from 99-112-125-163.lightspeed.cicril.sbcglobal.net ([99.112.125.163]:57404 helo=qfloss) by sanpietro.red-bean.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rykiW-004W2A-1B; Mon, 22 Apr 2024 03:51:44 +0000 In-Reply-To: (Dani Moncayo's message of "Sat, 20 Apr 2024 08:50:30 +0200") Received-SPF: pass client-ip=45.79.25.59; envelope-from=kfogel@red-bean.com; helo=sanpietro.red-bean.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:317944 Archived-At: On 20 Apr 2024, Dani Moncayo wrote: >On Sat, Apr 20, 2024 at 2:54=E2=80=AFAM Karl Fogel =20 >wrote: >> Nope, you didn't make any mistake. I see the problem; please >> try this revised version, and thank you for testing. > >OK. With this second patch, I don't see the first problem [1] >anymore, but I keep seeing the second one [2]. Ah, I'm sorry, I meant to discuss that second problem here. For=20 reference, here's your description of it: > 1. Open some *info* manual and set a named bookmark there. > E.g. [C-h r C-x r m f o o RET]. > 2. Kill the *info* buffer and open it again: [C-x k RET C-h r]. >=20 > When I do that, I don't see the bookmark icon in the fringe=20 > (wrong). > > But I _do_ see the icon if I _jump_ to the bookmark: [C-x r b f=20 > o o RET] This is the expected behavior, I think. Let me explain why I believe that. If you or someone can point=20 out why this reasoning is wrong, I'd appreciate it. In general, there's no mechanism for a bookmark fringe mark to be=20 shown when one goes to a bookmarked location by some means *other*=20 than through a bookmark function. For example, 1. Find a file "SomeFile" in your home directory. 2. Create new bookmark "foo" on the first line. (Now you see a fringe mark.) 3. Kill the buffer entirely.=20 4. Use [C-x C-f] to find "SomeFile" into a buffer again. (Now you don't see a fringe mark.) 5. Kill the buffer again. 6. Use [C-x r b] (`bookmark-jump') to visit bookmark "foo" (Now you see the fringe mark again.) The reason the fringe mark appears in Step 6 is because the=20 bookmark code had a chance to get involved (i.e.,=20 `bookmark--set-fringe-mark' got called somewhere along the way=20 from `bookmark-jump'). In general, if you set a bookmark in a buffer, and you merely=20 *leave* the buffer but don't kill the buffer (e.g., you do=20 `bury-buffer' or something), then that fringe mark will still be=20 there when you come back. The fringe mark will also be placed if=20 you get to the location via `bookmark-jump', and if you set a=20 bookmark there with `bookmark-set'. Also, if you retarget bookmark "foo" to point to a new location,=20 then if there's some buffer currently displaying the old target of=20 "foo", that old buffer's corresponding fringe mark for "foo" will=20 get removed (bug #1 that I just fixed was about a special case of=20 this behavior). Now let's look at how this all works with Info nodes: Often, two Info nodes are actually in the same file. This was the=20 case with the two that you used in your reproduction recipe: the=20 "Distrib" node and the "Intro" node in the Emacs manual -- both=20 are in emacs.info.gz, which is located at=20 /usr/local/share/info/emacs.info.gz for me (but might be somewhere=20 else for you). When two Info nodes X and Y are in the same underlying file, then=20 if you put a bookmark in node X, the fringe mark will stay there=20 even if you go visit node Y and then come back to X (assuming you=20 didn't do anything to kill the "*info*" buffer along the way).=20 This is because the buffer has never been killed and the=20 underlying file that it's visiting has not actually changed. But imagine that your two nodes X and Y were in two different Info=20 files. If you set a bookmark in X and then go visit Y, and then=20 come back to X (but not by using `bookmark-jump'), the fringe mark=20 will be gone from from X. So in your reproduction recipe quoted above, when you kill the=20 "*info*" buffer, you're killing the buffer that's visiting that=20 particular Info file. When you visit that same Info node again=20 via a non-bookmark route, there's no code that magically knows=20 that there is a bookmark located here, and so no fringe mark is=20 displayed. On the other hand, when you use `bookmark-jump' to=20 jump to the bookmark, then of course the bookmark code has a=20 chance to put the fringe mark back. By the way, I am not claiming that this behavior is ideal. It=20 would be wonderful if all of Emacs *did* magically have a way to=20 know when a line associated with some bookmark is being displayed,=20 so we could show a fringe mark there. But I can't think of any reasonable way to implement that. By=20 "reasonable", I mean worth the complexity involved (I'm also not=20 sure how to do it without an unacceptable performance penalty, but=20 I haven't thought hard about it, because I'm pretty sure that if=20 one *were* able to do it without a big performance hit, then the=20 solution would be far more complex than a fringe mark is worth). Best regards, -Karl