New plugin for diff-files

2008-09-29 Fir de Conversatie Philipp Marek
Hello everybody,


I have a plugin for (unified) diff files that I think might be of interest to 
other people, too.

If you put the attached file as 
/usr/share/vim/vimcurrent/plugin/diff.vim
you can press CR at the @@ -x,x +x,x @@ lines in a diff
to jump to that chunk in the file.

That's very nice if you're doing things like
:!svn diff  /tmp/a.patch
:e /tmp/a.patch
to review your changes before committing.


I hope that it finds some interest; feedback is welcome, of course.


Regards,

Phil

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

 Plugin to allow pressing CR on the line number information lines
 ( @@ -xx,xx +xx,xx @@ ) in unified diffs, to jump to that position in that
 file.


noremap silent buffer cr :call DiffJump()CR

function! DiffJump()
	let line=getline(.)
	if line =~ '^@@ -\d\+,\d\+ +\d\+,\d\+ @@'
		 Maybe allow to go to the old line?
		let dest=matchstr(line, '+\d\+')
		let filename_linenumber=search('^+++ ', bnW)
		 With the given pattern the filename always starts in byte 5.
		let t1=strpart(getline(filename_linenumber), 4)
		 Remove tab and all behind.
		let file=substitute(t1, '\t.*$', '', '')
		exe edit  . dest .   . file
	else
		echo Line doesn't include line numbers
	endif
endfunction



Re: improving character diff

2008-09-29 Fir de Conversatie Milan Vancura

Hello,

 If you think about it, you find that it is very difficult to define what
 changed means.  Diff normally has delete, insert and change operators.
 Applying that to a line of characters you can make a change in an
 unlimited number of ways.  Some define the optimal way to be the one
 that has the lowest number of operators, but that often leads to a weird
 display.  E.g., when comparing one two three four with one three two
 four, what should be highlighted?  Perhaps wo three and hree two,
 because that's the changed part of the text.  Or two in both lines, as
 it's deleted and inserted.  Or delete wo t and insert hree t?

What is the difference between char-diff of two lines and normal diff of two
files having one char at each line? A simple script doing :s/./^M/g ,
comparing the results and highlighting original lines according to that result
can do the work.

However, I think the base of the problem is elsewhere: you can do the described
comparison only if you can match exacly each line of file 1 to some line of
file 2 (1:1 mapping). If not (for example three lines in file 1 replaced by
seven lines in file 2), how can you tell which line should be compared with
which?

So, in general, this is 2D problem and can't be solved 100%. But this idea of
char-diff can be useful in cases where the amount of changed lines are same in
both actually compared hunks. And I must say I would like it very much in that
cases (comparing various config files etc.).

Milan
--
Milan Vancura, Prague, Czech Republic, Europe

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: CursorHold continually fires if it calls system()

2008-09-29 Fir de Conversatie Teemu Likonen

Richard Hartmann wrote (2008-09-27 00:46 +0200):

 Confirmed this behaviour for
 
 
 VIM - Vi IMproved 7.1 (2007 May 12, compiled Jun 24 2008 14:20:15)
 Included patches: 1-314

Strange because I'm not able to reproduce the bug with my Vim 7.1.314 
(Debian Etch backports) nor with 7.2.10 (Debian Sid).

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



BUG: Unicode characters in commands

