|Re: FW: use of vim signs||Christian Brabandt||5/30/13 12:07 AM|
Forwarding to vim-dev
On Mi, 29 Mai 2013, Ben Fritz wrote:
> I like the proposal by "glts" myself:
> > - ":set nonu nornu" means: I don't want any line numbers;
> > - ":set nu nornu" means: I want to see only absolute numbers;
> > - ":set nonu rnu" means: I want to see only relative numbers;
> > - ":set nu rnu" means: I want to have the best of both worlds.
> Christian, what is the problem you have with this approach?
I think, this is confusing. But as I said, I don't have a strong opinion
on that, so here is a patch to try out:
Die Natur bekï¿½mmert sich nicht um irgendeinen Irrtum; sie selbst
kann nicht anders, als ewig recht handeln, unbekï¿½mmert, was daraus
-- Goethe, Maximen und Reflektionen, Nr. 958
|Re: FW: use of vim signs||Nazri||5/30/13 2:13 AM|
On Thu, May 30, 2013 at 3:07 PM, Christian Brabandt <cbl...@256bit.org> wrote:I like this option-interrelationship. The code simpler too. The only missing
'feature' is the alignment of the current number (patch posted at ), compare
97 char_u *p;
1 char_u *newline;
2 char_u *oldline;
97 char_u *p;
1 char_u *newline;
2 char_u *oldline;
The former differentiates the current line number from the relatives ones by
aligning it to the left. This leaves a quite visible gap in the number column
- some people would find this aesthetically displeasing. I find that my brain
spends like a few milliseconds :) saying "oh this blank here is not really part
of the file content, it's the left over space for the current line number" - it
can be distracting at times. Ironically the intention of showing the current
line number there is to avoid the distraction of having to move your eyes down
to the statusline just to find out the current line number.
The latter keeps the current line number aligned with the relative ones.
There's no more gap - no more distraction when eyeballing the lines.
Some would argue that now it's a bit hard to differentiate between current line
number and the relative ones but that can be solved via syntax highlighting but
then there's also people who do not prefer colors in their editor.
|Re: FW: use of vim signs||Christian Brabandt||6/2/13 4:52 AM|
displaying the absolute line number instead of the zero for relative
line numbering seems to have caused many controversial opinions here and
at vim-use (but I have not seen it in the latest todo.txt file).
Would you consider any of the patches that make this behaviour
customizable for the vim 7.4 release?
Willst du den Wert des Geldes kennenlernen, geh und versuche dir
welches zu borgen.
-- Benjamin Franklin
|Re: FW: use of vim signs||Bram Moolenaar||6/2/13 7:57 AM|
There is too much discussion about this. I think the current behavior
is OK and does not have enough disadvantage to justify adding yet
hundred-and-one symptoms of being an internet addict:
42. Your virtual girlfriend finds a new net sweetheart with a larger bandwidth.
/// Bram Moolenaar -- Bram@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 ///
|Re: FW: use of vim signs||Grant Farnsworth||6/2/13 9:50 AM|
On Sunday, June 2, 2013 10:57:33 AM UTC-4, Bram Moolenaar wrote:There's a reason there's a lot of discussion about it, though. For those who use relative line numbering this is an important issue. Leaving it in a state that seriously (and negatively) affects a sizeable proportion of those who use it, particularly when the prior behavior did not do this, indicates to me that you may not care much about relative line numbering in general, not that those who use it are indifferent about how it works or that the change is insignificant.
I opened screen.c to patch my local copy so it would work the way I want and noticed that the line numbering was consuming a full 6 columns of my 80 column terminal because of this new feature. That is far more than it should. Multiplied across all the users who do or will use relative line numbering, this is by no means an insignificant loss in visible screen area and productivity.
I can understand not caring all that much to change (or rather, unchange) a feature that isn't integrated into your personal workflow. However, in all humility I believe it hasn't been discussed enough. It was added without much discussion because when you just hear about it, it sounds like it adds something without really costing anything. In practice, though, it costs quite a bit. This was by no means a small change to the workings of vim, and it removed valuable functionality without offering users a chance to preserve the way it worked before, which was better.
In light of that, I think it would be best not to be premature in making judgments about its importance or how acceptable the current state is, even if there are many other things on developers' minds now. Don't you?
|Re: FW: use of vim signs||Christian Brabandt||6/2/13 11:23 AM|
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.
Ich leider nicht, meine Freunde; aber ich fï¿½hle eine gewisse
Schwierigkeit zu existieren.
-- Bernard Le Bovier de Fontenelle
|Re: FW: use of vim signs||Bram Moolenaar||6/2/13 12:30 PM|
You mean the patch you sent on May 30?
I don't see anybody responding that they like that solution.
52. You ask a plumber how much it would cost to replace the chair in front of
your computer with a toilet.
|Re: FW: use of vim signs||glts||6/2/13 1:07 PM|
On Sunday, June 2, 2013 9:30:20 PM UTC+2, Bram Moolenaar wrote:
This is exactly one of the reasons people are calling for a proper issue
I proposed this originally but I'm still undecided. I think it would be
|Re: FW: use of vim signs||Grant Farnsworth||6/2/13 1:36 PM|
> - ":set nonu nornu" means: I don't want any line numbers;
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.
|Re: FW: use of vim signs||Bram Moolenaar||6/2/13 2:09 PM|
There already is an issue tracker.
54. You start tilting your head sideways to smile. :-)
|Re: FW: use of vim signs||ZyX||6/2/13 3:02 PM|
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.
> --> --
> 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.
|Re: FW: use of vim signs||Bram Moolenaar||6/3/13 2:16 AM|
It does support attachments.
What's a PR? Problem Report?
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.
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.
58. You turn on your computer and turn off your wife.
|Re: FW: use of vim signs||Ben Fritz||6/3/13 7:24 AM|
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).
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.
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).
|Re: FW: use of vim signs||Bram Moolenaar||6/3/13 8:42 AM|
> > > And there are no PR's here. Other issue tracker problems are tolerable,Context diffs work just fine. Anybody with basic Linux tools can use
them, no need to figure out hg or git commands and setting up an
environment where they work. I hardly ever had a problem with "bitrot",
except for refactorings where nothing would help.
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
There was a promise from someone to keep the Issue Tracker up to date,
close fixed issues and so on, but that doesn't really appear to happen.
I don't really have time to do that on top of everything else.
In an ideal world everything happens wonderfully, we'll have to live
with the real world.
68. Your cat always puts viruses on your dogs homepage
|Re: FW: use of vim signs||Ben Fritz||6/3/13 10:30 AM|
Sorry for the duplicate, Bram. I meant to include the list and forgot to "reply all".
On Mon, Jun 3, 2013 at 10:42 AM, Bram Moolenaar <Br...@moolenaar.net> wrote:
I assume you keep the todo list up-to-date as you work, but you just
List admins (or any other responders on the list) can help with having
|Re: FW: use of vim signs||ZyX||6/3/13 1:45 PM|
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.
|Re: FW: use of vim signs||Ben Fritz||6/3/13 2:36 PM|
On Mon, Jun 3, 2013 at 3:45 PM, ZyX ZyX <zyx...@gmail.com> wrote:Yes, if the developers decide they're worth doing anyway. It would
replace the TODO list.
No. Some projects (TortoiseSVN for example) require that all issues be
vetted on a mailing list before they go in the bug tracker. Entering a
bug in the tracker without agreement on the mailing list means the bug
gets rejected without inspection. Then only relevant information to
resolving or reproducing the bug goes in the issue tracker. Discussion
about how to fix the bug (or whether to fix it) can go on in the
mailing list. Many projects have a mailing list as first contact, and
then the response is not "I'll add it to the TODO list", it is "filed
as bug ID 123456".
|Re: FW: use of vim signs||Ben Fritz||6/3/13 2:39 PM|
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?
|Re: FW: use of vim signs||Bram Moolenaar||6/4/13 2:18 AM|
Yeah, it appears this time there is nobody against this solution.
78. You find yourself dialing IP numbers on the phone.
|Re: FW: use of vim signs||toothpik||6/4/13 3:13 AM|
On Tue, Jun 04, 2013 at 11:18:49AM +0200, Bram Moolenaar wrote:it is indeed an intuitive and option minimizing approach, and our BDFL
isn't against it -- that matters
oh mama -- if I were a practiced patch cooker-upper I'd be on this --
I know exactly what we need here -- it's all in the thread -- the two
gotchas are (1) I am NOT a practiced patch cooker-upper, and (2) Bram
only accepts patches from ppl who post their real name right here in
front of god and everybody -- eesh -- that is so not me -- Grant? --
we are soo close...
_|_ _ __|_|_ ._ o|
|Re: FW: use of vim signs||Charles Campbell||6/5/13 8:38 AM|
Bram Moolenaar wrote:
> [snip] (discussion about relative numbers)
> There is too much discussion about this. I think the current behaviorI won't be using the relative numbers option in its current state.
|Re: FW: use of vim signs||Charles Campbell||6/5/13 8:43 AM|
Christian Brabandt wrote:I plan on trying your patch out soon, probably tonight (can't build vim
on my SL6.3 at work properly, although I can build it on a SL6.3 system
at home). Sounds like a good solution to me.
|Re: FW: use of vim signs||Ben Fritz||6/5/13 8:54 AM|
On Wednesday, June 5, 2013 10:43:23 AM UTC-5, Charles Campbell wrote:
It looks like it became patch 7.3.1115.