GNU bug report logs -
#60505
29.0.60; Fido Mode and Tramp Completion
Previous Next
Reported by: Julien Roy <julien <at> jroy.ca>
Date: Tue, 3 Jan 2023 00:22:02 UTC
Severity: normal
Merged with 51386,
52758,
53513,
54042
Found in versions 28.0.50, 29.0.50, 29.0.60
Fixed in version 29.2
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 60505 in the body.
You can then email your comments to 60505 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#60505; Package
emacs.
(Tue, 03 Jan 2023 00:22:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Julien Roy <julien <at> jroy.ca>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 03 Jan 2023 00:22:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
When I C-x C-f and start typing a TRAMP session to an SSH host, for instance
`/ssh:`, then hit <tab>, I see a list of known hosts proposed for
completion. This is the expected behavior. If I then enable fido-mode
and do the same, instead of having known hosts proposed when hitting
<tab>, I only get a list of TRAMP methods for completion, eg. `ssh:`,
`sshx:` and `sshfs:`. I would expect to also have known hosts on
fido-mode.
To reproduce, open emacs -Q; then:
C-x C-f /ssh: <tab>
(This produces the expected behavior of proposing known hosts)
M-x fido-mode
C-x C-f /ssh: <tab>
(Now, only TRAMP methods are proposed for completion)
In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.35, cairo version 1.17.6) of 2022-12-27 built on localhost
Repository revision: ba1ddea9dabf51c9c6e463d667bcce0b48294453
Repository branch: emacs-29
System Description: Gentoo Linux
Configured using:
'configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --datarootdir=/usr/share
--disable-silent-rules --docdir=/usr/share/doc/emacs-29.0.9999-r1
--htmldir=/usr/share/doc/emacs-29.0.9999-r1/html --libdir=/usr/lib64
--program-suffix=-emacs-29-vcs --includedir=/usr/include/emacs-29-vcs
--infodir=/usr/share/info/emacs-29-vcs --localstatedir=/var
--enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
--without-compress-install --without-hesiod --without-pop
--with-file-notification=inotify --with-pdumper --enable-acl
--with-dbus --with-modules --without-gameuser --with-libgmp --with-gpm
--with-native-compilation=aot --without-json --without-kerberos
--without-kerberos5 --with-lcms2 --with-xml2 --without-mailutils
--without-selinux --without-sqlite3 --with-gnutls --without-libsystemd
--with-threads --with-tree-sitter --without-wide-int --with-sound=alsa
--with-zlib --with-pgtk --without-x --without-ns
--with-toolkit-scroll-bars --without-gconf --with-gsettings
--with-harfbuzz --without-libotf --without-m17n-flt --without-xwidgets
--with-gif --with-jpeg --with-png --with-rsvg --with-tiff --with-webp
--without-imagemagick --with-dumping=pdumper 'CFLAGS=-march=znver2 -O2
-pipe' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed''
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG
SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3
ZLIB
Important settings:
value of $LC_MONETARY: en_US.UTF-8
value of $LC_NUMERIC: en_US.UTF-8
value of $LC_TIME: en_US.UTF-8
value of $LANG: en_US.utf8
locale-coding-system: utf-8-unix
Major mode: Org
Minor modes in effect:
flyspell-mode: t
org-indent-mode: t
server-mode: t
fido-vertical-mode: t
icomplete-vertical-mode: t
icomplete-mode: t
fido-mode: t
pixel-scroll-mode: t
electric-pair-mode: t
delete-selection-mode: t
global-hl-line-mode: t
shell-dirtrack-mode: t
override-global-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
global-prettify-symbols-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/usr/share/emacs/site-lisp/cmake-mode hides /usr/share/emacs/site-lisp/cmake/cmake-mode
/usr/share/emacs/site-lisp/desktop-entry-mode hides /usr/share/emacs/site-lisp/desktop-file-utils/desktop-entry-mode
Features:
(shadow emacsbug flyspell ispell org-indent org-element org-persist
org-id org-refile avl-tree generator oc-basic ol-eww eww xdg url-queue
ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect ol-docview doc-view
filenotify jka-compr image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m
ol-doi org-link-doi org ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-macro org-src ob-comint org-pcomplete org-list org-footnote
org-faces org-entities noutline outline ob-emacs-lisp ob-core ob-eval
org-cycle org-table ol org-fold org-fold-core org-keys oc org-loaddefs
find-func cal-menu calendar cal-loaddefs org-version org-compat org-macs
ebuild-mode skeleton sh-script smie treesit executable bookmark
gnus-notifications gnus-fun notifications mule-util sort gnus-cite
smiley qp mm-archive mail-extr textsec uni-scripts idna-mapping
ucs-normalize uni-confusable textsec-check gnus-async gnus-bcklg gnus-ml
disp-table gnus-topic nndraft nnmh nnrss mm-url nnfolder utf-7 epa-file
network-stream nsm gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig
gnus-cache gnus-sum shr pixel-fill kinsoku url-file svg dom comp
comp-cstr server display-line-numbers cl-extra checkdoc lisp-mnt
help-mode flymake-proc flymake project compile warnings thingatpt init
init-mentor init-flyspell init-flymake help-at-pt init-tramp init-modus
modus-vivendi-theme modus-themes pcase init-fido icomplete init-gnus
smtpmail gnus-demon nntp gnus-group gnus-undo gnus-start gnus-dbus dbus
xml gnus-cloud nnimap nnmail mail-source utf7 gnus-spec gnus-win nnoo
gnus-int gnus-range message sendmail yank-media puny rfc822 mml mml-sec
epa derived epg rfc6068 epg-config mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils
mailheader gnus nnheader gnus-util text-property-search mail-utils range
mm-util mail-prsvr init-org init-ui pixel-scroll cua-base dired
dired-loaddefs elec-pair delsel hl-line init-packages lxd-tramp tramp
tramp-loaddefs trampver tramp-integration cus-edit pp cus-load icons
wid-edit files-x tramp-compat rx shell pcomplete comint ansi-osc
ansi-color ring parse-time iso8601 time-date ls-lisp format-spec
use-package use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode use-package-core site-gentoo
mentor-autoloads xml-rpc-autoloads async-autoloads
org-contacts-autoloads yaml-mode-autoloads url-scgi-autoloads package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache
json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs
cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win
pgtk-win term/common-win pgtk-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo gtk pgtk lcms2 multi-tty make-network-process
native-compile emacs)
Memory information:
((conses 16 689456 32101)
(symbols 48 30811 5)
(strings 32 167646 8527)
(string-bytes 1 23679638)
(vectors 16 82271)
(vector-slots 8 2107107 230233)
(floats 8 487 403)
(intervals 56 2195 393)
(buffers 984 27))
<#secure method=pgpmime mode=sign>
--
Julien
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Tue, 03 Jan 2023 08:57:01 GMT)
Full text and
rfc822 format available.
Message #10 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Julien Roy <julien <at> jroy.ca> writes:
Hi Julien,
> When I C-x C-f and start typing a TRAMP session to an SSH host, for instance
> `/ssh:`, then hit <tab>, I see a list of known hosts proposed for
> completion. This is the expected behavior. If I then enable fido-mode
> and do the same, instead of having known hosts proposed when hitting
> <tab>, I only get a list of TRAMP methods for completion, eg. `ssh:`,
> `sshx:` and `sshfs:`. I would expect to also have known hosts on
> fido-mode.
>
> To reproduce, open emacs -Q; then:
> C-x C-f /ssh: <tab>
> (This produces the expected behavior of proposing known hosts)
> M-x fido-mode
> C-x C-f /ssh: <tab>
> (Now, only TRAMP methods are proposed for completion)
This is the same as bug#51386, bug#52758, bug#53513, bug#54042. I've merged
your report with them.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Thu, 05 Jan 2023 13:08:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 60505 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> When I C-x C-f and start typing a TRAMP session to an SSH host, for
> instance `/ssh:`, then hit <tab>, I see a list of known hosts proposed
> for completion. This is the expected behavior. If I then enable
> fido-mode and do the same, instead of having known hosts proposed when
> hitting <tab>, I only get a list of TRAMP methods for completion, eg.
> `ssh:`, `sshx:` and `sshfs:`. I would expect to also have known hosts on
> fido-mode.
>
> To reproduce, open emacs -Q; then:
> C-x C-f /ssh: <tab>
> (This produces the expected behavior of proposing known hosts)
> M-x fido-mode
> C-x C-f /ssh: <tab>
> (Now, only TRAMP methods are proposed for completion)
>
There are two problems here:
1. fido-mode sets completion-styles to 'flex', and as indicated in the
docstring of completion-styles "Tramp host name completion (e.g.,
"/ssh:ho<TAB>") currently doesn't work if this list doesn't contain at
least one of `basic', `emacs22' or `emacs21'." The workaround is to add
this to your init file:
(advice-add #'icomplete--fido-mode-setup
:after (lambda () (setq completion-styles '(flex basic))))
You could also ask for that change to be made in core.
2. Doing that is not enough, because of an incompatibility between Tramp
and the 'flex' and 'substring' mechanisms. The Tramp manual has a
footnote which mentions that incompatibility: "Some completion styles,
like `substring' or `flex', require to type at least one character after
the trailing `:'." A one-line patch to fix it was proposed, but rejected,
a year and a half ago. It is attached to this email, and you can use it
locally. As I said in the bug thread in which that patch was proposed: "I
expect other bug reports from confused users".
[Improve-handling-of-non-default-completion-styles-wi.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Thu, 05 Jan 2023 13:56:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> heytings.org> writes:
Hi Gregory,
> 2. Doing that is not enough, because of an incompatibility between
> Tramp and the 'flex' and 'substring' mechanisms. The Tramp manual has
> a footnote which mentions that incompatibility: "Some completion
> styles, like `substring' or `flex', require to type at least one
> character after the trailing `:'." A one-line patch to fix it was
> proposed, but rejected, a year and a half ago. It is attached to this
> email, and you can use it locally. As I said in the bug thread in
> which that patch was proposed: "I expect other bug reports from
> confused users".
I don't deny that there is a problem, and it isn't a surprise that
people report about. But I don't think that Tramp misbehaves, it does
exactly what it is specified to do.
I guess that flex and friends use completion out of the
specification. But I have no knowledge about the completion machinery;
otherwise I would have tried to find the root of the problem. I'm also
not opposed to extend the completion API for use in Tramp. What I'm
opposed to is to apply just an ad-hoc patch, which could have collateral
damages.
I still hope that somebody with more knowledge about the completion
machinery could take a stab at it.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Thu, 05 Jan 2023 14:15:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 60505 <at> debbugs.gnu.org (full text, mbox):
>> 2. Doing that is not enough, because of an incompatibility between
>> Tramp and the 'flex' and 'substring' mechanisms. The Tramp manual has
>> a footnote which mentions that incompatibility: "Some completion
>> styles, like `substring' or `flex', require to type at least one
>> character after the trailing `:'." A one-line patch to fix it was
>> proposed, but rejected, a year and a half ago. It is attached to this
>> email, and you can use it locally. As I said in the bug thread in
>> which that patch was proposed: "I expect other bug reports from
>> confused users".
>
> I don't deny that there is a problem, and it isn't a surprise that
> people report about. But I don't think that Tramp misbehaves, it does
> exactly what it is specified to do.
>
You may remind that we disagreed on that point. When a connection method
has already been fully specified by the user, such as "/ssh:", there is no
reason Tramp should tell the user that there are two other connection
methods "/sshfs:" and "/sshx:". IOW, after
C-x C-f /ssh TAB
it makes sense to tell the user that there are three possible methods:
"/ssh:", "/sshfs:" and "/sshx:". But after
C-x C-f /ssh: TAB
there is no reason to do that again. What the user expects at that point
is a list of hostnames.
>
> I guess that flex and friends use completion out of the specification.
> But I have no knowledge about the completion machinery; otherwise I
> would have tried to find the root of the problem. I'm also not opposed
> to extend the completion API for use in Tramp. What I'm opposed to is to
> apply just an ad-hoc patch, which could have collateral damages.
>
> I still hope that somebody with more knowledge about the completion
> machinery could take a stab at it.
>
Why could we not use the ad-hoc patch, with a FIXME note, until somebody
has the time to find a better solution, instead of letting bug reports
about that problem accumulate? Sure, it could possibly have a collateral
damage, but it could as well have no collateral damage at all.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Thu, 05 Jan 2023 20:59:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Hi Gregory,
Gregory Heytings <gregory <at> heytings.org> writes:
>
> There are two problems here:
>
> 1. fido-mode sets completion-styles to 'flex', and as indicated in the
> docstring of completion-styles "Tramp host name completion (e.g.,
> "/ssh:ho<TAB>") currently doesn't work if this list doesn't contain at
> least one of `basic', `emacs22' or `emacs21'." The workaround is to
> add this to your init file:
>
> (advice-add #'icomplete--fido-mode-setup
> :after (lambda () (setq completion-styles '(flex basic))))
>
> You could also ask for that change to be made in core.
>
> 2. Doing that is not enough, because of an incompatibility between
> Tramp and the 'flex' and 'substring' mechanisms. The Tramp manual has
> a footnote which mentions that incompatibility: "Some completion
> styles, like `substring' or `flex', require to type at least one
> character after the trailing `:'." A one-line patch to fix it was
> proposed, but rejected, a year and a half ago. It is attached to this
> email, and you can use it locally. As I said in the bug thread in
> which that patch was proposed: "I expect other bug reports from
> confused users".
>
>
<#secure method=pgpmime mode=sign>
I did that, added the snipped to my init file, and patched my
tramp.el. Now, Tramp completion works as expected in fido-mode:
C-x C-f /ssh <tab> : auto-completes tramp methods (/ssh: /sshx: /sshfs:)
C-x C-f /ssh: <tab> : auto-completes with known hosts
Thank you very much!
--
Julien
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Fri, 06 Jan 2023 09:52:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 60505 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> Why could we not use the ad-hoc patch, with a FIXME note, until somebody
> has the time to find a better solution, instead of letting bug reports
> about that problem accumulate? Sure, it could possibly have a
> collateral damage, but it could as well have no collateral damage at
> all.
>
By the way, to limit the scope of the potential collateral damages, it is
also possible to use that condition only when completion-styles contain
'substring' or 'flex'.
What do you think of the attached patch?
[Improve-handling-of-non-default-completion-styles-wi.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Sat, 14 Jan 2023 21:38:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Michael, what do you think of that patch? It would be regrettable to
leave that bug unfixed in Emacs 29.
>
> By the way, to limit the scope of the potential collateral damages, it
> is also possible to use that condition only when completion-styles
> contain 'substring' or 'flex'.
>
> What do you think of the attached patch?
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Sun, 15 Jan 2023 19:25:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> heytings.org> writes:
> Michael,
Hi Gregory,
> what do you think of that patch? It would be regrettable to
> leave that bug unfixed in Emacs 29.
Yes, it would be desirable to fix this. But it isn't the end of the
world if this doesn't happen, the problem is already evident in Emacs
28, so we don't have a regression.
>> By the way, to limit the scope of the potential collateral damages,
>> it is also possible to use that condition only when
>> completion-styles contain 'substring' or 'flex'.
>>
>> What do you think of the attached patch?
And what do we want to do if there are more completion-styles like this?
Extend Tramp then?
And there are more use cases like this, which are not working
properly. Think about changing the Tramp syntax to `separate', which
means a remote file name like "[method/user <at> host]/path/to/file". If you
use default completion, it works like this:
- emacs -Q -l tramp --eval '(tramp-change-syntax (quote separate))'
- Type "/ [ s TAB" and you see all methods
- Continue with "s h / TAB" and you see nonsense :-(
- Continue with "d TAB" and you see all possible host names starting
with "d"
- Select a host name and type "] TAB TAB" and you see the remote file names
And now with fido:
- emacs -Q -l tramp --eval '(tramp-change-syntax (quote separate))' -f fido-mode
- Type "/ [ s TAB" and you see no completion at all
- Continue with "s h / TAB" and you see the same nonsense :-(
- Continue with "d TAB" and you see no completion at all
- Type host name and type "] TAB TAB" and you see the remote file names
Although the default completion isn't perfect (likely a Tramp bug),
there is much more wrong with fido.
The last days, since you have shown your patch here, I've spent several
hours debugging Emacs completion in order to understand what's
up. Horrible, because Emacs completion machinery is pretty complex and
under-documented (I believe). And honestly, I'm not interested too much
in this machinery.
It is a pity, that *nobody* who knows this in detail tries to
investigate the problem here, although we have already five reports
about.
Instead, Tramp shall apply a patch which is not related there, which
adds further dependencies, which is not working for all use cases, and
which is good for making more trouble in the future. My opinion.
Anyway, I will try to investigate the completion machinery. No promise
that I will succeed.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Sun, 15 Jan 2023 22:39:03 GMT)
Full text and
rfc822 format available.
Message #34 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Hi Michael,
>> what do you think of that patch? It would be regrettable to leave that
>> bug unfixed in Emacs 29.
>
> Yes, it would be desirable to fix this. But it isn't the end of the
> world if this doesn't happen, the problem is already evident in Emacs
> 28, so we don't have a regression.
>
It's correct that the same problem is present in Emacs 28, but it is not
in Emacs 27, so it's a regression. As I tried to explain in bug#50387,
the problem is that once Tramp is loaded, Tramp methods are returned when
completions are requested for a root directory ("/"). This problem is
even worse since commit d5c6bf9625: prior to that commit only the 'scp'
and 'scpx' methods were returned (in emacs -Q), now all methods are
returned. And this confuses the flex and substring completion mechanisms.
>>> By the way, to limit the scope of the potential collateral damages, it
>>> is also possible to use that condition only when completion-styles
>>> contain 'substring' or 'flex'.
>>>
>>> What do you think of the attached patch?
>
> And what do we want to do if there are more completion-styles like this?
> Extend Tramp then?
>
Not extend Tramp, but add them, if necessary, to the list of
completion-styles that are handled specially by Tramp at that place.
Unless of course a better fix has been implemented in the meantime.
>
> And there are more use cases like this, which are not working properly.
> Think about changing the Tramp syntax to `separate', which means a
> remote file name like "[method/user <at> host]/path/to/file". If you use
> default completion, it works like this:
>
> - emacs -Q -l tramp --eval '(tramp-change-syntax (quote separate))'
> - Type "/ [ s TAB" and you see all methods
> - Continue with "s h / TAB" and you see nonsense :-(
> - Continue with "d TAB" and you see all possible host names starting with "d"
> - Select a host name and type "] TAB TAB" and you see the remote file names
>
> And now with fido:
>
> - emacs -Q -l tramp --eval '(tramp-change-syntax (quote separate))' -f fido-mode
> - Type "/ [ s TAB" and you see no completion at all
> - Continue with "s h / TAB" and you see the same nonsense :-(
> - Continue with "d TAB" and you see no completion at all
> - Type host name and type "] TAB TAB" and you see the remote file names
>
> Although the default completion isn't perfect (likely a Tramp bug),
> there is much more wrong with fido.
>
Well, that looks like a separate problem, with a non-default syntax, which
(given the number of hits of "tramp-change-syntax" on Google or on Github)
is apparently hardly ever used.
Nonetheless, I tried your recipe with the patch applied, and the good news
is that with it, under Fido, Tramp behaves the same way it behaves under
the default completions: the available methods are displayed after "/ [ s
TAB", the same nonsense is displayed after "/ [ ssh/ TAB", and the
possible host names are displayed after typing a letter followed by TAB.
>
> Instead, Tramp shall apply a patch which is not related there, which
> adds further dependencies, which is not working for all use cases, and
> which is good for making more trouble in the future. My opinion.
>
I don't understand what you mean here, sorry.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 18 Jan 2023 12:31:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 60505 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gregory Heytings <gregory <at> heytings.org> writes:
> Hi Michael,
Hi Gregory,
>>> what do you think of that patch? It would be regrettable to leave
>>> that bug unfixed in Emacs 29.
>>
>> Yes, it would be desirable to fix this. But it isn't the end of the
>> world if this doesn't happen, the problem is already evident in
>> Emacs 28, so we don't have a regression.
>>
>
> It's correct that the same problem is present in Emacs 28, but it is
> not in Emacs 27, so it's a regression. As I tried to explain in
> bug#50387, the problem is that once Tramp is loaded, Tramp methods are
> returned when completions are requested for a root directory ("/").
> This problem is even worse since commit d5c6bf9625: prior to that
> commit only the 'scp' and 'scpx' methods were returned (in emacs -Q),
> now all methods are returned. And this confuses the flex and
> substring completion mechanisms.
Yes. But this is not a Tramp fault. Completion styles like flex (and
substring, didn't test) do ignore Tramp file name syntax. They simply
think in terms of file name parts, separated by "/". This is not
appropriate for remote file names.
Tramp knows only file-name-completion and file-name-all-completions. This
is what it is called with; Tramp doesn't know anything about completion
styles. It would be an error to bring this into Tramp, based on these
two functions which are not designed to give the file name handler more
information about completion styles. This is our disagreement.
>>>> By the way, to limit the scope of the potential collateral
>>>> damages, it is also possible to use that condition only when
>>>> completion-styles contain 'substring' or 'flex'.
>>>>
>>>> What do you think of the attached patch?
>>
>> And what do we want to do if there are more completion-styles like
>> this? Extend Tramp then?
>
> Not extend Tramp, but add them, if necessary, to the list of
> completion-styles that are handled specially by Tramp at that
> place. Unless of course a better fix has been implemented in the
> meantime.
And this is exactly my fear: Tramp would depend on unrelated features,
and Tramp must follow. And you can't even guarantee that Tramp knows
all completion styles in question. Any user in the wild can specify her
own completion style.
> Well, that looks like a separate problem, with a non-default syntax,
> which (given the number of hits of "tramp-change-syntax" on Google or
> on Github) is apparently hardly ever used.
Then write a bug report, requesting to remove this Tramp syntax :-)
Seriously, this is the Tramp syntax used by XEmacs years ago. We've
promised the XEmacs converts to keep this syntax, in order to make their
life in GNU Emeacs less alienated.
> Nonetheless, I tried your recipe with the patch applied, and the good
> news is that with it, under Fido, Tramp behaves the same way it
> behaves under the default completions: the available methods are
> displayed after "/ [ s TAB", the same nonsense is displayed after "/ [
> ssh/ TAB", and the possible host names are displayed after typing a
> letter followed by TAB.
So yes, we shall at least hunt the bug displaying nonsense.
>> Instead, Tramp shall apply a patch which is not related there, which
>> adds further dependencies, which is not working for all use cases,
>> and which is good for making more trouble in the future. My opinion.
>
> I don't understand what you mean here, sorry.
Simply that it isn't Tramp's duty to fix the bug we're discussing. It
must be fixed by the flex (and possibly also substring) completion
styles.
I spent another couple of hours debugging completion in
minibuffer.el. The appended patch shows a possible fix for the flex
completion style. I don't claim this shall go into master; it is just a
rawhammer approach due to my limited knowledge about completion
styles. But it might give you an idea how a solution could look like.
Best regards, Michael.
[Message part 2 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 01 Feb 2023 18:13:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 60505 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> It's correct that the same problem is present in Emacs 28, but it is
>> not in Emacs 27, so it's a regression. As I tried to explain in
>> bug#50387, the problem is that once Tramp is loaded, Tramp methods are
>> returned when completions are requested for a root directory ("/").
>> This problem is even worse since commit d5c6bf9625: prior to that
>> commit only the 'scp' and 'scpx' methods were returned (in emacs -Q),
>> now all methods are returned. And this confuses the flex and substring
>> completion mechanisms.
>
> Yes. But this is not a Tramp fault.
>
It definitely is Tramp's "fault".
>
> Completion styles like flex (and substring, didn't test) do ignore Tramp
> file name syntax. They simply think in terms of file name parts,
> separated by "/". This is not appropriate for remote file names.
>
What filenames are is defined for example by POSIX in its Definitions
chapter ("Filename", "Pathname", "Pathname Resolution"). It is quite
clear in those definitions that there is no place for a _method_ or a
_host name_ in file names. Something with a method, a host name and a
path is a different beast: it's an URI. And it's not a coincidence if
(absolute) file names start with a slash, and URI do _not_ start with a
slash.
Tramp decided, for a reason I do not clearly understand, to invent URIs
starting with a slash. File name completion mechanisms rightly assume
that file names correspond to the standard syntax of file names, and there
is no reason (and, for that matter, no reliable way) to fix the current
problem at the level of completion styles.
So I have yet another proposal: add a variable to let users (and modes)
decide whether Tramp methods should be returned when completions for the
root directory are requested. Patch attached.
[Improve-handling-of-Tramp-methods-by-completion-styl.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 01 Feb 2023 20:16:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> heytings.org> writes:
Hi,
>>> It's correct that the same problem is present in Emacs 28, but it
>>> is not in Emacs 27, so it's a regression. As I tried to explain in
>>> bug#50387, the problem is that once Tramp is loaded, Tramp methods
>>> are returned when completions are requested for a root directory
>>> ("/"). This problem is even worse since commit d5c6bf9625: prior to
>>> that commit only the 'scp' and 'scpx' methods were returned (in
>>> emacs -Q), now all methods are returned. And this confuses the
>>> flex and substring completion mechanisms.
>>
>> Yes. But this is not a Tramp fault.
>
> It definitely is Tramp's "fault".
Have you even tried to check the PoC patch I've sent?
>> Completion styles like flex (and substring, didn't test) do ignore
>> Tramp file name syntax. They simply think in terms of file name
>> parts, separated by "/". This is not appropriate for remote file
>> names.
>
> What filenames are is defined for example by POSIX in its Definitions
> chapter ("Filename", "Pathname", "Pathname Resolution"). It is quite
> clear in those definitions that there is no place for a _method_ or a
> _host name_ in file names. Something with a method, a host name and a
> path is a different beast: it's an URI. And it's not a coincidence if
> (absolute) file names start with a slash, and URI do _not_ start with
> a slash.
>
> Tramp decided, for a reason I do not clearly understand, to invent
> URIs starting with a slash. File name completion mechanisms rightly
> assume that file names correspond to the standard syntax of file
> names, and there is no reason (and, for that matter, no reliable way)
> to fix the current problem at the level of completion styles.
In that case I recommend you to abstain from using Tramp.
I'm so fed up.
EOT
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 01 Feb 2023 21:28:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 60505 <at> debbugs.gnu.org (full text, mbox):
>
> Have you even tried to check the PoC patch I've sent?
>
I did, of course. It circumvents (a part of) the bug for the flex
completion style indeed. But alas it doesn't really work. For example:
emacs -Q -l tramp -f fido-mode
C-x C-f /ssh: TAB M-down
inserts a wrong completion candidate in the minibuffer.
More importantly (as I unsuccessfully tried to convey) it circumvents the
bug in the implementation of a particular completion mechanism, which is
not the place where the bug lies and should be fixed. It is not
reasonable to expect that all existing and future file completion
mechanisms should implement specific rules to deal with the Tramp syntax
(or, for that matter, with the syntax of any other package).
>
> In that case I recommend you to abstain from using Tramp.
>
I do not use Tramp (and I do not use Fido, either). I'm only trying to
help confused users here.
>
> I'm so fed up.
>
I'm sorry to hear that what I said annoyed you. Please consider that I
spent a significant amount of time on this bug, too, and that I proposed
at least three patches to fix it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Thu, 02 Feb 2023 06:39:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 60505 <at> debbugs.gnu.org (full text, mbox):
> Cc: 60505 <at> debbugs.gnu.org, Julien Roy <julien <at> jroy.ca>
> Date: Wed, 01 Feb 2023 21:27:33 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
>
> More importantly (as I unsuccessfully tried to convey) it circumvents the
> bug in the implementation of a particular completion mechanism, which is
> not the place where the bug lies and should be fixed. It is not
> reasonable to expect that all existing and future file completion
> mechanisms should implement specific rules to deal with the Tramp syntax
> (or, for that matter, with the syntax of any other package).
From my POV, it is very reasonable to expect that completion
mechanisms know about Tramp syntax and support it. Tramp became long
ago an integral part of the Emacs core, so its syntax is as important
to support as any other syntactical aspects of file names in Emacs,
such as the "/:" "quoting".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Thu, 02 Feb 2023 08:26:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> More importantly (as I unsuccessfully tried to convey) it circumvents the
>> bug in the implementation of a particular completion mechanism, which is
>> not the place where the bug lies and should be fixed. It is not
>> reasonable to expect that all existing and future file completion
>> mechanisms should implement specific rules to deal with the Tramp syntax
>> (or, for that matter, with the syntax of any other package).
>
> From my POV, it is very reasonable to expect that completion
> mechanisms know about Tramp syntax and support it. Tramp became long
> ago an integral part of the Emacs core, so its syntax is as important
> to support as any other syntactical aspects of file names in Emacs,
> such as the "/:" "quoting".
I could imagine that the completion machinery offers an API that a
package could register its own idea of a file name syntax. Plus a hook,
for parts of that file name the package is responsible itself. This
would avoid the need to check in the completion machinery, which Tramp
syntax is recent.
The current API, file name handlers for file-name-completion and
file-name-all-completions, is too restricted.
Other packages but Tramp would profit as well. For example, running
"emacs -Q", typing "/: TAB", removes the colon and offers completions
for "/". I don't know whether this is really right; there is a reason
that a user has started with "/:".
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Thu, 02 Feb 2023 09:16:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 60505 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Gregory Heytings <gregory <at> heytings.org>, 60505 <at> debbugs.gnu.org,
> julien <at> jroy.ca
> Date: Thu, 02 Feb 2023 09:25:41 +0100
>
> > From my POV, it is very reasonable to expect that completion
> > mechanisms know about Tramp syntax and support it. Tramp became long
> > ago an integral part of the Emacs core, so its syntax is as important
> > to support as any other syntactical aspects of file names in Emacs,
> > such as the "/:" "quoting".
>
> I could imagine that the completion machinery offers an API that a
> package could register its own idea of a file name syntax. Plus a hook,
> for parts of that file name the package is responsible itself. This
> would avoid the need to check in the completion machinery, which Tramp
> syntax is recent.
I won't object to developing such a mechanism. Stefan, would that
make sense and/or be reasonably practical to implement?
> Other packages but Tramp would profit as well. For example, running
> "emacs -Q", typing "/: TAB", removes the colon and offers completions
> for "/". I don't know whether this is really right; there is a reason
> that a user has started with "/:".
That's true, but completing after typing just "/:" doesn't make a lot
of sense to me; maybe I'm missing something. OTOH, I also don't
understand why remove the colon in this case. If we know which code
does that, perhaps we could look into its VCS history and learn
something.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Thu, 02 Feb 2023 15:06:01 GMT)
Full text and
rfc822 format available.
Message #58 received at 60505 <at> debbugs.gnu.org (full text, mbox):
> I don't deny that there is a problem, and it isn't a surprise that
> people report about. But I don't think that Tramp misbehaves, it does
> exactly what it is specified to do.
>
> I guess that flex and friends use completion out of the
> specification.
It's neither's fault, really. It's a shortcoming of the intermediary,
i.e. the completion-table API.
The completion-table API only offers "prefix" completion, so the only
thing "flex" and "substring" can do when asked to complete `/ssh:`
is to ask for all the completions in `/` (because the definition of
"substring" completion means that it should also match `/foossh:bar`
and similarly for "flex").
I have some draft of a new completion-table API where it's possible for
the completion style to propagate more information about which
completions it's looking for, so for example the completion-table might
be asked to return the completions that match `/*ssh:*` or even
`/*s*s*h*:*`. It's then up to the completion-table to do something
useful with it (of course, the API is designed such that the
completion-tables don't *have* to handle those more complex cases:
there's a general fallback mechanism which reduces those queries to
simpler ones).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Thu, 02 Feb 2023 15:18:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 60505 <at> debbugs.gnu.org (full text, mbox):
> Yes. But this is not a Tramp fault. Completion styles like flex (and
> substring, didn't test) do ignore Tramp file name syntax. They simply
> think in terms of file name parts, separated by "/". This is not
> appropriate for remote file names.
Actually, completion styles don't know whether they're completing file
names or not and don't really know that "/" is special in file name syntax.
This is done by `completion-file-name-table` instead. This one, in turn
tries not to pay attention to "/" either, and to rely on file-name
functions instead (e.g. `file-name-directory`).
> Tramp knows only file-name-completion and file-name-all-completions.
Tramp could also influence the completion behavior via the other
file-name functions.
E.g. defining (file-name-directory "/ssh:foo") => "/ssh:" could fix some
of the flex completion cases discussed here.
[ Note: I'm not actually suggesting that this is the solution.
It would likely come with its own set of problems. ]
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Thu, 02 Feb 2023 15:40:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 60505 <at> debbugs.gnu.org (full text, mbox):
> I could imagine that the completion machinery offers an API that a
> package could register its own idea of a file name syntax.
The completion code relies on `file-name-directory`,
`directory-file-name`, etc... for that.
The problem as I see it goes as follows:
According to `file-name-directory`, in `/ssh:myhost` the part
`ssh:myhost` is an element of the `/` directory. For this reason, the
completion machinery would expect (file-name-all-completions "s" "/") to
include "ssh:myhost" in its return list rather than only "ssh:".
Now, it's impractical for Tramp to do that. So the end result is the
kind of bug reports we're discussing.
One way to fix the problem is for Tramp to "teach" the rest of the
system that `/ssh:` is a kind of directory, in which case the completion
machinery would know that (file-name-all-completions "s" "/") returns
"ssh:" and that "myhost" would be included only in the return value of
(file-name-all-completions "" "/ssh:").
Another is to change Tramp's syntax so that it uses the regular "/"
separator rather than ":". This would get a similar result but without
touching `file-name-directory` and friends.
We could also consider introducing a new set of (file-name) functions
completion-file-name-directory, completion-directory-file-name, ...
so the completion code can use its own notion of how a file name gets
separated into parts. But introducing such a subtle distinction would
likely introduce a lot of bugs&confusion as well.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Fri, 03 Feb 2023 00:24:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 60505 <at> debbugs.gnu.org (full text, mbox):
>> More importantly (as I unsuccessfully tried to convey) it circumvents
>> the bug in the implementation of a particular completion mechanism,
>> which is not the place where the bug lies and should be fixed. It is
>> not reasonable to expect that all existing and future file completion
>> mechanisms should implement specific rules to deal with the Tramp
>> syntax (or, for that matter, with the syntax of any other package).
>
> From my POV, it is very reasonable to expect that completion mechanisms
> know about Tramp syntax and support it. Tramp became long ago an
> integral part of the Emacs core, so its syntax is as important to
> support as any other syntactical aspects of file names in Emacs, such as
> the "/:" "quoting".
>
The possibility that it would be necessary at some point to add an
explicit support for the Tramp syntax(es) in the completion mechanisms
cannot be ruled out, of course. But this bug (and the related ones) is
not a reason to do that, because it can easily be fixed inside Tramp.
Did you look at the options that are on the table?
Option 1 is a trivial three-line patch to tramp.el, which adds a
conditional around an existing statement to give users and modes control
on the way Tramp methods are displayed (unconditionally with
tramp-methods-in-completions t, lazily with tramp-methods-in-completions
nil):
diff --git a/lisp/net/tramp.el b/lisp/net/tramp.el
index 1916d50af03..ca08a0a2cd2 100644
--- a/lisp/net/tramp.el
+++ b/lisp/net/tramp.el
@@ -812,6 +812,8 @@ tramp-syntax
:initialize #'custom-initialize-default
:set #'tramp-set-syntax)
+(defcustom tramp-methods-in-completions t)
+
(defvar tramp-prefix-format)
(defvar tramp-prefix-regexp)
(defvar tramp-method-regexp)
@@ -3022,8 +3024,10 @@ tramp-completion-handle-file-name-all-completions
(delq nil all-user-hosts)))))
;; Possible methods.
- (setq result
- (append result (tramp-get-completion-methods m)))))))
+ (unless (and (string-empty-p method)
+ (not tramp-methods-in-completions))
+ (setq result
+ (append result (tramp-get-completion-methods m))))))))
;; Unify list, add hop, remove nil elements.
(dolist (elt result)
Option 2 is a N-lines patch (which doesn't exist yet) to minibuffer.el
(and possibly other files) to add support for the Tramp syntax in
completions mechanisms.
Option 3, 4, 5 and 6 were suggested by Stefan in his last three posts:
change the completion-table API, make Tramp teach the rest of the system
that its methods are a kind of directory, change Tramp's syntax from e.g.
'/ssh:' to '/ssh/', introduce a new set of completion file name functions.
I have no idea how complex any of these solutions are, but it's clear that
none of them can be implemented easily.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Fri, 03 Feb 2023 07:58:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 60505 <at> debbugs.gnu.org (full text, mbox):
> change Tramp's syntax from e.g. '/ssh:' to '/ssh/'
Why the leading slash? URI components from RFC3986:
foo://example.com:8042/over/there?name=ferret#nose
\_/ \______________/\_________/ \_________/ \__/
| | | | |
scheme authority path query fragment
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Fri, 03 Feb 2023 08:40:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
Hi Juri,
>> change Tramp's syntax from e.g. '/ssh:' to '/ssh/'
>
> Why the leading slash? URI components from RFC3986:
>
> foo://example.com:8042/over/there?name=ferret#nose
> \_/ \______________/\_________/ \_________/ \__/
> | | | | |
> scheme authority path query fragment
This is already supported by url-handler-mode. Do
--8<---------------cut here---------------start------------->8---
M-x url-handler-mode
C-x C-f ssh://user <at> remote.host/
--8<---------------cut here---------------end--------------->8---
But this has other disadvantages, and it doesn't help in the host name
completion case.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Fri, 03 Feb 2023 12:02:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 60505 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 60505 <at> debbugs.gnu.org,
> michael.albinus <at> gmx.de, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> julien <at> jroy.ca
> Date: Fri, 03 Feb 2023 09:43:14 +0200
>
> > change Tramp's syntax from e.g. '/ssh:' to '/ssh/'
>
> Why the leading slash? URI components from RFC3986:
>
> foo://example.com:8042/over/there?name=ferret#nose
> \_/ \______________/\_________/ \_________/ \__/
> | | | | |
> scheme authority path query fragment
Tramp file names are not URIs. If you make them URIs, we will have
breakage all over the place where we are now capable of handling
remote file names. That way lies madness.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Fri, 03 Feb 2023 15:42:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 60505 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
Hi Stefan,
>> I could imagine that the completion machinery offers an API that a
>> package could register its own idea of a file name syntax.
>
> The completion code relies on `file-name-directory`,
> `directory-file-name`, etc... for that.
>
> The problem as I see it goes as follows:
>
> According to `file-name-directory`, in `/ssh:myhost` the part
> `ssh:myhost` is an element of the `/` directory. For this reason, the
> completion machinery would expect (file-name-all-completions "s" "/") to
> include "ssh:myhost" in its return list rather than only "ssh:".
>
> Now, it's impractical for Tramp to do that. So the end result is the
> kind of bug reports we're discussing.
>
> One way to fix the problem is for Tramp to "teach" the rest of the
> system that `/ssh:` is a kind of directory, in which case the completion
> machinery would know that (file-name-all-completions "s" "/") returns
> "ssh:" and that "myhost" would be included only in the return value of
> (file-name-all-completions "" "/ssh:").
I've played with this idea, and the appended patch makes it work,
indeed. I had to adapt expand-file-name, file-exists-p,
file-name-directory and file-name-nondirectory, but the changes look
simple. It works for me now for the default completion styles (basic
partial-completion emacs22) as well as for fido-mode, with both the
default and simplified Tramp syntax.
It doesn't work (yet) for the separated Tramp syntax, but this isn't our
major problem, and could be fixed later. Could people check how it plays
in their environment?
> Another is to change Tramp's syntax so that it uses the regular "/"
> separator rather than ":". This would get a similar result but without
> touching `file-name-directory` and friends.
No way. We have had syntax ambiguities for Tramp in the past, and I
don't want to go this painful way, again.
> We could also consider introducing a new set of (file-name) functions
>
> completion-file-name-directory, completion-directory-file-name, ...
>
> so the completion code can use its own notion of how a file name gets
> separated into parts.
That's what I have done in the patch, adding such functions for the
tramp-completion-file-name-handler implementation. An implementation for
directory-file-name wasn't needed, but we could add if necessary.
> But introducing such a subtle distinction would likely introduce a lot
> of bugs&confusion as well.
Perhaps. So this patch isn't a candidate for Emacs 29.1. I would push it
to the master branch (when there is positive feedback), and I would also
add it to the tramp-2-6-stable branch in the Tramp git repo. By this,
the next Tramp 2.6 release on GNU ELPA would contain this change as
well, and we could get broader feedback.
What do people think?
> Stefan
Best regards, Michael.
[Message part 2 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Fri, 03 Feb 2023 18:44:01 GMT)
Full text and
rfc822 format available.
Message #82 received at 60505 <at> debbugs.gnu.org (full text, mbox):
> +(defun tramp-completion-handle-expand-file-name (filename &optional directory)
> + "Like `expand-file-name' for partial Tramp files."
> + (if (file-name-absolute-p filename)
> + filename
> + (concat (or directory default-directory "/") filename)))
Hmm... shouldn't a "/" may need to be added if `directory` or
`default-directory` doesn't end with one (except in cases like `/ssh:`)?
Then again, maybe not. I don't understand enough of the details of when
`tramp-completion-file-name-handler` is used (IOW what is meant exactly by
"partial Tramp file name").
IIUC the `tramp-completion-file-name*` thingies operate only for
"partial Tramp file name" (so the "completion" part of their name is
technically a misnomer, tho they make sense in practice since this part
of the code is only really important during completion), i.e. file names
that should be handled by Tramp but that are incomplete because they end
before getting to specifying the desired directory/file at the remote
end (or even specifying the remote host's name).
I didn't remember this part of the design, but it sounds good and does
make changes to that part (like the proposed patch) "safer", so it's
probably OK to try it on `master`.
I wonder how this patch interacts with `locate-dominating-file`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Fri, 03 Feb 2023 19:24:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
Hi Stefan,
>> +(defun tramp-completion-handle-expand-file-name (filename &optional directory)
>> + "Like `expand-file-name' for partial Tramp files."
>> + (if (file-name-absolute-p filename)
>> + filename
>> + (concat (or directory default-directory "/") filename)))
>
> Hmm... shouldn't a "/" may need to be added if `directory` or
> `default-directory` doesn't end with one (except in cases like `/ssh:`)?
Rather not. We're speaking about the tramp-completion-file-name-handler,
which is activated for file names matching
"\\`\\(?:\\)?/\\(?:\\(?:\\(-\\|[[:alnum:]]\\{2,\\}\\)\\(?::\\)\\(?:\\([^/:|[:blank:]]+\\)\\(?:@\\)\\)?\\(\\(?:[%._[:alnum:]-]+\\|\\(?:\\[\\)\\(?:\\(?:[[:alnum:]]*:\\)+[.[:alnum:]]*\\)?\\(?:]\\)\\)\\(?:\\(?:#\\)\\(?:[[:digit:]]+\\)\\)?\\)?\\)\\(?:|\\)\\)*\\(?:\\(?:-\\|[[:alnum:]]+\\)\\(?:\\(?::\\)\\(?:[%._[:alnum:]-]+\\)?\\)?\\)?\\'".
It looks complex, but in practice it is everything until
"/method:user <at> host" without a trailing colon. No slash there.
It's value is
--8<---------------cut here---------------start------------->8---
(rx
bos
;; `file-name-completion' uses absolute paths for matching.
;; This means that on W32 systems, something like
;; "/ssh:host:~/path" becomes "c:/ssh:host:~/path". See also
;; `tramp-drop-volume-letter'.
(? (regexp tramp-volume-letter-regexp))
;; We cannot use `tramp-prefix-regexp', because it starts with `bol'.
(literal tramp-prefix-format)
;; Optional multi hops.
(* (regexp tramp-remote-file-name-spec-regexp)
(regexp tramp-postfix-hop-regexp))
;; Last hop.
(? (regexp tramp-completion-method-regexp)
;; Method separator, user name and host name.
(? (regexp tramp-postfix-method-regexp)
;; This is a little bit lax, but it serves.
(? (regexp tramp-host-regexp))))
eos)
--8<---------------cut here---------------end--------------->8---
> Then again, maybe not. I don't understand enough of the details of when
> `tramp-completion-file-name-handler` is used (IOW what is meant exactly by
> "partial Tramp file name").
Exactly that.
> I didn't remember this part of the design, but it sounds good and does
> make changes to that part (like the proposed patch) "safer", so it's
> probably OK to try it on `master`.
There is no special design for it. Ordinary file name handler machinery.
> I wonder how this patch interacts with `locate-dominating-file`.
I'll check tomorrow. But since there isn't a slash in such filenames
(except the leading one), I expect it shall work. Needs more testing,
this case and other use cases.
> Stefan
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Fri, 03 Feb 2023 20:52:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 60505 <at> debbugs.gnu.org (full text, mbox):
>> I didn't remember this part of the design, but it sounds good and does
>> make changes to that part (like the proposed patch) "safer", so it's
>> probably OK to try it on `master`.
> There is no special design for it. Ordinary file name handler machinery.
I was referring to the design choice of approximating "completion
context" by "partial Tramp file name".
>> I wonder how this patch interacts with `locate-dominating-file`.
> I'll check tomorrow. But since there isn't a slash in such filenames
> (except the leading one), I expect it shall work. Needs more testing,
> this case and other use cases.
I was thinking of what happens when `locate-dominating-file` does:
try /ssh:host:./foo/bar/.git
try /ssh:host:./foo/.git
try /ssh:host:./.git
? try /ssh:.git ?
try /.git
-- Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Fri, 03 Feb 2023 22:34:01 GMT)
Full text and
rfc822 format available.
Message #91 received at 60505 <at> debbugs.gnu.org (full text, mbox):
>
> I've played with this idea, and the appended patch makes it work,
> indeed. I had to adapt expand-file-name, file-exists-p,
> file-name-directory and file-name-nondirectory, but the changes look
> simple. It works for me now for the default completion styles (basic
> partial-completion emacs22) as well as for fido-mode, with both the
> default and simplified Tramp syntax.
>
Congratulations, that seems to work correctly indeed. It fixes the bug in
Tramp, but not in the way I suggested, so I guess everyone is happy now.
One minor problem:
emacs -Q -l tramp
C-x C-f / TAB
displays "-:" in the completion candidates.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Sat, 04 Feb 2023 09:55:01 GMT)
Full text and
rfc822 format available.
Message #94 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> heytings.org> writes:
> One minor problem:
>
> emacs -Q -l tramp
> C-x C-f / TAB
>
> displays "-:" in the completion candidates.
"-" is a valid method, it means "Use the default method".
See (info "(tramp) Default Method")
While working on the patch I've detected, that it isn't offered in file
name completion. So I've fixed this as well, silently.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Sat, 04 Feb 2023 16:06:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
Hi Stefan,
>>> I didn't remember this part of the design, but it sounds good and does
>>> make changes to that part (like the proposed patch) "safer", so it's
>>> probably OK to try it on `master`.
>> There is no special design for it. Ordinary file name handler machinery.
>
> I was referring to the design choice of approximating "completion
> context" by "partial Tramp file name".
According to the ChangeLog, this was added to Tramp in August 2002. I
don't remember a public discussion about, it was just agreed between Kai
and me.
>>> I wonder how this patch interacts with `locate-dominating-file`.
>> I'll check tomorrow. But since there isn't a slash in such filenames
>> (except the leading one), I expect it shall work. Needs more testing,
>> this case and other use cases.
>
> I was thinking of what happens when `locate-dominating-file` does:
>
> try /ssh:host:./foo/bar/.git
> try /ssh:host:./foo/.git
> try /ssh:host:./.git
> ? try /ssh:.git ?
> try /.git
Don't know. Likely no problem, because
(file-name-directory (directory-file-name "/ssh:host:"))
=> "/ssh:host:"
Perhaps it is a good idea anyway, to add a regexp matching "/ssh:host:"
to locate-dominating-stop-dir-regexp.
> -- Stefan
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Sat, 04 Feb 2023 16:49:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 60505 <at> debbugs.gnu.org (full text, mbox):
>> I was referring to the design choice of approximating "completion
>> context" by "partial Tramp file name".
> According to the ChangeLog, this was added to Tramp in August 2002. I
> don't remember a public discussion about, it was just agreed between Kai
> and me.
In any case, I like it :-)
> Don't know. Likely no problem, because
>
> (file-name-directory (directory-file-name "/ssh:host:"))
> => "/ssh:host:"
Perfect!
> Perhaps it is a good idea anyway, to add a regexp matching "/ssh:host:"
> to locate-dominating-stop-dir-regexp.
I'd rather not if it's not needed.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Mon, 06 Feb 2023 17:27:01 GMT)
Full text and
rfc822 format available.
Message #103 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
Hi,
> I've played with this idea, and the appended patch makes it work,
> indeed. I had to adapt expand-file-name, file-exists-p,
> file-name-directory and file-name-nondirectory, but the changes look
> simple. It works for me now for the default completion styles (basic
> partial-completion emacs22) as well as for fido-mode, with both the
> default and simplified Tramp syntax.
>
> It doesn't work (yet) for the separated Tramp syntax, but this isn't our
> major problem, and could be fixed later. Could people check how it plays
> in their environment?
I've improved the patch, and I've committed it to master. It works now
for all different Tramp syntaxes as well as for all completion styles
except `initials' and `shorthand'. Likely, these two are not so relevant
for file name completion.
There's also a new test, tramp-test26-interactive-file-name-completion.
It doesn't cover yet user name completion and multi-hop file name
completion, these are still open. I'll keep the bugs open until this has
been fixed as well.
> Perhaps. So this patch isn't a candidate for Emacs 29.1. I would push it
> to the master branch (when there is positive feedback), and I would also
> add it to the tramp-2-6-stable branch in the Tramp git repo. By this,
> the next Tramp 2.6 release on GNU ELPA would contain this change as
> well, and we could get broader feedback.
The upcoming Tramp 2.6.0.2, being released on GNU ELPA later this month,
will contain the fixes.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Mon, 06 Feb 2023 17:42:01 GMT)
Full text and
rfc822 format available.
Message #106 received at 60505 <at> debbugs.gnu.org (full text, mbox):
>
> I've improved the patch, and I've committed it to master. It works now
> for all different Tramp syntaxes as well as for all completion styles
> except `initials' and `shorthand'.
>
That's great, thanks for your work Michael!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Tue, 07 Feb 2023 00:36:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> I've improved the patch, and I've committed it to master. It works now
> for all different Tramp syntaxes as well as for all completion styles
> except `initials' and `shorthand'. Likely, these two are not so relevant
> for file name completion.
This breaks Emacs horribly: in emacs -Q (require 'tramp) and M-x dired RET
for example:
Debugger entered--Lisp error: (file-missing "Searching for program" "No such file or directory" "ls")
(call-process "ls" nil nil nil "--dired")
...
(dired-noselect "~/" nil)
All programs seem to be gone, shells etc. I thought my Laptop had died!
Rebasing with your commit omitted fixes the problem.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Tue, 07 Feb 2023 08:55:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 60505 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
Hi Michael,
>> I've improved the patch, and I've committed it to master. It works now
>> for all different Tramp syntaxes as well as for all completion styles
>> except `initials' and `shorthand'. Likely, these two are not so relevant
>> for file name completion.
>
> This breaks Emacs horribly: in emacs -Q (require 'tramp) and M-x dired RET
> for example:
>
> Debugger entered--Lisp error: (file-missing "Searching for program" "No such file or directory" "ls")
> (call-process "ls" nil nil nil "--dired")
> ...
> (dired-noselect "~/" nil)
I'm very sorry about this. Strangely, I cannot reproduce the problem
with your recipe.
> All programs seem to be gone, shells etc. I thought my Laptop had died!
> Rebasing with your commit omitted fixes the problem.
Does the appended patch fixes this for you?
> Michael.
Best regards, Michael.
[Message part 2 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Tue, 07 Feb 2023 18:22:01 GMT)
Full text and
rfc822 format available.
Message #115 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> I'm very sorry about this. Strangely, I cannot reproduce the problem
> with your recipe.
Strange indeed.
> index 69812506e48..b75a1816fdb 100644
> --- a/lisp/net/tramp.el
> +++ b/lisp/net/tramp.el
> @@ -2773,7 +2773,7 @@ tramp-completion-file-name-handler
> "Invoke Tramp file name completion handler for OPERATION and ARGS.
> Falls back to normal file name handler if no Tramp file name handler exists."
> (if-let
> - ((fn (and tramp-mode
> + ((fn (and tramp-mode minibuffer-completing-file-name
> (assoc operation tramp-completion-file-name-handler-alist))))
But this fixes the issue for me.
Thanks,
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Tue, 07 Feb 2023 18:31:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
Hi Michael,
>> index 69812506e48..b75a1816fdb 100644
>> --- a/lisp/net/tramp.el
>> +++ b/lisp/net/tramp.el
>> @@ -2773,7 +2773,7 @@ tramp-completion-file-name-handler
>> "Invoke Tramp file name completion handler for OPERATION and ARGS.
>> Falls back to normal file name handler if no Tramp file name handler exists."
>> (if-let
>> - ((fn (and tramp-mode
>> + ((fn (and tramp-mode minibuffer-completing-file-name
>> (assoc operation tramp-completion-file-name-handler-alist))))
>
> But this fixes the issue for me.
Thanks for the feedback, I've pushed it to the master branch.
> Thanks,
>
> Michael.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Tue, 07 Feb 2023 19:19:01 GMT)
Full text and
rfc822 format available.
Message #121 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> I'm very sorry about this. Strangely, I cannot reproduce the problem
> with your recipe.
If it matters: maybe it depends on PATH? Mine currently looks like
/home/micha/bin:.:/home/micha/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
And I'm using non-standard shells (fish, elvish).
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Tue, 07 Feb 2023 20:40:02 GMT)
Full text and
rfc822 format available.
Message #124 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Thanks for the feedback, I've pushed it to the master branch.
It still happens sometimes:
| Debugger entered--Lisp error: (file-missing "Searching for program" "No such file or directory" "ls")
| (call-process "ls" nil nil nil "--dired")
| (dired-insert-directory "/home/" "-ahl" nil nil t)
| (dired-readin-insert)
| (#f(compiled-function () #<bytecode 0x8e6bc1f0877cf80>))
| (combine-change-calls-1 1 1 #f(compiled-function () #<bytecode 0x8e6bc1f0877cf80>))
| (dired-readin)
| (#f(compiled-function (dir-or-list &optional switches mode) #<bytecode -0x5d986f621ad9bc8>) "/home/" nil)
| (apply #f(compiled-function (dir-or-list &optional switches mode) #<bytecode -0x5d986f621ad9bc8>) ("/home/" nil))
| (dired-internal-noselect "/home/" nil)
| (dired-noselect "/home/" nil)
| (#f(compiled-function (dirname &optional switches) "\"Edit\" directory DIRNAME--delete, rename, print, etc. some files in it.\nOptional second argument SWITCHES specifies the options to be used\nwhen invoking `insert-directory-program', usually `ls', which produces\nthe listing of the directory files and their attributes.\nInteractively, a prefix argument will cause the command to prompt\nfor SWITCHES.\n\nIf DIRNAME is a string, Dired displays a list of files in DIRNAME (which\nmay also have shell wildcards appended to select certain files).\n\nIf DIRNAME is a cons, its first element is taken as the directory name\nand the rest as an explicit list of files to make directory entries for.\nIn this case, SWITCHES are applied to each of the files separately, and\ntherefore switches that control the order of the files in the produced\nlisting have no effect.\n\n\\<dired-mode-map>You can flag files for deletion with \\[dired-flag-file-deletion] and then\ndelete them by typing \\[dired-do-flagged-delete].\nType \\[describe-mode] after entering Dired for more info.\n\nIf DIRNAME is already in a Dired buffer, that buffer is used without refresh." (interactive (dired-read-dir-and-switches "")) #<bytecode -0x14edfe378d0a8e85>) "/home/" nil)
| (ls-lisp--dired #f(compiled-function (dirname &optional switches) "\"Edit\" directory DIRNAME--delete, rename, print, etc. some files in it.\nOptional second argument SWITCHES specifies the options to be used\nwhen invoking `insert-directory-program', usually `ls', which produces\nthe listing of the directory files and their attributes.\nInteractively, a prefix argument will cause the command to prompt\nfor SWITCHES.\n\nIf DIRNAME is a string, Dired displays a list of files in DIRNAME (which\nmay also have shell wildcards appended to select certain files).\n\nIf DIRNAME is a cons, its first element is taken as the directory name\nand the rest as an explicit list of files to make directory entries for.\nIn this case, SWITCHES are applied to each of the files separately, and\ntherefore switches that control the order of the files in the produced\nlisting have no effect.\n\n\\<dired-mode-map>You can flag files for deletion with \\[dired-flag-file-deletion] and then\ndelete them by typing \\[dired-do-flagged-delete].\nType \\[describe-mode] after entering Dired for more info.\n\nIf DIRNAME is already in a Dired buffer, that buffer is used without refresh." (interactive (dired-read-dir-and-switches "")) #<bytecode -0x14edfe378d0a8e85>) "/home/")
| (apply ls-lisp--dired #f(compiled-function (dirname &optional switches) "\"Edit\" directory DIRNAME--delete, rename, print, etc. some files in it.\nOptional second argument SWITCHES specifies the options to be used\nwhen invoking `insert-directory-program', usually `ls', which produces\nthe listing of the directory files and their attributes.\nInteractively, a prefix argument will cause the command to prompt\nfor SWITCHES.\n\nIf DIRNAME is a string, Dired displays a list of files in DIRNAME (which\nmay also have shell wildcards appended to select certain files).\n\nIf DIRNAME is a cons, its first element is taken as the directory name\nand the rest as an explicit list of files to make directory entries for.\nIn this case, SWITCHES are applied to each of the files separately, and\ntherefore switches that control the order of the files in the produced\nlisting have no effect.\n\n\\<dired-mode-map>You can flag files for deletion with \\[dired-flag-file-deletion] and then\ndelete them by typing \\[dired-do-flagged-delete].\nType \\[describe-mode] after entering Dired for more info.\n\nIf DIRNAME is already in a Dired buffer, that buffer is used without refresh." (interactive (dired-read-dir-and-switches "")) #<bytecode -0x14edfe378d0a8e85>) "/home/")
| (dired "/home/")
| (helm-point-file-in-dired "/home/micha/.")
| (funcall helm-point-file-in-dired "/home/micha/.")
| ((closure ((action . helm-point-file-in-dired)) (arg) (setq command-history (cons (list 'funcall (list 'function action) (list 'quote arg)) command-history)) (funcall action arg)) "/home/micha/.")
| (helm-execute-selection-action-1)
| (helm-execute-selection-action)
| (helm-internal helm-source-find-files "/home/micha/" "Find files or url: " nil nil "*helm find files*" nil nil nil)
| (apply helm-internal (helm-source-find-files "/home/micha/" "Find files or url: " nil nil "*helm find files*" nil nil nil))
| (helm helm-source-find-files "/home/micha/" "Find files or url: " nil nil "*helm find files*" nil nil nil)
| (apply helm (helm-source-find-files "/home/micha/" "Find files or url: " nil nil "*helm find files*" nil nil nil))
| (helm :sources helm-source-find-files :input "/home/micha/" :case-fold-search smart :preselect nil :ff-transformer-show-only-basename nil :default nil :prompt "Find files or url: " :buffer "*helm find files*")
| (helm-find-files-1 "/home/micha/" nil)
| (helm-find-files nil)
| (funcall-interactively helm-find-files nil)
| (call-interactively helm-find-files nil nil)
| (command-execute helm-find-files)
Can I help with this in any way? You can also give me a private phone
call if that would the fastest way of investigation.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Tue, 07 Feb 2023 22:24:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 60505 <at> debbugs.gnu.org (full text, mbox):
>>> @@ -2773,7 +2773,7 @@ tramp-completion-file-name-handler
>>> "Invoke Tramp file name completion handler for OPERATION and ARGS.
>>> Falls back to normal file name handler if no Tramp file name handler exists."
>>> (if-let
>>> - ((fn (and tramp-mode
>>> + ((fn (and tramp-mode minibuffer-completing-file-name
>>> (assoc operation tramp-completion-file-name-handler-alist))))
Looks like a "quick&dirty workaround" rather than fix.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 08 Feb 2023 08:06:01 GMT)
Full text and
rfc822 format available.
Message #130 received at 60505 <at> debbugs.gnu.org (full text, mbox):
dick <dick.r.chiang <at> gmail.com> writes:
> It's ironic that the guy who could most benefit from checking EMBA
> before committing a change is also the guy in charge of EMBA.
You cannot "check EMBA before committing a change". EMBA fetches changes
from Emacs' remote git repository.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 08 Feb 2023 13:05:02 GMT)
Full text and
rfc822 format available.
Message #133 received at 60505 <at> debbugs.gnu.org (full text, mbox):
EMBA, being a Gitlab product, was designed to accommodate branches, the
idea being you vet your changes on a feature branch before merging to
master. Something for management to think about since no one, including
the guy in charge of EMBA, seems to do this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 08 Feb 2023 13:09:01 GMT)
Full text and
rfc822 format available.
Message #136 received at 60505 <at> debbugs.gnu.org (full text, mbox):
dick <dick.r.chiang <at> gmail.com> writes:
Hi,
> EMBA, being a Gitlab product, was designed to accommodate branches, the
> idea being you vet your changes on a feature branch before merging to
> master. Something for management to think about since no one, including
> the guy in charge of EMBA, seems to do this.
Here you have a point. I didn't expect so much trouble in this case, and
so I haven't used a branch. Which would have other disadvantages, for
example less people to test.
And a branch to be (pre-)tested on EMBA wouldn't help here. I have added
ERT tests for the new behavior, and they run on EMBA successfully. The
problem is the *interactive* reading of file names - something which
cannot be tested on EMBA.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 08 Feb 2023 13:21:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 60505 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: 60505 <at> debbugs.gnu.org, Michael Heerdegen <michael_heerdegen <at> web.de>,
> Gregory Heytings <gregory <at> heytings.org>, Stefan Monnier
> <monnier <at> iro.umontreal.ca>, julien <at> jroy.ca, Eli Zaretskii <eliz <at> gnu.org>
> Date: Wed, 08 Feb 2023 14:08:04 +0100
>
> dick <dick.r.chiang <at> gmail.com> writes:
>
> Hi,
>
> > EMBA, being a Gitlab product, was designed to accommodate branches, the
> > idea being you vet your changes on a feature branch before merging to
> > master. Something for management to think about since no one, including
> > the guy in charge of EMBA, seems to do this.
>
> Here you have a point. I didn't expect so much trouble in this case, and
> so I haven't used a branch. Which would have other disadvantages, for
> example less people to test.
>
> And a branch to be (pre-)tested on EMBA wouldn't help here. I have added
> ERT tests for the new behavior, and they run on EMBA successfully. The
> problem is the *interactive* reading of file names - something which
> cannot be tested on EMBA.
Michael, please don't sweat over this. Using temporary branches for
CI-style testing before committing to mainline requires a very
different style and procedures of development than what we have. We
don't have the resources to use those development procedures on a
routine basis, and the group of people who can be vaguely described as
"the development team" -- those who contribute changes frequently
enough to benefit from test-before-commit workflow -- is too diverse
and too decentralized to expect them to abide by the discipline
required for implementing CI-driven workflows. dick.r.chiang goes the
easy way of commenting from the peanut gallery (in his usual arrogant
and condescending style) instead of doing what is expected from a
well-meaning community member: volunteer to do this job himself and
find enough volunteers for us to be able to go anywhere near using CI
routinely.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 08 Feb 2023 14:29:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 60505 <at> debbugs.gnu.org (full text, mbox):
> And a branch to be (pre-)tested on EMBA wouldn't help here.
That's because you've largely missed the point of the Gitlab product.
Register everyone with commit rights to EMBA. And then hope they're
conscientious enough to kick off a test run before making a nontrivial
change. This last step would be less of an issue if management ceased
clinging to a neolithic changeset procedure that keeps the dev base
artificially small and old.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 08 Feb 2023 14:29:03 GMT)
Full text and
rfc822 format available.
Message #145 received at 60505 <at> debbugs.gnu.org (full text, mbox):
EZ> dick.r.chiang goes the easy way of commenting from the peanut gallery
This was my dialogue with the EMBA guy in November 2021.
Guy: Your patch to gitlab-ci.yml doesn't help here. [Ed. he says "your
blank doesn't help here" a lot]
Me: If you lack the time to make EMBA relevant, let me do it. I can do it.
Guy: Thanks for the offer, patches welcome! If you like, I could add also an
account for you on emba.gnu.org.
Me: By "account for you on emba.gnu.org," I assume you mean an ssh login
with write privileges to the gitlab installation. If so, I accept.
Guy: No, I'm speaking about an account of that gitlab instance. OK?
Me: Then never mind, good sir. Among other issues, I wanted https://emba.gnu.org
to respond within the realm of useabilty (sooner than the current ~10s). I'm
going to need ssh for that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 08 Feb 2023 14:43:01 GMT)
Full text and
rfc822 format available.
Message #148 received at 60505 <at> debbugs.gnu.org (full text, mbox):
dick <dick.r.chiang <at> gmail.com> writes:
Hi,
> EZ> dick.r.chiang goes the easy way of commenting from the peanut gallery
>
> This was my dialogue with the EMBA guy in November 2021.
>
> Guy: Your patch to gitlab-ci.yml doesn't help here. [Ed. he says "your
> blank doesn't help here" a lot]
>
> Me: If you lack the time to make EMBA relevant, let me do it. I can do it.
>
> Guy: Thanks for the offer, patches welcome! If you like, I could add also an
> account for you on emba.gnu.org.
>
> Me: By "account for you on emba.gnu.org," I assume you mean an ssh login
> with write privileges to the gitlab installation. If so, I accept.
>
> Guy: No, I'm speaking about an account of that gitlab instance. OK?
>
> Me: Then never mind, good sir. Among other issues, I wanted https://emba.gnu.org
> to respond within the realm of useabilty (sooner than the current ~10s). I'm
> going to need ssh for that.
This discussion is from bug#51399. You have forgotten to quote the rest
of this discussion. (And no, I don't want to discuss this, again.)
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 08 Feb 2023 15:06:02 GMT)
Full text and
rfc822 format available.
Message #151 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
Hi Michael,
> It still happens sometimes:
>
> | Debugger entered--Lisp error: (file-missing "Searching for program" "No such file or directory" "ls")
> | (call-process "ls" nil nil nil "--dired")
> | (dired-insert-directory "/home/" "-ahl" nil nil t)
> | (dired-readin-insert)
> | (#f(compiled-function () #<bytecode 0x8e6bc1f0877cf80>))
> | (combine-change-calls-1 1 1 #f(compiled-function () #<bytecode 0x8e6bc1f0877cf80>))
> | (dired-readin)
> | (#f(compiled-function (dir-or-list &optional switches mode) #<bytecode -0x5d986f621ad9bc8>) "/home/" nil)
> | (apply #f(compiled-function (dir-or-list &optional switches mode) #<bytecode -0x5d986f621ad9bc8>) ("/home/" nil))
> | (dired-internal-noselect "/home/" nil)
> | (dired-noselect "/home/" nil)
> | (#f(compiled-function (dirname &optional switches) "\"Edit\"
> | directory DIRNAME--delete, rename, print, etc. some files in
> | it.\nOptional second argument SWITCHES specifies the options to be
> | used\nwhen invoking `insert-directory-program', usually `ls', which
> | produces\nthe listing of the directory files and their
> | attributes.\nInteractively, a prefix argument will cause the command
> | to prompt\nfor SWITCHES.\n\nIf DIRNAME is a string, Dired displays a
> | list of files in DIRNAME (which\nmay also have shell wildcards
> | appended to select certain files).\n\nIf DIRNAME is a cons, its
> | first element is taken as the directory name\nand the rest as an
> | explicit list of files to make directory entries for.\nIn this case,
> | SWITCHES are applied to each of the files separately, and\ntherefore
> | switches that control the order of the files in the
> | produced\nlisting have no effect.\n\n\\<dired-mode-map>You can flag
> | files for deletion with \\[dired-flag-file-deletion] and
> | then\ndelete them by typing \\[dired-do-flagged-delete].\nType
> | \\[describe-mode] after entering Dired for more info.\n\nIf DIRNAME
> | is already in a Dired buffer, that buffer is used without refresh."
> | (interactive (dired-read-dir-and-switches "")) #<bytecode
> | -0x14edfe378d0a8e85>) "/home/" nil)
> | (ls-lisp--dired #f(compiled-function (dirname &optional switches)
> | "\"Edit\" directory DIRNAME--delete, rename, print, etc. some files
> | in it.\nOptional second argument SWITCHES specifies the options to
> | be used\nwhen invoking `insert-directory-program', usually `ls',
> | which produces\nthe listing of the directory files and their
> | attributes.\nInteractively, a prefix argument will cause the command
> | to prompt\nfor SWITCHES.\n\nIf DIRNAME is a string, Dired displays a
> | list of files in DIRNAME (which\nmay also have shell wildcards
> | appended to select certain files).\n\nIf DIRNAME is a cons, its
> | first element is taken as the directory name\nand the rest as an
> | explicit list of files to make directory entries for.\nIn this case,
> | SWITCHES are applied to each of the files separately, and\ntherefore
> | switches that control the order of the files in the
> | produced\nlisting have no effect.\n\n\\<dired-mode-map>You can flag
> | files for deletion with \\[dired-flag-file-deletion] and
> | then\ndelete them by typing \\[dired-do-flagged-delete].\nType
> | \\[describe-mode] after entering Dired for more info.\n\nIf DIRNAME
> | is already in a Dired buffer, that buffer is used without refresh."
> | (interactive (dired-read-dir-and-switches "")) #<bytecode
> | -0x14edfe378d0a8e85>) "/home/")
> | (apply ls-lisp--dired #f(compiled-function (dirname &optional
> | switches) "\"Edit\" directory DIRNAME--delete, rename, print,
> | etc. some files in it.\nOptional second argument SWITCHES specifies
> | the options to be used\nwhen invoking `insert-directory-program',
> | usually `ls', which produces\nthe listing of the directory files and
> | their attributes.\nInteractively, a prefix argument will cause the
> | command to prompt\nfor SWITCHES.\n\nIf DIRNAME is a string, Dired
> | displays a list of files in DIRNAME (which\nmay also have shell
> | wildcards appended to select certain files).\n\nIf DIRNAME is a
> | cons, its first element is taken as the directory name\nand the rest
> | as an explicit list of files to make directory entries for.\nIn this
> | case, SWITCHES are applied to each of the files separately,
> | and\ntherefore switches that control the order of the files in the
> | produced\nlisting have no effect.\n\n\\<dired-mode-map>You can flag
> | files for deletion with \\[dired-flag-file-deletion] and
> | then\ndelete them by typing \\[dired-do-flagged-delete].\nType
> | \\[describe-mode] after entering Dired for more info.\n\nIf DIRNAME
> | is already in a Dired buffer, that buffer is used without refresh."
> | (interactive (dired-read-dir-and-switches "")) #<bytecode
> | -0x14edfe378d0a8e85>) "/home/")
> | (dired "/home/")
> | (helm-point-file-in-dired "/home/micha/.")
> | (funcall helm-point-file-in-dired "/home/micha/.")
> | ((closure ((action . helm-point-file-in-dired)) (arg) (setq command-history (cons (list 'funcall (list 'function action) (list 'quote arg)) command-history)) (funcall action arg)) "/home/micha/.")
> | (helm-execute-selection-action-1)
> | (helm-execute-selection-action)
> | (helm-internal helm-source-find-files "/home/micha/" "Find files or url: " nil nil "*helm find files*" nil nil nil)
> | (apply helm-internal (helm-source-find-files "/home/micha/" "Find files or url: " nil nil "*helm find files*" nil nil nil))
> | (helm helm-source-find-files "/home/micha/" "Find files or url: " nil nil "*helm find files*" nil nil nil)
> | (apply helm (helm-source-find-files "/home/micha/" "Find files or url: " nil nil "*helm find files*" nil nil nil))
> | (helm :sources helm-source-find-files :input "/home/micha/" :case-fold-search smart :preselect nil :ff-transformer-show-only-basename nil :default nil :prompt "Find files or url: " :buffer "*helm find files*")
> | (helm-find-files-1 "/home/micha/" nil)
> | (helm-find-files nil)
> | (funcall-interactively helm-find-files nil)
> | (call-interactively helm-find-files nil nil)
> | (command-execute helm-find-files)
>
> Can I help with this in any way? You can also give me a private phone
> call if that would the fastest way of investigation.
I'm still unable to reproduce. I've installed the needed packages from
GNU ELPA (I believe), and then I've applied
# src/emacs -Q -l tramp \
-l ~/.emacs.d/elpa/helm-20230129.1448/helm-autoloads.el \
-l ~/.emacs.d/elpa/helm-core-20230117.1925/helm-core-autoloads.el \
-l ~/.emacs.d/elpa/async-20221228.1315/async-autoloads.el
M-x helm-find-files
=> custom-initialize-reset: In ‘Find Files’ source: ‘helm-find-files-get-candidates’
(user-error "Error: file-notify-error (\"File watching is not available\" \"Too many open files\")")
M-x helm-find-files
/home/albinus/ RET
=> Proper dired listing.
Grrrr. Do you like to run a jitsi session together with me, for debugging?
> Michael.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 08 Feb 2023 15:10:02 GMT)
Full text and
rfc822 format available.
Message #154 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
Hi Michael,
>> I'm very sorry about this. Strangely, I cannot reproduce the problem
>> with your recipe.
>
> If it matters: maybe it depends on PATH? Mine currently looks like
>
> /home/micha/bin:.:/home/micha/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
>
> And I'm using non-standard shells (fish, elvish).
Anything goes, but it doesn't look like it is related. We're speaking
about Tramp file name completion (method or host part), so only
directory names like "/xxx", w/o a slash except the very first one, would matter.
Which directory is meant by "."? Being curious, would it help to remove
it from your PATH temporarily?
> Michael.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 08 Feb 2023 15:12:02 GMT)
Full text and
rfc822 format available.
Message #157 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
Hi Stefan,
>>>> @@ -2773,7 +2773,7 @@ tramp-completion-file-name-handler
>>>> "Invoke Tramp file name completion handler for OPERATION and ARGS.
>>>> Falls back to normal file name handler if no Tramp file name handler exists."
>>>> (if-let
>>>> - ((fn (and tramp-mode
>>>> + ((fn (and tramp-mode minibuffer-completing-file-name
>>>> (assoc operation tramp-completion-file-name-handler-alist))))
>
> Looks like a "quick&dirty workaround" rather than fix.
Perhaps. But how could I tell Emacs, that this file name handler is
meant for (interactive) file name completion only?
> Stefan
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 08 Feb 2023 16:19:02 GMT)
Full text and
rfc822 format available.
Message #160 received at 60505 <at> debbugs.gnu.org (full text, mbox):
>>>>> @@ -2773,7 +2773,7 @@ tramp-completion-file-name-handler
>>>>> "Invoke Tramp file name completion handler for OPERATION and ARGS.
>>>>> Falls back to normal file name handler if no Tramp file name handler exists."
>>>>> (if-let
>>>>> - ((fn (and tramp-mode
>>>>> + ((fn (and tramp-mode minibuffer-completing-file-name
>>>>> (assoc operation tramp-completion-file-name-handler-alist))))
>>
>> Looks like a "quick&dirty workaround" rather than fix.
>
> Perhaps. But how could I tell Emacs, that this file name handler is
> meant for (interactive) file name completion only?
You can't. Instead it should work regardless.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 08 Feb 2023 18:00:02 GMT)
Full text and
rfc822 format available.
Message #163 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
Hi Stefan,
>>>>>> @@ -2773,7 +2773,7 @@ tramp-completion-file-name-handler
>>>>>> "Invoke Tramp file name completion handler for OPERATION and ARGS.
>>>>>> Falls back to normal file name handler if no Tramp file name handler exists."
>>>>>> (if-let
>>>>>> - ((fn (and tramp-mode
>>>>>> + ((fn (and tramp-mode minibuffer-completing-file-name
>>>>>> (assoc operation tramp-completion-file-name-handler-alist))))
>>>
>>> Looks like a "quick&dirty workaround" rather than fix.
>>
>> Perhaps. But how could I tell Emacs, that this file name handler is
>> meant for (interactive) file name completion only?
>
> You can't. Instead it should work regardless.
Then we're back at the beginning. The heart of my patch is
(file-name-directory "/ssh:host") => "/ssh:"
And this shall happen only in read-file-name.
> Stefan
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Wed, 08 Feb 2023 19:05:01 GMT)
Full text and
rfc822 format available.
Message #166 received at 60505 <at> debbugs.gnu.org (full text, mbox):
>> You can't. Instead it should work regardless.
>
> Then we're back at the beginning. The heart of my patch is
>
> (file-name-directory "/ssh:host") => "/ssh:"
What's the problem with that?
> And this shall happen only in read-file-name.
Why?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Thu, 09 Feb 2023 00:39:02 GMT)
Full text and
rfc822 format available.
Message #169 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Which directory is meant by "."? Being curious, would it help to remove
> it from your PATH temporarily?
Seems this is not the case.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#60505; Package
emacs.
(Fri, 10 Feb 2023 16:57:01 GMT)
Full text and
rfc822 format available.
Message #172 received at 60505 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
Hi Stefan,
>>> You can't. Instead it should work regardless.
>>
>> Then we're back at the beginning. The heart of my patch is
>>
>> (file-name-directory "/ssh:host") => "/ssh:"
>
> What's the problem with that?
>
>> And this shall happen only in read-file-name.
>
> Why?
Indeed, my patch got trouble when Tramp file name completion was in the
way even if it wasn't asked for. Thanks to Michael, I could debug it in
his environment. Fix pushed to master.
There are still some cases it doesn't work as expected (user name
completion to be mentioned); I'll continue to work on this.
> Stefan
Best regards, Michael.
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>:
You have taken responsibility.
(Sun, 12 Feb 2023 19:28:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Julien Roy <julien <at> jroy.ca>:
bug acknowledged by developer.
(Sun, 12 Feb 2023 19:28:02 GMT)
Full text and
rfc822 format available.
Message #177 received at 60505-done <at> debbugs.gnu.org (full text, mbox):
Version: 29.2
Michael Albinus <michael.albinus <at> gmx.de> writes:
> There are still some cases it doesn't work as expected (user name
> completion to be mentioned); I'll continue to work on this.
This works now fine, and also multi-hop completion passes the tests. I'm
closing this bug (and the merged ones).
Best regards, Michael.
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>:
You have taken responsibility.
(Sun, 12 Feb 2023 19:28:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Manuel Uberti <manuel.uberti <at> inventati.org>:
bug acknowledged by developer.
(Sun, 12 Feb 2023 19:28:03 GMT)
Full text and
rfc822 format available.
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>:
You have taken responsibility.
(Sun, 12 Feb 2023 19:28:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Bird <birdsite <at> airmail.cc>:
bug acknowledged by developer.
(Sun, 12 Feb 2023 19:28:03 GMT)
Full text and
rfc822 format available.
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>:
You have taken responsibility.
(Sun, 12 Feb 2023 19:28:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
schlurfi <at> mailbox.org:
bug acknowledged by developer.
(Sun, 12 Feb 2023 19:28:03 GMT)
Full text and
rfc822 format available.
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>:
You have taken responsibility.
(Sun, 12 Feb 2023 19:28:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ergus <spacibba <at> aol.com>:
bug acknowledged by developer.
(Sun, 12 Feb 2023 19:28:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 19 Mar 2023 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 31 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.