Small nit in the manual

Hi, people.  Would you check if the following diff is appropriate?  I
guess that the manual says the contrary of what is meant.  This is for
Vim 6.2.

--- develop.txt.bak	2004-01-01 20:24:16.000000000 -0500
+++ develop.txt	2004-01-01 20:25:11.000000000 -0500
 <at>  <at>  -341,7 +341,7  <at>  <at> 
 have one window that shows the text with function bodies folded, another
 window that shows a function body.

-Folding is a way to display the text.  It should change the text itself.
+Folding is a way to display the text.  It should not change the text itself.
 Therefore the folding has been implemented as a filter between the text stored
 in a buffer (buffer lines) and the text displayed in a window (logical lines).

--

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Small nit in the manual

On Thu, Jan 01, 2004 at 09:06:25PM -0500, François Pinard wrote:
> Hi, people.  Would you check if the following diff is appropriate?  I
> guess that the manual says the contrary of what is meant.  This is for
> Vim 6.2.
> 
> 
> --- develop.txt.bak	2004-01-01 20:24:16.000000000 -0500
> +++ develop.txt	2004-01-01 20:25:11.000000000 -0500
>  <at>  <at>  -341,7 +341,7  <at>  <at> 
>  have one window that shows the text with function bodies folded, another
>  window that shows a function body.
>  
> -Folding is a way to display the text.  It should change the text itself.
> +Folding is a way to display the text.  It should not change the text itself.
>  Therefore the folding has been implemented as a filter between the text stored
>  in a buffer (buffer lines) and the text displayed in a window (logical lines).

     I agree with the content of your change.  As for format, I prefer
to use the same one as the official patches:  context-style diffs (diff
-c) generated from the top-level distribution directory.  Something like
this for a single file:

$ cd .../vim62
$ diff -c runtime/doc/develop.txt.bak runtime/doc/develop.txt > develop.txt.diff

HTH					--Benji Fisher

Re: Small nit in the manual

[Benji Fisher]

> I agree with the content of your change.  As for format, I prefer to
> use the same one as the official patches: context-style diffs (diff
> -c) generated from the top-level distribution directory.  Something
> like this for a single file:

This is annoying...  Some maintainers like context diffs and hate
unidiffs, other maintainers just want the contrary.  I find it difficult
to remember, for every tool I use, what are the little whims of each
maintainer.  They all try to educate me into their particular habits.

Plain diffs, I would understand.  But context diffs or unidiffs are
fully equivalent, and moreover, there are tools converting between
both, which maintainers should silently use for themselves.  (I think I
even have one somewhere in my distributions, contributed long ago by an
employee from Borland.  There are others floating around, as well.)

Times have changed.  Not so long ago, I would have written a very simple
message directly to the maintainer that a "not" word was missing,
quoting the document and the sentence, and this would have fully
sufficient, and plain welcome.  In this case, I ought to make the effort
of prematurely subscribing to the `vim-dev' mailing list (working my
way around a slightly broken robot, but this is another matter), and
producing a diff for this tiny nit, well aware that a diff is likely
overkill: a simple and quick Vim session is probably much more efficient
than `patch' in this case.  You scrutinise diffs anyway, don't you! 
I spent nearly an hour for a single word, and you're still not happy?

On the other hand, it could have been much worse, and you might have

Re: Small nit in the manual

From: François Pinard, Thu Jan  1 23:01:36 2004
> [Benji Fisher]
> >
> > I agree with the content of your change. As for format, I prefer
> > to use the same one as the official patches: context-style diffs
> > (diff -c) generated from the top-level distribution directory.
> > Something like this for a single file:
>
> This is annoying...

[lengthy diff rant snipped]

> I spent nearly an hour for a single word, and you're still not
> happy?

I just spent a half an hour reading your rant trying to understand why
you wasted so much bandwidth against comments that were instructional,
supplied with an example, and straight out of the documentation:

  :help style-changes (from development.txt)

>                                   Keep happy!

Please.

--

-- 
Steve Hall  [ digitect <at> mindspring.com ]

Re: Small nit in the manual

On Thu, Jan 01, 2004 at 11:33:25PM -0500, Steve Hall wrote:

> > I spent nearly an hour for a single word, and you're still not
> > happy?
> 
> I just spent a half an hour reading your rant trying to understand why
> you wasted so much bandwidth against comments that were instructional,
> supplied with an example, and straight out of the documentation:

As far as my brief little search told me, every diff that has been
posted to this list in the past few months, except for Bram's is a 'diff
-u' diff, not a 'diff -c'.  I believe Bram uses '-c' for compability
with older versions of diffs.  Bram's patches go to many people.  Diffs
that come in only have to work with Bram's version of patch, which I'm
guessing is perfectly capable of handling '-u' diffs.

