GNU bug report logs - #70198
M-x shell: deal with environment variables present when tab expanding

Previous Next

To reply to this bug, email your comments to 70198 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dan Jacobson <jidanni <at> jidanni.org>
To: bug-gnu-emacs <at> gnu.org
Subject: M-x shell: deal with environment variables present when tab expanding
Date: Thu, 4 Apr 2024 21:51:01 +0800

In M-x shell
$ dat<TAB>
expands to date.
Alas, unlike bash readline,
$ LC_ALL=C dat<TAB>
doesn't yet.

emacs-version "29.3"

Message #8 received at 70198 <at> debbugs.gnu.org (full text, mbox):

From: Federico Tedin <federicotedin <at> gmx.de>
To: Dan Jacobson <jidanni <at> jidanni.org>
Cc: 70198 <at> debbugs.gnu.org
Subject: Re: bug#70198: M-x shell: deal with environment variables present
 when tab expanding
Date: Wed, 10 Jul 2024 18:22:35 +0200

[Message part 1 (text/plain, inline)]

Dan Jacobson <jidanni <at> jidanni.org> writes:

> In M-x shell
> $ dat<TAB>
> expands to date.
> Alas, unlike bash readline,
> $ LC_ALL=C dat<TAB>
> doesn't yet.
>
> emacs-version "29.3"

I took a crack at fixing this, I'm attaching a patch.

It's been some time since my last contribution, but I've kept the
copyright assignment updated (should be under federicotedin <at> gmail.com).
There's a chance the formatting for the patch may be a bit off too but I
tried to re-read the guide at CONTRIBUTE.

