On Wednesday, April 20, 2016 at 1:17:35 AM UTC+3, Björn Linse wrote:
> To reproduce:
>
> vim -u NONE -i NONE
> :let x = getreg("a",1,1)
> :call setreg("0",x)
>
> gives SIGSEGV on master vim (huge build). "-i NONE" is needed to make sure
> registers are undefined.
>
> it seems like getreg retur
On Sunday, March 29, 2015 at 2:55:12 PM UTC+3, Guyz Zmolotov wrote:
> On Sun, Mar 29, 2015 at 04:04:23AM -0700, ZyX wrote:
> > On Sunday, March 29, 2015 at 1:57:31 PM UTC+3, Fredrik Gustafsson wrote:
> > > On Sun, Mar 29, 2015 at 03:55:55AM -0700, ZyX wrote:
> > > > N
On Sunday, March 29, 2015 at 2:10:09 PM UTC+3, Fredrik Gustafsson wrote:
> On Sun, Mar 29, 2015 at 04:04:23AM -0700, ZyX wrote:
> > On Sunday, March 29, 2015 at 1:57:31 PM UTC+3, Fredrik Gustafsson wrote:
> > > On Sun, Mar 29, 2015 at 03:55:55AM -0700, ZyX wrote:
> > > &
On Sunday, March 29, 2015 at 1:57:31 PM UTC+3, Fredrik Gustafsson wrote:
> On Sun, Mar 29, 2015 at 03:55:55AM -0700, ZyX wrote:
> > NeoVim project tried to do this and found it non-comfortable to keep them in
> > sync (I mean, any contributor which needs to change both code and
&g
On Saturday, March 28, 2015 at 5:11:26 PM UTC+3, Bram Moolenaar wrote:
> Marshall Ward wrote:
>
> > Bram-
> > Just a quick comment, followed by a maintenance question:
> >
> > First:
> >
> > Despite being a long time git and github user, I would still vote that
> > you go with your personal pref
On Wednesday, March 25, 2015 at 11:48:42 PM UTC+3, Bram Moolenaar wrote:
> Christian Brabandt wrote:
>
> [...]
>
> > @Bram, perhaps it is necessary to split the runtime directory into a
> > separate
> > github repository, so they could be easier handled.
>
> How is that easier? Most users will
# HG changeset patch
# User ZyX
# Date 1427625389 -10800
# Sun Mar 29 13:36:29 2015 +0300
# Node ID d6e58fa2f6ffa3fdd6bd21eed97d5f42dd56cbf5
# Parent 1f42458bf2e78f36041a349b9d0b100b4ad2a1c8
Update YAML syntax file
Differences:
- Performance of the syntax rules was optimized.
- Syntax file
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 NONE --cmd 'autocmd BufReadCmd edit://foo :call
setline(".", "foo")|setlocal b
I also see this issue once I use GVim and not terminal Vim.
On Tuesday, March 3, 2015 at 10:37:53 PM UTC+3, Christian Brabandt wrote:
> Hi Simon!
>
> On Di, 03 Mär 2015, Simon Kohlmeyer wrote:
>
> > Hi everyone,
> >
> > I'm having a problem with the statusline in gvim.
> > After certain three-b
Try the following code:
echo "echomsg 42" > '$HOME'
vim -u NONE -i NONE -S '$HOME'
. It will show “E484: Can't open file /home/zyx”, while it should just echo 42.
Worse things will happen if file happens to contain pipe: as `-S …` is
translated to
In `:h :syn-sync-maxlines` at the end of the section the following example is
given:
:syntax sync ccomment maxlines=500
. This example is not correct and does not do what you expect: it is
interpreted as syntax_sync(ccomment="maxlines=500"), not as
syntax_sync(ccomment=default, maxlines=50
Consider the following script:
= bug.vim =
highlight clear SpellBad
highlight FgYellowBgBlue ctermfg=Yellow ctermbg=Blue
highlight FgGreenctermfg=Green
highlight SpellBad ctermfg=Cyan ctermbg=Red
call matchadd('FgGreen', '.*')
syntax
On Saturday, December 6, 2014 8:51:08 PM UTC+3, ZyX wrote:
> On Saturday, December 6, 2014 8:01:22 PM UTC+3, ZyX wrote:
> > On Saturday, December 6, 2014 7:55:34 PM UTC+3, ZyX wrote:
> > > On Friday, December 5, 2014 10:54:45 PM UTC+3, Christian Brabandt wrote:
> > > >
On Saturday, December 6, 2014 8:01:22 PM UTC+3, ZyX wrote:
> On Saturday, December 6, 2014 7:55:34 PM UTC+3, ZyX wrote:
> > On Friday, December 5, 2014 10:54:45 PM UTC+3, Christian Brabandt wrote:
> > > Hi Bram!
> > >
> > > On Fr, 05 Dez 2014, Bram Moole
On Saturday, December 6, 2014 7:55:34 PM UTC+3, ZyX wrote:
> On Friday, December 5, 2014 10:54:45 PM UTC+3, Christian Brabandt wrote:
> > Hi Bram!
> >
> > On Fr, 05 Dez 2014, Bram Moolenaar wrote:
> >
> > > ZyX wrote:
> > >
> > > >
On Friday, December 5, 2014 10:54:45 PM UTC+3, Christian Brabandt wrote:
> Hi Bram!
>
> On Fr, 05 Dez 2014, Bram Moolenaar wrote:
>
> > ZyX wrote:
> >
> > > Consider the following script:
> > >
> > > echo strwidth(nr2char(0x1F48E))
> &
Consider the following script:
echo strwidth(nr2char(0x1F48E))
. It should display “2” because 0x1F48E is a fullwidth ruby symbol. But Vim
actually displays “1”. This causes rendering bugs at least in terminal because
unlike Vim terminal (Konsole) knows that ruby symbol occupies two display
On Sunday, November 23, 2014 12:48:39 AM UTC+3, Bram Moolenaar wrote:
> ZyX wrote:
>
> > While working on VimL parser I have seen *very* large number of these
> > cryptic error messages. I.e. consider the following line:
> >
> > sort no/some long regex/
>
While working on VimL parser I have seen *very* large number of these cryptic
error messages. I.e. consider the following line:
sort no/some long regex/
. This will give you `E474: Invalid argument` with no further explanation or an
exact position where error is located. I.e. it is indicati
Update: merged with upstream and extended documentation regarding &t_8f and
&t_8b.
diff -r 03a813f2cf51 -r 64d20b6d9488 runtime/doc/options.txt
--- a/runtime/doc/options.txt Thu Nov 20 23:07:05 2014 +0100
+++ b/runtime/doc/options.txt Sat Nov 22 18:38:22 2014 +0300
@@ -3401,6 +3401,18 @@
do_set from option.c contains the following code
(http://code.google.com/p/vim/source/browse/src/option.c?r=575e8caa46a23a700ef41276995a348bd502d3c2#4543)
value = strtol((char *)arg, NULL, 0);
if (arg[i] == '0' && TOLOWER_ASC(arg[i + 1]) ==
+writefile( {list}, {fname} [, {binary/append}])
Name `{binary/append}` is too lengthy and is compound. There are no names like
this elsewhere in eval.txt, so I suggest using `{flags}` or `{mode}`.
+ When {binary/append} is contains "b" binary mode is used:
`is` is incorrect here.
> This problem was already reported at least once. Do not remember any patches
> though.
https://groups.google.com/forum/#!searchin/vim_dev/langmap$20imap/vim_dev/HJaS5AxwYSE/UxJkOPZRT2EJ
There is an extended discussion there, including reply from Bram (only one):
> We could add an option 'nol
find any tests for :yank or :delete):
*** /tmp/extdiff.y9BxRE/vim-upstream.79c59b4c9d20/src/ex_docmd.c
2014-10-12 23:30:54.924767233 +0400
--- /home/zyx/a.a/Proj/c/vim-upstream/src/ex_docmd.c2014-10-12
23:30:01.284767830 +0400
***
*** 2485,2491
Updated patch with second approach:
# HG changeset patch
# User ZyX
# Date 1409287235 -14400
# Fri Aug 29 08:40:35 2014 +0400
# Node ID 93db73f6960f25b2ffb10b12010d524252b0ac4a
# Parent 0ccbf92e36c043ec944614b02f4c83f0f41929d6
Fix slice operations on partially locked list
Patch from https
On Sunday, August 17, 2014 9:28:25 PM UTC+4, ZyX wrote:
> And fourth: behave like map: do its job until lock occurs and fail at the
> first lock.
> * The above code was for :unlet, for :let slice assignment there should be
> something similar (except that option 3. will no longer b
And fourth: behave like map: do its job until lock occurs and fail at the first
lock.
* The above code was for :unlet, for :let slice assignment there should be
something similar (except that option 3. will no longer be consistent with
anything).
--
--
You received this message from the "vim
> So, what do you suggest? Do an "or" of the lock flag for all the items
> in the slice?
I see three possibilities:
1. Check locks in the same cycle listitem_remove is called (so items that are
not locked will be removed).
2. Add cycle just before it which will check locks before removal (so it
1. List item locked with lockvar may be set using slice assignment:
let l = [1, 2, 3, 4]
lockvar! l
unlockvar l[1]
let l[0:1] = [0, 1] " ^ Reports E741
echo l " [1, 2, 3, 4]
let l[1:2] = [0, 1]
echo l " [1, 0, 1, 4]
2. Same for :unlet: if
> Also, I'd say 4. should just use the actual settings rather than
> parse them from a Christmas tree of options. Vim tradition seems to be
> to leave it to the user to save and restore the context before doing the
> job.
And, by the way, setting &tabstop and &ambiwidth without &lazyredraw wi
> This seems useful, but do you _have_ to do all that in a single
> function? Perhaps 2. and 3. could be split into separate functions?
It does not make sense as long as 4. exists.
> Also, I'd say 4. should just use the actual settings rather than
> parse them from a Christmas tree of op
On Saturday, July 5, 2014 12:42:19 PM UTC+4, lith wrote:
> Hi!
>
> Let's assume files is ['foo(bar).txt']. Let's try
>
> :exec 'grep' fnameescape(join(files))
Are you sure you have written exactly what you want? If you assume files is
['a', 'b'] and these files exist,
:execute 'grep' f
> fnameescape() is for Vim commands. Since "grep" executes an external
> command you need to use shellescape(). And that does handle parens.
>
> :exe '!ls ' . shellescape('asdf(asdf)asdf')
> ls: cannot access asdf(asdf)asdf: No such file or directory
It is incorrect to use shellesca
> I agree 100% that it's broken. They still do it.
>
> For what it's worth, I had to look at the sources at many of said
> compilers to get syntastic to understand their output, and using virtual
> columns isn't *that* far fetched. Most of the time they just expand
> tabs while parsing a
Given recent discussion around matchaddpos() and the fact that converting
virtual column to byte offset has a larger variety of use cases (I personally
needed this to get -selected block without altering marks, registers,
cursor position, etc) I propose the new function colnr():
colnr :: (s
> +#define RUNTIME_AFTER RUNTIME_USER "/after"
>
> Older C compilers do not support this. I'm not sure which ones, it is
> not used yet in Vim.
I used it for exception messages in Python. It is also present in version.c:
https://bitbucket.org/ZyX_I/vim/src/ef30fcd05203feee8ca40a23ac75eed55549
> Here is an example:
> The original patch does this:
> ,
> | Lorem ipsum dolor sit amet,
> | consetetur sadipscing elitr,
> | sed
> | Lorem ipsum dolor sit amet,
> | >>consetetur sadipscing elitr,
> | >>sed
> `
>
> While the second version makes it more like this:
> ,
> |
On Saturday, April 19, 2014 8:16:41 PM UTC+4, ZyX wrote:
> Consider the following two operations:
>
> echo {} > {}
> echo [] > []
>
> . In first case Vim will report
>
> E736: Invalid operation for Dictionary
>
> (singular form). In the secon
Consider the following two operations:
echo {} > {}
echo [] > []
. In first case Vim will report
E736: Invalid operation for Dictionary
(singular form). In the second case Vim will report
E692: Invalid operation for Lists
(*plural* form).
--
--
You received this message fro
o allocate zero
bytes). Should probably be used to unset register/set it to an empty string.
# HG changeset patch
# User ZyX
# Date 1396645333 -14400
# Sat Apr 05 01:02:13 2014 +0400
# Node ID ef30fcd05203feee8ca40a23ac75eed55549c681
# Parent 8bf05884266be337087b025d22ce7aad0b8a29ec
Fix pr
> --- 12638,12664
> if (n == FALSE)
> {
> if (STRNICMP(name, "patch", 5) == 0)
> ! {
> ! if (name[5] == '-'
> ! && STRLEN(name) > 11
> ! && vim_isdigit(name[6])
> ! && vim_isdigit(name[8])
> ! && vim_
Consider the following script:
vim -u NONE -N /proc/meminfo /proc/cpuinfo -c next -c $ARG
where $ARG is one of
Next 1 ++enc=ucs4
Next 1 +echomsg1
Next /proc/cpuinfo
. In the first case it is expected to open /proc/meminfo in UCS4 encoding, but
it does not. It will if you remove
Consider the following script:
vim -u NONE -N xxx /proc/cpuinfo -c vsplit -c bnext -c e++enc=ucs4
(you can replace `/proc/cpuinfo` with any file that contains a few KiB of text
in encoding other then ucs4 and xxx with any file that does not exist).
You will see that characters from window s
According to the documentation `:e + file` should position cursor to the last
line of the file. This works for `:e + ` (`:e+`) and for `:e +
file` (again there is a space). But if you use `:e +` (`:e+`, no
trailing space) it will position the cursor at the start of the file.
Fix is simple:
dif
> Note that these curly-braces expressions are deprecated, especially
> because of this kind of problem.
I do not see deprecation warning in :h curly-braces-names. These expressions
are sometimes convenient (though I generally avoid them in a favor of regular
dictionaries).
This specific bug wa
> Thanks for your insights. It's not perfect but it's much better than
> I was
> originally thinking.
>
> I didn't say that string indexing has to be fixed. I said the
> inconsistencies
> had to be fixed. There is a difference.
>
> The inconsistency of looking at this:
On Sunday, March 30, 2014 5:59:34 PM UTC+4, Andre Sihera wrote:
> On 30/03/14 22:46, Dmitry Frank wrote:
>
> > let my_str = "こんにちわ世界"
>
> > let match_start = match(my_str, "世界", 0, 1)
>
> > echo strchars(my_str[: match_start - 1])
>
> So it is.
>
> And the reason I didn't know about this cunni
> String indexing *must* not fixed. As I said there is a number of plugins that
> need *exactly* bytes: any plugin implementing hash function. char2nr(s[i]) is
> guaranteed to return a value between 0x00 and 0xFF (inclusive) (0x00 is
> returned only if s[i] is an empty string).
There are basica
On Sunday, March 30, 2014 5:00:13 PM UTC+4, Andre Sihera wrote:
> On 30/03/14 20:32, Yasuhiro MATSUMOTO wrote:
> Now this is interesting.
>
> index() does indeed split on character, not byteboundaries. However, even if
> I can do this:
>
> split("こんにちわ世界", '\zs')
>
> to get this:
>
>
d, '=') is used. To do
this correctly one needs to use
expr = skipwhite(argend);
if (*expr != '=' && !(vim_strchr("+-.", *expr) != NULL && expr[1] == '='))
# HG changeset patch
# User ZyX
# Date 1396172847 -14400
# Sun Mar 30 13:47:
> 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 you add hacks for
some specific cases (e.g. if `execute` is followed by a string litera
According to the documentation :lunmap can be abbreviated as :lu. But it can
only be abbreviated as :lun because :lu is taken by :lua (whose help does not
say about any abbreviation).
Knowing that :lua is relatively recent addition and :lunmap with its
abbreviation existed at least since 7.0.1
Consider the following script:
execute 'if 0'
echo 'Not shown'
else
echo 'Shown'
endif
. If you source it you find that instead of 3 errors (“missing :endif”, “:else
without :if”, “:endif without :if”) and two messages (“Not shown” and “Shown”)
you will see one messa
> Isn't this to do with the fact that "<(...)" causes the shell to create
> a temporary file
It does not. It is =(...) that uses temporary files (assuming you use zsh),
<(...) creates file descriptors before forking and attaches them to ...’s
stdout.
> which is then sourced by ViM, and in ViM,
> I think you meant:
>
> vim -u NONE 1 2 3 -c 'bufdo if 1 | echo 1'
>
> doesn't complain about the missing "endif". As it happens, the "while"
> example
> doesn't complain either.
This or “in place of complaining about endwhile”, does not matter. Title says
about block commands, you will have
Documentation (quickfix.txt) defines the following incorrect abbreviations
Full | Listed | Correct
-- | -- | ---
caddexpr | cad| cadde
laddexpr | lad| ladde
caddbuffer | caddb | cad
laddbuffer | laddb | lad
--
--
You received this mess
The following script will echo 1 three times without any errors in place of
complaining about missing endif:
vim -u NONE 1 2 3 -c 'bufdo while 1 | echo 1'
. The following script will ask user three times for endif:
vim -u NONE 1 2 3 -s <(echo ':bufdo if 1 | echo 1')
.
--
--
You rece
Consider the following script:
vim -u NONE -N -s <(echo -E ':execute "append\nabc\n."')
. It prompts for user input, but it is expected to act like
vim -u NONE -N -c 'execute "append\nabc\n."'
which just appends abc.
--
--
You received this message from the "vim_dev" maillist.
Do not
If you type `:bufdo $append` 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 buffer is being processed.
2. It is hard to understand that cursor in the command-line with
Consider the following script:
LANG=ru_RU.UTF-8 vim -u NONE --cmd 'try|finally|catch|endtry'
. You will see message
E604: :catch без :finally: catch|endtry
which is translated from Russian as “:catch without :finally”. But with English
locale this message is the following:
E604: :
On Friday, March 14, 2014 2:04:26 AM UTC+4, Viktor Kojouharov wrote:
> It contains the full path which was used to start vim. It could very well be
> a relative path, or be the same as progname, if vim was run started from the
> $PATH, but wouldn't the value be enough to start another instance of
On Thursday, February 20, 2014 12:50:13 AM UTC+4, Juan Campa wrote:
> On Wednesday, January 15, 2014 9:44:24 AM UTC-5, Ben Fritz wrote:
> > I thought the idea of this patch, was to allow background threads to send
> > Vim a message, that says "when you get a chance, run function X". Then, at
> >
uot;)
debug call Abc()
0debuggreedy
. When launched with
vim -u NONE -S bug.vim
this prints the following:
Entering Debug mode. Type "cont" to continue.
/home/zyx/a.a/Proj/c/zsh/bug.vim
line 14: call Abc()
>n
:return made pending
Exception t
On Tuesday, February 11, 2014 11:54:46 PM UTC+4, ZyX wrote:
> PyErr_Format("%ld") is supported since python 2.5. Officially we support
> python 2.4 and older. Thus you should either drop support for python 2.4 or
> cast to (int). I was using the latter, though I cannot re
PyErr_Format("%ld") is supported since python 2.5. Officially we support python
2.4 and older. Thus you should either drop support for python 2.4 or cast to
(int). I was using the latter, though I cannot recall whether I just forgot to
add type casts when transforming %ld I wanted to use initial
> Main question is: what would the student work on?
I suggest reworking input since it is demanded, not too easy, but most likely
doable. Though there are other jobs: multitasking (not threading: that would be
too hard) (there is a good head start with existing patches), improving
language bind
> A quick search reveals this:
>
> http://www.greenend.org.uk/rjk/tech/putenv.html
>
> According to this guy unsetenv() was added in Solaris 5.10, which is
> now ~10 years old. On Solaris you could modify *environment directly,
> but IIRC on OSF/1 that was explicitly forbidden.
Th
> You mean SysV does not have C function for unsetting environment? I guess
> this is why zsh has coded direct environ global manipulations (controlled by
> USE_SET_UNSET_ENV). We can probably borrow code from there. I cannot say
> though in which systems **environ is supported, but both bash an
> IIRC, SysV had putenv(3), while BSD had setenv(3). The latter had a
> corresponding unsetenv(3), while the former didn't.
>
> > On my Ubuntu Linux system, the unsetenv(3) man page says that it
> > conforms to 4.3BSD and POSIX.1-2001.
>
> POSIX? As Wietse Venema used to put it, you're
On Monday, February 3, 2014 8:14:37 AM UTC+4, Ernie Rael wrote:
> I'm confused about something. With the release binary of 7.4 on
> windows, for
>
> echo exists("$xyzzy")
>
>
> the following two give different results (xyzzy is not in the
> shell's environment).
>
> xyz
> Before you sit there in your arrogance and blast every suggestion
> that is put before you, why don't you READ people's posts.
I do not always use mild words, but I do read them. I have never blasted
anything without explaining why.
I see two messages where you are ignoring the fact that
On Monday, February 3, 2014 7:22:28 AM UTC+4, Andre Sihera wrote:
> On 03/02/14 11:57, ZyX wrote:
>
> >
>
> > `exists()` does not have to be changed. Neither does result of accessing
> > non-existent. I am only talking about `:unlet`.
>
>
>
> Before yo
> It appears that we have two conflicting requirements here when only one
> can be supported.
No.
> On the one hand we have ViM's current behaviour as pointed out by Bram:
>
> On 03/02/14 02:54, Bram Moolenaar wrote:
> >
> > Historically environment variables cannot be deleted, only made empty
On Monday, February 3, 2014 12:52:48 AM UTC+4, Bee wrote:
> On Sunday, February 2, 2014 12:06:25 PM UTC-8, ZyX wrote:
> > > How about using a shell script:
> > ? I am talking about unsetting environment variables which are set in vim.
> > How is this script related?
>
> How about using a shell script:
>
> #!/bin/sh
> vimx=`which vim`
> PATH=""
> echo $PATH
> exec $vimx
>
> Then in vim:
> :echo $PATH
> returns empty.
>
> That way you do not disturb the system PATH.
? I am talking about unsetting environment variables which are set in vim. How
is this script
> Historically environment variables cannot be deleted, only made empty.
> It's not a good idea to check for existence, check for it being
> non-empty instead.
Do not tell it me. There is an example: if PYTHONDUMPREFS variable is set for
debug build of python, no matter whether or not it is empty
> Note: INTERNAL to vim
And guess where they are actually stored? In vim process memory. In linux there
is a special global variable that is manipulated by various *env functions (see
“man getenv”, there is a “SEE ALSO” list at the bottom). AFAIR I saw direct
manipulations of this global in zsh
If I do
vim -u NONE -c 'unlet $PATH'
I get “E488: Trailing characters” error.
That means that there is no way to get rid of environment variable after it was
set which may be essential if tools using variables check for their existence,
not for their contents (e.g. in tcsh scripts checking
On Wednesday, January 29, 2014 5:21:20 PM UTC+4, antonis@gmail.com wrote:
> On Wednesday, March 23, 2011 12:02:57 AM UTC+2, Bram Moolenaar wrote:
> > Tobias Columbus wrote:
> >
> > > > On Tuesday 22 March 2011 13:40:19 you wrote:
> > > > > Kearn Holliday reported that this Python command crash
The following patch should fix the problem:
# HG changeset patch
# User ZyX
# Date 1390927556 -14400
# Tue Jan 28 20:45:56 2014 +0400
# Branch VimTryEnd-current_exception-fix
# Node ID 5595c64ce5eaeefe60958ae5cb93f9f1ab359a0c
# Parent c9cad40b418113f62ce3481f66351137b90910ef
Only work with
On Tuesday, January 28, 2014 1:02:20 AM UTC+4, Daniel Hahler wrote:
> Hello,
>
> I have experienced a crash issue between vdebug and the easytags plugin [1],
> and came up with the following code to reproduce it.
>
> Test case:
>
> 1. Create a file (e.g. /tmp/vimrc) with the following cont
> But all other Ex command have a tag starting with :. Thus it wasn't
> consistent before. Oh well, let's add both for now.
:s/\= is not referring to an ex command. Worse, it is not referring to ex
command argument or a part of it. It is referring to a part of an argument that
is common for *t
changeset patch
# User ZyX
# Date 1389066029 -14400
# Tue Jan 07 07:40:29 2014 +0400
# Branch remove-no_autoload-global
# Node ID 7b182c0bfaf563de5b977e8773c409fef2457297
# Parent bc19475ed196b91bf1ecda2224d88a47b5b497bb
Replace no_autoload global with arguments and flags
diff -r bc19475ed1
> Thank you for finding it out. I didn't notice it.
>
> Perhaps there is another problem that exists('x[y#z()]') doesn't trigger
> autoload.
There is. The very good probability of such bugs is one of the reasons why I
did not even consider adding similar global in extended funcref patch when I
> Yes, I am.
You should not be.
let d={}
echo exists('*d[extend(g:, {"Foo#x": function("tr")})]')
. f_exists() sets no_autoload to TRUE, dict_extend() runs var_check_func_name()
which you have modified setting it back to FALSE before f_exists ends. f_exists
should by the way save no_au
> I meant for the web downloader, where does that come from? I assume always
> from git.
What web downloader? All sources are defined in VAM-kr.
> > You can use git archive from github, but this is a fallback option only in
> > case git, mercurial and bazaar executables are not available or mer
> That looks cool...but where does it pull from? Some plugins I pretty much
> always pull from vim.org, other plugins I like downloading the latest
> revision in an archive from github.
>From wherever available. If VAM knows about git source it will use it. There
>is a setting to disable all so
On Tuesday, December 24, 2013 8:53:19 PM UTC+4, Ishfaque Jahan Rafee wrote:
> Its been a pleasure discussing with you. I learnt a lot from it. @MarcWeber
> thanks a lot for your cordial response. I use some of your plugins & love
> them.
>
> Some of you, I think got me wrong. I am not a Vim hat
I found some problems in makefiles:
src/Makefile contains references to test104, test105, test106 and test107
which do not exist.
src/testdir/Make_ming.mak contains test100out in SCRIPTS while it should be
test100.out (note the dot).
They should be fixed with the following patch:
diff
> forgive my banality, but by any chance is there an extra 's' in the
> subject of this email?
Function was named in such a way because vim.foo objects are normally defined
with Foo* functions and vim.options is named vim.options and not vim.option
because it grants access to the number of optio
eck the attached patch.
>
> Additionally, I found one suspicious part:
> c:\work\vim-msvc\src\if_py_both.h(3008) : warning C6246: Local declaration of
> 'todecref' hides declaration of the same name in outer scope. For additional
> information, see previous declaration at
# HG changeset patch
# User ZyX
# Date 1386410239 -14400
# Sat Dec 07 13:57:19 2013 +0400
# Branch fix-sa-warning-1
# Node ID c87415f3c0adc44106d6c2944c53f721c94cc6f5
# Parent 486655e0c5a21469364d3cf895535137f09b3724
Fix error found by @Ken Takata
diff -r 486655e0c5a2 -r c87415f3c0ad src
On Thursday, December 5, 2013 6:19:25 AM UTC+4, Brook Hong wrote:
> I'd also like to use as leader key, as the issue reporter.
> https://code.google.com/p/vim/issues/detail?id=125
>
> diff --git a/src/normal.c b/src/normal.c
> index 013fdce..cb092a0 100644
> --- a/src/normal.c
> +++ b/src/normal.
eset patch
# User ZyX
# Date 1385842851 -14400
# Sun Dec 01 00:20:51 2013 +0400
# Branch S-modifier
# Node ID ce302bfd3622491bed0267bc6fedad0eb7cfc221
# Parent 486655e0c5a21469364d3cf895535137f09b3724
Add %:S filename modifier
diff -r 486655e0c5a2 -r ce302bfd3622 runtime/doc/cmdline.txt
must not be there. This should fix “newlines in
{expr} may cause the command to fail” from system() documentation as as far as
I see it is shellescape() problem and not system().
# HG changeset patch
# User ZyX
# Date 1385842851 -14400
# Sun Dec 01 00:20:51 2013 +0400
2013 +0400
@@ -53,9 +53,6 @@
Patch to fix building with Ruby on Cygwin. (Steve Hall, 2013 Nov 21)
-Patch to fix that in Python vim.eval errors are not caught by try/catch.
-(ZyX, 2013 Nov 26)
-
Problem that a previous silent ":throw" causes a following try/catch not to
work. (ZyX, 2
This is a fix for https://groups.google.com/forum/#!topic/vim_use/UW3YAAQ5ulk.
# HG changeset patch
# User ZyX
# Date 1385490752 -14400
# Tue Nov 26 22:32:32 2013 +0400
# Branch fix-vim.eval-throw
# Node ID 50125a7e0dea60b72db9fc73ccd5bcc697d788cf
# Parent
On Saturday, November 9, 2013 10:25:18 PM UTC+4, ZyX wrote:
> On Nov 9, 2013 6:46 PM, "Tom Jones" wrote:
> >
> > # fine
> > ---
> > - key1: foo
> > - key2: bar="abc"
> > - key3: qwerty
> >
> > # fine
>
The sequence is finished and should be ready for inclusion. I can add tests for
system()/readshell(), but only if somebody will tell me what preconditions I
should rely on (e.g. POSIX shell with at least printf; or working cat or type).
There is also a lack of tests for readfile()/writefile(), b
# HG changeset patch
# User ZyX
# Date 1383994886 -14400
# Sat Nov 09 15:01:26 2013 +0400
# Branch NL-funcs
# Node ID c25ccecf79b681e79005bb0b8aed9153094ce207
# Parent 268983a1e62d0f05a1cb9658a65e4578128f7f2c
Add type cast
diff --git a/src/ops.c b/src/ops.c
--- a/src/ops.c
+++ b/src/ops.c
1 - 100 din 750 matches
Mail list logo
