* bug#15461: 24.3; exec-path on ms windows should contain current directory
@ 2013-09-25 13:24 Jarek Czekalski
2013-09-25 15:48 ` Eli Zaretskii
` (5 more replies)
0 siblings, 6 replies; 17+ messages in thread
From: Jarek Czekalski @ 2013-09-25 13:24 UTC (permalink / raw)
To: 15461
To be consistent with the native shell on Microsoft Windows,
the exec-path should include current directory.
I can do that in my init.el, but I think this should be a standard.
Steps to reproduce:
1. On Windows edit file test.bat, save it
2. M-x shell-command
3. test.ba <TAB>
Expected behaviour:
4. autocomplete to test.bat
Current behaviour:
4. [No match]
If the idea gets accepted then I have a following question:
Should I prepare a patch for that or you prefer to fix it by yourselves?
Best regards
Jarek
In GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
of 2013-03-17 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --with-gcc (4.7) --cflags
-ID:/devel/emacs/libs/libXpm-3.5.8/include
-ID:/devel/emacs/libs/libXpm-3.5.8/src
-ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
-ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
-ID:/devel/emacs/libs/giflib-4.1.4-1/include
-ID:/devel/emacs/libs/jpeg-6b-4/include
-ID:/devel/emacs/libs/tiff-3.8.2-1/include
-ID:/devel/emacs/libs/gnutls-3.0.9/include
-ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
-ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'
Important settings:
value of $LANG: pl
locale-coding-system: cp1250
default enable-multibyte-characters: t
Major mode: Ibuffer
Minor modes in effect:
diff-auto-refine-mode: t
shell-dirtrack-mode: t
global-whitespace-mode: t
global-hl-line-mode: t
recentf-mode: t
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
Recent input:
z y c j e ( i ) . s w w SPC ! = SPC " B R A K " <right>
<right> <right> <right> <right> <delete> <return> SPC
SPC <end> <return> e n d i f C-x C-s <up> <up> <up>
M-! s v n SPC d i f f <return> <f6> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <next> <prior> <prior> <prior> <prior>
<prior> <prior> <prior> <prior> <prior> <prior> <prior>
<prior> <prior> <prior> <prior> <prior> <prior> <prior>
<prior> <prior> <prior> <prior> <prior> <prior> <prior>
<prior> <prior> <prior> <prior> <prior> <prior> <prior>
<prior> <prior> <prior> <prior> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <C-home> C-SPC <C-end> M-w <C-home> C-SPC
<C-end> <delete> C-y C-x C-s <C-home> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> _ o o <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> SPC O o C-x C-s M-! <up> <return> <f6> <next>
<next> <C-end> <C-f4> M-! <up> <up> <up> <return> M-!
s v n SPC d i f f <return> <f6> <next> <next> <next>
<prior> <prior> <prior> M-! <up> <up> <return> <C-f4>
<down> <down> <down> <down> <down> <end> <left> <left>
<left> <left> <backspace> 4 C-x C-s C-x C-b <up> m
m m m m m m m m m m m m m m m D y M-x r e p o r <tab>
<return>
Recent messages:
Operation finished; killed 16 buffers
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils debug cus-edit
nxml-uchnm rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc
rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok info
cl-macs gv cl cl-lib thingatpt find-func two-column iso-transl mule-diag
help-fns etags vc-dispatcher vc-svn apropos vc-git bookmark pp ffap
url-parse auth-source eieio byte-opt bytecomp byte-compile cconv
gnus-util mm-util mail-prsvr password-cache url-vars ediff-merg
ediff-diff ediff-wind ediff-help ediff-util ediff-mult ediff-init ediff
diff-mode easy-mmode dired-aux shell pcomplete grep compile comint
ansi-color ring dired help-mode tmm electric ibuf-ext ibuffer misearch
multi-isearch whitespace hl-line cus-start cus-load edmacro kmacro
recentf tree-widget wid-edit easymenu server time-date tooltip
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process w32 multi-tty emacs)
In GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
of 2013-03-17 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --with-gcc (4.7) --cflags
-ID:/devel/emacs/libs/libXpm-3.5.8/include
-ID:/devel/emacs/libs/libXpm-3.5.8/src
-ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
-ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
-ID:/devel/emacs/libs/giflib-4.1.4-1/include
-ID:/devel/emacs/libs/jpeg-6b-4/include
-ID:/devel/emacs/libs/tiff-3.8.2-1/include
-ID:/devel/emacs/libs/gnutls-3.0.9/include
-ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
-ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'
Important settings:
value of $LANG: pl
locale-coding-system: cp1250
default enable-multibyte-characters: t
Major mode: Ibuffer
Minor modes in effect:
diff-auto-refine-mode: t
shell-dirtrack-mode: t
global-whitespace-mode: t
global-hl-line-mode: t
recentf-mode: t
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
Recent input:
z y c j e ( i ) . s w w SPC ! = SPC " B R A K " <right>
<right> <right> <right> <right> <delete> <return> SPC
SPC <end> <return> e n d i f C-x C-s <up> <up> <up>
M-! s v n SPC d i f f <return> <f6> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <next> <prior> <prior> <prior> <prior>
<prior> <prior> <prior> <prior> <prior> <prior> <prior>
<prior> <prior> <prior> <prior> <prior> <prior> <prior>
<prior> <prior> <prior> <prior> <prior> <prior> <prior>
<prior> <prior> <prior> <prior> <prior> <prior> <prior>
<prior> <prior> <prior> <prior> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <next> <next> <next> <next> <next> <next>
<next> <next> <C-home> C-SPC <C-end> M-w <C-home> C-SPC
<C-end> <delete> C-y C-x C-s <C-home> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> _ o o <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> SPC O o C-x C-s M-! <up> <return> <f6> <next>
<next> <C-end> <C-f4> M-! <up> <up> <up> <return> M-!
s v n SPC d i f f <return> <f6> <next> <next> <next>
<prior> <prior> <prior> M-! <up> <up> <return> <C-f4>
<down> <down> <down> <down> <down> <end> <left> <left>
<left> <left> <backspace> 4 C-x C-s C-x C-b <up> m
m m m m m m m m m m m m m m m D y M-x r e p o r <tab>
<return>
Recent messages:
Operation finished; killed 16 buffers
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils debug cus-edit
nxml-uchnm rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc
rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok info
cl-macs gv cl cl-lib thingatpt find-func two-column iso-transl mule-diag
help-fns etags vc-dispatcher vc-svn apropos vc-git bookmark pp ffap
url-parse auth-source eieio byte-opt bytecomp byte-compile cconv
gnus-util mm-util mail-prsvr password-cache url-vars ediff-merg
ediff-diff ediff-wind ediff-help ediff-util ediff-mult ediff-init ediff
diff-mode easy-mmode dired-aux shell pcomplete grep compile comint
ansi-color ring dired help-mode tmm electric ibuf-ext ibuffer misearch
multi-isearch whitespace hl-line cus-start cus-load edmacro kmacro
recentf tree-widget wid-edit easymenu server time-date tooltip
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process w32 multi-tty emacs)
*** E-Mail body has been placed on clipboard, please paste it here! ***
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: 24.3; exec-path on ms windows should contain current directory
2013-09-25 13:24 bug#15461: 24.3; exec-path on ms windows should contain current directory Jarek Czekalski
@ 2013-09-25 15:48 ` Eli Zaretskii
2013-09-26 17:23 ` bug#15461: why do I need it Jarek Czekalski
` (4 subsequent siblings)
5 siblings, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2013-09-25 15:48 UTC (permalink / raw)
To: Jarek Czekalski; +Cc: 15461
> Date: Wed, 25 Sep 2013 15:24:58 +0200
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
>
> To be consistent with the native shell on Microsoft Windows,
> the exec-path should include current directory.
In Emacs, every buffer has its own "current directory", the value of
default-directory of that buffer. So you are in effect proposing to
change exec-path whenever a buffer is switched, including temporary
buffers used by Emacs under the hood and whatnot.
OTOH, the current directory is always implicitly present, so while
completion indeed doesn't happen, typing "M-! test.bat RET" _will_ in
fact invoke the batch file.
So I wonder what are the real-life use cases that motivated you to ask
for this change. Is that only completion?
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: why do I need it
2013-09-25 13:24 bug#15461: 24.3; exec-path on ms windows should contain current directory Jarek Czekalski
2013-09-25 15:48 ` Eli Zaretskii
@ 2013-09-26 17:23 ` Jarek Czekalski
2013-09-26 17:59 ` Eli Zaretskii
2013-09-26 20:40 ` bug#15461: answer Jarek Czekalski
` (3 subsequent siblings)
5 siblings, 1 reply; 17+ messages in thread
From: Jarek Czekalski @ 2013-09-26 17:23 UTC (permalink / raw)
To: 15461
Hi Eli
> So I wonder what are the real-life use cases that motivated you to ask
> for this change. Is that only completion?
I like to have my environment comfortable. I often work with batch
files, sometimes they have long names. Whether I am in native windows
shell (cmd.exe) or in my previous editor (jedit) I am used to get the
batch file name completed after pressing tab. A requirement of typing
always the full name of a batch file is awkward.
You ask such a question that I am not sure what answer you expect. Maybe
you want to know more about me. I am open source enthusiast. When I
choose software I prefer to choose one of open-source sort. Whenever the
software doesn't meet my needs, I know I can extend it (I love this
feature by the way). I know I can work on bugs myself. So when I find
something that I think should be improved, that I would improve if it
was my software, then I do a move to apply the improvement. I prefer to
apply improvement to an official distro, rather than to my local
installation only. Sometimes I use the software on someone elses box and
don't have time to adjust everything from scratch.
Now you know it all :)
Regards
Jarek
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: why do I need it
2013-09-26 17:23 ` bug#15461: why do I need it Jarek Czekalski
@ 2013-09-26 17:59 ` Eli Zaretskii
2013-09-26 20:39 ` Stefan Monnier
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2013-09-26 17:59 UTC (permalink / raw)
To: Jarek Czekalski; +Cc: 15461
> Date: Thu, 26 Sep 2013 19:23:19 +0200
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
>
> > So I wonder what are the real-life use cases that motivated you to ask
> > for this change. Is that only completion?
>
> I like to have my environment comfortable. I often work with batch
> files, sometimes they have long names. Whether I am in native windows
> shell (cmd.exe) or in my previous editor (jedit) I am used to get the
> batch file name completed after pressing tab. A requirement of typing
> always the full name of a batch file is awkward.
>
> You ask such a question that I am not sure what answer you expect.
I expected nothing more than the answer to the question. Apologies if
the question was not clear enough.
Let me try to elaborate.
If the only use case where you need this is completion of executables,
an alternative solution could be to teach such completion to look in
the current buffer's default directory, on systems where that is
implicit. This could be an easier solution than futzing with the
environment.
The disadvantage of adding something to the environment is that it
affects more than just your use case, and it also affects every
sub-process Emacs will run. The broader the effect, the higher the
risk of unintended consequences (a.k.a. "bugs that we will introduce
while fixing this one").
It sounds like your problem is indeed limited to completion of
executable file names, which seems to suggest that a narrower, more
specific solution is possible.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: why do I need it
2013-09-26 17:59 ` Eli Zaretskii
@ 2013-09-26 20:39 ` Stefan Monnier
0 siblings, 0 replies; 17+ messages in thread
From: Stefan Monnier @ 2013-09-26 20:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 15461, Jarek Czekalski
> If the only use case where you need this is completion of executables,
> an alternative solution could be to teach such completion to look in
> the current buffer's default directory, on systems where that is
> implicit. This could be an easier solution than futzing with the
> environment.
Completion should mirror the behavior of the code that spawns the
process, so if the process name can be relative to default-directory,
completion should also accept file names in default-directory.
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: answer
2013-09-25 13:24 bug#15461: 24.3; exec-path on ms windows should contain current directory Jarek Czekalski
2013-09-25 15:48 ` Eli Zaretskii
2013-09-26 17:23 ` bug#15461: why do I need it Jarek Czekalski
@ 2013-09-26 20:40 ` Jarek Czekalski
2013-12-15 20:32 ` bug#15461: 24.3; exec-path on ms windows should contain current directory Jarek Czekalski
` (2 subsequent siblings)
5 siblings, 0 replies; 17+ messages in thread
From: Jarek Czekalski @ 2013-09-26 20:40 UTC (permalink / raw)
To: 15461
You revealed to me the deeper nature of things. Seems like someone needs
to investigate in what place exec-path is used and what is the best
place to achieve the desired functionality - autocompletion in
shell-command. Since I am the one who wants this functionality, I should
make this analyze first.
Now I also see what was unclear in my original report. The bug should be
rephrased as: auto-completion in shell-command on Windows should look in
current buffer's default directory.
Thanks
Jarek
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: 24.3; exec-path on ms windows should contain current directory
2013-09-25 13:24 bug#15461: 24.3; exec-path on ms windows should contain current directory Jarek Czekalski
` (2 preceding siblings ...)
2013-09-26 20:40 ` bug#15461: answer Jarek Czekalski
@ 2013-12-15 20:32 ` Jarek Czekalski
2013-12-15 21:16 ` Eli Zaretskii
2013-12-16 8:06 ` Jarek Czekalski
2013-12-25 23:14 ` bug#15461: 24.3; [PATCH] " Jarek Czekalski
5 siblings, 1 reply; 17+ messages in thread
From: Jarek Czekalski @ 2013-12-15 20:32 UTC (permalink / raw)
To: 15461
Some analyzis done:
1. shell-command uses libexec\emacs\24.3.50\i686-pc-mingw32\cmdproxy.exe
and this proxy locates files in the current directory. Side note: it
ignores exec-path and uses only system PATH variable
2. call-process does not run programs from the current directory (a new bug)
Now the Stefan's suggestion:
> Completion should mirror the behavior of the code that spawns the
> process
, which seemed perfectly at the beginning, makes less sense. Which
code's behaviour should be copied?
I guess first call-process should be fixed to include the current
directory, then its behaviour may be copied.
Any suggestions in which direction to go? Maybe the simplest consing
exec-path is still an option? Should I look at potential problems of
that solution?
I'm happy that my initial title for the bug makes sense now, because not
only completion is affected, but the spawning process as well :)
Jarek
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: 24.3; exec-path on ms windows should contain current directory
2013-12-15 20:32 ` bug#15461: 24.3; exec-path on ms windows should contain current directory Jarek Czekalski
@ 2013-12-15 21:16 ` Eli Zaretskii
0 siblings, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2013-12-15 21:16 UTC (permalink / raw)
To: Jarek Czekalski; +Cc: 15461
> Date: Sun, 15 Dec 2013 21:32:12 +0100
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
>
> Some analyzis done:
>
> 1. shell-command uses libexec\emacs\24.3.50\i686-pc-mingw32\cmdproxy.exe
> and this proxy locates files in the current directory. Side note: it
> ignores exec-path and uses only system PATH variable
cmdproxy emulates a shell, so it does what every shell would: ignore
exec-path (which is an Emacs feature, unknown to other programs), and
use PATH.
> 2. call-process does not run programs from the current directory (a new bug)
It's not a bug. Again, please keep in mind that each buffer in Emacs
has its own "current directory".
> Now the Stefan's suggestion:
>
> > Completion should mirror the behavior of the code that spawns the
> > process
>
> , which seemed perfectly at the beginning, makes less sense. Which
> code's behaviour should be copied?
>
> I guess first call-process should be fixed to include the current
> directory, then its behaviour may be copied.
I suggest to stay focused on the issue at hand: completion of
executable files. If we extend the issue to how executables are found
by call-process, cmdproxy, shell-command, etc., we will just add
unneeded complexity.
> Any suggestions in which direction to go? Maybe the simplest consing
> exec-path is still an option?
No, it is not. Again, let's stay focused on completion.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: 24.3; exec-path on ms windows should contain current directory
2013-09-25 13:24 bug#15461: 24.3; exec-path on ms windows should contain current directory Jarek Czekalski
` (3 preceding siblings ...)
2013-12-15 20:32 ` bug#15461: 24.3; exec-path on ms windows should contain current directory Jarek Czekalski
@ 2013-12-16 8:06 ` Jarek Czekalski
2013-12-16 16:45 ` Eli Zaretskii
2013-12-25 23:14 ` bug#15461: 24.3; [PATCH] " Jarek Czekalski
5 siblings, 1 reply; 17+ messages in thread
From: Jarek Czekalski @ 2013-12-16 8:06 UTC (permalink / raw)
To: 15461
> If we extend the issue to how executables are found
> by call-process, cmdproxy, shell-command, etc., we will just add
> unneeded complexity.
This remark is unnecessary. You already said that "call-process" on
Windows should not find the executables in the current buffer's
directory. That's the argument and that's enough. Saying about "unneeded
complexity" only makes me think that you want to close the bug as
quickly as possible, without much thinking.
> Again, let's stay focused on completion.
Agreed. I will provide a completion-only patch.
Jarek
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: 24.3; exec-path on ms windows should contain current directory
2013-12-16 8:06 ` Jarek Czekalski
@ 2013-12-16 16:45 ` Eli Zaretskii
2013-12-18 8:15 ` Jarek Czekalski
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2013-12-16 16:45 UTC (permalink / raw)
To: Jarek Czekalski; +Cc: 15461
> Date: Mon, 16 Dec 2013 09:06:11 +0100
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
>
> > If we extend the issue to how executables are found
> > by call-process, cmdproxy, shell-command, etc., we will just add
> > unneeded complexity.
>
> This remark is unnecessary. You already said that "call-process" on
> Windows should not find the executables in the current buffer's
> directory. That's the argument and that's enough. Saying about "unneeded
> complexity" only makes me think that you want to close the bug as
> quickly as possible, without much thinking.
Sorry, that was never the intent. I apologize for whatever of my
wording that led you to this conclusion.
> > Again, let's stay focused on completion.
>
> Agreed. I will provide a completion-only patch.
Thank you.
Btw, if the patch is going to be substantial, you may wish to start
your paperwork with FSF soon, as I don't see your name on file with
the FSF copyright assignment records.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: 24.3; exec-path on ms windows should contain current directory
2013-12-16 16:45 ` Eli Zaretskii
@ 2013-12-18 8:15 ` Jarek Czekalski
0 siblings, 0 replies; 17+ messages in thread
From: Jarek Czekalski @ 2013-12-18 8:15 UTC (permalink / raw)
To: 15461
I noticed that I didn't show what my workaround exactly is:
(setq exec-path (cons "." exec-path))
This makes also call-process catch the executables from the current
directory. Of course that doesn't change my position, that I'll do the
completion patch.
W dniu 2013-12-16 17:45, Eli Zaretskii pisze:
> Btw, if the patch is going to be substantial, you may wish to start
> your paperwork with FSF soon, as I don't see your name on file with
> the FSF copyright assignment records.
On Saturday I sent an inquiry to the assign mailbox, whether they
received my papers. Now waiting their 5 business days for an answer. It
should arrive soon :)
Jarek
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: 24.3; [PATCH] exec-path on ms windows should contain current directory
2013-09-25 13:24 bug#15461: 24.3; exec-path on ms windows should contain current directory Jarek Czekalski
` (4 preceding siblings ...)
2013-12-16 8:06 ` Jarek Czekalski
@ 2013-12-25 23:14 ` Jarek Czekalski
2013-12-26 16:23 ` Eli Zaretskii
5 siblings, 1 reply; 17+ messages in thread
From: Jarek Czekalski @ 2013-12-25 23:14 UTC (permalink / raw)
To: 15461
[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]
I am attaching a patch to fix this thing. The change is very small, but
when documenting it, I discovered some inconsistencies in the manual
regarding shell completion options. I did my best to fix them. Now the
documentation changes are bigger than the functional change.
Below I pointed several things that may need attention:
- Whether such broad changes in manual may be done together with a lisp
change (new variable)
- Whether an unnumbered subsubsection Shell Mode Completion Options in
Shell Mode Options is a good idea
- Whether anchors can be used, because our info viewer does not follow
them correctly
- Whether this new variable may be introduced despite the feature freeze
- Whether a new position in concept index (shell completion) is fine
Suggested commit message:
Introduce a variable shell-completion-cur-dir and document it.
Document a related detail in exec-path variable.
Add some consistency in the documentation of completion in the manual:
- add a link from Completion section to Shell Mode,
- move documentation of shell-completion-fignore from Shell Mode to Shell
Mode Options,
- group Shell Mode Completion Options into a new unnumbered subsubsection.
FIXME: anchors used in this commit currently do not work correctly in Emacs
info viewer, however work correctly in Linux info viewer, so this must be
a bug in our info viewer.
* lisp/shell.el (shell-completion-cur-dir): New variable to allow shell
completion to use filenames from current directory.
(shell--command-completion-data): Use it.
* src/callproc.c (Vexec_path): Documentation of the library path in it.
* doc/mini.texi (Completion Options): Add a link to Shell Mode
Completion
Options.
* doc/misc.texi (Shell Mode): Document new variable
shell-completion-cur-dir.
Move documentation of shell-completion-fignore from Shell Mode to Shell
Mode Options.
Add an unnumbered subsubsection to group completion options. This also
required to move pushd paragraph above this group.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: complete_cur_dir_1_0.diff --]
[-- Type: text/x-diff; name="complete_cur_dir_1_0.diff", Size: 11080 bytes --]
=== modified file 'doc/emacs/ChangeLog'
*** doc/emacs/ChangeLog 2013-12-25 02:18:43 +0000
--- doc/emacs/ChangeLog 2013-12-25 22:39:00 +0000
***************
*** 1,3 ****
--- 1,15 ----
+ 2013-12-25 Jarek Czekalski <jarekczek@poczta.onet.pl>
+
+ * mini.texi (Completion Options): Add a link to Shell Mode Completion
+ Options.
+ * misc.texi (Shell Mode): Document new variable
+ shell-completion-cur-dir.
+ Move documentation of shell-completion-fignore from Shell Mode to Shell
+ Mode Options.
+ Add an unnumbered subsubsection to group completion options. This also
+ required to move pushd paragraph above this group.
+
+
2013-12-25 Xue Fuqiao <xfq.free@gmail.com>
* files.texi (Diff Mode): Add an index.
=== modified file 'doc/emacs/mini.texi'
*** doc/emacs/mini.texi 2013-01-01 09:11:05 +0000
--- doc/emacs/mini.texi 2013-12-25 22:35:50 +0000
*************** previous example, @samp{foo.e} completes
*** 550,555 ****
--- 550,558 ----
disregards @code{completion-ignored-extensions} when showing
completion alternatives in the completion list.
+ Shell completion is an extended version of filename completion,
+ @xref{Shell Mode Completion Options}.
+
@vindex completion-auto-help
If @code{completion-auto-help} is set to @code{nil}, the completion
commands never display the completion list buffer; you must type
=== modified file 'doc/emacs/misc.texi'
*** doc/emacs/misc.texi 2013-12-23 13:01:25 +0000
--- doc/emacs/misc.texi 2013-12-25 22:36:30 +0000
*************** in the shell buffer to submit the curren
*** 677,696 ****
@item @key{TAB}
@kindex TAB @r{(Shell mode)}
@findex completion-at-point
Complete the command name or file name before point in the shell
buffer (@code{completion-at-point}). This uses the usual Emacs
completion rules (@pxref{Completion}), with the completion
alternatives being file names, environment variable names, the shell
command history, and history references (@pxref{History References}).
!
! @vindex shell-completion-fignore
! @vindex comint-completion-fignore
! The variable @code{shell-completion-fignore} specifies a list of file
! name extensions to ignore in Shell mode completion. The default
! setting is @code{nil}, but some users prefer @code{("~" "#" "%")} to
! ignore file names ending in @samp{~}, @samp{#} or @samp{%}. Other
! related Comint modes use the variable @code{comint-completion-fignore}
! instead.
@item M-?
@kindex M-? @r{(Shell mode)}
--- 677,689 ----
@item @key{TAB}
@kindex TAB @r{(Shell mode)}
@findex completion-at-point
+ @cindex shell completion
Complete the command name or file name before point in the shell
buffer (@code{completion-at-point}). This uses the usual Emacs
completion rules (@pxref{Completion}), with the completion
alternatives being file names, environment variable names, the shell
command history, and history references (@pxref{History References}).
! Also @xref{Shell Mode Completion Options}.
@item M-?
@kindex M-? @r{(Shell mode)}
*************** value means to omit an input that is the
*** 1161,1169 ****
--- 1154,1176 ----
The default is @code{nil}, which means to store each input even if it is
equal to the previous input.
+ @findex shell-pushd-tohome
+ @findex shell-pushd-dextract
+ @findex shell-pushd-dunique
+ You can configure the behavior of @samp{pushd}. Variables control
+ whether @samp{pushd} behaves like @samp{cd} if no argument is given
+ (@code{shell-pushd-tohome}), pop rather than rotate with a numeric
+ argument (@code{shell-pushd-dextract}), and only add directories to the
+ directory stack if they are not already on it
+ (@code{shell-pushd-dunique}). The values you choose should match the
+ underlying shell, of course.
+
+ @unnumberedsubsubsec Shell Mode Completion Options
+ @anchor{Shell Mode Completion Options}
@vindex comint-completion-addsuffix
@vindex comint-completion-recexact
@vindex comint-completion-autolist
+ @cindex shell completion
Three variables customize file name completion. The variable
@code{comint-completion-addsuffix} controls whether completion inserts a
space or a slash to indicate a fully completed file or directory name
*************** the possible completions whenever comple
*** 1179,1194 ****
If you set @code{shell-completion-execonly} to @code{nil},
it considers nonexecutable files as well.
! @findex shell-pushd-tohome
! @findex shell-pushd-dextract
! @findex shell-pushd-dunique
! You can configure the behavior of @samp{pushd}. Variables control
! whether @samp{pushd} behaves like @samp{cd} if no argument is given
! (@code{shell-pushd-tohome}), pop rather than rotate with a numeric
! argument (@code{shell-pushd-dextract}), and only add directories to the
! directory stack if they are not already on it
! (@code{shell-pushd-dunique}). The values you choose should match the
! underlying shell, of course.
@node Terminal emulator
@subsection Emacs Terminal Emulator
--- 1186,1208 ----
If you set @code{shell-completion-execonly} to @code{nil},
it considers nonexecutable files as well.
! @vindex shell-completion-fignore
! @vindex comint-completion-fignore
! The variable @code{shell-completion-fignore} specifies a list of file
! name extensions to ignore in Shell mode completion. The default
! setting is @code{nil}, but some users prefer @code{("~" "#" "%")} to
! ignore file names ending in @samp{~}, @samp{#} or @samp{%}. Other
! related Comint modes use the variable @code{comint-completion-fignore}
! instead.
!
! @vindex shell-completion-cur-dir
! The variable @code{shell-completion-cur-dir} controls whether filenames from
! the current buffer's directory will also be used as potential commands.
!
! @findex shell-dynamic-complete-command
! Some implementation details of the shell command completion may also be found
! in the lisp documentation of the @code{shell-dynamic-complete-command}
! function.
@node Terminal emulator
@subsection Emacs Terminal Emulator
=== modified file 'etc/NEWS'
*** etc/NEWS 2013-12-25 03:05:11 +0000
--- etc/NEWS 2013-12-25 23:09:58 +0000
*************** the variable `explicit-shell-file-name'
*** 2943,2948 ****
--- 2943,2954 ----
*** TAB is now bound to the standard `completion-at-point' command,
which now implements the pcomplete rules for shell command completion.
+ ---
+ *** New customizable variable shell-completion-cur-dir, which controls
+ whether filenames from current directory will be found by
+ completion. Initialized to t on systems on which this is default
+ behavior.
+
** SMTPmail
*** SMTPmail now uses encrypted connections (via STARTTLS) by default
=== modified file 'lisp/ChangeLog'
*** lisp/ChangeLog 2013-12-24 19:48:40 +0000
--- lisp/ChangeLog 2013-12-25 21:17:16 +0000
***************
*** 1,3 ****
--- 1,9 ----
+ 2013-12-25 Jarek Czekalski <jarekczek@poczta.onet.pl>
+
+ * shell.el (shell-completion-cur-dir): New variable to allow shell
+ completion to use filenames from current directory.
+ (shell--command-completion-data): Use it.
+
2013-12-24 Fabián Ezequiel Gallina <fgallina@gnu.org>
* progmodes/python.el (python-nav-beginning-of-statement): Speed
=== modified file 'lisp/shell.el'
*** lisp/shell.el 2013-09-12 05:40:50 +0000
--- lisp/shell.el 2013-12-25 22:54:47 +0000
*************** Detecting executability of files may slo
*** 211,216 ****
--- 211,223 ----
:type 'boolean
:group 'shell)
+ (defcustom shell-completion-cur-dir
+ (member system-type '(windows-nt ms-dos t))
+ "Non-nil if completion should match filenames from the current buffer's
+ directory. Initialized to t on systems in which this behavior is a default."
+ :type 'boolean
+ :group 'shell)
+
(defcustom shell-popd-regexp "popd"
"Regexp to match subshell commands equivalent to popd."
:type 'regexp
*************** searches `exec-path' (minus the trailing
*** 1112,1119 ****
candidates. Note that this may not be the same as the shell's idea of the
path.
! Completion is dependent on the value of `shell-completion-execonly', plus
! those that effect file completion.
Returns t if successful."
(interactive)
--- 1119,1127 ----
candidates. Note that this may not be the same as the shell's idea of the
path.
! Completion is dependent on the value of `shell-completion-execonly',
! `shell-completion-fignore', `shell-completion-cur-dir', plus those that affect
! file completion. See Info node `Shell Mode Completion Options'.
Returns t if successful."
(interactive)
*************** Returns t if successful."
*** 1138,1144 ****
(start (if (zerop (length filename)) (point) (match-beginning 0)))
(end (if (zerop (length filename)) (point) (match-end 0)))
(filenondir (file-name-nondirectory filename))
! (path-dirs (cdr (reverse exec-path))) ;FIXME: Why `cdr'?
(cwd (file-name-as-directory (expand-file-name default-directory)))
(ignored-extensions
(and comint-completion-fignore
--- 1146,1155 ----
(start (if (zerop (length filename)) (point) (match-beginning 0)))
(end (if (zerop (length filename)) (point) (match-end 0)))
(filenondir (file-name-nondirectory filename))
! ; why cdr? see `shell-dynamic-complete-command', however on Windows
! ; we have 3 library directories and this does not fully work
! (path-dirs (append (cdr (reverse exec-path))
! (if shell-completion-cur-dir '("."))))
(cwd (file-name-as-directory (expand-file-name default-directory)))
(ignored-extensions
(and comint-completion-fignore
=== modified file 'src/ChangeLog'
*** src/ChangeLog 2013-12-24 17:21:06 +0000
--- src/ChangeLog 2013-12-25 22:44:31 +0000
***************
*** 1,3 ****
--- 1,7 ----
+ 2013-12-25 Jarek Czekalski <jarekczek@poczta.onet.pl>
+
+ * callproc.c (Vexec_path): Documentation of the library path in it.
+
2013-12-24 Eli Zaretskii <eliz@gnu.org>
* w32fns.c (Fw32_shell_execute): Ensure DOCUMENT is an absolute
=== modified file 'src/callproc.c'
*** src/callproc.c 2013-12-18 20:36:50 +0000
--- src/callproc.c 2013-12-25 08:45:33 +0000
*************** default if SHELL is not set. */);
*** 1686,1692 ****
DEFVAR_LISP ("exec-path", Vexec_path,
doc: /* List of directories to search programs to run in subprocesses.
! Each element is a string (directory name) or nil (try default directory). */);
DEFVAR_LISP ("exec-suffixes", Vexec_suffixes,
doc: /* List of suffixes to try to find executable file names.
--- 1686,1696 ----
DEFVAR_LISP ("exec-path", Vexec_path,
doc: /* List of directories to search programs to run in subprocesses.
! Each element is a string (directory name) or nil (try default directory).
!
! By default the last element of this list is Emacs library path. The
! last element is not always used, for example in shell completion
! (`shell-dynamic-complete-command'). */);
DEFVAR_LISP ("exec-suffixes", Vexec_suffixes,
doc: /* List of suffixes to try to find executable file names.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: 24.3; [PATCH] exec-path on ms windows should contain current directory
2013-12-25 23:14 ` bug#15461: 24.3; [PATCH] " Jarek Czekalski
@ 2013-12-26 16:23 ` Eli Zaretskii
2013-12-26 22:27 ` Jarek Czekalski
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2013-12-26 16:23 UTC (permalink / raw)
To: Jarek Czekalski; +Cc: 15461
> Date: Thu, 26 Dec 2013 00:14:47 +0100
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
>
> I am attaching a patch to fix this thing.
Thanks.
> - Whether such broad changes in manual may be done together with a lisp
> change (new variable)
If they are related, yes.
> - Whether an unnumbered subsubsection Shell Mode Completion Options in
> Shell Mode Options is a good idea
It's not a catastrophe, but a @node is preferable. Except that in
this case, I don't think even a node is justified, as you only added a
single variable to a node that was not very large anyway.
> - Whether anchors can be used, because our info viewer does not follow
> them correctly
They work fine for me, both with the current trunk and with Emacs
24.3. Do you see the problem in 'emacs -Q"? If so, what exactly
doesn't work?
> - Whether this new variable may be introduced despite the feature freeze
I'm not sure it should be introduced at all. My reasoning:
. Users of Posix platforms that would want this behavior will most
probably already have "." in their PATH, and exec-path will inherit
that.
. Users of Windows who do _not_ want this are IMO insane (pardon my
French), because every Windows program and shell will behave like
that, whether they want it or not
So I think we should just behave on each platform as its users should
expect.
> - Whether a new position in concept index (shell completion) is fine
It is fine, but you added 2 identical index entries, which is
generally not recommended, because they will be presented to the user
by the 'i' command as "shell completion<1>" and "shell completion<2>",
something that will make it hard to decide which one to choose.
Instead, qualify each entry with some context of what is described in
each place about shell completion. Alternatively, decide which of the
two index entries is not really necessary, and remove it.
> Suggested commit message:
>
> Introduce a variable shell-completion-cur-dir and document it.
> Document a related detail in exec-path variable.
It would be better to have only one header line in the commit message,
because that's what "bzr log --line" shows for each commit. The rest
of the details will be visible from the ChangeLog entries that you
will copy into the commit message.
> - move documentation of shell-completion-fignore from Shell Mode to Shell
> Mode Options,
> - group Shell Mode Completion Options into a new unnumbered subsubsection.
As I wrote above, I'm not sure a new subsection is justified in this
case.
> * doc/misc.texi (Shell Mode): Document new variable
> shell-completion-cur-dir.
> Move documentation of shell-completion-fignore from Shell Mode to Shell
> Mode Options.
> Add an unnumbered subsubsection to group completion options. This also
> required to move pushd paragraph above this group.
In general, don't start from a new line when you describe changes to
the same node. Just continue.
> + Shell completion is an extended version of filename completion,
> + @xref{Shell Mode Completion Options}.
@xref is not appropriate in the middle of a sentence, because it
generates text that begins with a capital letter. (You don't see that
in Emacs, because Emacs by default hides that text and replaces it
with something it invents. But it is clearly visible in the
stand-alone Info reader, and even more acutely visible in the printed
output.) Instead, either use "see @ref", or start a new sentence with
@xref.
> + ---
Why "---"? It means this does not need to be documented. You want
"+++" instead, which means "already documented".
> + *** New customizable variable shell-completion-cur-dir, which controls
> + whether filenames from current directory will be found by
> + completion. Initialized to t on systems on which this is default
^^
Two spaces between sentences, please.
> + (defcustom shell-completion-cur-dir
> + (member system-type '(windows-nt ms-dos t))
Why 'member' and not 'memq'? And why did you put t at the end of the
list?
> + "Non-nil if completion should match filenames from the current buffer's
> + directory. Initialized to t on systems in which this behavior is a default."
^^ ^^^^^^^^^
Two spaces, and "the default".
Btw, it is OK to mention those systems explicitly, there's no need for
obscurity here.
I would also suggest a slight rewording:
Non-nil if shell completion should match executable filenames from
the current buffer's directory.
> *************** Returns t if successful."
> *** 1138,1144 ****
> (start (if (zerop (length filename)) (point) (match-beginning 0)))
> (end (if (zerop (length filename)) (point) (match-end 0)))
> (filenondir (file-name-nondirectory filename))
> ! (path-dirs (cdr (reverse exec-path))) ;FIXME: Why `cdr'?
> (cwd (file-name-as-directory (expand-file-name default-directory)))
> (ignored-extensions
> (and comint-completion-fignore
> --- 1146,1155 ----
> (start (if (zerop (length filename)) (point) (match-beginning 0)))
> (end (if (zerop (length filename)) (point) (match-end 0)))
> (filenondir (file-name-nondirectory filename))
> ! ; why cdr? see `shell-dynamic-complete-command', however on Windows
> ! ; we have 3 library directories and this does not fully work
> ! (path-dirs (append (cdr (reverse exec-path))
> ! (if shell-completion-cur-dir '("."))))
The remark about Windows is no longer true on the trunk, and I think
comments should explain better than that. In any case, this is a
completely separate issue, for which I will start a new thread.
> DEFVAR_LISP ("exec-path", Vexec_path,
> doc: /* List of directories to search programs to run in subprocesses.
> ! Each element is a string (directory name) or nil (try default directory).
> !
> ! By default the last element of this list is Emacs library path. The
> ! last element is not always used, for example in shell completion
> ! (`shell-dynamic-complete-command'). */);
This also belongs to that separate issue (and "library path" is a term
that we don't use anywhere else, except in the part of the manual
which you modified, so I think we should not use it in the doc
string). See there.
Bottom line: I think the change in shell--command-completion-data
should go in, modulo the comment. I don't think we need the new
option, but if Stefan decides otherwise, I won't object.
As to the changes in the manual, if we don't add the option, I'd leave
the manual alone, except for the indexing. If we do add the option, I
think it could be left in the same node where we describe the other
options.
Thanks again for working on this.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: 24.3; [PATCH] exec-path on ms windows should contain current directory
2013-12-26 16:23 ` Eli Zaretskii
@ 2013-12-26 22:27 ` Jarek Czekalski
2013-12-26 23:22 ` Juanma Barranquero
2013-12-27 8:19 ` Eli Zaretskii
0 siblings, 2 replies; 17+ messages in thread
From: Jarek Czekalski @ 2013-12-26 22:27 UTC (permalink / raw)
To: 15461
[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]
Hi Eli
This was a thorough review of the patch and exhausting answers. Thank you.
I no longer have any justification for creating a variable
shell-completion-cur-dir. After removing this variable the patch, the
code and the manual are better and cleaner.
"shell completion" concept index now points only to <TAB> paragraph in
Shell Mode node.
Only a few things require an answer from me. Those omitted are the ones
I completely agree with and took a lesson from them.
> >- Whether an unnumbered subsubsection Shell Mode Completion Options in
> >Shell Mode Options is a good idea
> It's not a catastrophe, but a @node is preferable. Except that in
> this case, I don't think even a node is justified, as you only added a
> single variable to a node that was not very large anyway.
Half of this node regards shell completion options. It would be good to
group these options in some way. I just wanted to give them a heading
and separate from others. But after your remark I removed the node and
the anchor. The grouping may be done later.
> + (defcustom shell-completion-cur-dir
> + (member system-type '(windows-nt ms-dos t))
> Why 'member' and not 'memq'? And why did you put t at the end of the
> list?
>
The t was a mistake, I thought it will make it return t. Member and memq
have identical docstrings, so I actually don't know why this one.
Changed to memq.
> ! ; why cdr? see `shell-dynamic-complete-command', however on Windows
> ! ; we have 3 library directories and this does not fully work
> ! (path-dirs (append (cdr (reverse exec-path))
> ! (if shell-completion-cur-dir '("."))))
> The remark about Windows is no longer true on the trunk, and I think
> comments should explain better than that. In any case, this is a
> completely separate issue, for which I will start a new thread.
The remark about cdr is valid at the moment and answers the question
that was here before, so I don't remove it. However if the remark about
windows was missed, I cut it. Actually I discovered it some time ago and
not verified lately.
If you still want to strip the patch from some of the changes, please do.
Attached the modified patch, the commit message could be:
Shell completion for filenames from current directory, related docs.
* doc/emacs/mini.texi (Completion Options): Add a link to Shell
Options.
* doc/emacs/misc.texi (Shell Mode): Move documentation of
shell-completion-fignore from Shell Mode to Shell Options.
* lisp/shell.el Shell completion now matches executable filenames from
the current buffer's directory, on systems in which this behaviour
is the default (windows-nt, ms-dos).
* src/callproc.c (Vexec_path): Documentation of the library path in it.
Jarek
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: complete_cur_dir_2_0.diff --]
[-- Type: text/x-diff; name="complete_cur_dir_2_0.diff", Size: 7526 bytes --]
=== modified file 'doc/emacs/ChangeLog'
*** doc/emacs/ChangeLog 2013-12-25 02:18:43 +0000
--- doc/emacs/ChangeLog 2013-12-26 21:30:14 +0000
***************
*** 1,3 ****
--- 1,10 ----
+ 2013-12-25 Jarek Czekalski <jarekczek@poczta.onet.pl>
+
+ * mini.texi (Completion Options): Add a link to Shell Options.
+ * misc.texi (Shell Mode): Move documentation of
+ shell-completion-fignore from Shell Mode to Shell Options.
+
+
2013-12-25 Xue Fuqiao <xfq.free@gmail.com>
* files.texi (Diff Mode): Add an index.
=== modified file 'doc/emacs/mini.texi'
*** doc/emacs/mini.texi 2013-01-01 09:11:05 +0000
--- doc/emacs/mini.texi 2013-12-26 22:21:42 +0000
*************** previous example, @samp{foo.e} completes
*** 550,555 ****
--- 550,558 ----
disregards @code{completion-ignored-extensions} when showing
completion alternatives in the completion list.
+ Shell completion is an extended version of filename completion,
+ @pxref{Shell Options}.
+
@vindex completion-auto-help
If @code{completion-auto-help} is set to @code{nil}, the completion
commands never display the completion list buffer; you must type
=== modified file 'doc/emacs/misc.texi'
*** doc/emacs/misc.texi 2013-12-23 13:01:25 +0000
--- doc/emacs/misc.texi 2013-12-26 22:16:37 +0000
*************** in the shell buffer to submit the curren
*** 677,696 ****
@item @key{TAB}
@kindex TAB @r{(Shell mode)}
@findex completion-at-point
Complete the command name or file name before point in the shell
buffer (@code{completion-at-point}). This uses the usual Emacs
completion rules (@pxref{Completion}), with the completion
alternatives being file names, environment variable names, the shell
command history, and history references (@pxref{History References}).
!
! @vindex shell-completion-fignore
! @vindex comint-completion-fignore
! The variable @code{shell-completion-fignore} specifies a list of file
! name extensions to ignore in Shell mode completion. The default
! setting is @code{nil}, but some users prefer @code{("~" "#" "%")} to
! ignore file names ending in @samp{~}, @samp{#} or @samp{%}. Other
! related Comint modes use the variable @code{comint-completion-fignore}
! instead.
@item M-?
@kindex M-? @r{(Shell mode)}
--- 677,689 ----
@item @key{TAB}
@kindex TAB @r{(Shell mode)}
@findex completion-at-point
+ @cindex shell completion
Complete the command name or file name before point in the shell
buffer (@code{completion-at-point}). This uses the usual Emacs
completion rules (@pxref{Completion}), with the completion
alternatives being file names, environment variable names, the shell
command history, and history references (@pxref{History References}).
! For options controlling the completion, @pxref{Shell Options}.
@item M-?
@kindex M-? @r{(Shell mode)}
*************** the possible completions whenever comple
*** 1179,1184 ****
--- 1172,1191 ----
If you set @code{shell-completion-execonly} to @code{nil},
it considers nonexecutable files as well.
+ @vindex shell-completion-fignore
+ @vindex comint-completion-fignore
+ The variable @code{shell-completion-fignore} specifies a list of file
+ name extensions to ignore in Shell mode completion. The default
+ setting is @code{nil}, but some users prefer @code{("~" "#" "%")} to
+ ignore file names ending in @samp{~}, @samp{#} or @samp{%}. Other
+ related Comint modes use the variable @code{comint-completion-fignore}
+ instead.
+
+ @findex shell-dynamic-complete-command
+ Some implementation details of the shell command completion may also be found
+ in the lisp documentation of the @code{shell-dynamic-complete-command}
+ function.
+
@findex shell-pushd-tohome
@findex shell-pushd-dextract
@findex shell-pushd-dunique
=== modified file 'lisp/ChangeLog'
*** lisp/ChangeLog 2013-12-24 19:48:40 +0000
--- lisp/ChangeLog 2013-12-26 22:08:26 +0000
***************
*** 1,3 ****
--- 1,10 ----
+ 2013-12-25 Jarek Czekalski <jarekczek@poczta.onet.pl>
+
+ * shell.el Shell completion now matches executable filenames from
+ the current buffer's directory, on systems in which this behaviour
+ is the default (windows-nt, ms-dos).
+
+
2013-12-24 Fabián Ezequiel Gallina <fgallina@gnu.org>
* progmodes/python.el (python-nav-beginning-of-statement): Speed
=== modified file 'lisp/shell.el'
*** lisp/shell.el 2013-09-12 05:40:50 +0000
--- lisp/shell.el 2013-12-26 22:24:11 +0000
*************** searches `exec-path' (minus the trailing
*** 1112,1119 ****
candidates. Note that this may not be the same as the shell's idea of the
path.
! Completion is dependent on the value of `shell-completion-execonly', plus
! those that effect file completion.
Returns t if successful."
(interactive)
--- 1112,1120 ----
candidates. Note that this may not be the same as the shell's idea of the
path.
! Completion is dependent on the value of `shell-completion-execonly',
! `shell-completion-fignore', plus those that affect file completion. See Info
! node `Shell Options'.
Returns t if successful."
(interactive)
*************** Returns t if successful."
*** 1138,1144 ****
(start (if (zerop (length filename)) (point) (match-beginning 0)))
(end (if (zerop (length filename)) (point) (match-end 0)))
(filenondir (file-name-nondirectory filename))
! (path-dirs (cdr (reverse exec-path))) ;FIXME: Why `cdr'?
(cwd (file-name-as-directory (expand-file-name default-directory)))
(ignored-extensions
(and comint-completion-fignore
--- 1139,1147 ----
(start (if (zerop (length filename)) (point) (match-beginning 0)))
(end (if (zerop (length filename)) (point) (match-end 0)))
(filenondir (file-name-nondirectory filename))
! ; why cdr? see `shell-dynamic-complete-command'
! (path-dirs (append (cdr (reverse exec-path))
! (if (memq system-type '(windows-nt ms-dos)) '("."))))
(cwd (file-name-as-directory (expand-file-name default-directory)))
(ignored-extensions
(and comint-completion-fignore
=== modified file 'src/ChangeLog'
*** src/ChangeLog 2013-12-24 17:21:06 +0000
--- src/ChangeLog 2013-12-26 21:25:24 +0000
***************
*** 1,3 ****
--- 1,7 ----
+ 2013-12-25 Jarek Czekalski <jarekczek@poczta.onet.pl>
+
+ * callproc.c (Vexec_path): Documentation of the library path in it.
+
2013-12-24 Eli Zaretskii <eliz@gnu.org>
* w32fns.c (Fw32_shell_execute): Ensure DOCUMENT is an absolute
=== modified file 'src/callproc.c'
*** src/callproc.c 2013-12-18 20:36:50 +0000
--- src/callproc.c 2013-12-25 08:45:33 +0000
*************** default if SHELL is not set. */);
*** 1686,1692 ****
DEFVAR_LISP ("exec-path", Vexec_path,
doc: /* List of directories to search programs to run in subprocesses.
! Each element is a string (directory name) or nil (try default directory). */);
DEFVAR_LISP ("exec-suffixes", Vexec_suffixes,
doc: /* List of suffixes to try to find executable file names.
--- 1686,1696 ----
DEFVAR_LISP ("exec-path", Vexec_path,
doc: /* List of directories to search programs to run in subprocesses.
! Each element is a string (directory name) or nil (try default directory).
!
! By default the last element of this list is Emacs library path. The
! last element is not always used, for example in shell completion
! (`shell-dynamic-complete-command'). */);
DEFVAR_LISP ("exec-suffixes", Vexec_suffixes,
doc: /* List of suffixes to try to find executable file names.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: 24.3; [PATCH] exec-path on ms windows should contain current directory
2013-12-26 22:27 ` Jarek Czekalski
@ 2013-12-26 23:22 ` Juanma Barranquero
2013-12-27 8:19 ` Eli Zaretskii
1 sibling, 0 replies; 17+ messages in thread
From: Juanma Barranquero @ 2013-12-26 23:22 UTC (permalink / raw)
To: Jarek Czekalski; +Cc: 15461
On Thu, Dec 26, 2013 at 11:27 PM, Jarek Czekalski
<jarekczek@poczta.onet.pl> wrote:
> Member and memq have identical docstrings
Not really.
Comparison done with `equal'.
vs
Comparison done with `eq'.
(eq X Y) says whether X and Y are the same object, not whether they
are "equal" (for some values of "equal"; see
http://www.nhplace.com/kent/PS/EQUAL.html).
Interning a symbol in the main obarray always return the same object,
so `memq' is preferred to check a symbol against a list of symbols.
J
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: 24.3; [PATCH] exec-path on ms windows should contain current directory
2013-12-26 22:27 ` Jarek Czekalski
2013-12-26 23:22 ` Juanma Barranquero
@ 2013-12-27 8:19 ` Eli Zaretskii
2013-12-27 21:02 ` Jarek Czekalski
1 sibling, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2013-12-27 8:19 UTC (permalink / raw)
To: Jarek Czekalski; +Cc: 15461
> Date: Thu, 26 Dec 2013 23:27:48 +0100
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
>
> This was a thorough review of the patch and exhausting answers. Thank you.
And thank you for working on this in the first place.
> Half of this node regards shell completion options. It would be good to
> group these options in some way. I just wanted to give them a heading
> and separate from others. But after your remark I removed the node and
> the anchor. The grouping may be done later.
If you still have some problems with using anchor-generated references
in the Emacs Info reader, please tell the details (in another thread).
> Attached the modified patch, the commit message could be:
>
> Shell completion for filenames from current directory, related docs.
>
> * doc/emacs/mini.texi (Completion Options): Add a link to Shell
> Options.
> * doc/emacs/misc.texi (Shell Mode): Move documentation of
> shell-completion-fignore from Shell Mode to Shell Options.
> * lisp/shell.el Shell completion now matches executable filenames from
> the current buffer's directory, on systems in which this behaviour
> is the default (windows-nt, ms-dos).
> * src/callproc.c (Vexec_path): Documentation of the library path in it.
Looks good, please commit, with this single gotcha:
> ! By default the last element of this list is Emacs library path. The
I'd prefer that we talk about exec-directory here, not "library path",
which is mostly unknown terminology to Emacs users. By contrast,
exec-directory is a documented variable.
Thanks.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#15461: 24.3; [PATCH] exec-path on ms windows should contain current directory
2013-12-27 8:19 ` Eli Zaretskii
@ 2013-12-27 21:02 ` Jarek Czekalski
0 siblings, 0 replies; 17+ messages in thread
From: Jarek Czekalski @ 2013-12-27 21:02 UTC (permalink / raw)
To: 15461
Commited as r115775. Will be fixed in Emacs 24.4.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2013-12-27 21:02 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-25 13:24 bug#15461: 24.3; exec-path on ms windows should contain current directory Jarek Czekalski
2013-09-25 15:48 ` Eli Zaretskii
2013-09-26 17:23 ` bug#15461: why do I need it Jarek Czekalski
2013-09-26 17:59 ` Eli Zaretskii
2013-09-26 20:39 ` Stefan Monnier
2013-09-26 20:40 ` bug#15461: answer Jarek Czekalski
2013-12-15 20:32 ` bug#15461: 24.3; exec-path on ms windows should contain current directory Jarek Czekalski
2013-12-15 21:16 ` Eli Zaretskii
2013-12-16 8:06 ` Jarek Czekalski
2013-12-16 16:45 ` Eli Zaretskii
2013-12-18 8:15 ` Jarek Czekalski
2013-12-25 23:14 ` bug#15461: 24.3; [PATCH] " Jarek Czekalski
2013-12-26 16:23 ` Eli Zaretskii
2013-12-26 22:27 ` Jarek Czekalski
2013-12-26 23:22 ` Juanma Barranquero
2013-12-27 8:19 ` Eli Zaretskii
2013-12-27 21:02 ` Jarek Czekalski
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).