This is exactly one of the reasons people are calling for a proper issue
tracker on BitBucket or similar. I remember reading one dismissive and
three favourable reactions to this idea either on vim_dev or on vim_use.
On an issue tracker these would have been impossible to overlook.
I proposed this originally but I'm still undecided. I think it would be
good to hear a few more voices.
In my opinion this is the best solution I have heard. It preserves the functionality of what people on both sides of the issue want without adding additional options.
I think it actually makes the numbering options in question a little *more* intuitive: I recall that I was confused when I started using vim because I was not expecting setting nu to also unset rnu and vice versa. I guess I was expecting to see both relative numbers and absolute numbers if both were set to true, even though it is unlikely I would ever want it that way. So to me having both options set to true result in a hybrid numbering scheme that includes the current absolute number and the other numbers as relative makes sense.
I believe this is what Christian's patch does, so count me as a fan. Sorry I didn't speak up in support earlier.
On Jun 3, 2013 1:09 AM, "Bram Moolenaar" <Br...@moolenaar.net> wrote:
>
>
> Glts wrote:
>
> > On Sunday, June 2, 2013 9:30:20 PM UTC+2, Bram Moolenaar wrote:
> > > Christian Brabandt wrote:
> > >
> > > > Note, that latest patch I sent, does not require an extra option, is
> > > > rather small, makes the code much more readable (imho) and we can even
> > > > get rid of test89.
> > >
> > > You mean the patch you sent on May 30?
> > > I don't see anybody responding that they like that solution.
> >
> > This is exactly one of the reasons people are calling for a proper issue
> > tracker on BitBucket or similar. I remember reading one dismissive and
> > three favourable reactions to this idea either on vim_dev or on vim_use.
> > On an issue tracker these would have been impossible to overlook.
> >
> > I proposed this originally but I'm still undecided. I think it would be
> > good to hear a few more voices.
>
> There already is an issue tracker.
I can hardly call what Google code has an issue tracker. It lacks basic functionality. It does not even support formatting and attachments, not to mention more advanced things like components. Or such a thing like finely looking UI. It is not surprising most people do not want to use it.
And there are no PR's here. Other issue tracker problems are tolerable, absence of PR's and attachments makes it impossible to hold patches there making it useless when it comes to resolving the mentioned problem.
> --
> hundred-and-one symptoms of being an internet addict:
> 54. You start tilting your head sideways to smile. :-)
>
> /// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
> /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
I think he is referring to a "pull request", so that somebody can fix an issue in a clone of the repository, and request that you pull in and merge the changes.
I didn't get the impression that was something you'd want to do anyway.
But maybe you'd start accepting Hg "bundle"s? Then there would be no doubt where the changes were based on and less bitrot compared to a patch (though a merge or rebase will be needed).
>
> I don't think that the functionality of the Issue Tracker is relevant.
>
> What matters is that the discussions happen on the vim-dev maillist,
>
> that's where the developers are. I don't see that changing no matter
>
> how beautiful or functional any issue tracker would be.
>
>
GitHub's issue tracker is very pretty and has a lot of features. I haven't used BitBucket, I imagine it is similar. Google Code is not as nice, but it's certainly not the worst I've seen. And if you don't plan to use a feature, I don't think it's relevant whether it's there or not.
>
> For me, the main issue with Issue trackers is that I can't edit them
>
> with Vim. Switching to a browser and having to click around slows down
>
> my work. That's why I use the todo list.
>
One problem with the todo list, is that it is not up-to-date until you publish runtime files periodically. So sometimes it is hard to tell whether you noticed a patch or fixed a bug in a later version. And, once a bug goes away from the TODO list, nobody can find it later to see that it was an issue but has been fixed (and when).
On Mon, Jun 3, 2013 at 10:42 AM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>
> Ben Fritz wrote:
>
>> One problem with the todo list, is that it is not up-to-date until you
>> publish runtime files periodically. So sometimes it is hard to tell
>> whether you noticed a patch or fixed a bug in a later version. And,
>> once a bug goes away from the TODO list, nobody can find it later to
>> see that it was an issue but has been fixed (and when).
>
> Keeping the TODO list up-to-date is less work than updating stuff on
> some website. Whatever issue tracker there is, it's not going to make
> MY work more efficient. And since I'm the bottleneck that's what
> matters.
>
I assume you keep the todo list up-to-date as you work, but you just
don't commit/push it until you have other runtime file updates to
push. Do you think you could commit/push the TODO list alongside the
patch (or patch series) when you apply it? That might help to some
extent. Looking at the patches README can help figure out when/if
something got fixed. But it is still sometimes hard to figure out from
the short patch description, what the specific issue is. An issue
tracker ID is helpful there, but a vim_dev discussion link might do as
well. Or at least a date to go with the name of the person
reporting/fixing it.
List admins (or any other responders on the list) can help with having
too many different discussions on the same issue, by referring any
duplicate discussions back to the first discussion and continuing
there only. There is a "close topic" action admins can apply to any
thread, I assume this will prevent new posts to a topic if it has been
referred to a different thread.
The basic idea of having an issue tracker is that *all* bugs, feature requests and pull requests (PR's) go there. Thus you don't need to sync anything since there is nothing to sync with. I.e. switching to issue tracker means shutting down vim-dev mailing list. Otherwise it is not that useful and it either needs to be kept in sync or will contain only partial information.
Note that even Google code bug tracker allows using regular emails to respond to the issue.
Back on topic: Bram, this method seems to have a good deal of support, and does not introduce any new options. What do you think?
It looks like it became patch 7.3.1115.