I find it odd that complaints were made against one particular diff when
it matches most others that are submitted to this list.

Dave

Re: Small nit in the manual

François Pinard wrote:

> Hi, people.  Would you check if the following diff is appropriate?  I
> guess that the manual says the contrary of what is meant.  This is for
> Vim 6.2.

Right, thanks for the correction.

Sending me unified diffs is fine, but a few people with older systems
can't handle them.

--

-- 
Support your right to bare arms!  Wear short sleeves!

 /// Bram Moolenaar -- Bram <at> Moolenaar.net -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

Re: Small nit in the manual

> On Thu, Jan 01, 2004 at 09:06:25PM -0500, François Pinard wrote:
> > Hi, people.  Would you check if the following diff is appropriate?  I
[snip]

On Thu, Jan 01, 2004 at 10:20:33PM -0500, François Pinard wrote:
> [Benji Fisher]
> 
> > I agree with the content of your change.  As for format, I prefer to
> > use the same one as the official patches: context-style diffs (diff
> > -c) generated from the top-level distribution directory.  Something
> > like this for a single file:
> 
> This is annoying...  Some maintainers like context diffs and hate
> unidiffs, other maintainers just want the contrary.  I find it difficult
> to remember, for every tool I use, what are the little whims of each
> maintainer.  They all try to educate me into their particular habits.

     I am sorry.  I interpreted the first line quoted above as asking
for advice on the format as well as the content of the diff.

> Plain diffs, I would understand.  But context diffs or unidiffs are
> fully equivalent, and moreover, there are tools converting between
> both, which maintainers should silently use for themselves.  (I think I
> even have one somewhere in my distributions, contributed long ago by an
> employee from Borland.  There are others floating around, as well.)

     I think the main reason for preferring context diffs is that some
versions of patch cannot deal with the unified format.  Perhaps I should
have stressed that this is a preference, not a requirement:  most
readers of this list can deal with either type, but context diffs are

strange behavior with first [d

     Can anyone confirm this?  I make a little TeX file with

\def\a{aardvark}

\a

and then position the cursor on the last line.  The default
ftplugin/tex.vim sets the 'define' option to recognize the macro
definition, so I try "[d" (starting in Normal mode, without the quotes)
on the last line.  I get Error E388 (couldn't find definition).  I try
"[d" again, and it works fine.

     Same result starting with "vim -u NONE" after

:set nocp
:so $VIMRUNTIME/ftplugin/tex.vim

     At first, I could not reproduce the problem with ft=c but now I
can:

#define MAX 17

MAX

If I move the cursor, then "[d" works on the last line.  For example,
if I cut and paste, ending on the first line, then move to the last
line, there is no problem.  If I just move to the start of the last line
and back again, I do see the problem.  It is a nuisance to reproduce,
since it only happens the first time I try "[d" in a session...  Also,
if I use a realistic line, like "a = MAX;", then it works.

Bugreport

Hello,

A Happy new Year to you all. I got a little bugreport which looks like
this (attachment). I was able to solve this by commenting some lines
within the code. Would be cool to have that fixed. System Linux, XFree86
4.4.0 RC2, Lunix 2.6.0 :)

Starting make in the src directory.
If there are problems, cd to the src directory and run make there
cd src && make first
make[1]: Entering directory `/tmp/vim62/src'
gcc -c -I. -Iproto -DHAVE_CONFIG_H     -g -O2  -I/usr/X11R6/include       -o objects/buffer.o buffer.c
In file included from /usr/X11R6/include/X11/Intrinsic.h:56,
                 from structs.h:76,
                 from vim.h:1351,
                 from buffer.c:29:
/usr/X11R6/include/X11/Xlib.h:103: error: conflicting types for `_Xmblen'
auto/osdef.h:124: error: previous declaration of `_Xmblen'
make[1]: *** [objects/buffer.o] Error 1
make[1]: Leaving directory `/tmp/vim62/src'
make: *** [first] Error 2

Re: Bugreport

Ali Akcaagac wrote:
> 
> A Happy new Year to you all. I got a little bugreport which looks like
> this (attachment). I was able to solve this by commenting some lines
> within the code. Would be cool to have that fixed. System Linux, XFree86
> 4.4.0 RC2, Lunix 2.6.0 :)
> 
> /usr/X11R6/include/X11/Xlib.h:103: error: conflicting types for `_Xmblen'
> auto/osdef.h:124: error: previous declaration of `_Xmblen'

Looks like you need the (very) recently released 6.2.169 patch which 
should solve this very problem.

ftp://ftp.vim.org/pub/vim/patches/6.2.169

Dan Sharp