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.bugs Subject: bug#70019: [PATCH] Fix two bugs in removing bookmark fringe marks (bug#70019) Date: Sun, 21 Apr 2024 22:51:43 -0500 Message-ID: <87jzkqawc0.fsf__49272.5300182187$1713757995$gmane$org@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="14101"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 70019@debbugs.gnu.org, Emacs Developers To: Dani Moncayo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 22 05:53:07 2024 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 1rykjq-0003Tt-PD for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 22 Apr 2024 05:53:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rykjZ-0001RD-H1; Sun, 21 Apr 2024 23:52:49 -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 1rykjX-0001Qp-9S for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2024 23:52:47 -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 1rykjW-0000y2-VJ for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2024 23:52:47 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rykjm-0002Nb-CO for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2024 23:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Karl Fogel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Apr 2024 03:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70019 X-GNU-PR-Package: emacs Original-Received: via spool by 70019-submit@debbugs.gnu.org id=B70019.17137579298806 (code B ref 70019); Mon, 22 Apr 2024 03:53:02 +0000 Original-Received: (at 70019) by debbugs.gnu.org; 22 Apr 2024 03:52:09 +0000 Original-Received: from localhost ([127.0.0.1]:45331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rykis-0002Hk-Pa for submit@debbugs.gnu.org; Sun, 21 Apr 2024 23:52:08 -0400 Original-Received: from sanpietro.red-bean.com ([45.79.25.59]:57012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rykin-0002Gn-5y for 70019@debbugs.gnu.org; Sun, 21 Apr 2024 23:52:04 -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") 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:283791 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