bug#10827: 24.0.93; M-RET behaviour with M-x diff-buffer-with-file RET

bug#10827: 24.0.93; M-RET behaviour with M-x diff-buffer-with-file RET

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]


1. Make some modification to a file and don't save it.  
2. Do M-x diff-buffer-with-file RET. 
3. Pick a modified line and press M-RET. 
4. Now the user is prompted for a file. 
5. Pressing RET "blindly" here doesn't do anything useful. Instead the
   user is prompted with a bunch of completions. Also there is this
   "#<buffer " that is offered which sticks out like sore thumb.

My question is when the "parent" buffer (from which the diff was
produced) why do I need to go through steps 4 and 5 above? Btw, steps 4
and 5 are very fuzzy and have to be made user-friendly.

I am attaching a screen shot at step 4 above.


[-- Attachment #2: diff-buffer-with-file+M-RET.PNG --]
[-- Type: image/png, Size: 36525 bytes --]

[-- Attachment #3: Type: text/plain, Size: 614 bytes --]




In GNU Emacs 24.0.93.1 (i386-mingw-nt5.1.2600)
 of 2012-01-30 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --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 --ldflags
 -LD:/devel/emacs/libs/gnutls-3.0.9/lib'

bug#10827: 24.0.93; M-RET behaviour with M-x diff-buffer-with-file RET

[Stefan Monnier]

> 1. Make some modification to a file and don't save it.  
> 2. Do M-x diff-buffer-with-file RET.
> 3. Pick a modified line and press M-RET.
> 4. Now the user is prompted for a file.

When I try it, Emacs just jumps to the corresponding line in the
original buffer without prompting the user for a file name.
Could the problem be triggered by some particular customization
of yours?  (I.e. try to reproduce it with "emacs -Q" and if the problem
doesn't appear there, try to figure out which part of your config
triggers the problem).


        Stefan

bug#10827: 24.0.93; M-RET behaviour with M-x diff-buffer-with-file RET

[Jambunathan K]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 1. Make some modification to a file and don't save it.  
>> 2. Do M-x diff-buffer-with-file RET.
>> 3. Pick a modified line and press M-RET.
>> 4. Now the user is prompted for a file.
>
> When I try it, Emacs just jumps to the corresponding line in the
> original buffer without prompting the user for a file name.
> Could the problem be triggered by some particular customization
> of yours?  (I.e. try to reproduce it with "emacs -Q" and if the problem
> doesn't appear there, try to figure out which part of your config
> triggers the problem).

I am on Windows + Cygwin. The immediate problem seems to be that
`diff-hunk-file-names' assumes that file names have no spaces.

If I (blindly) modify the following regexp in `diff-hunk-file-names'

--8<---------------cut here---------------start------------->8---
"[-*][-*][-*] \\(\\S-+\\)\\(\\s-.*\\)?\n[-+][-+][-+] \\(\\S-+\\)"
--8<---------------cut here---------------end--------------->8---

to 

--8<---------------cut here---------------start------------->8---
"[-*][-*][-*] \\(.+\\)\\(\\s-.*\\)?\n[-+][-+][-+] \\(.+\\)"
              ^^^^^^^^                            ^^^^^^^^^ 
--8<---------------cut here---------------end--------------->8---

I get the right behaviour.

Down below is a *Diff* buffer that I get with `diff-buffer-with-file'.

With re-builder, you can see that the first regexp fails to "collect"
the files correctly.  The regexp (incorrectly) matches only part of the
filename/buffer name and not the whole name.

I also have my doubts regarding the correctness of another regexp
towards the end of `diff-hunk-file-names' which looks like this.

--8<---------------cut here---------------start------------->8---
"^diff \\(-\\S-+ +\\)*\\(\\S-+\\)\\( +\\(\\S-+\\)\\)?"
--8<---------------cut here---------------end--------------->8---

In summary, review the regexps in lisp/vc/diff-mode.el so that they do
the right thing on Windows where filenames can have spaces.

--8<---------------cut here---------------start------------->8---
diff -pub -L c\:/Documents\ and\ Settings/kjambunathan/My\ Documents/My\ Data/devel/devel-notes.org -L \#\<buffer\ devel-notes.org\> c\:/Documents\ and\ Settings/kjambunathan/My\ Documents/My\ Data/devel/devel-notes.org c\:/Documents\ and\ Settings/kjambunathan/My\ Documents/My\ Data/tmp/buffer-content-3804sEa
--- c:/Documents and Settings/kjambunathan/My Documents/My Data/devel/devel-notes.org
+++ #<buffer devel-notes.org>
@@ -4,6 +4,7 @@
 
 
 
+
 http://cygwin.com/ml/cygwin/2006-05/msg00756.html
 
 # texi to pdf conversion using miktex

Diff finished.  Thu Mar 22 20:04:55 2012

--8<---------------cut here---------------end--------------->8---

bug#10827: 24.0.93; M-RET behaviour with M-x diff-buffer-with-file RET

[Achim Gratz]

Am 22.03.2012 16:10, schrieb Jambunathan K:
> I am on Windows + Cygwin. The immediate problem seems to be that
> `diff-hunk-file-names' assumes that file names have no spaces.

You seem to be using an NT version of Emacs in conjunction with Cygwin. 
  While that does to some extent work (I'm doing that myself sometimes), 
it isn't a supported combination as the filename quoting rules on either 
side are completely different.  It is much easier to run Emacs from 
Cygwin instead and have _all_ of it work than trying to troubleshoot 
each missed path conversion or botched quoting.

-- 
Achim.

(on the road :-)

bug#10827: 24.0.93; M-RET behaviour with M-x diff-buffer-with-file RET

[Stefan Monnier]

>> I am on Windows + Cygwin. The immediate problem seems to be that
>> `diff-hunk-file-names' assumes that file names have no spaces.

> You seem to be using an NT version of Emacs in conjunction with
> Cygwin. While that does to some extent work (I'm doing that myself
> sometimes), it isn't a supported combination as the filename quoting rules
> on either side are completely different.  It is much easier to run Emacs
> from Cygwin instead and have _all_ of it work than trying to troubleshoot
> each missed path conversion or botched quoting.

While that is generally true, I don't think that will help him fix the
problem, because the problem is a limitation of Emacs's Elisp code.


        Stefan

bug#10827: 24.0.93; M-RET behaviour with M-x diff-buffer-with-file RET

[Achim Gratz]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> While that is generally true, I don't think that will help him fix the
> problem, because the problem is a limitation of Emacs's Elisp code.

I was indeed not commenting on the reported bug (which I cannot
currently test), but on the fact that sending Windows paths/filenames to
Cygwin and trying to make sense of the paths/filenames you get back from
a Cygwin application (in all likelyhood converted to a POSIX path) is
asking for trouble further down the road.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

bug#10827: 24.0.93; M-RET behaviour with M-x diff-buffer-with-file RET

[Jambunathan K]

OP here. Closed.