2008-09-29 Fir de Conversatie Matt Wozniski
On Sun, Sep 28, 2008 at 4:35 PM, Tony Mechelynck wrote:

 On Sun, Sep 28, 2008 at 9:40 AM, John Hughes wrote:
 I am trying to write a command that substitutes some Ascii characters
 with a Unicode character. The following substitution works when
 entered directly:

 :%s/\.\.\./…/eg

 However, when defined as a command, it does not work:

 :com Ellipsis %s/\.\.\./…/eg

 The command :Ellipsis converts

 ...

 into

 â80feX¦

 Why is this? Is there any way of using Unicode characters in
 substitute commands?

 I'm using gvim 7.2.21, huge build with Gnome2 GUI and 'encoding' set to
 UTF-8. Just like the OP, I see the following:

 - Typing the :s command at the command-line works OK.
 - Defining that :s command as a user-command text, then running that
 user command, replaces every set of three dots by â80feX¦ (5
 characters including two invalid UTF-8 sequences, 7 bytes viz. C3 A2 80
 FE 58 C2 A6).
 - Recalling that command definition with :command Ellipsis displays
 the ellipsis character as an ellipsis.
 - The ellipsis is U+2026, in UTF-8 0xE2 0x80 0xA6. Notice that 80 and A6
 appear (though not consecutively) as part of the replace-text actually
 used, and that E2 is C3 A2 which also appears. This makes me suspect
 that Vim is applying a spurious Latin1-to-UTF8 conversion to what is
 already UTF-8 (with something wrong, maybe buffer-overflow, happening in
 the middle). Another possibility would be using a character length
 instead of a byte length, or vice-versa, at some point in the
 user-command execution.

I can confirm this.  It looks to me like it's not a spurious
Latin1-UTF8 conversion, but an internally-escaped string that's not
un-escaped before being used.  Sourcediving, it seems that
mb_unescape() is called to escape any multibyte characters when
displaying the command, but that mb_unescape() is never called before
the command is passed to do_cmdline() to be executed.  That seems to
explain why it's displayed properly but executed incorrectly.  I don't
completely follow all of the string escaping being done here, though,
so Bram knows for sure.  I've cross-posted to the vim-dev list
accordingly.

~Matt

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



Re: BUG: Unicode characters in commands

2008-09-29 Fir de Conversatie Bram Moolenaar


Matt Wozniski wrote:

 On Sun, Sep 28, 2008 at 4:35 PM, Tony Mechelynck wrote:
 
  On Sun, Sep 28, 2008 at 9:40 AM, John Hughes wrote:
  I am trying to write a command that substitutes some Ascii characters
  with a Unicode character. The following substitution works when
  entered directly:
 
  :%s/\.\.\./…/eg
 
  However, when defined as a command, it does not work:
 
  :com Ellipsis %s/\.\.\./…/eg
 
  The command :Ellipsis converts
 
  ...
 
  into
 
  â80feX¦
 
  Why is this? Is there any way of using Unicode characters in
  substitute commands?
 
  I'm using gvim 7.2.21, huge build with Gnome2 GUI and 'encoding' set to
  UTF-8. Just like the OP, I see the following:
 
  - Typing the :s command at the command-line works OK.
  - Defining that :s command as a user-command text, then running that
  user command, replaces every set of three dots by â80feX¦ (5
  characters including two invalid UTF-8 sequences, 7 bytes viz. C3 A2 80
  FE 58 C2 A6).
  - Recalling that command definition with :command Ellipsis displays
  the ellipsis character as an ellipsis.
  - The ellipsis is U+2026, in UTF-8 0xE2 0x80 0xA6. Notice that 80 and A6
  appear (though not consecutively) as part of the replace-text actually
  used, and that E2 is C3 A2 which also appears. This makes me suspect
  that Vim is applying a spurious Latin1-to-UTF8 conversion to what is
  already UTF-8 (with something wrong, maybe buffer-overflow, happening in
  the middle). Another possibility would be using a character length
  instead of a byte length, or vice-versa, at some point in the
  user-command execution.
 
 I can confirm this.  It looks to me like it's not a spurious
 Latin1-UTF8 conversion, but an internally-escaped string that's not
 un-escaped before being used.  Sourcediving, it seems that
 mb_unescape() is called to escape any multibyte characters when
 displaying the command, but that mb_unescape() is never called before
 the command is passed to do_cmdline() to be executed.  That seems to
 explain why it's displayed properly but executed incorrectly.  I don't
 completely follow all of the string escaping being done here, though,
 so Bram knows for sure.  I've cross-posted to the vim-dev list
 accordingly.

I'll add it to the todo list.  Don't expect a solution soon...

-- 
hundred-and-one symptoms of being an internet addict:
116. You are living with your boyfriend who networks your respective
 computers so you can sit in separate rooms and email each other

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---