[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54459: 29.0.50; Simplify connection-local variables (feature request
From: |
Michael Albinus |
Subject: |
bug#54459: 29.0.50; Simplify connection-local variables (feature request) |
Date: |
Sun, 20 Mar 2022 12:04:28 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Ergus via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:
> Hi:
Hi,
> There are 3 issues that could be solved/improved:
>
> 1) If another buffer of a file in the same remote host is already open,
> then when the function is called in that buffer for the first time it
> will use the value cached in gtags--executable-connection. That's why in
> the code I need to create a buffer local variable... Could we provide a
> way to update all of them immediately?
I don't understand the scenario, sorry. Could you pls explain it in detail?
> 2) There are functions to set connection-local profile variables
> (connection-local-set-profile-variables) But so far there are not any
> clean way to append variables to an existing profile; so a call to
> connection-local-set-profile-variables deleted any previous variable,
> actually the user is enforced to create a unique name for every profile
> every time it needs something like this.
--8<---------------cut here---------------start------------->8---
(connection-local-set-profile-variables
'profile
(append
(connection-local-get-profile-variables 'profile)
my-variables-list))
--8<---------------cut here---------------end--------------->8---
> 3) In the ideal world it may be possible to add an optional parameter to
> tell executable-find to cache the found values per host and executable
> name... so it could avoid the extra remote search... I understand this
> shouldn't be enabled by default, but many packages may find it
> useful. executable-find could be smart enough to remember some of the
> previous searches at least in remote hosts.
That's hard to do. A user could change the remote PATH while the result
of executable-find is cached. Furthermore, Tramp appends the local part
of the remote default-directory to the directory search list. Therefore,
executable-find could return a possibly wrong cached value.
You could write your own function, using Tramp's cache mechanism, but at
your own risk. Something like (untested)
--8<---------------cut here---------------start------------->8---
(defun my-executable-find (command &optional remote)
(if (and remote (file-remote-p default-directory))
(with-tramp-connection-property
(tramp-get-process (tramp-dissect-file-name default-directory))
(concat "executable-find-" command)
(executable-find command remote))
(executable-find command remote)))
--8<---------------cut here---------------end--------------->8---
Best regards, Michael.