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
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 preference by
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:
NeoVim project tried to do
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:
NeoVim project tried to do this and found
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 want just
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
documentation needs
# HG changeset patch
# User ZyX kp-...@yandex.ru
# 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
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
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 `so …` without escaping anything
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-byte utf-8
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 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))
. It should display “2” because 0x1F48E is a fullwidth ruby symbol
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:
Consider the following script:
echo strwidth(nr2char(0x1F48E
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 Moolenaar wrote:
ZyX wrote:
Consider
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:
Hi Bram!
On Fr, 05 Dez 2014
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
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
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/
. This will give you `E474: Invalid
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
):
*** /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
if (
#ifdef FEAT_USR_CMDS
valid_yank_reg
Updated patch with second approach:
# HG changeset patch
# User ZyX kp-...@yandex.ru
# Date 1409287235 -14400
# Fri Aug 29 08:40:35 2014 +0400
# Node ID 93db73f6960f25b2ffb10b12010d524252b0ac4a
# Parent 0ccbf92e36c043ec944614b02f4c83f0f41929d6
Fix slice operations on partially locked list
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
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 items
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
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 be consistent
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 will for
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 shellescape()
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'
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 C-v-selected block without altering marks, registers,
cursor position, etc) I propose the new function colnr():
colnr
+#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:
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:
,
| Lorem ipsum
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 from
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 second case Vim will report
E692: Invalid
--- 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_isdigit(name[10]))
(+-., *expr) != NULL expr[1] == '='))
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1396172847 -14400
# Sun Mar 30 13:47:27 2014 +0400
# Branch fix-let-curly-brace-eq
# Node ID 65a5c984027e8587502bcf6252b3bf0e756740e5
# Parent 70fac246bfe4128c74f8312b48a408c4cca1ed7b
Fix :let var1 {0==1
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:
['こ', 'ん',
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 basically
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 cunning trick is due
According to the documentation `:e + file` should position cursor to the last
line of the file. This works for `:e + ` (`:espace+space`) and for `:e +
file` (again there is a space). But if you use `:e +` (`:espace+`, no
trailing space) it will position the cursor at the start of the file.
Fix
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 literal
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:
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 buffer is being processed.
2. It is hard to understand that cursor in the command-line
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
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
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
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 the same
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, all
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
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
some
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 thrown: Vim(return):E724: variable nested
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
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 recall whether I just
forgot
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
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 and
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.
Then I
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
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
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,
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 related?
Also
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?
Your original post said:
vim -u
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 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 you sit there in your arrogance and blast every
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 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).
xyzzy=x vim
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 crashes
some
The following patch should fix the problem:
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1390927556 -14400
# Tue Jan 28 20:45:56 2014 +0400
# Branch VimTryEnd-current_exception-fix
# Node ID 5595c64ce5eaeefe60958ae5cb93f9f1ab359a0c
# Parent c9cad40b418113f62ce3481f66351137b90910ef
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 contents.
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
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
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
in flags passed to some functions.
Changed behavior: lockvar and islocked() no longer trigger script autoloading
(except for evaluating nested expressions like
islocked('not#autoloaded#dict[autoloaded#function()]')). Do not think anybody
actually relied on this.
# HG changeset patch
# User ZyX kp
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
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
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 hater.
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
declaration of
'todecref' hides declaration of the same name in outer scope. For additional
information, see previous declaration at line '2930' of
'c:\work\vim-msvc\src\if_py_both.h': Lines: 2930
Maybe it's better to ask to ZyX.
It seems that Py_XDECREF() is not called after the call
Is this sufficient to explain what this does exactly?
Perhaps a few more references are needed in the help, it's not easy to
guess that escaping can be done this way.
Done. Here two changesets are exported, update is in the second one. c.diff
contains both:
# HG changeset patch
# User ZyX
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 kp-...@ya.ru
# Date 1385842851 -14400
# Sun Dec 01 00:20:51 2013 +0400
# Branch S-modifier
# Node ID
This is a fix for https://groups.google.com/forum/#!topic/vim_use/UW3YAAQ5ulk.
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1385490752 -14400
# Tue Nov 26 22:32:32 2013 +0400
# Branch fix-vim.eval-throw
# Node ID 50125a7e0dea60b72db9fc73ccd5bcc697d788cf
# Parent
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1383992075 -14400
# Sat Nov 09 14:14:35 2013 +0400
# Branch NL-funcs
# Node ID 268983a1e62d0f05a1cb9658a65e4578128f7f2c
# Parent 5938d7011707823ab1a66bc3b3fe554ab9539e7a
Make system() support second argument that is a list.
Note: system
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1383995203 -14400
# Sat Nov 09 15:06:43 2013 +0400
# Branch NL-funcs
# Node ID b719d5d95852adc804831af9c524db3640382067
# Parent c25ccecf79b681e79005bb0b8aed9153094ce207
Add readshell() function
diff --git a/runtime/doc/eval.txt b/runtime
# HG changeset patch
# User ZyX kp-...@ya.ru
# 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
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(),
On Saturday, November 9, 2013 10:25:18 PM UTC+4, ZyX wrote:
On Nov 9, 2013 6:46 PM, Tom Jones mesek...@gmail.com wrote:
# fine
---
- key1: foo
- key2: bar=abc
- key3: qwerty
# fine
---
- key1: foo
- key2: bar x
- key3: qwerty
# broken, thinks
Replies here (in the mailing list) are not posted to the issue tracker
(http://code.google.com/p/vim/issues/detail?id=177). I am not sure OP will see
your reply. Likely not if he is not subscribed.
When writing replies to issues it is best to write them from web interface.
--
--
You received
This means in Vim 7.4 Vim script stops after a Vim error occurs in
Python code. This seems very wrong to me. Vim script writers are used
to the fact that VimL code execution does not stop after an error
unless there is a try/catch or when function has abort argument.
Code that relies on this
compatibility new function is to be defined.
5. system() again, now the second argument: no way to pass Nul to an external
command. Should accept a list, just like setreg().
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1383485698 -14400
# Sun Nov 03 17:34:58 2013 +0400
# Branch NL-funcs
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1383490773 -14400
# Sun Nov 03 18:59:33 2013 +0400
# Branch NL-funcs
# Node ID d15f8c220a1f84d0b372272adfe430b7a599f486
# Parent 5d29bb3409c9e046fb7a08dcc585dc80362bf758
Add third optional argument to getreg()
Note: it appears that getreg
It's a great idea to address this issue, but in my opinion the
documentation can be improved. :) It should be explained what said list
consist of, and I think the reference to getline() is confusing at best.
/lcd
There are basically two functions which return a list like this:
.__contains__ is
faster though.)
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1383332303 -14400
# Fri Nov 01 22:58:23 2013 +0400
# Branch python-.options
# Node ID f332d6dfb4749c7fc7f1f4961b8e817ce3cba46b
# Parent 92c9748e0ccbc42a5e28ce8fb9b8818e756a06da
Add options iterator
diff -r
Forgot c.diff.
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1383332303 -14400
# Fri Nov 01 22:58:23 2013 +0400
# Branch python-.options
# Node ID f332d6dfb4749c7fc7f1f4961b8e817ce3cba46b
# Parent 92c9748e0ccbc42a5e28ce8fb9b8818e756a06da
Add options iterator
diff -r 92c9748e0ccb -r
On Friday, November 1, 2013 10:51:48 AM UTC+4, Nirk Niggler wrote:
From structs.h:
# define DB_COUNT 4/* up to four buffers can be diff'ed */
Is there a compelling reason to keeping the limit at 4 rather than upping it
to a limit like 9?
I do not know reason for 4 (though @LCD 47
I recompiled vim with a DB_COUNT of 5, and that successfully worked to
diff five files. I suspect that the DB_COUNT limit can be raised
without difficulty. I suspect that with a bit of coding that the
DB_COUNT could be made arbitrary (ie. dependent upon how many files are
being
Without this patch vim crashes on added tests (`0 in vim.Dictionary()` and `
in vim.Dictionary()`)
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1383332846 -14400
# Fri Nov 01 23:07:26 2013 +0400
# Branch python-dictionary-contains
# Node ID 5aed0175472a6f79ed2727441ffe524ec7282837
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1382894384 -14400
# Sun Oct 27 21:19:44 2013 +0400
# Branch typo-1
# Node ID c5f7f666d4020ae9d446978ccddba386d2454b3e
# Parent 92c9748e0ccbc42a5e28ce8fb9b8818e756a06da
Fix typo in the comment in main_loop() function
diff -r 92c9748e0ccb -r
On Sunday, October 27, 2013 6:54:16 PM UTC+4, Michael Henry wrote:
On Sat, Oct 26, 2013 at 12:50 PM, Bram Moolenaar b...@moolenaar.net wrote:
I already said this: It's fine to add so long as it's 100% backwards
compatible. That means encoding keys on top of what's already there,
and
Here is the updated patch:
# HG changeset patch
# User ZyX kp-...@ya.ru
# Date 1381860915 -14400
# Tue Oct 15 22:15:15 2013 +0400
# Node ID 3f2e288daa4b92ea22139b213621e90b20f500f0
# Parent 92c9748e0ccbc42a5e28ce8fb9b8818e756a06da
When skipping allow any expression to pretend being
1 - 100 din 703 matches
Mail list logo
