GNU bug report logs - #11348
24.0.95; TAB-completion in shell-command produces d:\/foo on MS-Windows

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Thu, 26 Apr 2012 11:12:02 UTC

Severity: normal

Found in version 24.0.95

Fixed in version 24.0.97

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11348 <at> debbugs.gnu.org
Subject: Re: bug#11348: 24.0.95;
	TAB-completion in shell-command produces d:\/foo on MS-Windows
Date: Mon, 07 May 2012 11:27:15 -0400
> I'm not sure why it worked for you, because it still doesn't for me.
> Are you applying the changes to the emacs-24 branch?  Because that's
> what I do, this bug being against Emacs 24.0.96 and a regression from
> Emacs 23.4.

Yes, I tried it with the 24.0.96 pretest.   Hmm...

> According to my debugging inside shell-parse-pcomplete-arguments, what
> happens there is that this fragment

>           (while (looking-at
>                   (eval-when-compile
>                     (concat
>                      "\\(?:[^\s\t\n\\\"']+"
>                      "\\|'\\([^']*\\)'?"
>                      "\\|\"\\(\\(?:[^\"\\]\\|\\\\.\\)*\\)\"?"
>                      "\\|\\\\\\(\\(?:.\\|\n\\)?\\)\\)")))

> decides that \g is an escape sequence.

No, it does match "\g" but then the new code:

              (push (cond
                     ((null pcomplete-arg-quote-list)
                      (goto-char (match-beginning 3)) "\\")
                     ((= (match-beginning 3) (match-end 3)) "\\")
                     (t (match-string 3)))
                    arg))

sees that pcomplete-arg-quote-list is nil, pushes "\\" and moves
backward 1 char (to right before the "g") so you end up with
("gnu" "\\" "d:").

Can you check to see why this is not happening?

> (Btw, what's the purpose of using eval-when-compile here?)

To avoid calling `concat' at run-time (especially within the loop).
In older Emacsen, `concat' was marked as pure so the byte-compiler would
evaluate it at compile-time, but someone complained that it's not
strictly correct because he wanted that (concat <foo>) is not `eq' to
(concat <foo>).  I actually think this change was a mistake and would
rather mark `concat' as pure again.


        Stefan




This bug report was last modified 13 years and 76 days ago.

Previous Next


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