Re: [patch] Put ~ markers into their own highlight group

Bram Moolenaar wrote (Fri, Oct 31, 2014 at 01:03:59PM +0100): > The only bit that I don't like is having to change all color schemes > to add the highlight link. Can't this be done by default? Instead of > specifying colors that are initially equal to NonText, link > EndOfBuffer to NonText when i

Re: [patch] Put ~ markers into their own highlight group

And here are the patches.. -- Github: http://github.com/mhinz | Twitter: http://twitter.com/_mhinz_ -- -- 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 ---

[patch] Put ~ markers into their own highlight group

Hi, this might be yet another controversial patch, but it's asked for on IRC all the time. The problem is that the ~ markers (end of buffer) and parts of 'listchars' both use the same highlight group: NonText. Now people wish to use different colors for this, thus this patch introduces a new hig

vim_dev@googlegroups.com

Hey, the help of 'showbreak' seems to suggest that multibyte characters are allowed as long as they're visible and single-cell. 7.4.473 introduced STRLEN to compute the proper cursor placement and doesn't take multibyte characters into account. I hope the attached patch fixes it properly. ~mhi

Re: [patch] :sign-jump to curwin if the buffer is visible

> Refreshed patch against current sources and renamed the test files to > test_signs.*. Good work! As an author of a Vim plugin that uses signs, I'd like to see this patch included. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you

Re: [patch] Cut fold and sign columns at end of buffer

> The screenshot attached to the proposal doesn't show the case when > all four of the highlight groups have the same background color. In > that case, the proposal looks bizarre. In that case it wouldn't look bizarre, but identical to the current way, apart from the ~ markers potentially being i

Re: [patch] Cut fold and sign columns at end of buffer

> Well, I suppose there is something to say for both ways. What do the > users prefer? I understand that such visual changes are almost always controversial, especially for such a long-lasting editor with its big community. I'd argue that this patch makes the fold and sign column work as the numb

[patch] Cut fold and sign columns at end of buffer

Hi, win_draw_end() is used to clear the end of the screen in certain cases, e.g. very long, wrapped lines or the actual end of the buffer. Fold and sign columns get continued although that's not useful at all for the case of the end of buffer. Therefore win_draw_end() gets split into: draw_

Re: Typo in src/version.c

Hi Bram, > It was there intentionally. Does it cause a problem anywhere? Oh, not at all. But it seemed inconsistent because ":h +feature-list" lists the feature as "+fork", but :version shows "+fork()". That could mislead people to use code like "has('fork()')". -- -- You received this mess

Typo in src/version.c

Hey, I just noticed a little glitch when I looked at :version --- a/src/version.c Thu May 30 22:44:02 2013 +0200 +++ b/src/version.c Fri May 31 17:19:56 2013 +0200 @@ -250,1 +250,1 @@ - "+fork()", + "+fork", -- -- You received this message from the "vim_dev" maillist. Do no

:echo is not working under certain conditions

Hello! A member of #vim has experienced a weird behaviour while Vim scripting. Under certain conditions :echo would only print one line at max. Thus neither 2x echo nor 1x echo containing a \n would work. Conditions: 1) the :echo's are wrapped in an if/endif block 2) the if/endif block is the