Re: Patch 7.4.944

2015-11-29 19:36 GMT+03:00 Bram Moolenaar : > > Patch 7.4.944 > Problem:Writing tests for Vim script is hard. > Solution: Add assertEqual(), assertFalse() and assertTrue() functions. > Add > ​Why `assert{upper case letter}`? I know exactly no functions that use this

Re: Patch 7.4.944

2015-11-30 0:01 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>: > > Christian Brabandt wrote: > > > On So, 29 Nov 2015, Bram Moolenaar wrote: > > > > > > > > Nikolay Pavlov wrote: > > > > > > > 2015-11-29 19:36 GMT+03:00 Bram

Re: Support for new way of testing

2015-11-29 19:53 GMT+03:00 Nikolay Pavlov <zyx@gmail.com>: > > > 2015-11-29 19:46 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>: > >> >> Testing Vim functionality has always been difficult. The tests in >> src/testdir are hard to write and even harde

Re: Support for new way of testing

2015-11-29 19:46 GMT+03:00 Bram Moolenaar : > > Testing Vim functionality has always been difficult. The tests in > src/testdir are hard to write and even harder to read back. > > I have just sent out patch 7.4.944 which should make testing easier. > This is what simple test

Re: Patch 7.4.944

2015-11-30 2:10 GMT+03:00 Tony Mechelynck : > I'm not going to take sides here, just compare with some other > project: In Mozilla code (Firefox, Thunderbird, SeaMonkey), > preferences (which are user-visible, at least for technical-minded > users who dare use the

Re: pyeval

2015-11-21 16:41 GMT+03:00 Damien : > Hi list, > > Vim function `py{,3}eval()` cannot used with a void expression. > :call pyeval('None') > E859: Failed to convert returned python object to vim value > > This is expected? > ​Yes, of course. Pyeval is for getting result

[DOC? BUG] Documentation regarding viminfo-% is incorrect

Consider the following script: vim -u NONE -i /tmp/foo.viminfo -c 'help :command' -c 'setlocal buflisted' -c 'set viminfo='\''0,%' -c 'qa' This will result in the following contents in foo.viminfo: # This viminfo file was generated by Vim 7.4. # You may edit it if you're careful!

Re: pyeval

2015-11-24 1:14 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>: > > Nikolay Pavlov wrote: > > 2015-11-21 16:41 GMT+03:00 Damien <damien...@gmx.fr>: > > > > Hi list, > > > > > > Vim function `py{,3}eval()` cannot used with a void expression.

Re: [DOC? BUG] Documentation regarding viminfo-% is incorrect

2015-11-24 8:23 GMT+03:00 Tony Mechelynck <antoine.mechely...@gmail.com>: > On Mon, Nov 23, 2015 at 1:12 PM, Nikolay Pavlov <zyx@gmail.com> wrote: > > Consider the following script: > > > > vim -u NONE -i /tmp/foo.viminfo -c 'help :command' -c 'setloc

Re: [patch] Get window local cwd by getcwd()

Test contains error: +: let tab_changed = 0 Here variable is named `tab_changed` (and this is the name checked later) +: let mod = ":t" +: if a:tab > 0 && a:tab != tabpagenr() +: let tab_change = 1 But here it is `tab_change`. +: exec "tabnext " . a:tab +: endif +: let bufname =

Re: [patch] Get window local cwd by getcwd()

By the way, how about modifying the API to use usual {tab}, {win} order (seen in various *tabwin* functions), with {tab}=0 used to get the current tab implicitly. It is 1. consistent with other functions accepting tab and window and 2. allows getcwd({tab}) to return tab-local working directory

Re: Set line breaks, word wraps and word searching for Thai and other non-latin languages

2015-11-12 19:17 GMT+03:00 Brian Wilson : > I posted the following question on the vi/vim stack exchange > > and was told that the vim-dev mailing list

[BUG/DOC PATCH] Variable actual_curbuf is unset without notice and any documentation

Consider the following script: vim -u NONE -i NONE -N --cmd 'let g:actual_curbuf="foo"' --cmd 'set statusline=%{bufnr('\'\'')} laststatus=2' --cmd 'redrawstatus' --cmd 'echo g:actual_curbuf' you will see E121: Undefined variable: g:actual_curbuf. But trying to use help to understand what

Re: Patch 7.4.916

2015-11-10 21:04 GMT+03:00 Bram Moolenaar : > > Patch 7.4.916 > Problem:When running out of memory while copying a dict memory may be > freed twice. (ZyX) It was not “twice freeing” (though you may see this problem under some circumstances), it was “use after

Re: [BUG] It looks like OOM handling code is harmful

