GNU bug report logs - #15461
24.3; exec-path on ms windows should contain current directory

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15461 in the body.
You can then email your comments to 15461 AT debbugs.gnu.org in the normal way.

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

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3; exec-path on ms windows should contain current directory
Date: Wed, 25 Sep 2013 15:24:58 +0200

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15461 <at> debbugs.gnu.org
Subject: Re: bug#15461: 24.3;
 exec-path on ms windows should contain current directory
Date: Wed, 25 Sep 2013 18:48:43 +0300

> Date: Wed, 25 Sep 2013 15:24:58 +0200
> From: Jarek Czekalski <jarekczek <at> 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?

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: 15461 <at> debbugs.gnu.org
Subject: why do I need it
Date: Thu, 26 Sep 2013 19:23:19 +0200

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15461 <at> debbugs.gnu.org
Subject: Re: bug#15461: why do I need it
Date: Thu, 26 Sep 2013 20:59:34 +0300

> Date: Thu, 26 Sep 2013 19:23:19 +0200
> From: Jarek Czekalski <jarekczek <at> 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.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15461 <at> debbugs.gnu.org, Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Subject: Re: bug#15461: why do I need it
Date: Thu, 26 Sep 2013 16:39:07 -0400

> 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

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: 15461 <at> debbugs.gnu.org
Subject: answer
Date: Thu, 26 Sep 2013 22:40:56 +0200

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

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: 15461 <at> debbugs.gnu.org
Subject: 24.3; exec-path on ms windows should contain current directory
Date: Sun, 15 Dec 2013 21:32:12 +0100

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15461 <at> debbugs.gnu.org
Subject: Re: bug#15461: 24.3;
 exec-path on ms windows should contain current directory
Date: Sun, 15 Dec 2013 23:16:50 +0200

> Date: Sun, 15 Dec 2013 21:32:12 +0100
> From: Jarek Czekalski <jarekczek <at> 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.

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: 15461 <at> debbugs.gnu.org
Subject: 24.3; exec-path on ms windows should contain current directory
Date: Mon, 16 Dec 2013 09:06:11 +0100

> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15461 <at> debbugs.gnu.org
Subject: Re: bug#15461: 24.3;
 exec-path on ms windows should contain current directory
Date: Mon, 16 Dec 2013 18:45:02 +0200

> Date: Mon, 16 Dec 2013 09:06:11 +0100
> From: Jarek Czekalski <jarekczek <at> 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.

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: 15461 <at> debbugs.gnu.org
Subject: bug#15461: 24.3;
 exec-path on ms windows should contain current directory
Date: Wed, 18 Dec 2013 09:15:16 +0100

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

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: 15461 <at> debbugs.gnu.org
Subject: bug#15461: 24.3;
 [PATCH] exec-path on ms windows should contain current directory
Date: Thu, 26 Dec 2013 00:14:47 +0100

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

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.

[complete_cur_dir_1_0.diff (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15461 <at> debbugs.gnu.org
Subject: Re: bug#15461: 24.3;
 [PATCH] exec-path on ms windows should contain current directory
Date: Thu, 26 Dec 2013 18:23:19 +0200

> Date: Thu, 26 Dec 2013 00:14:47 +0100
> From: Jarek Czekalski <jarekczek <at> 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.

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: 15461 <at> debbugs.gnu.org
Subject: bug#15461: 24.3;
 [PATCH] exec-path on ms windows should contain current directory
Date: Thu, 26 Dec 2013 23:27:48 +0100

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

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

[complete_cur_dir_2_0.diff (text/x-diff, attachment)]

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15461 <at> debbugs.gnu.org
Subject: Re: bug#15461: 24.3; [PATCH] exec-path on ms windows should contain
 current directory
Date: Fri, 27 Dec 2013 00:22:59 +0100

On Thu, Dec 26, 2013 at 11:27 PM, Jarek Czekalski
<jarekczek <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
Cc: 15461 <at> debbugs.gnu.org
Subject: Re: bug#15461: 24.3;
 [PATCH] exec-path on ms windows should contain current directory
Date: Fri, 27 Dec 2013 10:19:19 +0200

> Date: Thu, 26 Dec 2013 23:27:48 +0100
> From: Jarek Czekalski <jarekczek <at> 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.

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

From: Jarek Czekalski <jarekczek <at> poczta.onet.pl>
To: 15461 <at> debbugs.gnu.org
Subject: Re: bug#15461: 24.3; [PATCH] exec-path on ms windows should contain
 current directory
Date: Fri, 27 Dec 2013 22:02:27 +0100

Commited as r115775. Will be fixed in Emacs 24.4.

Previous Next

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