The list on vim-patches page
Suresh Govindachar
Hello,
It would help if the items listed on the "vim-patches" page mentioned any restrictions on OS
http://groups.google.com/group/vim_dev/web/vim-patches
Thanks,
--Suresh
Tony Mechelynck
"Using Vim as editor within MS Visual Studio" is useless without MS
Visual Studio (which I suppose means MS-Windows) while vimGDB means yu
debug with gdb (and probably compile with gcc) which can mean either a
Unix-like installation (including, I presume, Mac OS X), or MinGW or
maybe Cygwin on a W32 system. Similarly, "Console cygwin Vim using W32
clipboard" is quite obviously for one particular platform only.
Apart from the three above-mentioned patches, I expect that the other
ones on that page are probably OS-agnostic (but I could be wrong). If
there are any more restrictions, I agree that the patch descriptions
ought to mention them.
Best regards,
Tony.
--
[From an announcement of a congress of the International Ontopsychology
Association, in Rome]:
The Ontopsychological school, availing itself of new research criteria
and of a new telematic epistemology, maintains that social modes do not
spring from dialectics of territory or of class, or of consumer goods,
or of means of power, but rather from dynamic latencies capillarized in
millions of individuals in system functions which, once they have
reached the event maturation, burst forth in catastrophic phenomenology
engaging a suitable stereotype protagonist or duty marionette (general,
president, political party, etc.) to consummate the act of social
schizophrenia in mass genocide.
Suresh Govindachar
Around Sunday, December 13, 2009 2:53 PM, Tony Mechelynck wrote:
> On 13/12/09 23:07, Suresh Govindachar wrote:
>>
>> Hello,
>>
>> It would help if the items listed on the "vim-patches" page
>> mentioned any restrictions on OS
>> http://groups.google.com/group/vim_dev/web/vim-patches
>>
>> Thanks,
>>
>> --Suresh
>>
>
> It would, though in some cases it's quite obvious from the
> description:
>
> "Using Vim as editor within MS Visual Studio" is useless without
> MS Visual Studio (which I suppose means MS-Windows) while vimGDB
> means yu debug with gdb (and probably compile with gcc) which
> can mean either a Unix-like installation (including, I presume,
> Mac OS X), or MinGW or maybe Cygwin on a W32 system. Similarly,
> "Console cygwin Vim using W32 clipboard" is quite obviously for
> one particular platform only.
>
> Apart from the three above-mentioned patches, I expect that the
> other ones on that page are probably OS-agnostic (but I could be
> wrong). If there are any more restrictions, I agree that the
> patch descriptions ought to mention them.
time, it was only for true unix systems (not mingw, not cygwin,
/perhaps/ not even for "unix within windows via virtual-wares
such as VMWare"). Has this changed?
--Suresh
Xavier de Gaye
>
> vimGDB is the specific one I am not sure about -- for a long
> time, it was only for true unix systems (not mingw, not cygwin,
> /perhaps/ not even for "unix within windows via virtual-wares
> such as VMWare"). Has this changed?
>
The "vim-patches" page includes a pointer to clewn web site for
vimgdb. The clewn web site refers to the pyclewn web site where a
table lists the differences between vimgdb, clewn and pyclewn and
provides the information you are missing: vimgdb runs on unix.
Xavier
Tom Link
included in vim? Since some of these patches were written for older
versions of vim, there is a danger that they won't be applicable to
future versions of vim. But unless they aren't included in the next
beta version, they probably will never be tested by a sufficiently
large number of users.
One reason I ask is because of patch 15 "Correctly indent wrapped
lines". I sometimes have to work with an unpatched version of vim and
I really miss the options provided by that patch. I know of the
reports that other people had problems with that patch when applied to
the vim sources that includes all recent patches. It works perfectly
well with my version though and I wasn't able to reproduce those
problems.
Regard,
Tom
Charles Campbell
>> It would help if the items listed on the "vim-patches" page mentioned any restrictions on OShttp://groups.google.com/group/vim_dev/web/vim-patches
>>
>
> BTW what is the procedure to determine whether these patches are ever
> included in vim?
into the vim source. He has some voting going on for different features
if you contribute to the Kibaale Children's Centre charity.
> versions of vim, there is a danger that they won't be applicable to
> future versions of vim. But unless they aren't included in the next
> beta version, they probably will never be tested by a sufficiently
> large number of users.
>
accommodate new versions of vim, as an example of this difficulty.
Presumably others could update some patch they're interested in and make
that update available as yet-another-patch. This process could end up
making a mess on vim-patches, though.
Regards,
Chip Campbell
Tom Link
> into the vim source.
some problems with it and that he waited for a new version that solves
these issues. These problems were reported by the author of the patch,
which IIRC was originally written for version 7.0. Back then, this
sounded reasonable to me because I've seen those very same error
messages the author has reported. But I've seen those messages also
with an unpatched version of vim and I haven't got one of those
messages after some "regular" patch to the 7.0 source base. Ever since
the patch has worked flawlessly for me and I personally don't think
it's totally out of question (but that's just a personal theory/
hypothesis) that those error messages where a problem of a vanilla vim
7.0 rather than a problem of the patch.
Anyway, there seems to be no way to report success/failures with
certain patches in a systematic manner that would allow Bram to get an
adequate overview of how many people use a certain patch with which
version (incl patch level) of vim and how many of those people
experience problems that can be reproduced so that we know for sure
that the problem is actually caused by the patch etc. Otherwise the
patch authors (I didn't contribute a patch so this is just another
"personal theory") probably get frustrated, they abandon vim, they
stop maintaining their patches with the consequence that their patches
are likely to quickly become unusable since the development of vim
continues.
Regards,
Tom
Christian Brabandt
> Anyway, there seems to be no way to report success/failures with
> certain patches in a systematic manner that would allow Bram to get an
> adequate overview of how many people use a certain patch with which
> version (incl patch level) of vim and how many of those people
> experience problems that can be reproduced so that we know for sure
> that the problem is actually caused by the patch etc. Otherwise the
> patch authors (I didn't contribute a patch so this is just another
> "personal theory") probably get frustrated, they abandon vim, they
> stop maintaining their patches with the consequence that their patches
> are likely to quickly become unusable since the development of vim
> continues.
I think it could help, if those working patches from the vim_extended
repository could be distributed as a precompiled alpha/testing release
of vim. I am sure, this would increase the user base.
I must admit, I haven't tested any of the patches from that repository
since I am afraid of having to take care of updating myself and since I
work on many different systems, it's hard to get it done everywhere. But
I think there are many exciting new features, which I'd like to test.
So could it be possible to provide a 7.3 testing release which
integrates these patches? I would certainly use that release and give
feedback. Of course there needs to be a possibility to give feedback to
the patch authors/maintainers as well. Maybe the linux distributions
could also provide a vim-patched package (similar to how it is done with
mutt-patched).
James, what do you think, could that be possible for Debian?
regards,
Christian
--
:wq
Tony Mechelynck
[...]
> Anyway, there seems to be no way to report success/failures with
> certain patches in a systematic manner that would allow Bram to get an
> adequate overview of how many people use a certain patch with which
> version (incl patch level) of vim and how many of those people
> experience problems that can be reproduced so that we know for sure
> that the problem is actually caused by the patch etc. Otherwise the
> patch authors (I didn't contribute a patch so this is just another
> "personal theory") probably get frustrated, they abandon vim, they
> stop maintaining their patches with the consequence that their patches
> are likely to quickly become unusable since the development of vim
> continues.
>
> Regards,
> Tom
>
OK, so let's add a user's report.
The only patch I use from that vim-dev list of semi-official patches is
Bill McCarthy's "extra float functions" patch. I've been using it
constantly in Huge Vim builds with GTK2/Gnome2 GUI ever since it was
published (which was more than a year ago) and I've had exactly zero
problems with it in all that time. Of course patches to eval.c apply
with a line-offset but that's strictly all. I believe it would be a
valuable addition to Vim (versions with +float, of course -- all this
patch's code is bracketed by #ifdef FEAT_FLOAT). This patch integrates
so "naturally" with Vim that when I use a float function in an :echo
statement (usually :echo printf(...)) at the command-line, I don't know
(unless I look into the help, of course) whether it's from Bill's set of
float functions, or from Bram's.
Also, if anyone has had any problems at all with this float-functions
patch, I haven't noticed any mention of it on the list.
P.S. Bill: a missing #ifdef FEAT_FLOAT around the lines concerning tan()
and tanh() at line 7807-after of eval.c 7.2.350 (line 7664-before /
7690-after at the time the patch was written) seems to imply that this
patch wouldn't compile in a build with +eval but -float. I don't see the
problem since "my" builds are either Huge (+eval +float) or Tiny (-eval).
It may seem weird to include a "floating-point patch" in a build
compiled with -float but one might want to compile several
differently-configured versions out of the same sources -- as I do but
not in a way to be hurt.
Best regards,
Tony.
--
Dear Lord, observe this bended knee
This visage meek and humble,
And hear this confidential plea
Voiced in reverent mumble:
Give me Shylock, give me Fagin
But O God spare me Ronald Reagan!
-- Ansel Adams