updated 'relativenumber' patch
Markus Heidelberg
I have adapted my relativenumber patch to Vim 7.2a, initial version was from
21.02.2008. Unfortunately it didn't get into mainline yet.
Short description:
Set the new option 'relativenumber' or 'rnu' to display relative line numbers.
With it you can just read the values for [count], that is used in very many
commands (e.g. j k + - y d c < > gq gw =), without calculating it by yourself.
This evolves the power of the count mechanism more than ever.
Markus
Richard Hartmann
<markus.h...@web.de> wrote:
> I have adapted my relativenumber patch to Vim 7.2a, initial version was from
> 21.02.2008. Unfortunately it didn't get into mainline yet.
I did not test it against 7.2a, but the feature does have its uses.
Bram, are you
willing to accept this patch? Is there something you want to see from the
community before you consider adding it?
Richard
Bram Moolenaar
Richard -
I don't know. I can see it's somewhat useful, but it's also a "yet
another option" thing.
- Bram
--
FIXME and XXX are two common keywords used to mark broken or incomplete code
not only since XXX as a sex reference would grab everbodys attention but
simply due to the fact that Vim would highlight these words.
-- Hendrik Scholz
/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///
Ag. D. Hatzimanikas
>
>
> Richard -
>
> > On Fri, Jun 27, 2008 at 01:23, Markus Heidelberg
> > <markus.h...@web.de> wrote:
> >
> > > I have adapted my relativenumber patch to Vim 7.2a, initial version
> > > was from 21.02.2008. Unfortunately it didn't get into mainline yet.
> >
> > I did not test it against 7.2a, but the feature does have its uses.
> > Bram, are you
> > willing to accept this patch? Is there something you want to see from the
> > community before you consider adding it?
>
> I don't know. I can see it's somewhat useful, but it's also a "yet
> another option" thing.
>
Besides that it looks like a useful option, (with this chance) I would
like to suggest a new project, with the simple purpose to gather or to link,
to all those patches from different sources for different purposes and
needs, that are not *yet* on the mainline or for some reasons they will
never be.
This will help:
- to redirect people when looking for a feature that is not yet
available in the mainline
- to help Bram integrate a patch, when the patch is mature or there
is a demand for it
- to be easy to contribute for a (possible) better implementation
or for a simple fix
- to have a centralized place to all those patches, to help users
extend their vim in various (sometimes unlimited) ways
I know at least (besides Markus Heidelberg's relativenumber patch):
[1] Vince Negri's Conseal patch
[2] Bill McCArthy's & Ben Schmidt's (some more math functions)
[3] Konstantin Korikov's langmapmb (very useful in multibyte locales)
[4] vimGdb
[5] vimshell
... and I am sure there might be others.
As a host I would suggest code google [6], as it has svn access, an issue
tracker and a wiki. A link to this project from the official vim site, will
be appropriate (with the usual warnings), although not strictly
necessary. A link also from the vim wiki it seems natural.
Just an idea.
1. http://vince.negri.googlepages.com/
2. http://groups.google.com/group/vim_dev/browse_thread/thread/995aa20aac6b7bd4#
3. http://lostclus.linux.kiev.ua/Other_Works/Patches?action=AttachFile&do=get&target=vim71-langmapmb-4.patch
http://tech.groups.yahoo.com/group/vim-multibyte/message/2232?l=1
4. http://clewn.sourceforge.net/
5. http://www.wana.at/vimshell/
http://www.wogri.at/pipermail/vimshell/2007-August/000648.html
6. http://code.google.com/hosting/
Regards,
Ag.
Richard Hartmann
> Besides that it looks like a useful option, (with this chance) I would
> like to suggest a new project, with the simple purpose to gather or to link,
> to all those patches from different sources for different purposes and
> needs, that are not *yet* on the mainline or for some reasons they will
> never be.
This could indeed be a useful tool. A MM series for VIM, so to speak.
I would argue that seperating the the 'they will never make it' and the
'they might make it' patchsets would make more sense, though. The
focus of the one is to be a stable VIM alternative, the other would be
a testbed of sorts.
Bram, do you think this would help you in the way you work &
accept/reject patches?
Richard
Richard Hartmann
> I don't know. I can see it's somewhat useful, but it's also a "yet
> another option" thing.
True, yet this option would not impact VIM in any meaningful way.
I.e. it is a small, granular patch that does neither introduce too
much bloat nor a likelyhood of breaking.
Richard
Richard Hartmann
be that no one is interested or lots of people are waiting for this.
Would this (voting/comment period) generally help in ways of
deciding which patches to accept?
Richard
Ben Schmidt
I too have been thinking for some time that something like this would be
useful.
I was thinking on a much smaller scale: just thinking that a 'patches'
section on Vim.org, the same but separate from the scripts section could
be good.
Of course, it would be even better if the vim.org search system worked
better as has been the subject of a fair amount of recent discussion.
Of course, I have no objection to something on a larger scale if there's
someone out there who can maintain such a thing!
Ben.
John Beckett
>> As a host I would suggest code google [6], as it has svn access,
>> an issue tracker and a wiki. A link to this project from the
>> official vim site, will be appropriate (with the usual warnings),
>> although not strictly necessary.
>
> this would be useful.
>
> I was thinking on a much smaller scale: just thinking that a
> 'patches' section on Vim.org, the same but separate from the
> scripts section could be good.
>
> Of course, it would be even better if the vim.org search
> system worked better as has been the subject of a fair amount
> of recent discussion.
>
> Of course, I have no objection to something on a larger scale
> if there's someone out there who can maintain such a thing!
Maintenance is the killer, and I will take this opportunity to whinge (to the list,
not you!).
Prior to the move of the Vim Tips from vim.org to vim.wikia.com, there was a lot of
enthusiasm for the project; around 20 people were involved in the discussion.
However, a much smaller number have provided useful assistance. While I'm grateful
to get new tips, we actually need the old tips fixed.
If anyone would like to help, please start here:
http://vim.wikia.com/wiki/Vim_Tips_Wiki:Todo
My feeling is that a collection of patches would need quite a bit of maintenance.
John
Erik Falor
Richard
Tony Mechelynck
>> I would
>> like to suggest a new project, with the simple purpose to gather or to link,
>> to all those patches from different sources for different purposes and
>> needs, that are not *yet* on the mainline or for some reasons they will
>> never be.
>>
>> This will help:
>>
>> - to redirect people when looking for a feature that is not yet
>> available in the mainline
>> - to help Bram integrate a patch, when the patch is mature or there
>> is a demand for it
>> - to be easy to contribute for a (possible) better implementation
>> or for a simple fix
>> - to have a centralized place to all those patches, to help users
>> extend their vim in various (sometimes unlimited) ways
>>
>> I know at least (besides Markus Heidelberg's relativenumber patch):
>>
>> [1] Vince Negri's Conseal patch
>> [3] Konstantin Korikov's langmapmb (very useful in multibyte locales)
>> [4] vimGdb
>> [5] vimshell
>>
>> ... and I am sure there might be others.
>>
>> As a host I would suggest code google [6], as it has svn access, an issue
>> tracker and a wiki. A link to this project from the official vim site, will
>> be appropriate (with the usual warnings), although not strictly
>> necessary. A link also from the vim wiki it seems natural.
>>
>> Just an idea.
>
> I too have been thinking for some time that something like this would be
> useful.
>
> I was thinking on a much smaller scale: just thinking that a 'patches'
> section on Vim.org, the same but separate from the scripts section could
> be good.
>
> Of course, it would be even better if the vim.org search system worked
> better as has been the subject of a fair amount of recent discussion.
>
> Of course, I have no objection to something on a larger scale if there's
> someone out there who can maintain such a thing!
>
> Ben.
The problem with patches is bit-rot. Scripts will usually remain valid,
even when unattended; patches must be cared for, or after some time they
won't apply anymore.
Best regards,
Tony.
--
"Not Hercules could have knock'd out his brains, for he had none."
-- Shakespeare
Christian MICHON
<antoine.m...@gmail.com> wrote:
> The problem with patches is bit-rot. Scripts will usually remain valid,
> even when unattended; patches must be cared for, or after some time they
> won't apply anymore.
>
you can avoid bitrotting provided you can rebase your patches with a
tracked upstream (Bram's repo).
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Bram Moolenaar
Richard Hartmann wrote:
It doesn't help me, really. It does help people who want to try out a
modified version of Vim, and it helps people who make modifications to
make their work easier to find.
One thing to keep in mind: when it's one project with many separate
patches, each with a different owner, you may run into access rights
problems. It might be better to setup a separate project for each patch
and have a central place that links to them. That also allows people to
pick a different site, if they want to. We could make this work similar
to scripts on www.vim.org.
--
hundred-and-one symptoms of being an internet addict:
124. You begin conversations with, "Who is your internet service provider?"
Markus Heidelberg
>
> On Mon, Jun 30, 2008 at 6:31 PM, Tony Mechelynck
> <antoine.m...@gmail.com> wrote:
> > The problem with patches is bit-rot. Scripts will usually remain valid,
> > even when unattended; patches must be cared for, or after some time they
> > won't apply anymore.
> >
>
> you can avoid bitrotting provided you can rebase your patches with a
> tracked upstream (Bram's repo).
It depends on the amount of changes in the patch and in upstream.
The relativenumber stuff for example didn't cost many maintenance effort.
Between 7.1.258 (initial patch) and 7.1.330 every change did merge
automatically, also a backport to 7.1.0 worked without intervention. The patch
from 7.1.258 still applies to 7.1.330 with some "Hunk succeeded" messages. Just
the transition to 7.2a led to conflicts in some runtime files.
Markus
Markus Heidelberg
>
> On Sun, Jun 29, 2008 at 17:02, Ag. D. Hatzimanikas <a.ha...@gmail.com> wrote:
>
> > Besides that it looks like a useful option, (with this chance) I would
> > like to suggest a new project, with the simple purpose to gather or to link,
> > to all those patches from different sources for different purposes and
> > needs, that are not *yet* on the mainline or for some reasons they will
> > never be.
>
> This could indeed be a useful tool. A MM series for VIM, so to speak.
> I would argue that seperating the the 'they will never make it' and the
> 'they might make it' patchsets would make more sense, though. The
> focus of the one is to be a stable VIM alternative, the other would be
> a testbed of sorts.
I also was immediately reminded on the recently started linux-staging tree for
drivers and similar stuff for the Linux kernel in patch form.
See http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=summary
I don't know what's the status of the Vim patches that Ag. listed, but at least
some web pages seem to be a bit outdated. Perhaps the death of those patches
can be avoided with a Vim Patches Project!? Of course there need to be
maintainer people.
Without thinking any further, I got the idea of a "master patch", which helps
in integrating the other patches into the source tree. After applying the
master patch, you are able to select different patches for automatic
downloading, applying, unapplying, ...
Markus