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

[Stefan Monnier]

> 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