I've also found something interesting with the
`shell-dynamic-complete-command' function. I do not see it being called,
referred to, or assigned to a key anywhere in the Emacs code, but the
manual mentions it as if it being were actively used:

> Some implementation details of the shell command completion may also be found
> in the lisp documentation of the @code{shell-dynamic-complete-command}
> function.

Maybe the manual is outdated?

- Fede

[0001-Fix-tab-expanding-not-working-in-shell-mode-bug-7019.patch (text/x-diff, attachment)]

Message #11 received at 70198 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Federico Tedin <federicotedin <at> gmx.de>
Cc: 70198 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#70198: M-x shell: deal with environment variables present when
 tab expanding
Date: Wed, 10 Jul 2024 20:45:11 +0300

> Cc: 70198 <at> debbugs.gnu.org
> Date: Wed, 10 Jul 2024 18:22:35 +0200
> From:  Federico Tedin via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> +	         (save-match-data (not (string-match "[~/]" filename)))
> +	         (eq (match-beginning 0)
> +		         (save-excursion
> +                   ;; Go back to beginning of command
> +                   (shell-backward-command 1)
> +                   ;; Skip any potential environment variables
> +                   (shell--skip-environment-variables pt)
> +                   (point))))
> +	    (shell--command-completion-data))))
> +
> +(defun shell--skip-environment-variables (pt)
> +  "Move forward up to PT through any present environment variables."
> +  (while (re-search-forward "=" pt t)
> +    (skip-syntax-forward "^ " pt)
> +    (skip-syntax-forward " " pt)))

What happens if the command itself has embedded '='?
What happens if the '=' character is quoted?

I think a better idea might be first to try to find what is "the word
at point", and then complete only that word.  WDYT?

Message #14 received at 70198 <at> debbugs.gnu.org (full text, mbox):

From: Federico Tedin <federicotedin <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70198 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#70198: M-x shell: deal with environment variables present
 when tab expanding
Date: Wed, 10 Jul 2024 20:11:07 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> What happens if the command itself has embedded '='?

Ah good point, I incorrectly assumed that after
`comint-match-partial-filename' was called, the point would be at the
beginning of the command rather than at the end. That being said if we
used (match-beginning 0) as PT then it would address this particular
scenario (when calling `shell--skip-environment-variables' I mean).

> What happens if the '=' character is quoted?

What would be an example of this? (in the context of writing shell
commands).

> I think a better idea might be first to try to find what is "the word
> at point", and then complete only that word.  WDYT?

Yep, however I do think we still need to walk back some words in order
to ensure that we are not autocompleting an argument; for example

$ echo whoam[TAB]

should not autocomplete to "whoami", I'm assuming.

So for the actual walking backwards we need to maybe:
- modify shell-backward-command so that it leaves the point at the
beginning of the command, but after any env vars
- or, move backwards using `shell-command-regexp' until the last thing
that does not look like FOO=BAR or FOO= is found.

All of this just to ensure that the word at point is an actual command
and not an argument to a command. Maybe this approach itself could be
re-evaluated though !

Message #17 received at 70198 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Federico Tedin <federicotedin <at> gmx.de>
Cc: 70198 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#70198: M-x shell: deal with environment variables present
 when tab expanding
Date: Wed, 10 Jul 2024 21:34:51 +0300

> From: Federico Tedin <federicotedin <at> gmx.de>
> Cc: jidanni <at> jidanni.org,  70198 <at> debbugs.gnu.org
> Date: Wed, 10 Jul 2024 20:11:07 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > What happens if the '=' character is quoted?
> 
> What would be an example of this? (in the context of writing shell
> commands).

Something like

  $ FOO='foo=bar' date

> > I think a better idea might be first to try to find what is "the word
> > at point", and then complete only that word.  WDYT?
> 
> Yep, however I do think we still need to walk back some words in order
> to ensure that we are not autocompleting an argument; for example
> 
> $ echo whoam[TAB]
> 
> should not autocomplete to "whoami", I'm assuming.

It should, just not command completion.

> So for the actual walking backwards we need to maybe:
> - modify shell-backward-command so that it leaves the point at the
> beginning of the command, but after any env vars
> - or, move backwards using `shell-command-regexp' until the last thing
> that does not look like FOO=BAR or FOO= is found.
> 
> All of this just to ensure that the word at point is an actual command
> and not an argument to a command. Maybe this approach itself could be
> re-evaluated though !

If we want to detect FOO=BAR, we need to use syntax classes, and I'm
not sure regexps are the best instrument for that.

Message #20 received at 70198 <at> debbugs.gnu.org (full text, mbox):

From: Federico Tedin <federicotedin <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70198 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#70198: M-x shell: deal with environment variables present
 when tab expanding
Date: Wed, 10 Jul 2024 22:17:41 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Something like
>
>   $ FOO='foo=bar' date
>

Ah right, that makes sense.

> It should, just not command completion.

> If we want to detect FOO=BAR, we need to use syntax classes, and I'm
> not sure regexps are the best instrument for that.

But then, just to make sure I'm on the right track:

- When the word at point is a command (not an arg)
`shell-command-completion' should return the proper command completions.

- When the word at point is *not* a command, `shell-command-completion' should
return nil so that other completion functions are attempted.

And these two scenarios need to be decided on using syntax classes
instead of regexps.

Message #23 received at 70198 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Federico Tedin <federicotedin <at> gmx.de>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 70198 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#70198: M-x shell: deal with environment variables present
 when tab expanding
Date: Thu, 11 Jul 2024 07:36:53 +0300

> From: Federico Tedin <federicotedin <at> gmx.de>
> Cc: 70198 <at> debbugs.gnu.org,  jidanni <at> jidanni.org
> Date: Wed, 10 Jul 2024 22:17:41 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > If we want to detect FOO=BAR, we need to use syntax classes, and I'm
> > not sure regexps are the best instrument for that.
> 
> But then, just to make sure I'm on the right track:
> 
> - When the word at point is a command (not an arg)
> `shell-command-completion' should return the proper command completions.
> 
> - When the word at point is *not* a command, `shell-command-completion' should
> return nil so that other completion functions are attempted.
> 
> And these two scenarios need to be decided on using syntax classes
> instead of regexps.

Yes, I think so.  I added Stefan to the discussion in case he has
comments or suggestions.  Stefan, what do you think is the best method
of parsing the beginning of the command line to detect where a
program's name starts?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.