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

Previous Next

Packages: w32, emacs;

Reported by: Jarek Czekalski <jarekczek <at> poczta.onet.pl>

Date: Wed, 25 Sep 2013 13:26:02 UTC

Severity: wishlist

Tags: fixed

Found in version 24.3

Fixed in version 24.4

Done: Jarek Czekalski <jarekczek <at> poczta.onet.pl>

Bug is archived. No further changes may be made.

Full log


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

This bug report was last modified 11 years and 148 days ago.

Previous Next


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