2015-11-06 0:48 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>: > > Nikolay Pavlov wrote: > >> >> Consider the following scenario: while processing function dict_copy >> >> >> >> static dict_T * >> >> dict_copy(orig, d

Re: [BUG] It looks like OOM handling code is harmful

2015-11-05 1:22 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>: > > Nikolay Pavlov wrote: > >> Consider the following scenario: while processing function dict_copy >> >> static dict_T * >> dict_copy(orig, deep, copyID) >> d

[BUG] It looks like OOM handling code is harmful

Consider the following scenario: while processing function dict_copy static dict_T * dict_copy(orig, deep, copyID) dict_T *orig; int deep; int copyID; { dict_T *copy; dictitem_T *di; int todo;

Re: [patch][Win32] Vim crashes when opening very long filename

2015-11-01 2:54 GMT+03:00 Dominique Pellé : > Andre Sihera wrote: > >> On 01/11/15 00:01, mattn wrote: Thanks. Is there any corner case where we would need a few more bytes than MAXPATHL? >>> >>> In utf-8, max bytes of letter

Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting

2015-10-27 14:44 GMT+03:00 Christian Brabandt : > Hi, > currently setting 'isk' option has - among others - an unwanted side > effect on the syntax highlighting. > > For example by removing the '_' from the 'iskeyword' setting, defined > syntax keywords start matching where

Re: proposed patch: Make syntax highlighting independent of 'iskeyword' setting

2015-10-27 20:00 GMT+03:00 Charles Campbell : > Christian Brabandt wrote: >> That is true with many patches however. It works only well, if >> contributors do use it. And a lot of syntax files need to be >> maintained, if only because the language evolves within times.

Re: Don't set "text" filetype for files that look like help files

2015-10-20 21:11 GMT+03:00 glts <676c7...@gmail.com>: > In a plain Vim installation, if I have a personal ftplugin > ~/.vim/ftplugin/text.vim that contains the line > > setlocal expandtab This file is missing `b:undo_ftplugin` variable, see :h undo_ftplugin. Examples are in every or

Re: [PATCH 0/3] syntax: sh: heredoc fixes

2015-10-15 14:03 GMT+03:00 Felipe Contreras <felipe.contre...@gmail.com>: > On Thu, Oct 15, 2015 at 5:49 AM, Nikolay Pavlov <zyx@gmail.com> wrote: >> 2015-10-15 13:10 GMT+03:00 Felipe Contreras <felipe.contre...@gmail.com>: >>> Hello? >>> >>

Re: [PATCH 0/3] syntax: sh: heredoc fixes

2015-10-15 13:10 GMT+03:00 Felipe Contreras : > Hello? > > Why hasn't this been fixed? You need to CC file maintainer, not just list. Also do not top post. > > On Fri, May 23, 2014 at 1:05 AM, Felipe Contreras > wrote: >> I noticed a bunch

Re: netrw on windows+shellslash

2015-10-08 20:44 GMT+03:00 Charles Campbell : > mattn wrote: >> Hi. >> >> I wrote a patch to enable http/ftp/webdav access with netrw on >> windows+shellslash. I'm using vim but not use cygwin or msys2. However, then >> editing http file on vim, URL is displayed as:

Re: Unexpected result when using getreg() with three arguments

2015-10-05 19:18 GMT+03:00 glts <676c7...@gmail.com>: > On Sunday, October 4, 2015 at 11:38:26 PM UTC+2, ZyX wrote: >> 2015-10-05 0:02 GMT+03:00 glts <676c7...@gmail.com>: >> > 'getreg(regname, 1, 1)' returns different lists for the same selection >> > in characterwise and linewise mode. Why? >> >

Re: Unexpected result when using getreg() with three arguments

2015-10-05 0:02 GMT+03:00 glts <676c7...@gmail.com>: > 'getreg(regname, 1, 1)' returns different lists for the same selection > in characterwise and linewise mode. Why? > > To reproduce: > - Do 'Vy' on one line of text, then run :echo getreg('"', 1, 1). > The result is ['text']. > - Do '0v$y' on

Re: [vim] Vim is unable to automatically detect my Python version (#419)

2015-09-16 0:14 GMT+03:00 Markus Meskanen : > I installed Python 3.5 (tried with both 32- and 64-bit versions), but my > Vim is unable to recognize the version. > Apparently I would have to recompile the whole Vim to work with any other > version than Python 3.2. > Here

Re: config wiping out myconfig

2015-09-08 22:00 GMT+03:00 toothpik : > > I'd reply to my first email but google never lets me see my emails, > hence this new one I always see my own emails in the thread in web interface. AFAIR I saw them in thread in Gmail Android app when I was using it. In any case you

Re: RFE: Allow defining digraphs by hex value

2015-09-08 0:31 GMT+03:00 LCD 47 : > On 8 September 2015, LCD 47 wrote: >> On 7 September 2015, Christian Brabandt wrote: >> > On Mo, 07 Sep 2015, LCD 47 wrote: >> > >> > > On 7 September 2015, Christian Brabandt wrote:

Re: RFE: Allow defining digraphs by hex value

2015-09-06 23:36 GMT+03:00 LCD 47 : > On 6 September 2015, Bram Moolenaar wrote: >> >> Lcd wrote: >> >> > On 5 September 2015, Tony Mechelynck wrote: >> > > Let's say I want to define ,, (two commas) as a digraph for … (U+2026

Re: [bug] :set all might break encoding

2015-08-22 17:04 GMT+03:00 Bram Moolenaar b...@moolenaar.net: Björn Linse wrote: :set all might change encoding without reexecuting mb_init(), if encoding was changed earlier from the locale default, leaving multibyte handling in inconsistent state. To reproduce (assuming utf-8 locale):

Re: Moving to github

ZyX_I repository is repository with my Vim variant and my work. It is not synchronized automatically, only when I think I need to merge my Vim variant with interesting patches with upstream. 2015-08-12 2:24 GMT+03:00 tux. z...@tuxproject.de: Sorry, I lost track. Which Bitbucket repository is the

Re: [patch] matchit.vim doesn't handle multibyte chars properly

2015-07-22 18:55 GMT+03:00 Ken Takata ktakata65...@gmail.com: Hi Benji and list, I found a problem that % in Operator pending mode doesn't work properly when multibyte characters are set in b:match_words. E.g. consider setting （ (U+FF08, FULLWIDTH LEFT PARENTHESIS) and ） (U+FF09, FULLWIDTH

Re: [patch] matchit.vim doesn't handle multibyte chars properly

2015-07-22 18:55 GMT+03:00 Ken Takata ktakata65...@gmail.com: Hi Benji and list, I found a problem that % in Operator pending mode doesn't work properly when multibyte characters are set in b:match_words. E.g. consider setting （ (U+FF08, FULLWIDTH LEFT PARENTHESIS) and ） (U+FF09, FULLWIDTH

Re: Unicode 6.0.0 symbols show with incionsistent width

2015-07-21 9:54 GMT+03:00 Yuri Vic yuriv...@gmail.com: 1. are 1-wide 2. the *font itself* is too wide. So this problem has nothing to do with Vim. To check whether it is the case, use terminal emulator which does not support fallback fonts or does not do it by default. E.g. rxvt-unicode

Re: Unicode 6.0.0 symbols show with incionsistent width

2015-07-21 0:25 GMT+03:00 Yuri Vic yuriv...@gmail.com: I came across this symbol: U+1F44D THUMBS UP SIGN () In vim-7.4.778 it shows with width one or two, depending if the cursor is to the left of it or not. So the text in this line jumps when cursor moves over the symbol. Attaching

Re: Possible bug: Unicode characters in [g]vim -S file name on Windows 8.1

2015-07-09 6:47 GMT+03:00 ben bgol...@gmail.com: Not sure if this is the right place to report a bug, but here it comes... How to reproduce: 1. Start Command Prompt. 2. Create an empty test directory anywhere and cd into it. 3. Create a subdirectory with a Unicode character in it, e.g.

Re: Please fix the overzealous :diffoff command

2015-06-21 21:17 GMT+03:00 Olaf Dabrunz o...@fctrace.org: On 21-Jun-15, Manuel Ortega wrote: Doing :h diffoff gives: The :diffoff command resets the relevant options to the values they had when using |:diffsplit|, |:diffpatch| , |:diffthis|. or starting Vim in diff mode. Otherwise they are

Re: Patch 7.4.741

This patch is incorrect by its nature. If “empty item” in list is significant then `set +=` *removes* element from the list and adds a new one, while it is supposed only to add an element. I do not know what is the problem with wildignore (I do not see any visible effect from “empty item” when

Re: asynchronously updating statusline from python plugin?

2015-06-14 15:04 GMT+03:00 AA theone.ash...@gmail.com: On Sunday, June 14, 2015 at 4:45:00 PM UTC+5:30, ZyX wrote: 2015-06-14 14:10 GMT+03:00 Nikolay Pavlov 2015-06-13 17:02 GMT+03:00 AA When I update the statusline from a python thread forked from main, the update gets registered by vim

Re: asynchronously updating statusline from python plugin?

2015-06-13 17:02 GMT+03:00 AA theone.ash...@gmail.com: When I update the statusline from a python thread forked from main, the update gets registered by vim but is shown only after take an action, a movement using keys, or a mouse scroll. Python code here if it helps: http://sprunge.us/LCfM

Re: asynchronously updating statusline from python plugin?

2015-06-14 14:10 GMT+03:00 Nikolay Pavlov zyx@gmail.com: 2015-06-13 17:02 GMT+03:00 AA theone.ash...@gmail.com: When I update the statusline from a python thread forked from main, the update gets registered by vim but is shown only after take an action, a movement using keys, or a mouse

Re: [PATCH] fix asciidoc syntax highlight performance

2015-06-01 16:14 GMT+03:00 Atte Peltomäki ora...@gmail.com: Vim includes AsciiDoc syntax highlight definition, but it's very, very slow. Fix attached. Disclaimer: I don't really understand what the removed options are for, but removing them fixes the issue without causing perceivable

Re: Supporting multiple shells in system()?

2015-05-30 6:08 GMT+03:00 Andy Russell arussell...@gmail.com: While writing my own plugins, I wish to support users who have fish or cmd.exe set as their shell. However, this often leads to a tedious pattern of: if fnamemodify(shell, ':t') ==# 'fish' Fish syntax let cmd = ... else

Re: Very slow yaml syntax highlighting (7.3.1106)

2015-05-22 11:45 GMT+03:00 Dominique Pellé dominique.pe...@gmail.com: Christian Wellenbrock christian.wellenbr...@gmail.com wrote: I attached a yaml file as example. Please open it with vim to test the highlighting speed. Scolling and searching is very slow. Tested on vim 7.3.1106 Viewing

Re: InsertCharPre not suport enter bs

2015-05-20 11:06 GMT+03:00 feng D fengi...@gmail.com: I found that the InsertCharPre event not suport enter and bs. Neither insert-mode command is inserting any characters, so InsertCharPre does not have a reason to work (though I think documentation on this matter can be enhanced). Enter is

Re: Replace MzScheme by something newer

Last time I checked Vim built and run with Racket support, but crashed when I tried to use it. 2015-05-13 0:09 GMT+03:00 tux. z...@tuxproject.de: Vim has (in theory) had support for MzScheme for a while now; still, as MzScheme is dead (integrated in the new language Racket), it could be

Re: issue: indent lines (shift lines with '' key)

2015-05-12 21:29 GMT+03:00 Mikhail V mikhail...@gmail.com: For python code, indenting selected lines with '' key does not shift commented line, if it has initially zero indent. Can be reproduced only with smartindent setting on. Version 7.4.52, Ubuntu. Example: print a #print a after

Re: [patch] extend() does not change an item in a locked dictionary

2015-05-03 9:06 GMT+03:00 Olaf Dabrunz o...@fctrace.org: On 02-May-15, Nikolay Pavlov wrote: 2015-05-02 5:44 GMT+03:00 Olaf Dabrunz o...@fctrace.org: On 30-Apr-15, Nikolay Pavlov wrote: 2015-04-30 10:56 GMT+03:00 Olaf Dabrunz o...@fctrace.org: diff -r 18d84ed365a5 src/testdir/test55

Re: [patch] extend() does not change an item in a locked dictionary

2015-05-02 5:44 GMT+03:00 Olaf Dabrunz o...@fctrace.org: On 30-Apr-15, Nikolay Pavlov wrote: 2015-04-30 10:56 GMT+03:00 Olaf Dabrunz o...@fctrace.org: diff -r 18d84ed365a5 src/testdir/test55.in --- a/src/testdir/test55.in Wed Apr 22 22:18:22 2015 +0200 +++ b/src/testdir/test55

Re: [patch] extend() does not change an item in a locked dictionary

2015-04-30 10:56 GMT+03:00 Olaf Dabrunz o...@fctrace.org: Example: :let d = {'a': 99, 'b': 100} :lockvar 1 d :call extend(d, {'a': 123}) E741: Value is locked: extend() argument :let d.a = 123 :let d d {'a': 123, 'b': 100} The

Re: Request for features in new release of Vim

2015-04-18 12:19 GMT+03:00 Bidit Mazumder bidit.mazum...@gmail.com: On Thursday, April 16, 2015 at 11:31:12 PM UTC+3, Christian Brabandt wrote: Hi Bidit! On Do, 16 Apr 2015, Bidit Mazumder wrote: First, I would like to thank Bram Moolenaar for making Vim, and Björn Winckler for the MacVim

Re: Request for features in new release of Vim

2015-04-18 19:11 GMT+03:00 Bidit Mazumder bidit.mazum...@gmail.com: On Saturday, April 18, 2015 at 2:59:26 PM UTC+3, Christian Brabandt wrote: On Sa, 18 Apr 2015, Christian Brabandt wrote: We could probably add a flag to 'cpoptions' to change this behaviour, but we wouldn't change the

Re: Repository cleanup (Was: Preparations for moving to github)

2015-04-16 9:36 GMT+03:00 Roland Eggner ed...@systemanalysen.net: On 2015-04-14 Tuesday at 20:00 +0300 Nikolay Pavlov wrote: 2015-04-14 17:37 GMT+03:00 Roland Eggner ed...@systemanalysen.net: @Bram, @Christian, @all ─── During some 10 years of almost daily usage

Re: Neovim changes

2015-04-14 20:28 GMT+03:00 Ben Fritz fritzophre...@gmail.com: On Tuesday, April 14, 2015 at 10:43:11 AM UTC-5, Thiago Arruda wrote: It's easy to accidentally make a Vim script that consumes all memory. If you see this often then you must be running Vim on a machine with an extremely low

Re: Repository cleanup (Was: Preparations for moving to github)

2015-04-14 20:45 GMT+03:00 Christian Brabandt cbli...@256bit.org: Hi Markus! On Mo, 13 Apr 2015, Markus Heidelberg wrote: [...] hg rebase --dest tip~7 --source tip~6 --collapse -mAdd missing tags I was brave and tested your script. There are two points I noticed. 1) rebase needs to be

Re: Repository cleanup (Was: Preparations for moving to github)

2015-04-14 17:37 GMT+03:00 Roland Eggner ed...@systemanalysen.net: On 2015-04-13 Monday at 20:00 +0200 Christian Brabandt wrote: On Mo, 13 Apr 2015, Bram Moolenaar wrote: Markus Heidelberg wrote: Some things can perhaps be done on the Mercurial repository before the import, but I

Re: Neovim changes

2015-04-14 18:43 GMT+03:00 Thiago Padilha tpadilh...@gmail.com: It's easy to accidentally make a Vim script that consumes all memory. If you see this often then you must be running Vim on a machine with an extremely low amount of memory. This is not the case for most users though, in the

Re: Neovim changes

2015-04-14 17:16 GMT+03:00 Bram Moolenaar b...@moolenaar.net: James McCoy wrote: On Mon, Apr 13, 2015 at 03:44:54PM +0200, Bram Moolenaar wrote: I included a few changes that were discussed on the neovim project. I'm sure there are more, but it requires browsing through the issues and

Re: Repository cleanup (Was: Preparations for moving to github)

2015-04-14 21:02 GMT+03:00 Christian Brabandt cbli...@256bit.org: On Di, 14 Apr 2015, Nikolay Pavlov wrote: 2015-04-14 20:45 GMT+03:00 Christian Brabandt cbli...@256bit.org: Hi Markus! On Mo, 13 Apr 2015, Markus Heidelberg wrote: [...] hg rebase --dest tip~7 --source tip~6

Re: Repository cleanup (Was: Preparations for moving to github)

2015-04-14 21:36 GMT+03:00 Christian Brabandt cbli...@256bit.org: On Di, 14 Apr 2015, Nikolay Pavlov wrote: 2015-04-14 21:02 GMT+03:00 Christian Brabandt cbli...@256bit.org: On Di, 14 Apr 2015, Nikolay Pavlov wrote: 2015-04-14 20:45 GMT+03:00 Christian Brabandt cbli...@256bit.org: Hi

Re: Repository cleanup (Was: Preparations for moving to github)

2015-04-14 21:50 GMT+03:00 Nikolay Pavlov zyx@gmail.com: 2015-04-14 21:36 GMT+03:00 Christian Brabandt cbli...@256bit.org: On Di, 14 Apr 2015, Nikolay Pavlov wrote: 2015-04-14 21:02 GMT+03:00 Christian Brabandt cbli...@256bit.org: On Di, 14 Apr 2015, Nikolay Pavlov wrote: 2015-04-14

Re: Repository cleanup (Was: Preparations for moving to github)

2015-04-01 22:52 GMT+03:00 Bram Moolenaar b...@moolenaar.net: Markus Heidelberg wrote: if switching to Git, we could seriously consider cleaning up the repository, now it might be the last chance for quite a while. I have collected some possibilities for improvement - some simple, some a

Re: Preparations for moving to github

2015-03-29 18:56 GMT+03:00 Bram Moolenaar b...@moolenaar.net: ZyX wrote: [...] But the serious question: How will this work for syntax maintainers? In the past, we just send patches to the maintainers, who would then pass them along to you. Should we now send pull requests

Re: Preparations for moving to githubj

2015-03-29 15:55 GMT+03:00 Fredrik Gustafsson iv...@iveqy.com: On Sun, Mar 29, 2015 at 05:15:08AM -0700, ZyX wrote: This is not dead code, this is primary out-of-sync documentation (since unlike NeoVim Vim does not have that much supporting code in runtime: NeoVim has various providers

Re: Google Code shuts down

2015-03-14 3:32 GMT+03:00 MURAOKA Taro koron.kaor...@gmail.com: I think it is problem that the name of vim is taken by someone already on github. https://github.com/vim Could we request to concede that vim name if we deside to move to github? Github has a thing called “name squatting

Re: Issue 341 in vim: Google Code will close

2015-03-14 11:05 GMT+03:00 Tux z...@tuxproject.de: The big majority disagrees. https://code.google.com/p/vim/issues/detail?id=341. Your comment made by email is not seen there, **DO NOT REPLY TO ISSUES WITH MAIL**. If you reply by email your comment will be seen by the mailing list users, but

Re: Google Code shuts down

2015-03-14 6:57 GMT+03:00 lilydjwg lilyd...@gmail.com: On Fri, Mar 13, 2015 at 07:43:57AM -0700, Ben Fritz wrote: [...] Yes, that's mostly what I was referring to. While long-time git users may find it obvious that push --force is a stupid thing to do, new git users may not realize that. I

Re: [BUG] Sessions do not work with nofile BufReadCmd buffers properly

2015-03-08 16:49 GMT+03:00 Bram Moolenaar b...@moolenaar.net: ZyX wrote: Consider the following code: % vim -u NONE -i NONE --cmd 'autocmd BufReadCmd edit://foo :call setline(., foo)|setlocal buftype=nofile' -c 'edit edit://foo' -c 'mksession ses.vim' -c qall! % vim -u

Re: [BUG] Sessions do not work with nofile BufReadCmd buffers properly

2015-03-07 17:04 GMT+03:00 Bram Moolenaar b...@moolenaar.net: ZyX wrote: Consider the following code: % vim -u NONE -i NONE --cmd 'autocmd BufReadCmd edit://foo :call setline(., foo)|setlocal buftype=nofile' -c 'edit edit://foo' -c 'mksession ses.vim' -c qall! % vim -u NONE -i

Re: can't edit ~/.alias - segmentation fault

2015-03-04 10:29 GMT+03:00 Ran Regev regev@gmail.com: # alias eali alias eali='vim ~/.alias' Can you replace Vim with echo and show what is `~/.alias` expanded to actually? # eali Vim: Caught deadly signal SEGV Vim: Finished. Segmentation fault (core dumped) # gdb /usr/bin/vim core

Re: Vim development model

2015-01-22 19:24 GMT+03:00 Ben Fritz fritzophre...@gmail.com: On Thursday, January 22, 2015 at 10:11:40 AM UTC-6, ZyX wrote: 2015-01-21 23:02 GMT+03:00 Ben Fritz fritzophre...@gmail.com: Many open-source projects do not accept major new features or potentially breaking changes except

Re: Vim development model

2015-01-21 23:02 GMT+03:00 Ben Fritz fritzophre...@gmail.com: On Wednesday, January 21, 2015 at 1:33:35 PM UTC-6, Tim Lebedkov wrote: For a beginning, you could maintain a separate installer so that people can actually try that it works and you get feedback. Then you can also gradually

Re: Any automatic bracket-insertion plugins not breaking undo?

2015-01-17 1:55 GMT+03:00 Christian Brabandt cbli...@256bit.org: Hi Bram! On Fr, 16 Jan 2015, Bram Moolenaar wrote: Christian Brabandt wrote: On Fr, 16 Jan 2015, Ben Fritz wrote: The problem is, there is no way to move the cursor in insert mode, without breaking the undo

Re: Patch 7.4.264

On May 16, 2014 12:29 PM, Alex Efros power...@powerman.name wrote: Hi! On Fri, Apr 25, 2014 at 03:27:40PM +0200, Bram Moolenaar wrote: My guess right solution should be fun s:Foo() endfun let g:Foo = function('s:Foo') but I'm not 100% sure. That should be the

Re: Patch 7.4.264

On May 16, 2014 1:58 PM, Alex Efros power...@powerman.name wrote: Hi! On Fri, May 16, 2014 at 12:53:17PM +0400, Nikolay Pavlov wrote: On May 16, 2014 12:29 PM, Alex Efros power...@powerman.name wrote: fun s:Foo() endfun let g:Foo = function('s:Foo') This change

Re: Patch 7.4.264

On Apr 25, 2014 6:22 PM, Bram Moolenaar b...@moolenaar.net wrote: Alex Efros wrote: On Fri, Apr 25, 2014 at 03:27:40PM +0200, Bram Moolenaar wrote: My guess right solution should be fun s:Foo() endfun let g:Foo = function('s:Foo') but I'm not 100% sure.

Re: Patch 7.4.264

On Apr 25, 2014 2:52 AM, Alex Efros power...@powerman.name wrote: Hi! On Thu, Apr 24, 2014 at 12:43:01PM +0200, Bram Moolenaar wrote: Me, too. The following used to work: fun! Foo() endfun let g:Foo = function('Foo') After 7.4.264, I get: E705: Variable

Re: Patch 7.4.264

On Apr 25, 2014 7:40 PM, Alex Efros power...@powerman.name wrote: Hi! On Fri, Apr 25, 2014 at 07:34:16PM +0400, Nikolay Pavlov wrote: because the fact that you received a funcref never means you can call it Why is that? Funcref is a mere string. There is no guarantee that referenced

Re: [patch] possible bug in gui_mch_init() in gui_gtk_x11.c

On Apr 18, 2014 7:28 PM, Cade Forester ahx2...@gmail.com wrote: + if (strcmp(setlocale(LC_NUMERIC, NULL), C) != 0) strcmp() cause segmentation fault for NULL pointer -- diff --git a/src/gui_gtk_x11.c b/src/gui_gtk_x11.c --- a/src/gui_gtk_x11.c +++ b/src/gui_gtk_x11.c @@ -3144,7

Re: [patch] append($, 'foobar') does not return an error

On Apr 17, 2014 7:26 PM, Christian Brabandt cbli...@256bit.org wrote: Bram, I accidentally called append($, 'foobar') and was surprised the string was actually entered at the top. I did rather expect E116 invalid arguments for function append. So here is a patch: diff --git

Re: .git Overhead in Vim Plugins

On Apr 10, 2014 4:16 PM, Peter Aronoff telemac...@arpinum.org wrote: On Thu Apr 04/10/14 at 1:58, Fredrik Gustafsson wrote: If you don't need the history or beeing able to take part in the development of the plugins I suggest you instead of fetching the git repository just fetch a tarball

Re: Bug? Vim listchars error (E474) with unicode chars

On Apr 1, 2014 10:35 AM, vexw...@gmail.com wrote: On win7 x64 using VIM 7.4, I get an error with gVim upon reading the _vimrc, when Unicode chars are in the listchars section. A simple example to trigger would read: set listchars=eol:¶ I get an Error detected...E474 Invalid argument: set

Re: Page on developing Vim

On Apr 1, 2014 7:42 PM, Ben Fritz fritzophre...@gmail.com wrote: On Monday, March 31, 2014 9:04:50 PM UTC-5, Danek Duvall wrote: Christian Brabandt wrote: Secondly, I disagree that It is dangerous to pull changes from the central vim repository, while there are still patches applied.

Re: Page on developing Vim

On Apr 2, 2014 1:54 AM, Ben Fritz fritzophre...@gmail.com wrote: On Tuesday, April 1, 2014 10:53:38 AM UTC-5, ZyX wrote: I am wondering why you need any rebasing in the first place? I use regular mercurial branches or bookmarks and regular hg merge. If you are not going to release a series

Re: Issue in match() function with multi-byte characters

On Mar 30, 2014 5:54 AM, Andre Sihera andre.sih...@hotmail.co.jp wrote: On 30/03/14 09:03, Nikolay Pavlov wrote: On Mar 30, 2014 3:35 AM, Dmitry Frank dimon.fr...@gmail.com wrote: Hello all. match() function returns index of first match, but if there are multi-byte chars before first

Re: Issue in match() function with multi-byte characters

need count for the jump-to-virtcol (pipe) motion. 2014-03-30 4:03 GMT+04:00 Nikolay Pavlov zyx@gmail.com: On Mar 30, 2014 3:35 AM, Dmitry Frank dimon.fr...@gmail.com wrote: Hello all. match() function returns index of first match, but if there are multi-byte chars before first

Re: Issue in match() function with multi-byte characters

On Mar 30, 2014 12:59 PM, Dmitry Frank dimon.fr...@gmail.com wrote: 2014-03-30 12:51 GMT+04:00 Nikolay Pavlov zyx@gmail.com: On Mar 30, 2014 4:19 AM, Dmitry Frank dimon.fr...@gmail.com wrote: Then, how can I get the symbol index (not byte offset) of a match? There is awesome

Re: [patch] add sortuniq() function

On Mar 25, 2014 11:41 PM, Charles E Campbell drc...@campbellfamily.biz wrote: LCD 47 wrote: On 19 March 2014, Cade Forester ahx2...@gmail.com wrote: Looks like you made a copy of f_sort() and modified it a bit. That's a lot of duplicate code. Better move the common stuff into a function

Fwd: [BUG] :*do $append asks for input for each *

On Mar 22, 2014 2:58 AM, Bram Moolenaar b...@moolenaar.net wrote: ZyX wrote: If you type `:bufdo $appendCR` vim will start iterating over buffers. Each time buffer is entered $append asks for input. But 1. Buffer is not shown in the window, neither there are any messages about which

Re: Fwd: [BUG] :*do $append asks for input for each *

On Mar 22, 2014 10:08 PM, LCD 47 lcd...@gmail.com wrote: On 22 March 2014, Nikolay Pavlov zyx@gmail.com wrote: [...] I am currently writing VimL parser for neovim (or for other project if neovim fails: precise VimL parser is not only useful for vim fork), this greatly improves

Re: [BUG] :execute 'if 1' works like :if 1

On Mar 23, 2014 12:19 AM, Bram Moolenaar b...@moolenaar.net wrote: ZyX wrote: The docs are wrong, using if is allowed. The other two are not. Why? It makes parsing impossible. E.g. like indicated by @Yukihiro Nakadaira, there is absolutely nothing you can do with this error unless

Re: [patch] doc/eval.txt: add g: to :function description

On Mar 16, 2014 6:09 PM, Bram Moolenaar b...@moolenaar.net wrote: Cade Forester wrote: diff -r f99b6efb5193 runtime/doc/eval.txt --- a/runtime/doc/eval.txtWed Mar 12 21:28:26 2014 +0100 +++ b/runtime/doc/eval.txtSun Mar 16 13:16:10 2014 +0700 @@ -6624,7 +6624,7 @@

Re: [patch] doc/eval.txt and doc/map.txt: small fixes

On Mar 11, 2014 9:26 PM, Cade Forester ahx2...@gmail.com wrote: In the example the function is called s:SID, and that's what is being matched. I don't think this needs to change If somebody copy this code and rename function, pattern will not match. Since the function name can't contain

Re: Incorrect expansion of %?

On Mar 11, 2014 9:51 PM, Charles Campbell charles.e.campb...@nasa.gov wrote: Ingo Karkat wrote: On 11-Mar-2014 15:14 +0100, Ben Fritz wrote: snip Isn't this situation what shellescape() is designed for? That's not saying shellescape() will work, but I think it's supposed to work, unlike

Re: Incorrect expansion of %?

On Mar 11, 2014 11:53 PM, Gary Johnson garyj...@spocom.com wrote: On 2014-03-11, Nikolay Pavlov wrote: On Mar 11, 2014 9:51 PM, Charles Campbell wrote: Ingo Karkat wrote: On 11-Mar-2014 15:14 +0100, Ben Fritz wrote: snip Isn't this situation what shellescape

Re: 7.4 not listed in upload form

On Mar 7, 2014 5:16 PM, Jakson Alves de Aquino jalve...@gmail.com wrote: Hi, The form to upload new versions of scripts at www.vim.org doesn't show 7.4 as an option of required Vim version; the highest version is 7.3. I think that 7.4 should be included in the drop down list. Vim version

Re: [PATCH] XDG Base Directory Specification support

On Mar 4, 2014 7:30 AM, Jean-François Bignolles jf.bignol...@gmail.com wrote: Hello, the attached patch adds support for XDG Base Directory Specification. This is a compile-time option (--enable-xdg-basedir), off by default. See

Re: [PATCH] XDG Base Directory Specification support

On Mar 5, 2014 12:49 AM, Jean-François Bignolles jf.bignol...@gmail.com wrote: Hello, Le mardi 4 mars 2014 15:48:49 UTC+1, ZyX a écrit : On Mar 4, 2014 7:30 AM, Jean-François Bignolles jf.big...@gmail.com wrote: the attached patch adds support for XDG Base Directory Specification.

Re: E685: Internal error: hash_add() happen when assigning autoload variable

On Jan 1, 2014 9:47 AM, Yukihiro Nakadaira yukihiro.nakada...@gmail.com wrote: Steps to reproduce: $ cat ~/.vim/autoload/Foo.vim let Foo#x = 0 $ vim -u NONE -N :let Foo#x = function('tr') E685: Internal error: hash_add() eval.c:set_var() - var_check_func_name()Foo.vim is

  1   2   3   >