bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54459: 29.0.50; Simplify connection-local variables (feature request


From: Ergus
Subject: bug#54459: 29.0.50; Simplify connection-local variables (feature request)
Date: Sun, 20 Mar 2022 13:09:55 +0100

On Sun, Mar 20, 2022 at 12:04:28PM +0100, Michael Albinus wrote:
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?

Suppose:

C-x C-f /ssh:myhost:file1
C-x C-f /ssh:myhost:file2
(executable-find mycommand 1)
And here we set the connection local variable...

When we go to file1 if does not know about the variable in spite of it
is in the same host.

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---

Could you consider to add a snippet in the documentation explaining
this? Please?

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.

SO this means that the executable in default-directory are also
considered? Like on Windows? I was not aware of that...

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---

I was thinking in something like:

(executable-find command &optional remote cache) but basically the same idea.

But it was just a dream... A man can dream, a man can dream ;p

Best regards, Michael.

Thanks,
Ergus




reply via email to

[Prev in Thread] Current Thread [Next in Thread]