GNU bug report logs -
#65039
30.0.50; [PATCH] Add bookmark handler for M-x shell
Previous Next
Reported by: Protesilaos Stavrou <info <at> protesilaos.com>
Date: Thu, 3 Aug 2023 14:42:01 UTC
Severity: wishlist
Tags: patch
Found in version 30.0.50
Fixed in version 31.1
Done: Michael Albinus <michael.albinus <at> gmx.de>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 65039 in the body.
You can then email your comments to 65039 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Thu, 03 Aug 2023 14:42:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Protesilaos Stavrou <info <at> protesilaos.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 03 Aug 2023 14:42:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Dear maintainers,
I noticed that M-x shell does not have a bookmark handler like M-x
eshell does. What do you think about the attached patch?
All the best,
Protesilaos (or simply "Prot")
--
Protesilaos Stavrou
https://protesilaos.com
[0001-Add-bookmark-handler-for-M-x-shell.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Thu, 03 Aug 2023 15:57:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 65039 <at> debbugs.gnu.org (full text, mbox):
> From: Protesilaos Stavrou <info <at> protesilaos.com>
> Date: Thu, 03 Aug 2023 17:41:27 +0300
>
> I noticed that M-x shell does not have a bookmark handler like M-x
> eshell does. What do you think about the attached patch?
I'll let users of bookmarks comment, but in any case, please also
check that the section "Bookmarks" in the Emacs user manual doesn't
need some update due to this feature. (You marked the NEWS entry with
"---", which might mean you already checked that, but I'm not sure.)
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Thu, 03 Aug 2023 17:09:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[வியாழன் ஆகஸ்ட் 03, 2023] Protesilaos Stavrou wrote:
> Dear maintainers,
>
> I noticed that M-x shell does not have a bookmark handler like M-x
> eshell does. What do you think about the attached patch?
I think it would be nice to also store the "Remote shell path" for
remote TRAMP buffers. I have no idea how to retrieve this value,
however.
[ When I visit a TRAMP ssh buffer and say M-x shell, it asks for the
remote shell path. ]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 04 Aug 2023 09:18:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 65039 <at> debbugs.gnu.org (full text, mbox):
> From: Eli Zaretskii <eliz <at> gnu.org>
> Date: Thu, 3 Aug 2023 18:56:15 +0300
>
>> From: Protesilaos Stavrou <info <at> protesilaos.com>
>> Date: Thu, 03 Aug 2023 17:41:27 +0300
>>
>> I noticed that M-x shell does not have a bookmark handler like M-x
>> eshell does. What do you think about the attached patch?
>
> I'll let users of bookmarks comment, but in any case, please also
> check that the section "Bookmarks" in the Emacs user manual doesn't
> need some update due to this feature. (You marked the NEWS entry with
> "---", which might mean you already checked that, but I'm not sure.)
I thought a change was not necessary. Though I am happy to do it, if
needed.
--
Protesilaos Stavrou
https://protesilaos.com
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 04 Aug 2023 09:21:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 65039 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Date: Thu, 3 Aug 2023 22:38:24 +0530
>
> [வியாழன் ஆகஸ்ட் 03, 2023] Protesilaos Stavrou wrote:
>
>> Dear maintainers,
>>
>> I noticed that M-x shell does not have a bookmark handler like M-x
>> eshell does. What do you think about the attached patch?
>
> I think it would be nice to also store the "Remote shell path" for
> remote TRAMP buffers. I have no idea how to retrieve this value,
> however.
> [ When I visit a TRAMP ssh buffer and say M-x shell, it asks for the
> remote shell path. ]
The code is adapted from Eshell, which has the capability you describe.
I do not have the means to test an SSH connection. Though I tried the
'sudo' TRAMP method and the bookmarking correctly logs me in as root
when I do 'bookmark-jump'. This works even if I kill the shell buffer
and all TRAMP buffers.
--
Protesilaos Stavrou
https://protesilaos.com
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 04 Aug 2023 10:33:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 65039 <at> debbugs.gnu.org (full text, mbox):
> From: Protesilaos Stavrou <info <at> protesilaos.com>
> Cc: 65039 <at> debbugs.gnu.org
> Date: Fri, 04 Aug 2023 12:17:43 +0300
>
> > I'll let users of bookmarks comment, but in any case, please also
> > check that the section "Bookmarks" in the Emacs user manual doesn't
> > need some update due to this feature. (You marked the NEWS entry with
> > "---", which might mean you already checked that, but I'm not sure.)
>
> I thought a change was not necessary. Though I am happy to do it, if
> needed.
It sounds like the notion of "jumping" to a bookmark has evolved, and
nowadays jumping to a bookmark might do much more than just jump to a
buffer position. Perhaps that node in the manual should say something
about that, and show a couple of examples?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 04 Aug 2023 13:02:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[வெள்ளி ஆகஸ்ட் 04, 2023] Protesilaos Stavrou wrote:
> The code is adapted from Eshell, which has the capability you describe.
> I do not have the means to test an SSH connection. Though I tried the
> 'sudo' TRAMP method and the bookmarking correctly logs me in as root
> when I do 'bookmark-jump'. This works even if I kill the shell buffer
> and all TRAMP buffers.
I see that `shell' sets the value of `explicit-shell-file-name' to the
filename of the remote shell chosen but unfortunately this gets set to
nil once `make-comint-in-buffer' function is called since `comint-mode'
kills all local variables. :-(
I don't know how reliable of a solution
(executable-find shell--start-prog)
is to get the absolute filename of the shell being used.
If that is an acceptable solution, then the following diff works fine
for both remote and local shells.
diff --git a/lisp/shell.el b/lisp/shell.el
index 5cf108bfa3..8396870a67 100644
--- a/lisp/shell.el
+++ b/lisp/shell.el
@@ -637,6 +637,7 @@ shell-mode
(setq comint-prompt-regexp shell-prompt-pattern)
(shell-completion-vars)
+ (setq-local bookmark-make-record-function #'shell-bookmark-make-record)
(setq-local paragraph-separate "\\'")
(setq-local paragraph-start comint-prompt-regexp)
(setq-local font-lock-defaults '(shell-font-lock-keywords t))
@@ -1770,6 +1771,32 @@ shell-highlight-undef-mode-restart
(when shell-highlight-undef-mode
(shell-highlight-undef-mode 1)))
+;;; Bookmark support
+
+;; Adapted from esh-mode.el
+(declare-function bookmark-prop-get "bookmark" (bookmark prop))
+
+(defun shell-bookmark-name ()
+ (format "shell-%s"
+ (file-name-nondirectory
+ (directory-file-name
+ (file-name-directory default-directory)))))
+
+(defun shell-bookmark-make-record ()
+ "Create a bookmark for the current Shell buffer."
+ `(,(shell-bookmark-name)
+ (location . ,default-directory)
+ (shell-filename . ,(executable-find shell--start-prog))
+ (handler . shell-bookmark-jump)))
+
+;;;###autoload
+(defun shell-bookmark-jump (bookmark)
+ "Default bookmark handler for Shell buffers."
+ (let ((default-directory (bookmark-prop-get bookmark 'location)))
+ (shell nil (bookmark-prop-get bookmark 'shell-filename))))
+
+(put 'shell-bookmark-jump 'bookmark-handler-type "Shell")
+
(provide 'shell)
;;; shell.el ends here
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 04 Aug 2023 14:08:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> From: Eli Zaretskii <eliz <at> gnu.org>
> Date: Fri, 4 Aug 2023 13:32:37 +0300
>
>> From: Protesilaos Stavrou <info <at> protesilaos.com>
>> Cc: 65039 <at> debbugs.gnu.org
>> Date: Fri, 04 Aug 2023 12:17:43 +0300
>>
>> > I'll let users of bookmarks comment, but in any case, please also
>> > check that the section "Bookmarks" in the Emacs user manual doesn't
>> > need some update due to this feature. (You marked the NEWS entry with
>> > "---", which might mean you already checked that, but I'm not sure.)
>>
>> I thought a change was not necessary. Though I am happy to do it, if
>> needed.
>
> It sounds like the notion of "jumping" to a bookmark has evolved, and
> nowadays jumping to a bookmark might do much more than just jump to a
> buffer position. Perhaps that node in the manual should say something
> about that, and show a couple of examples?
The revised patch includes a possible update to the manual. Are those
examples sufficient?
--
Protesilaos Stavrou
https://protesilaos.com
[0001-Add-bookmark-handler-for-M-x-shell.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 04 Aug 2023 14:14:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 65039 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Date: Fri, 4 Aug 2023 18:31:16 +0530
>
> [வெள்ளி ஆகஸ்ட் 04, 2023] Protesilaos Stavrou wrote:
>
>> The code is adapted from Eshell, which has the capability you describe.
>> I do not have the means to test an SSH connection. Though I tried the
>> 'sudo' TRAMP method and the bookmarking correctly logs me in as root
>> when I do 'bookmark-jump'. This works even if I kill the shell buffer
>> and all TRAMP buffers.
>
> I see that `shell' sets the value of `explicit-shell-file-name' to the
> filename of the remote shell chosen but unfortunately this gets set to
> nil once `make-comint-in-buffer' function is called since `comint-mode'
> kills all local variables. :-(
>
> I don't know how reliable of a solution
>
> (executable-find shell--start-prog)
>
> is to get the absolute filename of the shell being used.
Thank you! This seems reasonable. Have you checked the variable
'shell-file-name'?
> If that is an acceptable solution, then the following diff works fine
> for both remote and local shells.
> [... 47 lines elided]
As noted before, I cannot test your suggested changes as I have no SSH
connection available. Hopefully, someone can help try this.
--
Protesilaos Stavrou
https://protesilaos.com
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 04 Aug 2023 14:36:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[வெள்ளி ஆகஸ்ட் 04, 2023] Protesilaos Stavrou wrote:
>>> The code is adapted from Eshell, which has the capability you describe.
>>> I do not have the means to test an SSH connection. Though I tried the
>>> 'sudo' TRAMP method and the bookmarking correctly logs me in as root
>>> when I do 'bookmark-jump'. This works even if I kill the shell buffer
>>> and all TRAMP buffers.
>>
>> I see that `shell' sets the value of `explicit-shell-file-name' to the
>> filename of the remote shell chosen but unfortunately this gets set to
>> nil once `make-comint-in-buffer' function is called since `comint-mode'
>> kills all local variables. :-(
>>
>> I don't know how reliable of a solution
>>
>> (executable-find shell--start-prog)
>>
>> is to get the absolute filename of the shell being used.
>
> Thank you! This seems reasonable. Have you checked the variable
> 'shell-file-name'?
Unfortunately, it is not always reliable. I use mksh as my (local)
shell but I use bash in the remote system. In these remote shells, I
don't see the correct value being set:
(list major-mode (file-remote-p default-directory) shell-file-name shell--start-prog)
⇒ (shell-mode "/ssh:REDACTED <at> REDACTED:" "/bin/mksh" "bash")
`shell' also has this comment before the prompt for remote shell
filename:
;; On remote hosts, the local `shell-file-name' might be useless.
HTH.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 04 Aug 2023 14:36:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 65039 <at> debbugs.gnu.org (full text, mbox):
> It sounds like the notion of "jumping" to a bookmark has evolved, and
> nowadays jumping to a bookmark might do much more than just jump to a
> buffer position. Perhaps that node in the manual should say something
> about that, and show a couple of examples?
Not weighing in on whether the manual
should be changed. Just thought I'd
mention that the notion of "jumping"
to a bookmark has always included the
possibility of doing "much more" - as
well as much _less_.
It's _always_ been the case that
"jumping" to a bookmark can do anything
at all. A bookmark can record nearly
any data, and a bookmark handler is
just a function - it can do anything
a function can do.
(But yes, it might help for the manual
to say this explicitly. "Jumping" to
a bookmark is both evocative, for many
or most bookmarks, and misleading, for
some bookmarks.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 04 Aug 2023 17:02:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 65039 <at> debbugs.gnu.org (full text, mbox):
On 8/4/2023 2:20 AM, Protesilaos Stavrou wrote:
> The code is adapted from Eshell, which has the capability you describe.
> I do not have the means to test an SSH connection. Though I tried the
> 'sudo' TRAMP method and the bookmarking correctly logs me in as root
> when I do 'bookmark-jump'. This works even if I kill the shell buffer
> and all TRAMP buffers.
For what it's worth, when I want to test Tramp support (especially in
something like Eshell or Shell), I just connect to localhost via
"/ssh:localhost:~" or similar. So long as your system is running sshd,
that should work fine.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 05 Aug 2023 09:18:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 65039 <at> debbugs.gnu.org (full text, mbox):
> From: Protesilaos Stavrou <info <at> protesilaos.com>
> Cc: 65039 <at> debbugs.gnu.org
> Date: Fri, 04 Aug 2023 17:06:59 +0300
>
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > Date: Fri, 4 Aug 2023 13:32:37 +0300
> >
> >> From: Protesilaos Stavrou <info <at> protesilaos.com>
> >> Cc: 65039 <at> debbugs.gnu.org
> >> Date: Fri, 04 Aug 2023 12:17:43 +0300
> >>
> >> > I'll let users of bookmarks comment, but in any case, please also
> >> > check that the section "Bookmarks" in the Emacs user manual doesn't
> >> > need some update due to this feature. (You marked the NEWS entry with
> >> > "---", which might mean you already checked that, but I'm not sure.)
> >>
> >> I thought a change was not necessary. Though I am happy to do it, if
> >> needed.
> >
> > It sounds like the notion of "jumping" to a bookmark has evolved, and
> > nowadays jumping to a bookmark might do much more than just jump to a
> > buffer position. Perhaps that node in the manual should say something
> > about that, and show a couple of examples?
>
> The revised patch includes a possible update to the manual. Are those
> examples sufficient?
I guess so, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sun, 06 Aug 2023 04:44:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 65039 <at> debbugs.gnu.org (full text, mbox):
> From: Jim Porter <jporterbugs <at> gmail.com>
> Date: Fri, 4 Aug 2023 10:01:12 -0700
>
> On 8/4/2023 2:20 AM, Protesilaos Stavrou wrote:
>> The code is adapted from Eshell, which has the capability you describe.
>> I do not have the means to test an SSH connection. Though I tried the
>> 'sudo' TRAMP method and the bookmarking correctly logs me in as root
>> when I do 'bookmark-jump'. This works even if I kill the shell buffer
>> and all TRAMP buffers.
>
> For what it's worth, when I want to test Tramp support (especially in
> something like Eshell or Shell), I just connect to localhost via
> "/ssh:localhost:~" or similar. So long as your system is running sshd,
> that should work fine.
Thank you! This looks promising. I am trying to make it work, but it
denies the connection. Maybe you can share with me off-list the
relevant sshd settings? I tried to disable public key checking and
enable passwords. To no avail.
--
Protesilaos Stavrou
https://protesilaos.com
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 11 Aug 2023 04:56:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 65039 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Date: Fri, 4 Aug 2023 20:05:03 +0530
> [... 20 lines elided]
>> Thank you! This seems reasonable. Have you checked the variable
>> 'shell-file-name'?
>
> Unfortunately, it is not always reliable. I use mksh as my (local)
> shell but I use bash in the remote system. In these remote shells, I
> don't see the correct value being set:
>
> (list major-mode (file-remote-p default-directory) shell-file-name shell--start-prog)
> ⇒ (shell-mode "/ssh:REDACTED <at> REDACTED:" "/bin/mksh" "bash")
>
> `shell' also has this comment before the prompt for remote shell
> filename:
>
> ;; On remote hosts, the local `shell-file-name' might be useless.
>
> HTH.
I see. Thanks for the explanation! I shall revisit this patch as soon
as I have a way to test ssh myself. Not sure when...
--
Protesilaos Stavrou
https://protesilaos.com
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sun, 03 Sep 2023 11:07:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sun, 03 Sep 2023 11:17:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Protesilaos Stavrou <info <at> protesilaos.com>
>> Cc: 65039 <at> debbugs.gnu.org
>> Date: Fri, 04 Aug 2023 17:06:59 +0300
>>
>> > From: Eli Zaretskii <eliz <at> gnu.org>
>> > Date: Fri, 4 Aug 2023 13:32:37 +0300
>> >
>> >> From: Protesilaos Stavrou <info <at> protesilaos.com>
>> >> Cc: 65039 <at> debbugs.gnu.org
>> >> Date: Fri, 04 Aug 2023 12:17:43 +0300
>> >>
>> >> > I'll let users of bookmarks comment, but in any case, please also
>> >> > check that the section "Bookmarks" in the Emacs user manual doesn't
>> >> > need some update due to this feature. (You marked the NEWS entry with
>> >> > "---", which might mean you already checked that, but I'm not sure.)
>> >>
>> >> I thought a change was not necessary. Though I am happy to do it, if
>> >> needed.
>> >
>> > It sounds like the notion of "jumping" to a bookmark has evolved, and
>> > nowadays jumping to a bookmark might do much more than just jump to a
>> > buffer position. Perhaps that node in the manual should say something
>> > about that, and show a couple of examples?
>>
>> The revised patch includes a possible update to the manual. Are those
>> examples sufficient?
>
> I guess so, thanks.
Just to let you know, I had an issue with applying the patch, and had to
manually edit it:
1 git … am --3way -- ~/wip/emacs/0001-Add-bookmark-handler-for-M-x-shell.patch
Line longer than 78 characters in commit message
Commit aborted; please see the file CONTRIBUTE
Also, when the bug number is known, it is good if you can include it
somewhere in the commit message.
I was going to review and install this patch, but I noticed that there
was some further discussion in a subthread regarding some Tramp stuff?
Should that be resolved first, or is this ready as-is?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sun, 03 Sep 2023 11:44:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 65039 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sun, 3 Sep 2023 04:15:57 -0700
> Cc: Protesilaos Stavrou <info <at> protesilaos.com>, 65039 <at> debbugs.gnu.org
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> The revised patch includes a possible update to the manual. Are those
> >> examples sufficient?
> >
> > I guess so, thanks.
>
> Just to let you know, I had an issue with applying the patch, and had to
> manually edit it:
>
> 1 git … am --3way -- ~/wip/emacs/0001-Add-bookmark-handler-for-M-x-shell.patch
> Line longer than 78 characters in commit message
> Commit aborted; please see the file CONTRIBUTE
>
> Also, when the bug number is known, it is good if you can include it
> somewhere in the commit message.
>
> I was going to review and install this patch, but I noticed that there
> was some further discussion in a subthread regarding some Tramp stuff?
> Should that be resolved first, or is this ready as-is?
Yes, I think those issues need to be resolved first. I only reviewed
part of the patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Tue, 05 Sep 2023 04:40:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Good morning Stefan,
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sun, 3 Sep 2023 04:15:57 -0700
> [... 32 lines elided]
> Just to let you know, I had an issue with applying the patch, and had to
> manually edit it:
>
> 1 git … am --3way -- ~/wip/emacs/0001-Add-bookmark-handler-for-M-x-shell.patch
> Line longer than 78 characters in commit message
> Commit aborted; please see the file CONTRIBUTE
>
> Also, when the bug number is known, it is good if you can include it
> somewhere in the commit message.
Good to know. Thanks!
> I was going to review and install this patch, but I noticed that there
> was some further discussion in a subthread regarding some Tramp stuff?
> Should that be resolved first, or is this ready as-is?
I am using the patch locally and it works for me, including for the
Tramp 'sudo' method. The problem is with a Tramp 'ssh' connection. I
don't have a machine with ssh access to test this. Another person
suggested a setup to establish an ssh connection to localhost, but I
cannot get it to work.
All the best,
Protesilaos (or simply "Prot")
--
Protesilaos Stavrou
https://protesilaos.com
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Tue, 05 Sep 2023 06:18:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Hello Prot,
> The problem is with a Tramp 'ssh' connection. I don't have a machine
> with ssh access to test this. Another person suggested a setup to
> establish an ssh connection to localhost, but I cannot get it to work.
If it helps, you can send me your SSH public key (possibly off-list),
and I'll give you SSH access to one of my machines for testing.
Best,
Eshel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Mon, 18 Sep 2023 05:30:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 65039 <at> debbugs.gnu.org (full text, mbox):
> From: Eshel Yaron <me <at> eshelyaron.com>
> Date: Tue, 5 Sep 2023 08:17:50 +0200
>
> Hello Prot,
Hello Eshel,
Sorry for being slow to respond. I did not have electricity at home.
Now I do and am back in action.
>> The problem is with a Tramp 'ssh' connection. I don't have a machine
>> with ssh access to test this. Another person suggested a setup to
>> establish an ssh connection to localhost, but I cannot get it to work.
>
> If it helps, you can send me your SSH public key (possibly off-list),
> and I'll give you SSH access to one of my machines for testing.
Thank you! I will send it now off-list.
All the best,
Prot
--
Protesilaos Stavrou
https://protesilaos.com
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Tue, 11 Feb 2025 19:57:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This is a continuation of the discussion in this bug report. I've had shell
bookmark support privately for a while, and I see Prot had something
similar, as I'm sure many others do. One of the open items from Prot's last
message was accommodating remote shells.
The attached patch aims to address both local and remote shells. There is a
feature to inhibit remote connections useful when restoring sessions with
'desktop-load' (or another session management package), where the time
delays to establish a connection for each remote shell can be long. When
you reload an unconnected remote buffer using 'C-x C-v', a connection will
be initiated.
Remote shell bookmarks remember the buffer's remote 'default-directory'
at the time you create a bookmark, along with the shell used to
start the remote shell. I think this is something Visuwesh commented on
and which this patch attempts to address.
There are two options for shell bookmark names, one using default-directory
similar to eshell, and one using buffer name (my shell buffer names are
automated in a style I prefer).
I cc'd Michael Albinus on this since it touches remote features and he may
want to scrutinize what's in this patch. Testing this patch is what led me
to help fix the bug in ansi-osc-directory-tracker.
Let me know what you all think.
-Stephane
[Message part 2 (text/html, inline)]
[0001-Add-shell-mode-bookmark-support-for-local-and-remote.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Wed, 12 Feb 2025 12:20:01 GMT)
Full text and
rfc822 format available.
Message #70 received at 65039 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Tue, 11 Feb 2025 14:56:08 -0500
> Cc: 65039 <at> debbugs.gnu.org
>
> +---
Should we mention this feature in the user manual?
> +*** Shell buffers now support bookmarks support.
> +
> +You can now bookmark shell buffers using the bookmark menu
> +'bookmark-bmenu-list', or by using the command 'bookmark-set'. Shell
> +bookmarks can be loaded via the menu, or by using the command
> +'bookmark-jump'.
> +
> +Remote shell bookmarks remember the buffer's remote 'default-directory'
> +at the time you create a bookmark, along with the shell you used to
> +start the remote shell. You can inhibit remote connections during
> +bookmark loading. This is useful when restoring sessions with
> +'desktop-load', where the time delays to establish a connection for each
> +remote shell can be long. When you reload an unconnected remote buffer
> +using 'C-x C-v', a connection will be initiated.
> +
> +You can customize the bookmark naming function to suit your preferences.
> +The default option is to use the final component of the buffer's
> +'default-directory'. An alternate provided option uses the buffer's
> +name with its 'rename-uniquely' suffix brackets "<>" stripped. You can
> +supply your own function.
AFAU, this doesn't explain what it means to "jump to a shell
bookmark". Does it start a shell, does it change the current
directory in an existing shell buffer, does it initiate a connection
to the remote host, does it do something else? I don't think the
answers to these questions are trivial, so I suggest to have them
answered in the NEWS entry.
By contrast, the second and the third paragraphs describe aspects of
secondary importance, and should perhaps be in the doc strings and not
in NEWS.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Wed, 12 Feb 2025 12:32:01 GMT)
Full text and
rfc822 format available.
Message #73 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Sure. I'll work on documentation and NEWS once the patch is agreed so any
alterations are captured. bookmark-jump perhaps can use an alias
bookmark-open. The concept of jumping is very document centric considering
that bookmarks can be just about anything that a handler writer wants. One
of the packages I help maintain uses bookmarks in a more expansive way for
which I will also leverage the new property to inhibit bookmark-insert.
On Wed, Feb 12, 2025 at 7:18 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Tue, 11 Feb 2025 14:56:08 -0500
> > Cc: 65039 <at> debbugs.gnu.org
> >
> > +---
>
> Should we mention this feature in the user manual?
>
> > +*** Shell buffers now support bookmarks support.
> > +
> > +You can now bookmark shell buffers using the bookmark menu
> > +'bookmark-bmenu-list', or by using the command 'bookmark-set'. Shell
> > +bookmarks can be loaded via the menu, or by using the command
> > +'bookmark-jump'.
> > +
> > +Remote shell bookmarks remember the buffer's remote 'default-directory'
> > +at the time you create a bookmark, along with the shell you used to
> > +start the remote shell. You can inhibit remote connections during
> > +bookmark loading. This is useful when restoring sessions with
> > +'desktop-load', where the time delays to establish a connection for each
> > +remote shell can be long. When you reload an unconnected remote buffer
> > +using 'C-x C-v', a connection will be initiated.
> > +
> > +You can customize the bookmark naming function to suit your preferences.
> > +The default option is to use the final component of the buffer's
> > +'default-directory'. An alternate provided option uses the buffer's
> > +name with its 'rename-uniquely' suffix brackets "<>" stripped. You can
> > +supply your own function.
>
> AFAU, this doesn't explain what it means to "jump to a shell
> bookmark". Does it start a shell, does it change the current
> directory in an existing shell buffer, does it initiate a connection
> to the remote host, does it do something else? I don't think the
> answers to these questions are trivial, so I suggest to have them
> answered in the NEWS entry.
>
> By contrast, the second and the third paragraphs describe aspects of
> secondary importance, and should perhaps be in the doc strings and not
> in NEWS.
>
> Thanks.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Thu, 13 Feb 2025 16:25:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
Hi,
> I cc'd Michael Albinus on this since it touches remote features and he
> may want to scrutinize what's in this patch. Testing this patch is
> what led me to help fix the bug in ansi-osc-directory-tracker.
>
> Let me know what you all think.
I gave it a cursory view. Nothing problematic; just some minor remarks.
> +(defcustom shell-bookmark-name-function #'shell-bookmark-name-from-default-directory
> + "Function to generate a shell bookmark name.
> +The default is `shell-bookmark-name', which see."
> + :group 'shell
> + :type `(choice (function-item ,#'shell-bookmark-name-from-default-directory)
> + (function-item ,#'shell-bookmark-name-from-buffer-name)
> + function)
Wouldn't this be sufficient?
--8<---------------cut here---------------start------------->8---
:type '(choice (function-item shell-bookmark-name-from-default-directory)
(function-item shell-bookmark-name-from-buffer-name)
function)
--8<---------------cut here---------------end--------------->8---
> + (replace-regexp-in-string "\\(.*\\)<[[:digit:]]+>\\'"
> + "\\1"
> + (buffer-name)))
--8<---------------cut here---------------start------------->8---
(replace-regexp-in-string "<[[:digit:]]+>\\'" "" (buffer-name)))
--8<---------------cut here---------------end--------------->8---
A further remark (don't know where to do it in your code): If you
bookmark a remote file name, I recommend to keep multi-hop file names
(let-bind tramp-show-ad-hoc-proxies to t). Otherwise, a remote file name
like "/ssh:host|sudo:host:/" would be saved in your bookmark-default-file
as "/sudo:host:/", which doesn't work in the next Emacs session.
> -Stephane
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Thu, 13 Feb 2025 16:35:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Feb 13, 2025 at 11:23 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Ship Mints <shipmints <at> gmail.com> writes:
>
> > +(defcustom shell-bookmark-name-function
> #'shell-bookmark-name-from-default-directory
> > + "Function to generate a shell bookmark name.
> > +The default is `shell-bookmark-name', which see."
> > + :group 'shell
> > + :type `(choice (function-item
> ,#'shell-bookmark-name-from-default-directory)
> > + (function-item ,#'shell-bookmark-name-from-buffer-name)
> > + function)
>
> Wouldn't this be sufficient?
>
> --8<---------------cut here---------------start------------->8---
> :type '(choice (function-item shell-bookmark-name-from-default-directory)
> (function-item shell-bookmark-name-from-buffer-name)
> function)
> --8<---------------cut here---------------end--------------->8---
>
It would be but referencing functions as functions vs. naked symbols seems
like a better style?
> > + (replace-regexp-in-string "\\(.*\\)<[[:digit:]]+>\\'"
> > + "\\1"
> > + (buffer-name)))
>
> --8<---------------cut here---------------start------------->8---
> (replace-regexp-in-string "<[[:digit:]]+>\\'" "" (buffer-name)))
> --8<---------------cut here---------------end--------------->8---
>
I'll review that regexp. Thanks for that simplification.
> A further remark (don't know where to do it in your code): If you
> bookmark a remote file name, I recommend to keep multi-hop file names
> (let-bind tramp-show-ad-hoc-proxies to t). Otherwise, a remote file name
> like "/ssh:host|sudo:host:/" would be saved in your bookmark-default-file
> as "/sudo:host:/", which doesn't work in the next Emacs session.
>
I'll experiment with multi-hop now and ensure they are correctly stored and
restored.
-Stephane
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Thu, 13 Feb 2025 17:55:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Feb 13, 2025 at 11:34 AM Ship Mints <shipmints <at> gmail.com> wrote:
> On Thu, Feb 13, 2025 at 11:23 AM Michael Albinus <michael.albinus <at> gmx.de>
> wrote:
>
>>
>> A further remark (don't know where to do it in your code): If you
>> bookmark a remote file name, I recommend to keep multi-hop file names
>> (let-bind tramp-show-ad-hoc-proxies to t). Otherwise, a remote file name
>> like "/ssh:host|sudo:host:/" would be saved in your bookmark-default-file
>> as "/sudo:host:/", which doesn't work in the next Emacs session.
>>
>
> I'll experiment with multi-hop now and ensure they are correctly stored
> and restored.
>
Hi, Michael,
With tramp-show-ad-hoc-proxies bound to t *at the time of multi-hop
connection*, default-directory retains the fully-qualified multi-hop file
name and bookmarks work fine. I tested both shell and file bookmarks.
Though files are not in scope for this patch, I ensured they worked, too.
When nil, default-directory is abbreviated, as you pointed out. I can't see
a way to recover the multi-hop nature of the buffer based on just
default-directory. I read through the tramp code and I can't find a way to
do that.
If it is possible to do at bookmarking time, please tell me how. If this is
not possible, we will highlight in the docs that tramp-show-ad-hoc-proxies
must be t if users expect multi-hop bookmarks to be effective.
-Stephane
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 14 Feb 2025 15:00:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
> Hi, Michael,
Hi,
> With tramp-show-ad-hoc-proxies bound to t *at the time of multi-hop
> connection*, default-directory retains the fully-qualified multi-hop
> file name and bookmarks work fine. I tested both shell and file
> bookmarks. Though files are not in scope for this patch, I ensured
> they worked, too.
>
> When nil, default-directory is abbreviated, as you pointed out. I
> can't see a way to recover the multi-hop nature of the buffer based on
> just default-directory. I read through the tramp code and I can't find
> a way to do that.
Yes, you're right :-(
> If it is possible to do at bookmarking time, please tell me how. If
> this is not possible, we will highlight in the docs that
> tramp-show-ad-hoc-proxies must be t if users expect multi-hop
> bookmarks to be effective.
I'll check, whether I can improve this in Tramp.
> -Stephane
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 14 Feb 2025 15:34:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Feb 14, 2025 at 9:59 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Ship Mints <shipmints <at> gmail.com> writes:
>
> > If it is possible to do at bookmarking time, please tell me how. If
> > this is not possible, we will highlight in the docs that
> > tramp-show-ad-hoc-proxies must be t if users expect multi-hop
> > bookmarks to be effective.
>
> I'll check, whether I can improve this in Tramp.
>
Perhaps something as simple as a buffer-local in either the main buffer or
in the remote buffer, accessible via with-connection-local-variables?
I'll work on the documentation as Eli suggested and post a revised patch
today including documentation for tramp-show-ad-hoc-proxies.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 14 Feb 2025 17:06:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
Hi,
> I'll check, whether I can improve this in Tramp.
>
> Perhaps something as simple as a buffer-local in either the main
> buffer or in the remote buffer, accessible via
> with-connection-local-variables?
My idea is rather to extend expand-file-name. If
tramp-show-ad-hoc-proxies is non-nil, it should return the whole ad-hoc
multi-hop remote file name. Something like this.
(I thought it is simple, but it looks a little bit more complex.)
> I'll work on the documentation as Eli suggested and post a revised
> patch today including documentation for tramp-show-ad-hoc-proxies.
Thanks.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 14 Feb 2025 17:15:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Feb 14, 2025 at 12:04 PM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Ship Mints <shipmints <at> gmail.com> writes:
>
> Hi,
>
> > I'll check, whether I can improve this in Tramp.
> >
> > Perhaps something as simple as a buffer-local in either the main
> > buffer or in the remote buffer, accessible via
> > with-connection-local-variables?
>
> My idea is rather to extend expand-file-name. If
> tramp-show-ad-hoc-proxies is non-nil, it should return the whole ad-hoc
> multi-hop remote file name. Something like this.
>
> (I thought it is simple, but it looks a little bit more complex.)
>
The original multi-hop file name is gone by then
if tramp-show-ad-hoc-proxies is nil globally. Let-binding
tramp-show-ad-hoc-proxies to t in a function context still has to have a
way to get the original remote file spec.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 14 Feb 2025 17:21:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
Hi,
> My idea is rather to extend expand-file-name. If
> tramp-show-ad-hoc-proxies is non-nil, it should return the whole
> ad-hoc
> multi-hop remote file name. Something like this.
>
> (I thought it is simple, but it looks a little bit more complex.)
>
> The original multi-hop file name is gone by then if
> tramp-show-ad-hoc-proxies is nil globally. Let-binding
> tramp-show-ad-hoc-proxies to t in a function context still has to have
> a way to get the original remote file spec.
The multi-hop file name can still be reconstructed from
tramp-default-proxies-alist. See string property tramp-ad-hoc.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 14 Feb 2025 18:11:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Feb 14, 2025 at 12:20 PM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Ship Mints <shipmints <at> gmail.com> writes:
>
> > The original multi-hop file name is gone by then if
> > tramp-show-ad-hoc-proxies is nil globally. Let-binding
> > tramp-show-ad-hoc-proxies to t in a function context still has to have
> > a way to get the original remote file spec.
>
> The multi-hop file name can still be reconstructed from
> tramp-default-proxies-alist. See string property tramp-ad-hoc.
>
Good to know. I applaud all the work you've put into remote features (and
the sheer amount of support work that generates).
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Fri, 14 Feb 2025 19:28:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Latest version of the patch attached.
On Fri, Feb 14, 2025 at 1:09 PM Ship Mints <shipmints <at> gmail.com> wrote:
> On Fri, Feb 14, 2025 at 12:20 PM Michael Albinus <michael.albinus <at> gmx.de>
> wrote:
>
>> Ship Mints <shipmints <at> gmail.com> writes:
>>
>> > The original multi-hop file name is gone by then if
>> > tramp-show-ad-hoc-proxies is nil globally. Let-binding
>> > tramp-show-ad-hoc-proxies to t in a function context still has to have
>> > a way to get the original remote file spec.
>>
>> The multi-hop file name can still be reconstructed from
>> tramp-default-proxies-alist. See string property tramp-ad-hoc.
>>
>
> Good to know. I applaud all the work you've put into remote features (and
> the sheer amount of support work that generates).
>
[Message part 2 (text/html, inline)]
[0001-Add-shell-mode-bookmark-support-for-local-and-remote.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 08:22:01 GMT)
Full text and
rfc822 format available.
Message #106 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
>> Hi, Michael,
Hi,
>> If it is possible to do at bookmarking time, please tell me how. If
>> this is not possible, we will highlight in the docs that
>> tramp-show-ad-hoc-proxies must be t if users expect multi-hop
>> bookmarks to be effective.
>
> I'll check, whether I can improve this in Tramp.
Finally, it is much simpler than expected. The Tramp manual tells us TheTruth™,
(info "(tramp) Frequently Asked Questions")
--8<---------------cut here---------------start------------->8---
• Why saved multi-hop file names do not work in a new Emacs session?
When saving ad-hoc multi-hop TRAMP file names (*note Ad-hoc
multi-hops::) via bookmarks, recent files, filecache, bbdb, or
another package, use the full ad-hoc file name including all hops,
like ‘/ssh:bird <at> bastion|ssh:news.my.domain:/opt/news/etc’.
Alternatively, when saving abbreviated multi-hop file names
‘/ssh:news <at> news.my.domain:/opt/news/etc’, the user option
‘tramp-save-ad-hoc-proxies’ must be set non-‘nil’ value.
--8<---------------cut here---------------end--------------->8---
If you document to set tramp-save-ad-hoc-proxies to non-nil it should
work out-of-the-box.
>> -Stephane
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 08:45:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
Hi,
> Latest version of the patch attached.
Still some minor comments :-)
> +(defun shell-bookmark-make-record ()
> + "Create a bookmark record for the current `shell-mode' buffer.
> +Handle both local and remote shell buffers.
> +Bind `tramp-show-ad-hoc-proxies' to non-nil to ensure multi-hop remote
> +connections are fully qualified."
Don't mention tramp-show-ad-hoc-proxies.
> + (let ((bookmark-shell-file-name
> + (cond
> + ((file-remote-p default-directory)
> + (with-connection-local-variables
> + (cdr (assoc 'shell-file-name (buffer-local-value
> + 'connection-local-variables-alist
> + (current-buffer))))))
> + (shell-file-name shell-file-name)
> + (t sh-shell-file))))
This can be expressed simpler:
(let ((bookmark-shell-file-name
(or (connection-local-value shell-file-name) sh-shell-file)))
> +(defun shell-bookmark-jump (bookmark)
> + "Default BOOKMARK handler for shell buffers.
> +Create a shell buffer with its `default-directory', shell process, and
> +buffer name from the bookmark. If there is an existing shell buffer of
> +the same name, default shell-mode behavior is to reuse that buffer.
> +
> +For a remote shell `default-directory' will be the remote file name.
> +Remote shell buffers reuse existing connections that match the remote
> +file name, or may prompt you to create a new connection. Bind
> +`tramp-show-ad-hoc-proxies' to non-nil to ensure multi-hop remote
> +connections are fully qualified.
Don't mention tramp-show-ad-hoc-proxies.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 11:26:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hmm. I prefer storing the fully-qualified multi-hop file name in the
bookmark itself. I share my bookmarks across machines which all have
identically structured file systems, identical ssh configurations,
identical "production" Emacs configs, and I expect my bookmarks to load
without having to copy over another file. I will occasionally share a
bookmark snippet with someone else and expect it to work (these people have
similar set ups--assuming they follow the configuration guidelines).
Can we take a look at fully-qualified file name reconstruction?
On Sat, Feb 15, 2025 at 3:21 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
> >> Hi, Michael,
>
> Hi,
>
> >> If it is possible to do at bookmarking time, please tell me how. If
> >> this is not possible, we will highlight in the docs that
> >> tramp-show-ad-hoc-proxies must be t if users expect multi-hop
> >> bookmarks to be effective.
> >
> > I'll check, whether I can improve this in Tramp.
>
> Finally, it is much simpler than expected. The Tramp manual tells us
> TheTruth™,
> (info "(tramp) Frequently Asked Questions")
>
> --8<---------------cut here---------------start------------->8---
> • Why saved multi-hop file names do not work in a new Emacs session?
>
> When saving ad-hoc multi-hop TRAMP file names (*note Ad-hoc
> multi-hops::) via bookmarks, recent files, filecache, bbdb, or
> another package, use the full ad-hoc file name including all hops,
> like ‘/ssh:bird <at> bastion|ssh:news.my.domain:/opt/news/etc’.
>
> Alternatively, when saving abbreviated multi-hop file names
> ‘/ssh:news <at> news.my.domain:/opt/news/etc’, the user option
> ‘tramp-save-ad-hoc-proxies’ must be set non-‘nil’ value.
> --8<---------------cut here---------------end--------------->8---
>
> If you document to set tramp-save-ad-hoc-proxies to non-nil it should
> work out-of-the-box.
>
> >> -Stephane
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 11:37:01 GMT)
Full text and
rfc822 format available.
Message #115 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Since bookmarks can be loaded from alternate files, there's also that. I
have shared a few "standardized" bookmark files and instructed how to load
them. One day, I'll look at bookmark.el to see how much trouble it would be
to graft together multiple bookmark-origin files into a single list and
still retain their origin for persistence.
On Sat, Feb 15, 2025 at 6:24 AM Ship Mints <shipmints <at> gmail.com> wrote:
> Hmm. I prefer storing the fully-qualified multi-hop file name in the
> bookmark itself. I share my bookmarks across machines which all have
> identically structured file systems, identical ssh configurations,
> identical "production" Emacs configs, and I expect my bookmarks to load
> without having to copy over another file. I will occasionally share a
> bookmark snippet with someone else and expect it to work (these people have
> similar set ups--assuming they follow the configuration guidelines).
>
> Can we take a look at fully-qualified file name reconstruction?
>
> On Sat, Feb 15, 2025 at 3:21 AM Michael Albinus <michael.albinus <at> gmx.de>
> wrote:
>
>> Michael Albinus <michael.albinus <at> gmx.de> writes:
>>
>> >> Hi, Michael,
>>
>> Hi,
>>
>> >> If it is possible to do at bookmarking time, please tell me how. If
>> >> this is not possible, we will highlight in the docs that
>> >> tramp-show-ad-hoc-proxies must be t if users expect multi-hop
>> >> bookmarks to be effective.
>> >
>> > I'll check, whether I can improve this in Tramp.
>>
>> Finally, it is much simpler than expected. The Tramp manual tells us
>> TheTruth™,
>> (info "(tramp) Frequently Asked Questions")
>>
>> --8<---------------cut here---------------start------------->8---
>> • Why saved multi-hop file names do not work in a new Emacs session?
>>
>> When saving ad-hoc multi-hop TRAMP file names (*note Ad-hoc
>> multi-hops::) via bookmarks, recent files, filecache, bbdb, or
>> another package, use the full ad-hoc file name including all hops,
>> like ‘/ssh:bird <at> bastion|ssh:news.my.domain:/opt/news/etc’.
>>
>> Alternatively, when saving abbreviated multi-hop file names
>> ‘/ssh:news <at> news.my.domain:/opt/news/etc’, the user option
>> ‘tramp-save-ad-hoc-proxies’ must be set non-‘nil’ value.
>> --8<---------------cut here---------------end--------------->8---
>>
>> If you document to set tramp-save-ad-hoc-proxies to non-nil it should
>> work out-of-the-box.
>>
>> >> -Stephane
>>
>> Best regards, Michael.
>>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 12:38:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
Hi,
> Hmm. I prefer storing the fully-qualified multi-hop file name in the
> bookmark itself. I share my bookmarks across machines which all have
> identically structured file systems, identical ssh configurations,
> identical "production" Emacs configs, and I expect my bookmarks to
> load without having to copy over another file. I will occasionally
> share a bookmark snippet with someone else and expect it to work
> (these people have similar set ups--assuming they follow the
> configuration guidelines).
The crucial point is tramp-default-proxies-alist. If
tramp-save-ad-hoc-proxies is non-nil, an updated version of that user
option is saved in your ~/.emacs file, including ad-hoc definitions.
And if you share .emacs like you do it with your bookmarks, there is no pain.
> Can we take a look at fully-qualified file name reconstruction?
There is a reason that ad-hoc multi-hop file names are called ad-hoc:
they are ad-hoc, cand not designed to survive an Emacs session.
For example, Tramp supports a use case (requested by Tramp users), where
a container with the very same name exists @work on a remote machine,
and @home on another remote machine. Tramp supports this scenario, you
can always access this container as "docker:container-name:". See
section "6.4.1 Using different proxies for the same destination" in the
Tramp manual. If the extended multi-hop file name would be saved in your
bookmarks (or recentf) file, this doesn't work.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 12:43:01 GMT)
Full text and
rfc822 format available.
Message #121 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Is there any harm if people who want to achieve what I outlined
bind tramp-show-ad-hoc-proxies to non-nil? If that works in the way I
suggest, why not recommend it?
On Sat, Feb 15, 2025 at 7:37 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Ship Mints <shipmints <at> gmail.com> writes:
>
> Hi,
>
> > Hmm. I prefer storing the fully-qualified multi-hop file name in the
> > bookmark itself. I share my bookmarks across machines which all have
> > identically structured file systems, identical ssh configurations,
> > identical "production" Emacs configs, and I expect my bookmarks to
> > load without having to copy over another file. I will occasionally
> > share a bookmark snippet with someone else and expect it to work
> > (these people have similar set ups--assuming they follow the
> > configuration guidelines).
>
> The crucial point is tramp-default-proxies-alist. If
> tramp-save-ad-hoc-proxies is non-nil, an updated version of that user
> option is saved in your ~/.emacs file, including ad-hoc definitions.
>
> And if you share .emacs like you do it with your bookmarks, there is no
> pain.
>
> > Can we take a look at fully-qualified file name reconstruction?
>
> There is a reason that ad-hoc multi-hop file names are called ad-hoc:
> they are ad-hoc, cand not designed to survive an Emacs session.
>
> For example, Tramp supports a use case (requested by Tramp users), where
> a container with the very same name exists @work on a remote machine,
> and @home on another remote machine. Tramp supports this scenario, you
> can always access this container as "docker:container-name:". See
> section "6.4.1 Using different proxies for the same destination" in the
> Tramp manual. If the extended multi-hop file name would be saved in your
> bookmarks (or recentf) file, this doesn't work.
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 12:56:02 GMT)
Full text and
rfc822 format available.
Message #124 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
Hi,
> Is there any harm if people who want to achieve what I outlined bind
> tramp-show-ad-hoc-proxies to non-nil? If that works in the way I
> suggest, why not recommend it?
There is no harm, if you set it before a connection is established, as
your tests have shown. But you should know the consequences, which I
have described last message.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 13:02:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Okay, so no objections to clarifying that users need to ensure they bind
tramp-show-ad-hoc-proxies to non-nil in advance of any multi-hop
connections? I can mention both, as succinctly as I can in the footnote and
docstring, and refer readers to the Tramp manual entries in the shell
bookmark manual?
On Sat, Feb 15, 2025 at 7:55 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Ship Mints <shipmints <at> gmail.com> writes:
>
> Hi,
>
> > Is there any harm if people who want to achieve what I outlined bind
> > tramp-show-ad-hoc-proxies to non-nil? If that works in the way I
> > suggest, why not recommend it?
>
> There is no harm, if you set it before a connection is established, as
> your tests have shown. But you should know the consequences, which I
> have described last message.
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 13:10:01 GMT)
Full text and
rfc822 format available.
Message #130 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
Hi,
> Okay, so no objections to clarifying that users need to ensure they
> bind tramp-show-ad-hoc-proxies to non-nil in advance of any multi-hop
> connections? I can mention both, as succinctly as I can in the
> footnote and docstring, and refer readers to the Tramp manual entries
> in the shell bookmark manual?
If I were you, I would mention both variants: using
tramp-show-ad-hoc-proxies and tramp-save-ad-hoc-proxies. References to
the Tramp manual shall be OK, because it is bundled with Emacs.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 15:35:01 GMT)
Full text and
rfc822 format available.
Message #133 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Would the below be correct, or are these options mutually exclusive in some
way? This commentary is intended for a docstring, not the manual, but the
footnotes for which will be similar and with xrefs:
Before creating ad-hoc multi-hop remote connections, customize either or
both:
`tramp-save-ad-hoc-proxies' to non-nil to persist proxy routes.
`tramp-show-ad-hoc-proxies' to non-nil to ensure connections are fully
qualified.
On Sat, Feb 15, 2025 at 8:08 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Ship Mints <shipmints <at> gmail.com> writes:
>
> Hi,
>
> > Okay, so no objections to clarifying that users need to ensure they
> > bind tramp-show-ad-hoc-proxies to non-nil in advance of any multi-hop
> > connections? I can mention both, as succinctly as I can in the
> > footnote and docstring, and refer readers to the Tramp manual entries
> > in the shell bookmark manual?
>
> If I were you, I would mention both variants: using
> tramp-show-ad-hoc-proxies and tramp-save-ad-hoc-proxies. References to
> the Tramp manual shall be OK, because it is bundled with Emacs.
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 15:45:02 GMT)
Full text and
rfc822 format available.
Message #136 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
Hi,
> Would the below be correct, or are these options mutually exclusive in
> some way? This commentary is intended for a docstring, not the manual,
> but the footnotes for which will be similar and with xrefs:
>
> Before creating ad-hoc multi-hop remote connections, customize either
> or
> both:
> `tramp-save-ad-hoc-proxies' to non-nil to persist proxy routes.
> `tramp-show-ad-hoc-proxies' to non-nil to ensure connections are fully
> qualified.
I've never tested, but I don't expect they are mutually exclusive.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 16:57:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
A quick check of tramp code suggests complete independence. Thanks.
Latest patch attached.
On Sat, Feb 15, 2025 at 10:44 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Ship Mints <shipmints <at> gmail.com> writes:
>
> Hi,
>
> > Would the below be correct, or are these options mutually exclusive in
> > some way? This commentary is intended for a docstring, not the manual,
> > but the footnotes for which will be similar and with xrefs:
> >
> > Before creating ad-hoc multi-hop remote connections, customize either
> > or
> > both:
> > `tramp-save-ad-hoc-proxies' to non-nil to persist proxy routes.
> > `tramp-show-ad-hoc-proxies' to non-nil to ensure connections are fully
> > qualified.
>
> I've never tested, but I don't expect they are mutually exclusive.
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
[0001-Add-shell-mode-bookmark-support-for-local-and-remote.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 17:17:01 GMT)
Full text and
rfc822 format available.
Message #142 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
> Latest patch attached.
And still nitpicks :-)
> +Note: Before creating ad-hoc multi-hop remote connections, customize
> +either or both:
> +@code{tramp-save-ad-hoc-proxies} to non-nil to persist proxy routes.
> +@code{tramp-show-ad-hoc-proxies} to non-nil to ensure connections are
> +fully qualified. This is helpful if you use the same persisted
> +bookmarks file on multiple hosts.
non-@code{nil}
> +@xref{Top, The Tramp Manual,, tramp, The Tramp Manual}. Also see the
> +more detailed documentation available here
> +@url{https://www.gnu.org/software/tramp/}.
??? Both the info manual and the HTML page are the same text.
> + (let ((bookmark-shell-file-name
> + (cond
> + ((file-remote-p default-directory)
> + (with-connection-local-variables
> + (cdr (assoc 'shell-file-name (buffer-local-value
> + 'connection-local-variables-alist
> + (current-buffer))))))
> + (shell-file-name shell-file-name)
> + (t sh-shell-file))))
My previous comment still stands: Use `connection-local-value'. Did you check?
> +(defun shell-bookmark-jump (bookmark)
> + "Default BOOKMARK handler for shell buffers.
> +Create a shell buffer with its `default-directory', shell process, and
> +buffer name from the bookmark. If there is an existing shell buffer of
> +the same name, default shell-mode behavior is to reuse that buffer.
`shell-mode'
> +For a remote shell `default-directory' will be the remote file name.
> +Remote shell buffers reuse existing connections that match the remote
> +file name, or may prompt you to create a new connection. Bind
> +`tramp-show-ad-hoc-proxies' to non-nil to ensure multi-hop remote
> +connections are fully qualified.
non-@code{nil}
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 17:42:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Feb 15, 2025 at 12:16 PM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Ship Mints <shipmints <at> gmail.com> writes:
>
> > Latest patch attached.
>
> And still nitpicks :-)
>
They're all thoughtful and welcome comments. Good engineers should be
nitpicky.
> non-@code{nil}
>
Done.
> +@xref{Top, The Tramp Manual,, tramp, The Tramp Manual}. Also see the
> > +more detailed documentation available here
> > +@url{https://www.gnu.org/software/tramp/}.
>
> ??? Both the info manual and the HTML page are the same text.
>
Done. This was just ignorance on my part, not knowing the tramp manual was
in a different doc subdirectory.
My previous comment still stands: Use `connection-local-value'. Did you
> check?
>
Got it. It was an oversight.
> `shell-mode'
>
Done.
> +For a remote shell `default-directory' will be the remote file name.
> > +Remote shell buffers reuse existing connections that match the remote
> > +file name, or may prompt you to create a new connection. Bind
> > +`tramp-show-ad-hoc-proxies' to non-nil to ensure multi-hop remote
> > +connections are fully qualified.
>
> non-@code{nil}
>
I see references to non-nil without quotes all over the place in docstrings.
Further, checkdoc warns about not putting t or nil in quotes.
Latest revision attached.
-Stephane
[Message part 2 (text/html, inline)]
[0001-Add-shell-mode-bookmark-support-for-local-and-remote.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Sat, 15 Feb 2025 17:51:03 GMT)
Full text and
rfc822 format available.
Message #148 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
Hi,
> > +For a remote shell `default-directory' will be the remote file
> name.
> > +Remote shell buffers reuse existing connections that match the
> remote
> > +file name, or may prompt you to create a new connection. Bind
> > +`tramp-show-ad-hoc-proxies' to non-nil to ensure multi-hop
> remote
> > +connections are fully qualified.
>
> non-@code{nil}
>
> I see references to non-nil without quotes all over the place in
> docstrings. Further, checkdoc warns about not putting t or nil in
> quotes.
My bad. Of course, the @code{} construct is just for texinfo. Pls ignore
this comment.
> -Stephane
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Wed, 05 Mar 2025 17:06:02 GMT)
Full text and
rfc822 format available.
Message #151 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Feb 15, 2025 at 12:50 PM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Ship Mints <shipmints <at> gmail.com> writes:
>
> Hi,
>
> > > +For a remote shell `default-directory' will be the remote file
> > name.
> > > +Remote shell buffers reuse existing connections that match the
> > remote
> > > +file name, or may prompt you to create a new connection. Bind
> > > +`tramp-show-ad-hoc-proxies' to non-nil to ensure multi-hop
> > remote
> > > +connections are fully qualified.
> >
> > non-@code{nil}
> >
> > I see references to non-nil without quotes all over the place in
> > docstrings. Further, checkdoc warns about not putting t or nil in
> > quotes.
>
> My bad. Of course, the @code{} construct is just for texinfo. Pls ignore
> this comment.
>
> > -Stephane
>
> Best regards, Michael.
>
Anything remaining to do before installing the most-recent version of the
patch?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Wed, 05 Mar 2025 17:22:02 GMT)
Full text and
rfc822 format available.
Message #154 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
Hi,
> Anything remaining to do before installing the most-recent version of the
> patch?
Nobody has complained, so I will do it tomorrow.
Best regards, Michael.
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>:
You have taken responsibility.
(Thu, 06 Mar 2025 11:56:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Protesilaos Stavrou <info <at> protesilaos.com>:
bug acknowledged by developer.
(Thu, 06 Mar 2025 11:56:02 GMT)
Full text and
rfc822 format available.
Message #159 received at 65039-done <at> debbugs.gnu.org (full text, mbox):
Version: 31.1
Hi,
>> Anything remaining to do before installing the most-recent version of the
>> patch?
>
> Nobody has complained, so I will do it tomorrow.
Done, closing the bug.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Tue, 18 Mar 2025 20:16:04 GMT)
Full text and
rfc822 format available.
Message #162 received at 65039-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Mar 6, 2025 at 6:55 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Version: 31.1
>
> Hi,
>
> >> Anything remaining to do before installing the most-recent version of
> the
> >> patch?
> >
> > Nobody has complained, so I will do it tomorrow.
>
> Done, closing the bug.
>
Michael, I've attached a tiny follow-on patch that promotes the
bookmark-handler property 'bookmark-inhibit from a scalar to a list. We
should have suggested this earlier. Best to take care of this now
before it gets used more widely.
Thank you,
-Stephane
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Tue, 18 Mar 2025 20:17:01 GMT)
Full text and
rfc822 format available.
Message #165 received at 65039-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 18, 2025 at 4:14 PM Ship Mints <shipmints <at> gmail.com> wrote:
> On Thu, Mar 6, 2025 at 6:55 AM Michael Albinus <michael.albinus <at> gmx.de>
> wrote:
>
>> Version: 31.1
>>
>> Hi,
>>
>> >> Anything remaining to do before installing the most-recent version of
>> the
>> >> patch?
>> >
>> > Nobody has complained, so I will do it tomorrow.
>>
>> Done, closing the bug.
>>
>
> Michael, I've attached a tiny follow-on patch that promotes the
> bookmark-handler property 'bookmark-inhibit from a scalar to a list. We
> should have suggested this earlier. Best to take care of this now
> before it gets used more widely.
>
> Thank you,
>
> -Stephane
>
Attachment...
[Message part 2 (text/html, inline)]
[0001-Promote-bookmark-handler-prop-bookmark-inhibit-to-li.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Wed, 19 Mar 2025 14:03:03 GMT)
Full text and
rfc822 format available.
Message #168 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
Hi,
> Michael, I've attached a tiny follow-on patch that promotes the
> bookmark-handler property 'bookmark-inhibit from a scalar to a
> list. We should have suggested this earlier. Best to take care
> of this now before it gets used more widely.
I suppose you must also adapt the docstring of bookmark-insert, which
speaks about "... the property `bookmark-inhibit' eq `insert'."
> Thank you,
>
> -Stephane
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Wed, 19 Mar 2025 14:54:03 GMT)
Full text and
rfc822 format available.
Message #171 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Mar 19, 2025 at 10:02 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Ship Mints <shipmints <at> gmail.com> writes:
>
> Hi,
>
> > Michael, I've attached a tiny follow-on patch that promotes the
> > bookmark-handler property 'bookmark-inhibit from a scalar to a
> > list. We should have suggested this earlier. Best to take care
> > of this now before it gets used more widely.
>
> I suppose you must also adapt the docstring of bookmark-insert, which
> speaks about "... the property `bookmark-inhibit' eq `insert'."
>
Right. Done in the attached patch. Thanks, again.
[Message part 2 (text/html, inline)]
[0001-Promote-bookmark-handler-prop-bookmark-inhibit-to-li.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Wed, 19 Mar 2025 15:03:03 GMT)
Full text and
rfc822 format available.
Message #174 received at 65039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Mar 19, 2025 at 10:53 AM Ship Mints <shipmints <at> gmail.com> wrote:
> On Wed, Mar 19, 2025 at 10:02 AM Michael Albinus <michael.albinus <at> gmx.de>
> wrote:
>
>> Ship Mints <shipmints <at> gmail.com> writes:
>>
>> Hi,
>>
>> > Michael, I've attached a tiny follow-on patch that promotes the
>> > bookmark-handler property 'bookmark-inhibit from a scalar to a
>> > list. We should have suggested this earlier. Best to take care
>> > of this now before it gets used more widely.
>>
>> I suppose you must also adapt the docstring of bookmark-insert, which
>> speaks about "... the property `bookmark-inhibit' eq `insert'."
>>
>
> Right. Done in the attached patch. Thanks, again.
>
I like this wording better...
[Message part 2 (text/html, inline)]
[0001-Promote-bookmark-handler-prop-bookmark-inhibit-to-li.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#65039; Package
emacs.
(Wed, 19 Mar 2025 16:02:01 GMT)
Full text and
rfc822 format available.
Message #177 received at 65039 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
Hi,
> Right. Done in the attached patch. Thanks, again.
>
> I like this wording better...
Pushed to master.
Best regards, Michael.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 17 Apr 2025 11:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 24 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.