Re: test harness cleanup

> > I've made some comments silent in the src/testdir Makefile, to keep them > > from being printed during test runs. > > Thanks. Would there be a make program that doesn't work with this? That's a good question, and I'm not sure of the answer. For what it's worth, posix seems to be ok with it, b

test harness cleanup

I've made some comments silent in the src/testdir Makefile, to keep them from being printed during test runs. Kartik http://akkartik.name/about -- -- 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,

Re: mixing three-piece and nested 'comments'

> The problem also goes away when inserting something else before the > "n:x". Thus it's related to skipping over the three part comment. Thanks! That's a useful tip. I hope to send a patch soon. I'm trying now to add tests to testdir. Are there any pointers on documentation for the format? For

Re: mixing three-piece and nested 'comments'

> $ VIM= VIMRUNTIME= VIMINIT= *vim* -u /dev/null -c "set formatoptions=r | *set comments=s1:/*,mb:*,ex:*/,n://"* The problem goes away if I move the "n://" to the start of the string. (It can't be in any other position in my example because start, middle and end are required to be contiguous and i

mixing three-piece and nested 'comments'

Can others reproduce this? Is it somehow expected behavior? $ uname -s -r -v -m -p -i -o Linux 3.13.0-35-generic #62~precise1-Ubuntu SMP Mon Aug 18 14:52:04 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ vim --version VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 11 2014 01:40:51) Included patches:

fixes to vim.org

https://news.ycombinator.com/item?id=8263697 He's referring to the link "Plain text (by Yegappan Lakshmanan and Gavin Sinclair)", which should probably be deleted. How does one make changes to the site's repo? Thanks, Kartik http://akkartik.name/abo

Re: weird matchadd() behavior

Argh, apologies, that didn't come out right. Let me try again. If I have these lines on screen: abc > abcd > @abc > ..and I type: :call matchadd('Identifier', '\') This causes the bolded bits to be colorized, as expected: *abc* > abcd > @*abc* > However, if I instead type: :call matchadd('I

weird matchadd() behavior

Dear vim devs, I just noticed that this colorizes: :call matchadd('Identifier', '\<@abc\>') But this doesn't: :call matchadd('Identifier', '\<@abc\>') Is there a reason for this? I've tested it without any startup files on 7.3 (patches 1-1302) on linux, with a file containing the following: a

Re: stale help about window-local options

Sorry about the delay. > Now the 'list' option is not set, because ":set nolist" resets the global > value, ":setlocal list" only changes the local value and ":e two" gets the > global value. Note that if you do this next: > > :e one > You will get back the 'list' value as it was the last

Update old vimtips urls in doc/

-- -- 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 unsu

stale help about window-local options

A coworker pointed out that part of the window-local example in ":help local-options" is no longer accurate. :e one :set list :e two Now the 'list' option will also be set in "two", since with the ":set list" command you have also set the global value. > :set nolist

Re: dependencies between features

Ah thanks for the investigation! I'm going to run with that patch. -- 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

Re: dependencies between features

Thanks, Tony. It seems to be because of a call to mb_string2cells in if_py_both.h:VimStrWidth. Since python isn't a feature in feature.h I'm not sure what to check for to enable FEAT_MBYTE.. -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text

Re: vim.vim organization

> You're likely looking at the "automatically generated keyword lists"; > vimCommands are generated automatically. The keywords are sorted in the > usual ascending alphabetical order with 100 keywords per line. Yeah I see the comments now that these lines are auto-generated: syn keyword vimComma

vim.vim organization

I notice many keywords in runtime/syntax/vim.vim are split across multiple lines. For example, I assume all the lines beginning with "syn keyword vimCommand" could logically be assumed to be a single (very long) command. Is that accurate? If this is correct, I'm curious if there's some pattern to

dependencies between features

I was building vim with python support today, and I noticed that it gives a linker error if multibyte support isn't also enabled. Is that unexpected, or is the usual model to include features and all their dependencies? -- You received this message from the "vim_dev" maillist. Do not top-post! Ty

Re: Proposal: new options for 'vertical' and 'horizontal' splits by default

>> Today I discovered a new keyboard shortcut: C-w C-s to split > > No I haven't done anything there. My reference to undotree was only marginally relevant. I was just saying that C-w C-s splits vertically as it should, and its documentation refers to splitvertical as well. So you were way ahead o

Re: Proposal: new options for 'vertical' and 'horizontal' splits by default

Thanks a lot for this patch[1], Christian! I've been using it for a few weeks now and it's been working absolutely great. It's also eliminated almost 200 lines from my vimrc. Today I discovered a new keyboard shortcut: C-w C-s to split (circuitously via http://news.ycombinator.com/item?id=1807008)

Re: Proposal: new options for 'vertical' and 'horizontal' splits by default

> This option already exists for :diff. :set diffopt+=vertical or :set > diffopt+=horizontal. This will probably have some weird interactions > with your patch (I have not tried it). Not my patch but Christian Brabandt's :) Thanks for the tip. I just tested it and splitvertical trumps diffopt hor

Re: Proposal: new options for 'vertical' and 'horizontal' splits by default

>> Bram decides what will be included in vim. He might comment on the patch >> and then it may or may not be included in Vim. I don't know. > > Just FYI, I made a couple of tweaks to syntax/vim.vim to include 6 > variants of splitvertical as keywords. After using splitvertical for a few weeks I fi

Re: Proposal: new options for 'vertical' and 'horizontal' splits by default

> Bram decides what will be included in vim. He might comment on the patch > and then it may or may not be included in Vim. I don't know. Just FYI, I made a couple of tweaks to syntax/vim.vim to include 6 variants of splitvertical as keywords. -- You received this message from the "vim_dev" mail

Re: How to scroll buffer in other window?

> Suppose that I have split a window in two with different files loaded > in each new window. How can I scroll one window to show the end of the > file without leaving the current buffer? Is it possible to that with > setpos()? The approach I used was to save the target window's winnr(). Now you c

Re: Proposal: new options for 'vertical' and 'horizontal' splits by default

On Fri, Sep 24, 2010 at 06:06, Christian Brabandt wrote: > Try the attached patch, it provides the new setting 'splitvertical' I've only been using it for a couple of hours, but I love it so far. Has this patch come up before on the list? I'd vote to have it in. (modulo adding splitvertical and v

Proposal: new options for 'vertical' and 'horizontal' splits by default

I've been thinking about adding two options to vim: :set horizontal [default] :set vertical What they would do is set the default split orientation for commands like C-w C-] (http://thread.gmane.org/gmane.editors.vim/48415), :diff and so on. Normal commands currently switch orientation using :