Re: Why is v:none needed?
On Sun, Feb 7, 2016 at 8:17 AM, Bram Moolenaar wrote:
>
> Tyru wrote:
>
>> >> Sorry Bram, I forgot to send this mail to vim_dev.
>> >> Send again with +alpha about problems of current JSON features.
>> >>
>> >> On Sat, Feb 6, 2016 at 11:50 PM, Bram Moolenaar
>> >> wrote:
>> >> >
>> >> >> What do you think about this?
>> >> >
>> >> > I don't want to spend much time discussing this. v:null and v:none are
>> >> > needed just like JavaScript has null and undefined.
>> >> >
>> >> > I was thinking of taking this a step further to a more efficient
>> >> > encoding that is similar to Javascript. Unfortunately I haven't been
>> >> > able to find a specification. I thought it was used in combination with
>> >> > protocol buffers. Besides empty entries in an array, it also removes
>> >> > the quotes around object item names. It's more efficient and doesn't
>> >> > drop any functionality. We could add protocol buffer support, but let's
>> >> > leave that for some other time.
>> >> >
>> >> > Also keep in mind that when you want to stick to the JSON standard
>> >> > (well, one of them), you should not write the string yourself but use a
>> >> > library to create it. Arguments that it's hard to type or spot a
>> >> > mistake are hardly relevant.
>> >>
>> >> Okay.
>> >> Now I know you seem to follow JavaScript syntax rather than JSON standard.
>> >
>> > True. Perhaps we should split this and add jsencode() / jsdecode().
>>
>> Sounds great!
>> Do you have the plan to add jsencode() / jsdecode() ?
>> Or, will you merge the patch for those functions if I write?
>
> Feel free to make a patch.
Okay, thanks!
>
>> >> But please remind JSON is not only for JavaScript.
>> >> It might be used for a communication with Vim and scripts, external
>> >> commands, and so on.
>> >>
>> >> And more, currently, 'jsonencode({"key": v:none})' produces output
>> >> '{"key":}'.
>> >> This is not even a correct JavaScript syntax.
>> >
>> > I'll fix that.
>>
>> Thanks!
>> Now I confirmed that 7.4.1269 raises an E474 error for the expression.
>> But yet it seems to return the string ('{"key":}').
>> Is it intentional?
>
> When there is an error it returns what it has. Would it be better to
> return nothing?
Hmm, patch 7.4.1270 seemed to fix this temporarily last night
and the result was totally what I was thinking;
which returns 'v:none' instead of what it has.
An explicit error return value is better I think
because immediately we can notice something went wrong.
and if only a user checks the return value (without surrounding :try ~ :catch),
a user can detect an error, like 'delete()' returns -1 with an error.
let json = jsonencode({"key": v:none})
if json is v:none
echoerr 'error!'
return ...
endif
And sorry, tyru is a nickname.
The real name is Takuya Fujiwara.
I think you prefer a real name :)
(changed my nickname on google groups, too)
(oh, ':helpgrep Tyru' also shows my nickname in some places...)
>
>
> --
> You're as much use as a condom machine at the Vatican.
> -- Rimmer to Holly in Red Dwarf 'Queeg'
>
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Anybody has a BeBox or BeOS system?
__BEOS__ did not work, but __HAIKU__ did. That might take BeOS off
the support list, but put on Haiku. That might be okay. We're just
shy of 16 on a proper BeOS release. Haiku is 3 years out, in alpha,
but is still looking for funding in 2016.
FWIW
Thanks!
SB
On Sat, Feb 6, 2016 at 6:17 PM, Bram Moolenaar wrote:
>
> Shaun Brady wrote:
>
>> Attached.
>>
>> I removed the line to #include osdef.h and yes it compiled it worked.
>>
>> I think the terminal emulation might be a bit wonky on BeOS or there
>> was another problem, as I didn't see --INSERT--, but I did go in to
>> insert mode upon pressing 'i'. Wrote a file to /tmp/
>>
>> Running the tests ('make test'?) didn't have as much luck; the tail attached.
>
> Thus it sort of works. To exclude auto/osdef.h does this work:
>
> *** ../vim-7.4.1273/src/vim.h 2016-02-04 22:09:44.692012667 +0100
> --- src/vim.h 2016-02-07 00:06:30.004287511 +0100
> ***
> *** 290,296
>* glibc-2.2.5 has them in their system headers.
>*/
> #if !defined(__cplusplus) && defined(UNIX) \
> ! && !defined(MACOS_X) /* MACOS_X doesn't yet support osdef.h */
> # include "auto/osdef.h" /* bring missing declarations in */
> #endif
>
> --- 290,296
>* glibc-2.2.5 has them in their system headers.
>*/
> #if !defined(__cplusplus) && defined(UNIX) \
> ! && !defined(MACOS_X) && !defined(__BEOS__)
> # include "auto/osdef.h" /* bring missing declarations in */
> #endif
>
>
>
> --
> hundred-and-one symptoms of being an internet addict:
> 164. You got out to buy software, instead of going out for a beer.
>
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1246
On Wed, Feb 3, 2016 at 2:10 PM, LCD 47 wrote:
> On 3 February 2016, Bram Moolenaar wrote:
>>
>> Lcd wrote:
>>
>> > On 3 February 2016, Danek Duvall wrote:
>> > [...]
>> > > I think the most reliable thing to do here is to have a way to
>> > > know the pid and kill it directly, but since ! goes through
>> > > a shell, you don't have any way of knowing what the pid of
>> > > test_channel.py is.
>> >
>> > Or just make the server write its PID to a file with an unique
>> > name. This is still not ideal, but it's probably good enough for
>> > tests.
>>
>> Like we do for the port number. OK, that can work for now. But we
>> need job control functionality anyway. We should use that once it's
>> implemented.
>>
>> Vim can already start jobs, but currently always waits for them to
>> finish (with "!cmd" or system("cmd")). Should not be too difficult to
>> run a job in the background and get its PID. At least on Unix, not
>> sure about MS-Windows.
>
> Sure, job control is long overdue, but IMO it wouldn't be simple.
> Once you can put a process in background you need to be able to deal
> with a table of background processes, and this means waitpid(), SIGCHLD
> (perhaps mapped to an autocmd), kill(), timeouts, select(), pipes, the
> full range of file redirections, and careful (OS-dependent) handling of
> a pile of signals.
>
> That said, it would be a game changer. People came up with things
> like vimproc:
>
> https://github.com/Shougo/vimproc.vim
>
> And then vimproc's interface was found to be too low-level, so they
> came up with quickrun, which builds over vimproc:
>
> https://github.com/thinca/vim-quickrun
>
> A simpler (but in many ways less satisfactory) aproach might be
> dispatch:
>
> https://github.com/tpope/vim-dispatch
>
> There are other, somewhat less popular approches:
>
> https://github.com/idbrii/AsyncCommand
> https://github.com/xolox/vim-misc
> https://github.com/xolox/vim-shell
>
> And then there's NeoVim, which has an embedded terminal to deal with
> all this. :)
Neovim uses libuv[1] to achieve job control in a well-tested,
widely-used (node.js...) cross-platform manner. The embedded terminal
is provided by libvterm[2]. libuv runs on every platform that Vim *in
reality* runs on. Recently, Vim finally admitted that it doesn't run
on DOS, Win95, and Amiga. Perhaps using a widely-used cross-platform
library like libuv is worth considering for Vim, instead of
re-inventing it.
[1] https://github.com/libuv/libuv
[2] http://bazaar.leonerd.org.uk/c/libvterm/
---
Justin M. Keyes
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [bug] segfault when error happens during execution of :catch
Dominique Pellé wrote: > Steps to reproduce the crash: > > $ vim -u NONE -N -S crash.vim > Vim: Caught deadly signal SEGV > > Press ENTER or type command to continueVim: Finished. > > Segmentation fault (core dumped) > > Where crash.vim is the attached file. Sorry for the confusion. I attached the wrong file in my previous email. I now attach the correct file. $ cat crash-catch.vim s try s catch t =~ '' $ vim -u NONE -N -S crash-catch.vim Vim: Caught deadly signal SEGV Regards Dominique -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. crash-catch.vim Description: Binary data
[bug] segfault when error happens during execution of :catch
Hi
afl-fuzz found a crash with vim-7.4.1273 (and older).
Vim-7.4.52 that comes with xubuntu-14.04 does not crash.
I did a 'git bisect' to find when regression was introduced
and crash was introduced in this commit:
===
$ git bisect bad
e0ad365498399c1bd34dd6361b3f7dc38e84e4ca is the first bad commit
commit e0ad365498399c1bd34dd6361b3f7dc38e84e4ca
Author: Bram Moolenaar
Date: Tue Jan 27 12:59:55 2015 +0100
updated for version 7.4.593
Problem:Crash when searching for "x\{0,9}". (Dominique Pelle)
Solution: Bail out from the NFA engine when the max limit is much higher
than the min limit.
===
Steps to reproduce the crash:
$ vim -u NONE -N -S crash.vim
Vim: Caught deadly signal SEGV
Press ENTER or type command to continueVim: Finished.
Segmentation fault (core dumped)
Where crash.vim is the attached file.
Looking with gdb, vim crashes at ex_eval.c:1581 when
dereferencing current_exception which is NULL:
Program received signal SIGSEGV, Segmentation fault.
ex_catch (eap=0x7fffc510) at ex_eval.c:1581
1563│ save_cpo = p_cpo;
1564│ p_cpo = (char_u *)"";
! 1565│ regmatch.regprog = vim_regcomp(pat, RE_MAGIC
+ RE_STRING);
1566│ regmatch.rm_ic = FALSE;
1567│ if (end != NULL)
1568│ *end = save_char;
1570│ if (regmatch.regprog == NULL)
1571│ EMSG2(_(e_invarg2), pat);
1572│ else
1573│ {
1574│ /*
1575│ * Save the value of got_int and reset
it. We don't want
1576│ * a previous interruption cancel
matching, only hitting
1577│ * CTRL-C while matching should abort it.
1578│ */
1579│ prev_got_int = got_int;
1580│ got_int = FALSE;
!!1581├>caught = vim_regexec_nl(®match,
current_exception->value,
1582│ (colnr_T)0);
1583│ got_int |= prev_got_int;
1584│ vim_regfree(regmatch.regprog);
1585│
(gdb) bt
#0 ex_catch (eap=0x7fffc510) at ex_eval.c:1581
#1 0x00467f33 in do_one_cmd (cookie=0x7fffcb30,
fgetline=0x45c750 , cstack=0x7fffc5e0, sourcing=1,
cmdlinep=0x7fffc460) at ex_docmd.c:2930
#2 do_cmdline (cmdline=cmdline@entry=0x86ce10 "s",
fgetline=fgetline@entry=0x45c750 ,
cookie=cookie@entry=0x7fffcb30, flags=flags@entry=7) at
ex_docmd.c:1116
#3 0x0045cce2 in do_source (fname=fname@entry=0x86cbb3
"crash.vim", check_other=check_other@entry=0,
is_vimrc=is_vimrc@entry=0) at ex_cmds2.c:3469
#4 0x0045d36c in cmd_source (fname=0x86cbb3 "crash.vim",
eap=) at ex_cmds2.c:3082
#5 0x00467f33 in do_one_cmd (cookie=0x0, fgetline=0x0,
cstack=0x7fffcef0, sourcing=1, cmdlinep=0x7fffcd70) at
ex_docmd.c:2930
#6 do_cmdline (cmdline=cmdline@entry=0x825b80 "so crash.vim",
fgetline=fgetline@entry=0x0, cookie=cookie@entry=0x0,
flags=flags@entry=11) at ex_docmd.c:1116
#7 0x0046bbee in do_cmdline_cmd (cmd=cmd@entry=0x825b80 "so
crash.vim") at ex_docmd.c:721
#8 0x00409031 in exe_commands (parmp=0x7fffd460) at main.c:2917
#9 main (argc=, argv=) at main.c:960
(gdb) p current_exception
$1 = (except_T *) 0x0
(gdb) p did_throw
$2 = 0
I see that the block of code should not be entered if did_throw was 0 (see if
at ex_eval.c:1538). And in fact did_throw was 1 at line 1538, but it got
changed later to 0 when calling vim_regcomp() at line ex_eval.c:1565.
Not sure how to fix this.
Regards
Dominique
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
crash.vim
Description: Binary data
Re: Feature or bug? dw oddities
On Sat, Feb 6, 2016 at 3:05 PM, Christian Brabandt wrote: […] >> There are a few more places in the docs that need to point to this flag. >> Also, plugin writers must be aware of the two different behaviors. > > Alright, I'll post an update later. > >> Is there a better character than "_" to use for this? > > Hm, not sure. We are slowly running out of characters there. I'll check > that again. > > Perhaps we should start to use letters from other alphabets. I hear > cyrillic has some beautiful letters ;) > > Best, > Christian Well, so it does: Аа Бб Вв Гг Дд Ее Ёё Жж Зз Ии Йй Кк Лл Мм Нн Оо Пп Рр Сс Тт Уу Фф Хх Цц Чч Шш Щщ Ъъ Ыы Ьь Ээ Юю Яя (the above are from Russian Cyrillic; other varieties are each slightly different) and so does Greek (even not counting accents, breathings and diæresis): Αα Ββ Γγ Δδ Εε Ζζ Ηη Θθ Ιι Κκ Λλ Μμ Νν Ξξ Οο Ππ Ρρ Σσς Ττ Υυ Φφ Χχ Ψψ Ωω but not easy to type on a Western keyboard, not even Аа В Ее Ёё К М Н О Рр Сс Т у Хх Α Β Ε Ζ Η Ι Κ Μ Ν Οο Ρ Τ Υ Χ which look like Latin-alphabet letters but are different Unicode codepoints (and I'm not even counting lowercase beta which looks somewhat like eszett because the latter isn't found in us-ascii). On my Belgian keyboard I have ²³é§èçൣù even without using the dead keys, and a lot more with them, see http://users.skynet.be/antoine.mechelynck/other/keybbe.htm — but I don't know how one would get those non-ASCII letters on a (non-international) QWERTY keyboard meant for en-US. Another possibility :-P would be using CJK letters (with IME/XIM of course) for some commands. Yes, they are beautiful, and there are enough of them that you couldn't expect to use them all up, but how many non-East-Asian Vimmers know how to use this feature which is already built in Huge gvim? Best regards, Tony. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Anybody has a BeBox or BeOS system?
Shaun Brady wrote:
> Attached.
>
> I removed the line to #include osdef.h and yes it compiled it worked.
>
> I think the terminal emulation might be a bit wonky on BeOS or there
> was another problem, as I didn't see --INSERT--, but I did go in to
> insert mode upon pressing 'i'. Wrote a file to /tmp/
>
> Running the tests ('make test'?) didn't have as much luck; the tail attached.
Thus it sort of works. To exclude auto/osdef.h does this work:
*** ../vim-7.4.1273/src/vim.h 2016-02-04 22:09:44.692012667 +0100
--- src/vim.h 2016-02-07 00:06:30.004287511 +0100
***
*** 290,296
* glibc-2.2.5 has them in their system headers.
*/
#if !defined(__cplusplus) && defined(UNIX) \
! && !defined(MACOS_X) /* MACOS_X doesn't yet support osdef.h */
# include "auto/osdef.h" /* bring missing declarations in */
#endif
--- 290,296
* glibc-2.2.5 has them in their system headers.
*/
#if !defined(__cplusplus) && defined(UNIX) \
! && !defined(MACOS_X) && !defined(__BEOS__)
# include "auto/osdef.h" /* bring missing declarations in */
#endif
--
hundred-and-one symptoms of being an internet addict:
164. You got out to buy software, instead of going out for a beer.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Why is v:none needed?
Tyru wrote:
> >> Sorry Bram, I forgot to send this mail to vim_dev.
> >> Send again with +alpha about problems of current JSON features.
> >>
> >> On Sat, Feb 6, 2016 at 11:50 PM, Bram Moolenaar wrote:
> >> >
> >> >> What do you think about this?
> >> >
> >> > I don't want to spend much time discussing this. v:null and v:none are
> >> > needed just like JavaScript has null and undefined.
> >> >
> >> > I was thinking of taking this a step further to a more efficient
> >> > encoding that is similar to Javascript. Unfortunately I haven't been
> >> > able to find a specification. I thought it was used in combination with
> >> > protocol buffers. Besides empty entries in an array, it also removes
> >> > the quotes around object item names. It's more efficient and doesn't
> >> > drop any functionality. We could add protocol buffer support, but let's
> >> > leave that for some other time.
> >> >
> >> > Also keep in mind that when you want to stick to the JSON standard
> >> > (well, one of them), you should not write the string yourself but use a
> >> > library to create it. Arguments that it's hard to type or spot a
> >> > mistake are hardly relevant.
> >>
> >> Okay.
> >> Now I know you seem to follow JavaScript syntax rather than JSON standard.
> >
> > True. Perhaps we should split this and add jsencode() / jsdecode().
>
> Sounds great!
> Do you have the plan to add jsencode() / jsdecode() ?
> Or, will you merge the patch for those functions if I write?
Feel free to make a patch.
> >> But please remind JSON is not only for JavaScript.
> >> It might be used for a communication with Vim and scripts, external
> >> commands, and so on.
> >>
> >> And more, currently, 'jsonencode({"key": v:none})' produces output
> >> '{"key":}'.
> >> This is not even a correct JavaScript syntax.
> >
> > I'll fix that.
>
> Thanks!
> Now I confirmed that 7.4.1269 raises an E474 error for the expression.
> But yet it seems to return the string ('{"key":}').
> Is it intentional?
When there is an error it returns what it has. Would it be better to
return nothing?
--
You're as much use as a condom machine at the Vatican.
-- Rimmer to Holly in Red Dwarf 'Queeg'
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1273
Patch 7.4.1273 (after 7.4.1271)
Problem:assert_false(v:false) still fails.
Solution: Fix the typo.
Files: src/eval.c
*** ../vim-7.4.1272/src/eval.c 2016-02-06 20:29:24.357275499 +0100
--- src/eval.c 2016-02-06 23:56:35.150539328 +0100
***
*** 9217,9223
garray_T ga;
if (argvars[0].v_type == VAR_SPECIAL
! && argvars[0].vval.v_number == (isTrue ? VVAL_TRUE : VV_FALSE))
return;
if (argvars[0].v_type != VAR_NUMBER
|| (get_tv_number_chk(&argvars[0], &error) == 0) == isTrue
--- 9274,9280
garray_T ga;
if (argvars[0].v_type == VAR_SPECIAL
! && argvars[0].vval.v_number == (isTrue ? VVAL_TRUE : VVAL_FALSE))
return;
if (argvars[0].v_type != VAR_NUMBER
|| (get_tv_number_chk(&argvars[0], &error) == 0) == isTrue
*** ../vim-7.4.1272/src/version.c 2016-02-06 20:32:20.879442156 +0100
--- src/version.c 2016-02-06 23:59:26.220741366 +0100
***
*** 744,745
--- 749,752
{ /* Add new patch number below this line */
+ /**/
+ 1273,
/**/
--
If you feel lonely, try schizophrenia.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Anybody has a BeBox or BeOS system?
Shaun Brady wrote:
> Attached.
>
> I removed the line to #include osdef.h and yes it compiled it worked.
>
> I think the terminal emulation might be a bit wonky on BeOS or there
> was another problem, as I didn't see --INSERT--, but I did go in to
> insert mode upon pressing 'i'. Wrote a file to /tmp/
>
> Running the tests ('make test'?) didn't have as much luck; the tail attached.
>
> SB
Your attached file vim-tests1.txt contains:
Executing Test_symlink_recursive_delete()
Executing Test_valid()
Executing Test_with_directories()
Executing Test_with_tilde()
Executing Test_wrong_arguments()
Executed 28 tests
test77 NO OUTPUT
>From test_assert.vim:
Found errors in Test_assert_false():
function Test_assert_false line 2: Expected False but got v:false
Test results:
test77 NO OUTPUT
>From test_assert.vim:
Found errors in Test_assert_false():
function Test_assert_false line 2: Expected False but got v:false
TEST FAILURE
make[2]: *** [report] Error 1
make[2]: Leaving directory `/boot/home/vim/src/testdir'
make[1]: *** [test] Error 2
make[1]: Leaving directory `/boot/home/vim/src'
make: *** [test] Error 2
~/vim>
It test77 is the only one which fails, then it's not so bad.
Which version of Vim did you try on Haiku?
I wonder whether the test failure is related to this recent patch:
commit 3712792637516aea7acf76a11533be1066952820
Author: Bram Moolenaar
Date: Sat Feb 6 20:29:28 2016 +0100
patch 7.4.1271
Problem:assert_false(v:false) reports an error. (Nikolai Pavlov)
Solution: Recognize v:true and v:false. (Closes #625)
Regards
Dominique
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Anybody has a BeBox or BeOS system?
Attached.
I removed the line to #include osdef.h and yes it compiled it worked.
I think the terminal emulation might be a bit wonky on BeOS or there
was another problem, as I didn't see --INSERT--, but I did go in to
insert mode upon pressing 'i'. Wrote a file to /tmp/
Running the tests ('make test'?) didn't have as much luck; the tail attached.
SB
On Sat, Feb 6, 2016 at 4:16 PM, Dominique Pellé
wrote:
> Shaun Brady wrote:
>
>> Not right off the bat (see attached). Also, don't take my response as
>> a tally mark for a BeOS user. I grabbed the latest Haiku virtual
>> machine image and tried it out. I was just joking with a friend last
>> week about switching to BeOS, so I did it as more of a gag.
>>
>> Steps:
>> $ git clone https://www.github/vim/vim.git
>> $ cd vim
>> $ make
>>
>> Of note, vim (nor vi) is NOT installed in Haiku.
>>
>> SB
>
>
> The error in your attached file is:
>
> config.status: creating auto/config.h make -f Makefile all make[2]:
> Entering directory `/boot/home/vim/src' mkdir objects CC="gcc -Iproto
> -DHAVE_CONFIG_H " srcdir=. sh ./osdef.sh gcc -c -I. -Iproto
> -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall -o objects/buffer.o
> buffer.c In file included from /boot/home/vim/src/vim.h:294,
> from /boot/home/vim/src/buffer.c:28:
> /boot/home/vim/src/auto/osdef.h:40: parse error before `('
> /boot/home/vim/src/auto/osdef.h:40: parse error before `void'
> /boot/home/vim/src/auto/osdef.h:56: parse error before `('
> /boot/home/vim/src/auto/osdef.h:56: warning: conflicting types for
> built-in function `memset' make[2]: *** [objects/buffer.o] Error 1
> make[2]: Leaving directory `/boot/home/vim/src' make[1]: *** [myself]
> Error 2 make[1]: Leaving directory `/boot/home/vim/src' make: ***
> [first] Error 2 ~/vim>
>
>
> vim/src/auto/osdef.h is a generated header. Can you attach it?
> I also wonder whether Vim would compile if we just disable
> the include of "auto/osdef.h" in Vim.h at line 293. I see that
> it's not included for MACOX_X for example.
>
> I remember trying Haiku ~5 years ago. I thought of fixing Vim
> for Haiku, but it compiled and worked quite OK for me. All tests
> passed without any change at the time. See:
>
> http://permalink.gmane.org/gmane.editors.vim.devel/27942
>
> Regards
> Dominique
>
> --
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Executing Test_symlink_recursive_delete()
Executing Test_valid()
Executing Test_with_directories()
Executing Test_with_tilde()
Executing Test_wrong_arguments()
Executed 28 tests
test77 NO OUTPUT
From test_assert.vim:
Found errors in Test_assert_false():
function Test_assert_false line 2: Expected False but got v:false
Test results:
test77 NO OUTPUT
From test_assert.vim:
Found errors in Test_assert_false():
function Test_assert_false line 2: Expected False but got v:false
TEST FAILURE
make[2]: *** [report] Error 1
make[2]: Leaving directory `/boot/home/vim/src/testdir'
make[1]: *** [test] Error 2
make[1]: Leaving directory `/boot/home/vim/src'
make: *** [test] Error 2
~/vim>
/*
* osdef.h is automagically created from osdef?.h.in by osdef.sh -- DO NOT EDIT
*/
/* autoconf cannot fiddle out declarations. Use our homebrewn tools. (jw) */
/*
* Declarations that may cause conflicts belong here so that osdef.sh
* can clean out the forest. Everything else belongs in os_unix.h
*
* How this works:
* - This file contains all unix prototypes that Vim might need.
* - The shell script osdef.sh is executed at compile time to remove all the
* prototypes that are in an include file. This results in osdef.h.
* - osdef.h is included in vim.h.
*
* sed cannot always handle so many commands, this is file 1 of 2
*/
#ifndef fopen /* could be redefined to fopen64() */
#endif
#ifdef HAVE_FSEEKO
#endif
#ifdef HAVE_FSEEKO
#endif
#ifndef ferror /* let me say it again: "macros should never have prototypes" */
#endif
#if defined(sun) || defined(_SEQUENT_)
/* used inside of stdio macros getc(), puts(), putchar()... */
extern int _flsbuf(int, FILE *);
extern int _filbuf(FILE *);
#endif
#if !defined(HAVE_SELECT)
struct po
Re: Anybody has a BeBox or BeOS system?
Shaun Brady wrote:
> Not right off the bat (see attached). Also, don't take my response as
> a tally mark for a BeOS user. I grabbed the latest Haiku virtual
> machine image and tried it out. I was just joking with a friend last
> week about switching to BeOS, so I did it as more of a gag.
>
> Steps:
> $ git clone https://www.github/vim/vim.git
> $ cd vim
> $ make
>
> Of note, vim (nor vi) is NOT installed in Haiku.
>
> SB
The error in your attached file is:
config.status: creating auto/config.h make -f Makefile all make[2]:
Entering directory `/boot/home/vim/src' mkdir objects CC="gcc -Iproto
-DHAVE_CONFIG_H " srcdir=. sh ./osdef.sh gcc -c -I. -Iproto
-DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall -o objects/buffer.o
buffer.c In file included from /boot/home/vim/src/vim.h:294,
from /boot/home/vim/src/buffer.c:28:
/boot/home/vim/src/auto/osdef.h:40: parse error before `('
/boot/home/vim/src/auto/osdef.h:40: parse error before `void'
/boot/home/vim/src/auto/osdef.h:56: parse error before `('
/boot/home/vim/src/auto/osdef.h:56: warning: conflicting types for
built-in function `memset' make[2]: *** [objects/buffer.o] Error 1
make[2]: Leaving directory `/boot/home/vim/src' make[1]: *** [myself]
Error 2 make[1]: Leaving directory `/boot/home/vim/src' make: ***
[first] Error 2 ~/vim>
vim/src/auto/osdef.h is a generated header. Can you attach it?
I also wonder whether Vim would compile if we just disable
the include of "auto/osdef.h" in Vim.h at line 293. I see that
it's not included for MACOX_X for example.
I remember trying Haiku ~5 years ago. I thought of fixing Vim
for Haiku, but it compiled and worked quite OK for me. All tests
passed without any change at the time. See:
http://permalink.gmane.org/gmane.editors.vim.devel/27942
Regards
Dominique
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Anybody has a BeBox or BeOS system?
Not right off the bat (see attached). Also, don't take my response as
a tally mark for a BeOS user. I grabbed the latest Haiku virtual
machine image and tried it out. I was just joking with a friend last
week about switching to BeOS, so I did it as more of a gag.
Steps:
$ git clone https://www.github/vim/vim.git
$ cd vim
$ make
Of note, vim (nor vi) is NOT installed in Haiku.
SB
On Sat, Feb 6, 2016 at 8:46 AM, Bram Moolenaar wrote:
>
> In the code there are a few places with #ifdef __BEOS__. I wonder if
> compiling with BeOS still works. And if there is anybody doing that.
> I suspect not.
>
> It would clean up the code a little bit if we remove this.
>
> The last reference to it that I can find is for a patch to add Haiku
> support. That is apparently alive: https://www.haiku-os.org/
>
> --
> You are not really successful until someone claims he sat
> beside you in school.
>
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///
>
> --
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
config.status: creating auto/config.h make -f Makefile all make[2]:
Entering directory `/boot/home/vim/src' mkdir objects CC="gcc -Iproto
-DHAVE_CONFIG_H " srcdir=. sh ./osdef.sh gcc -c -I. -Iproto
-DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall -o objects/buffer.o
buffer.c In file included from /boot/home/vim/src/vim.h:294,
from /boot/home/vim/src/buffer.c:28:
/boot/home/vim/src/auto/osdef.h:40: parse error before `('
/boot/home/vim/src/auto/osdef.h:40: parse error before `void'
/boot/home/vim/src/auto/osdef.h:56: parse error before `('
/boot/home/vim/src/auto/osdef.h:56: warning: conflicting types for
built-in function `memset' make[2]: *** [objects/buffer.o] Error 1
make[2]: Leaving directory `/boot/home/vim/src' make[1]: *** [myself]
Error 2 make[1]: Leaving directory `/boot/home/vim/src' make: ***
[first] Error 2 ~/vim>
Patch 7.4.1272
Patch 7.4.1272 (after 7.4.1270)
Problem:Using future enum value.
Solution: Remove it.
Files: src/if_python.c, src/if_python3.c
*** ../vim-7.4.1271/src/if_python.c 2016-02-06 19:57:11.601323655 +0100
--- src/if_python.c 2016-02-06 20:31:06.272216997 +0100
***
*** 1559,1565
case VAR_NUMBER:
case VAR_STRING:
case VAR_FLOAT:
- case VAR_JOB:
case VAR_SPECIAL:
break;
}
--- 1559,1564
*** ../vim-7.4.1271/src/if_python3.c2016-02-06 19:57:11.601323655 +0100
--- src/if_python3.c2016-02-06 20:30:14.668752950 +0100
***
*** 1652,1658
case VAR_NUMBER:
case VAR_STRING:
case VAR_FLOAT:
- case VAR_JOB:
case VAR_SPECIAL:
break;
}
--- 1652,1657
*** ../vim-7.4.1271/src/version.c 2016-02-06 20:29:24.357275499 +0100
--- src/version.c 2016-02-06 20:32:16.535487268 +0100
***
*** 744,745
--- 744,747
{ /* Add new patch number below this line */
+ /**/
+ 1272,
/**/
--
hundred-and-one symptoms of being an internet addict:
163. You go outside for the fresh air (at -30 degrees) but open the
window first to hear new mail arrive.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1271
Patch 7.4.1271
Problem:assert_false(v:false) reports an error. (Nikolai Pavlov)
Solution: Recognize v:true and v:false. (Closes #625)
Files: src/eval.c, src/testdir/test_assert.vim
*** ../vim-7.4.1270/src/eval.c 2016-02-06 18:09:53.075952875 +0100
--- src/eval.c 2016-02-06 20:16:58.029028932 +0100
***
*** 9216,9221
--- 9216,9224
int error = FALSE;
garray_T ga;
+ if (argvars[0].v_type == VAR_SPECIAL
+ && argvars[0].vval.v_number == (isTrue ? VVAL_TRUE : VV_FALSE))
+ return;
if (argvars[0].v_type != VAR_NUMBER
|| (get_tv_number_chk(&argvars[0], &error) == 0) == isTrue
|| error)
*** ../vim-7.4.1270/src/testdir/test_assert.vim 2016-01-31 16:28:00.609674294
+0100
--- src/testdir/test_assert.vim 2016-02-06 20:09:51.569451592 +0100
***
*** 2,12
--- 2,14
func Test_assert_false()
call assert_false(0)
+ call assert_false(v:false)
endfunc
func Test_assert_true()
call assert_true(1)
call assert_true(123)
+ call assert_true(v:true)
endfunc
func Test_assert_equal()
*** ../vim-7.4.1270/src/version.c 2016-02-06 19:57:11.601323655 +0100
--- src/version.c 2016-02-06 20:16:17.877446163 +0100
***
*** 744,745
--- 744,747
{ /* Add new patch number below this line */
+ /**/
+ 1271,
/**/
--
hundred-and-one symptoms of being an internet addict:
162. You go outside and look for a brightness knob to turn down the sun.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1270
Patch 7.4.1270
Problem:Warnings for missing values in switch.
Solution: Change switch to if-else or add values.
Files: src/if_py_both.h, src/if_python.c, src/if_python3.c
*** ../vim-7.4.1269/src/if_py_both.h2016-01-23 19:45:48.622931332 +0100
--- src/if_py_both.h2016-02-06 19:52:17.484367234 +0100
***
*** 5831,5841
}
/* As we are not using copy_tv which increments reference count we must
* do it ourself. */
! switch(tv->v_type)
! {
! case VAR_DICT: ++tv->vval.v_dict->dv_refcount; break;
! case VAR_LIST: ++tv->vval.v_list->lv_refcount; break;
! }
}
else
{
--- 5831,5840
}
/* As we are not using copy_tv which increments reference count we must
* do it ourself. */
! if (tv->v_type == VAR_DICT)
! ++tv->vval.v_dict->dv_refcount;
! else if (tv->v_type == VAR_LIST)
! ++tv->vval.v_list->lv_refcount;
}
else
{
*** ../vim-7.4.1269/src/if_python.c 2016-01-30 17:24:01.798502450 +0100
--- src/if_python.c 2016-02-06 19:54:00.655299639 +0100
***
*** 1556,1561
--- 1556,1567
rettv->v_type = VAR_NUMBER;
rettv->vval.v_number = 0;
break;
+ case VAR_NUMBER:
+ case VAR_STRING:
+ case VAR_FLOAT:
+ case VAR_JOB:
+ case VAR_SPECIAL:
+ break;
}
}
*** ../vim-7.4.1269/src/if_python3.c2016-01-30 17:24:01.798502450 +0100
--- src/if_python3.c2016-02-06 19:56:23.765818687 +0100
***
*** 1649,1654
--- 1649,1660
rettv->v_type = VAR_NUMBER;
rettv->vval.v_number = 0;
break;
+ case VAR_NUMBER:
+ case VAR_STRING:
+ case VAR_FLOAT:
+ case VAR_JOB:
+ case VAR_SPECIAL:
+ break;
}
}
*** ../vim-7.4.1269/src/version.c 2016-02-06 18:42:01.651993383 +0100
--- src/version.c 2016-02-06 19:54:29.938996608 +0100
***
*** 744,745
--- 744,747
{ /* Add new patch number below this line */
+ /**/
+ 1270,
/**/
--
hundred-and-one symptoms of being an internet addict:
161. You get up before the sun rises to check your e-mail, and you
find yourself in the very same chair long after the sun has set.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Why is v:none needed?
2016-02-06 20:42 GMT+03:00 Bram Moolenaar :
>
> Tyru wrote:
>
>> Sorry Bram, I forgot to send this mail to vim_dev.
>> Send again with +alpha about problems of current JSON features.
>>
>> On Sat, Feb 6, 2016 at 11:50 PM, Bram Moolenaar wrote:
>> >
>> >> What do you think about this?
>> >
>> > I don't want to spend much time discussing this. v:null and v:none are
>> > needed just like JavaScript has null and undefined.
>> >
>> > I was thinking of taking this a step further to a more efficient
>> > encoding that is similar to Javascript. Unfortunately I haven't been
>> > able to find a specification. I thought it was used in combination with
>> > protocol buffers. Besides empty entries in an array, it also removes
>> > the quotes around object item names. It's more efficient and doesn't
>> > drop any functionality. We could add protocol buffer support, but let's
>> > leave that for some other time.
>> >
>> > Also keep in mind that when you want to stick to the JSON standard
>> > (well, one of them), you should not write the string yourself but use a
>> > library to create it. Arguments that it's hard to type or spot a
>> > mistake are hardly relevant.
>>
>> Okay.
>> Now I know you seem to follow JavaScript syntax rather than JSON standard.
>
> True. Perhaps we should split this and add jsencode() / jsdecode().
>
>> But please remind JSON is not only for JavaScript.
>> It might be used for a communication with Vim and scripts, external
>> commands, and so on.
>>
>> And more, currently, 'jsonencode({"key": v:none})' produces output
>> '{"key":}'.
>> This is not even a correct JavaScript syntax.
>
> I'll fix that.
>
>> And as ZyX said, please delegate the role of human readable format to
>> other formats, like YAML.
>> JSON should do just a communication work with something outside Vim.
>
> YAML has its advantages and disadvantages, I don't like it for
> inter-process communication.
> JSON is a nice format in many ways, although the requirement for quotes
> isn't that nice.
YAML is for things like configuration files, it was never meant for IPC.
JSON is one of the formats that tries to sit on two chairs: being
format for IPC and being human-readable, mostly because of its
background. And for IPC quotes do not matter and strict parser would
be preferred because “incoming” messages are also generated by a
computer and non-JSON stings indicate some bug.
Though JSON does not fit for IPC used by Vim: buffer lines can contain
strings which are not UTF-8, buffer names can contain such strings,
variable values are also not restricted; and all this even if
&encoding is UTF-8, so you can safely transfer basically no data*.
Format which allows binary strings would be preferred here.
* Python-3 bindings have exactly the same problem: you cannot use
vim.current.buffer.name, vim.eval, vim.current.buffer[N] without
possibly getting UnicodeEncodeError. Most plugins still ignore this
problem which they can because it is not present in Python-2 and
strings with characters that do not fit into &encoding are rare.
May be fixed by using 'surrogateescape' when encoding, which is also
one of the options for JSON, except that I cannot say how many
implementations can accept string which contains only low part of the
surrogate. Python JSON implementation accepts both strings
`’"\"\uDCFF\""` (U+DCFF it is the result of using 'surrogateescape' to
decode “UTF-8” string b'\xFF') and `"\"\\uDCFF\""`.
>
>> > you should not write the string yourself but use a
>> > library to create it.
>>
>> Hmm, why?
>
> To avoid mistakes. But you can create the strings manually if you want
> to, that's the advantage of using JSON over a binary format. Easier for
> debugging too. And for writing tests.
>
> --
> hundred-and-one symptoms of being an internet addict:
> 159. You get excited whenever discussing your hard drive.
>
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///
>
> --
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
--
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 unsubscribe from this group and st
Re: Why is v:none needed?
Hi Bram,
On Sun, Feb 7, 2016 at 2:42 AM, Bram Moolenaar wrote:
>
> Tyru wrote:
>
>> Sorry Bram, I forgot to send this mail to vim_dev.
>> Send again with +alpha about problems of current JSON features.
>>
>> On Sat, Feb 6, 2016 at 11:50 PM, Bram Moolenaar wrote:
>> >
>> >> What do you think about this?
>> >
>> > I don't want to spend much time discussing this. v:null and v:none are
>> > needed just like JavaScript has null and undefined.
>> >
>> > I was thinking of taking this a step further to a more efficient
>> > encoding that is similar to Javascript. Unfortunately I haven't been
>> > able to find a specification. I thought it was used in combination with
>> > protocol buffers. Besides empty entries in an array, it also removes
>> > the quotes around object item names. It's more efficient and doesn't
>> > drop any functionality. We could add protocol buffer support, but let's
>> > leave that for some other time.
>> >
>> > Also keep in mind that when you want to stick to the JSON standard
>> > (well, one of them), you should not write the string yourself but use a
>> > library to create it. Arguments that it's hard to type or spot a
>> > mistake are hardly relevant.
>>
>> Okay.
>> Now I know you seem to follow JavaScript syntax rather than JSON standard.
>
> True. Perhaps we should split this and add jsencode() / jsdecode().
Sounds great!
Do you have the plan to add jsencode() / jsdecode() ?
Or, will you merge the patch for those functions if I write?
>
>> But please remind JSON is not only for JavaScript.
>> It might be used for a communication with Vim and scripts, external
>> commands, and so on.
>>
>> And more, currently, 'jsonencode({"key": v:none})' produces output
>> '{"key":}'.
>> This is not even a correct JavaScript syntax.
>
> I'll fix that.
Thanks!
Now I confirmed that 7.4.1269 raises an E474 error for the expression.
But yet it seems to return the string ('{"key":}').
Is it intentional?
>
>> And as ZyX said, please delegate the role of human readable format to
>> other formats, like YAML.
>> JSON should do just a communication work with something outside Vim.
>
> YAML has its advantages and disadvantages, I don't like it for
> inter-process communication.
> JSON is a nice format in many ways, although the requirement for quotes
> isn't that nice.
>
>> > you should not write the string yourself but use a
>> > library to create it.
>>
>> Hmm, why?
>
> To avoid mistakes. But you can create the strings manually if you want
> to, that's the advantage of using JSON over a binary format. Easier for
> debugging too. And for writing tests.
>
> --
> hundred-and-one symptoms of being an internet addict:
> 159. You get excited whenever discussing your hard drive.
>
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Why is v:none needed?
Tyru wrote:
> Sorry Bram, I forgot to send this mail to vim_dev.
> Send again with +alpha about problems of current JSON features.
>
> On Sat, Feb 6, 2016 at 11:50 PM, Bram Moolenaar wrote:
> >
> >> What do you think about this?
> >
> > I don't want to spend much time discussing this. v:null and v:none are
> > needed just like JavaScript has null and undefined.
> >
> > I was thinking of taking this a step further to a more efficient
> > encoding that is similar to Javascript. Unfortunately I haven't been
> > able to find a specification. I thought it was used in combination with
> > protocol buffers. Besides empty entries in an array, it also removes
> > the quotes around object item names. It's more efficient and doesn't
> > drop any functionality. We could add protocol buffer support, but let's
> > leave that for some other time.
> >
> > Also keep in mind that when you want to stick to the JSON standard
> > (well, one of them), you should not write the string yourself but use a
> > library to create it. Arguments that it's hard to type or spot a
> > mistake are hardly relevant.
>
> Okay.
> Now I know you seem to follow JavaScript syntax rather than JSON standard.
True. Perhaps we should split this and add jsencode() / jsdecode().
> But please remind JSON is not only for JavaScript.
> It might be used for a communication with Vim and scripts, external
> commands, and so on.
>
> And more, currently, 'jsonencode({"key": v:none})' produces output '{"key":}'.
> This is not even a correct JavaScript syntax.
I'll fix that.
> And as ZyX said, please delegate the role of human readable format to
> other formats, like YAML.
> JSON should do just a communication work with something outside Vim.
YAML has its advantages and disadvantages, I don't like it for
inter-process communication.
JSON is a nice format in many ways, although the requirement for quotes
isn't that nice.
> > you should not write the string yourself but use a
> > library to create it.
>
> Hmm, why?
To avoid mistakes. But you can create the strings manually if you want
to, that's the advantage of using JSON over a binary format. Easier for
debugging too. And for writing tests.
--
hundred-and-one symptoms of being an internet addict:
159. You get excited whenever discussing your hard drive.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1269
Patch 7.4.1269
Problem:Encoding {'key':} to JSON doesn't give an error (Tyru)
Solution: Give an error.
Files: src/json.c, src/testdir/test_json.vim
*** ../vim-7.4.1268/src/json.c 2016-02-04 22:49:45.691504756 +0100
--- src/json.c 2016-02-06 18:32:27.577923277 +0100
***
*** 16,22
#include "vim.h"
#if defined(FEAT_EVAL) || defined(PROTO)
! static int json_encode_item(garray_T *gap, typval_T *val, int copyID);
static int json_decode_item(js_read_T *reader, typval_T *res);
/*
--- 16,22
#include "vim.h"
#if defined(FEAT_EVAL) || defined(PROTO)
! static int json_encode_item(garray_T *gap, typval_T *val, int copyID, int
allow_none);
static int json_decode_item(js_read_T *reader, typval_T *res);
/*
***
*** 29,35
/* Store bytes in the growarray. */
ga_init2(&ga, 1, 4000);
! json_encode_item(&ga, val, get_copyID());
return ga.ga_data;
}
--- 29,35
/* Store bytes in the growarray. */
ga_init2(&ga, 1, 4000);
! json_encode_item(&ga, val, get_copyID(), TRUE);
return ga.ga_data;
}
***
*** 121,127
* Return FAIL or OK.
*/
static int
! json_encode_item(garray_T *gap, typval_T *val, int copyID)
{
char_unumbuf[NUMBUFLEN];
char_u*res;
--- 121,127
* Return FAIL or OK.
*/
static int
! json_encode_item(garray_T *gap, typval_T *val, int copyID, int allow_none)
{
char_unumbuf[NUMBUFLEN];
char_u*res;
***
*** 135,141
{
case VVAL_FALSE: ga_concat(gap, (char_u *)"false"); break;
case VVAL_TRUE: ga_concat(gap, (char_u *)"true"); break;
! case VVAL_NONE: break;
case VVAL_NULL: ga_concat(gap, (char_u *)"null"); break;
}
break;
--- 135,144
{
case VVAL_FALSE: ga_concat(gap, (char_u *)"false"); break;
case VVAL_TRUE: ga_concat(gap, (char_u *)"true"); break;
! case VVAL_NONE: if (!allow_none)
! /* TODO: better error */
! EMSG(_(e_invarg));
! break;
case VVAL_NULL: ga_concat(gap, (char_u *)"null"); break;
}
break;
***
*** 152,158
break;
case VAR_FUNC:
! /* no JSON equivalent */
EMSG(_(e_invarg));
return FAIL;
--- 155,161
break;
case VAR_FUNC:
! /* no JSON equivalent TODO: better error */
EMSG(_(e_invarg));
return FAIL;
***
*** 172,178
ga_append(gap, '[');
for (li = l->lv_first; li != NULL && !got_int; )
{
! if (json_encode_item(gap, &li->li_tv, copyID) == FAIL)
return FAIL;
li = li->li_next;
if (li != NULL)
--- 175,182
ga_append(gap, '[');
for (li = l->lv_first; li != NULL && !got_int; )
{
! if (json_encode_item(gap, &li->li_tv, copyID, TRUE)
! == FAIL)
return FAIL;
li = li->li_next;
if (li != NULL)
***
*** 213,219
write_string(gap, hi->hi_key);
ga_append(gap, ':');
if (json_encode_item(gap, &dict_lookup(hi)->di_tv,
! copyID) == FAIL)
return FAIL;
}
ga_append(gap, '}');
--- 217,223
write_string(gap, hi->hi_key);
ga_append(gap, ':');
if (json_encode_item(gap, &dict_lookup(hi)->di_tv,
! copyID, FALSE) == FAIL)
return FAIL;
}
ga_append(gap, '}');
*** ../vim-7.4.1268/src/testdir/test_json.vim 2016-01-24 16:49:06.227712998
+0100
--- src/testdir/test_json.vim 2016-02-06 18:35:20.584136615 +0100
***
*** 74,79
--- 74,80
call assert_fails('echo jsonencode(function("tr"))', 'E474:')
call assert_fails('echo jsonencode([function("tr")])', 'E474:')
+ call assert_fails('echo jsonencode({"key":v:none})', 'E474:')
endfunc
func Test_decode()
*** ../vim-7.4.1268/src/version.c 2016-02-06 18:18:49.158400089 +0100
--- src/version.c 2016-02-06 18:33:33.937238017 +0100
***
*** 744,745
--- 744,747
{ /* Add new patch number below this line */
+ /**/
+ 12
Re: Patch 7.4.1263
Hirohito Higashi wrote:
> Hi Bram,
>
> 2016-2-6(Sat) 6:37:07 UTC+9 Bram Moolenaar:
> > Patch 7.4.1263
> > Problem:ch_open() hangs when the server isn't running.
> > Solution: Add a timeout. Use a dict to pass arguments. (Yasuhiro
> > Matsumoto)
> > Files: runtime/doc/eval.txt, runtime/doc/channel.txt, src/channel.c,
> > src/eval.c, src/netbeans.c, src/os_win32.c,
> > src/proto/channel.pro,
> > src/testdir/test_channel.vim
>
> I found conflict between document and source.
> And I have a confirmation to specification.
>
> ch_open() {argdict}'s waittime and timeout that the units are milliseconds.
> But in fact, this is using as the seconds.
>
> code>in channel.c
> code>tv.tv_sec = waittime;
> code>tv.tv_usec = 0;
Ah, that should be adjusted.
> Confirmation:
> :h ch_open
> doc> waittimeSpecify connect timeout as milliseconds.
> doc> Negative means forever.
> doc> Default: 0
>
> What is the meaning of 0?
> Infinite wait? or polling?
No wait.
> When `waittime` is set to 0, Current source code has become a polling
> (nowait).
> It's not useful.
The zero is useful when the server is supposed to be running already.
If not then it should fail immediately. Can also be used like this:
let handle = ch_open(address)
if handle < 0
!start_job
let handle = ch_open(address, {'waittime': 1000})
endif
--
hundred-and-one symptoms of being an internet addict:
156. You forget your friend's name but not her e-mail address.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1268
Patch 7.4.1268
Problem:Waittime is used as seconds instead of milliseconds. (Hirohito
Higashi)
Solution: Divide by 1000.
Files: src/channel.c
*** ../vim-7.4.1267/src/channel.c 2016-02-05 22:49:50.677170625 +0100
--- src/channel.c 2016-02-06 18:11:39.586849888 +0100
***
*** 440,447
FD_ZERO(&wfds);
FD_SET(sd, &rfds);
FD_SET(sd, &wfds);
! tv.tv_sec = waittime;
! tv.tv_usec = 0;
ret = select((int)sd+1, &rfds, &wfds, NULL, &tv);
if (ret < 0)
{
--- 440,447
FD_ZERO(&wfds);
FD_SET(sd, &rfds);
FD_SET(sd, &wfds);
! tv.tv_sec = waittime / 1000;
! tv.tv_usec = (waittime % 1000) * 1000;
ret = select((int)sd+1, &rfds, &wfds, NULL, &tv);
if (ret < 0)
{
*** ../vim-7.4.1267/src/version.c 2016-02-06 18:09:53.075952875 +0100
--- src/version.c 2016-02-06 18:12:22.854401786 +0100
***
*** 744,745
--- 744,747
{ /* Add new patch number below this line */
+ /**/
+ 1268,
/**/
--
hundred-and-one symptoms of being an internet addict:
157. You fum through a magazine, you first check to see if it has a web
address.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1267
Patch 7.4.1267
Problem:Easy to miss handling all types of variables.
Solution: Change the variable type into an enum.
Files: src/structs.h, src/eval.c
*** ../vim-7.4.1266/src/structs.h 2016-02-02 18:19:52.798743887 +0100
--- src/structs.h 2016-02-06 16:17:00.238321359 +0100
***
*** ,1122
typedef struct listvar_S list_T;
typedef struct dictvar_S dict_T;
/*
* Structure to hold an internal variable without a name.
*/
typedef struct
{
! char v_type; /* see below: VAR_NUMBER, VAR_STRING, etc. */
char v_lock; /* see below: VAR_LOCKED, VAR_FIXED */
union
{
--- ,1134
typedef struct listvar_S list_T;
typedef struct dictvar_S dict_T;
+ typedef enum
+ {
+ VAR_UNKNOWN = 0,
+ VAR_NUMBER, /* "v_number" is used */
+ VAR_STRING, /* "v_string" is used */
+ VAR_FUNC, /* "v_string" is function name */
+ VAR_LIST, /* "v_list" is used */
+ VAR_DICT, /* "v_dict" is used */
+ VAR_FLOAT,/* "v_float" is used */
+ VAR_SPECIAL /* "v_number" is used */
+ } vartype_T;
+
/*
* Structure to hold an internal variable without a name.
*/
typedef struct
{
! vartype_T v_type;
char v_lock; /* see below: VAR_LOCKED, VAR_FIXED */
union
{
***
*** 1130,1145
} vval;
} typval_T;
- /* Values for "v_type". */
- #define VAR_UNKNOWN 0
- #define VAR_NUMBER 1 /* "v_number" is used */
- #define VAR_STRING 2 /* "v_string" is used */
- #define VAR_FUNC3 /* "v_string" is function name */
- #define VAR_LIST4 /* "v_list" is used */
- #define VAR_DICT5 /* "v_dict" is used */
- #define VAR_FLOAT 6 /* "v_float" is used */
- #define VAR_SPECIAL 7 /* "v_number" is used */
-
/* Values for "dv_scope". */
#define VAR_SCOPE 1 /* a:, v:, s:, etc. scope dictionaries */
#define VAR_DEF_SCOPE 2 /* l:, g: scope dictionaries: here funcrefs are
not
--- 1142,1147
*** ../vim-7.4.1266/src/eval.c 2016-02-05 22:49:50.681170583 +0100
--- src/eval.c 2016-02-06 17:39:52.430587000 +0100
***
*** 3065,3070
--- 3065,3071
case VAR_DICT:
case VAR_FUNC:
case VAR_SPECIAL:
+ case VAR_UNKNOWN:
break;
case VAR_LIST:
***
*** 3837,3842
--- 3838,3851
switch (tv->v_type)
{
+ case VAR_UNKNOWN:
+ case VAR_NUMBER:
+ case VAR_STRING:
+ case VAR_FUNC:
+ case VAR_FLOAT:
+ case VAR_SPECIAL:
+ break;
+
case VAR_LIST:
if ((l = tv->vval.v_list) != NULL)
{
***
*** 5317,5339
char_u*s;
char_u*key = NULL;
! if (rettv->v_type == VAR_FUNC)
{
! if (verbose)
! EMSG(_("E695: Cannot index a Funcref"));
! return FAIL;
! }
#ifdef FEAT_FLOAT
! else if (rettv->v_type == VAR_FLOAT)
! {
! if (verbose)
! EMSG(_(e_float_as_string));
! return FAIL;
! }
#endif
! else if (rettv->v_type == VAR_SPECIAL)
! {
! return FAIL;
}
init_tv(&var1);
--- 5326,5357
char_u*s;
char_u*key = NULL;
! switch (rettv->v_type)
{
! case VAR_FUNC:
! if (verbose)
! EMSG(_("E695: Cannot index a Funcref"));
! return FAIL;
! case VAR_FLOAT:
#ifdef FEAT_FLOAT
! if (verbose)
! EMSG(_(e_float_as_string));
! return FAIL;
#endif
! case VAR_SPECIAL:
! if (verbose)
! EMSG(_("E909: Cannot index a special variable"));
! return FAIL;
! case VAR_UNKNOWN:
! if (evaluate)
! return FAIL;
! /* FALLTHROUGH */
!
! case VAR_STRING:
! case VAR_NUMBER:
! case VAR_LIST:
! case VAR_DICT:
! break;
}
init_tv(&var1);
***
*** 5428,5433
--- 5446,5457
switch (rettv->v_type)
{
+ case VAR_SPECIAL:
+ case VAR_FUNC:
+ case VAR_FLOAT:
+ case VAR_UNKNOWN:
+ break; /* not evaluating, skipping over subscript */
+
case VAR_NUMBER:
case VAR_STRING:
s = get_tv_string(rettv);
***
*** 6143,6148
--- 6167,6175
switch (tv1->v_type)
{
+ case VAR_UNKNOWN:
+ break;
+
case VAR_LIST:
++recursive_cnt;
r = list_equal(tv1->vval.v_list, tv2->vval.v_list, ic, TRUE);
***
*** 6177,6184
return tv1->vval.v_number == tv2->vval.v_number;
}
! EMSG2(_(e_intern2), "tv_equal()");
! return TRUE;
}
/*
--- 6204,6212
return tv1->vval.v_number == tv2->vval.v_number;
}
! /* VAR_UNKNOWN can be the result of a invalid expression,
Re: Bug: --remote-send can trigger FocusGained when it shouldn't
On Wednesday, September 30, 2015, Christian J. Robinson wrote: > On Wed, 30 Sep 2015, Christian Brabandt wrote: > > Can you reproduce it with the above command line I gave? >> > > Oops, you're right, I should have tried that. And you're correct, when > invoked that way I don't get the message. > I'm "pinging" this thread in the hope that it can be fixed. I did try to run it down in the source code, but it is unfortunately beyond my limited skills. - Christian -- Christian J. Robinson -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why is v:none needed?
Sorry Bram, I forgot to send this mail to vim_dev.
Send again with +alpha about problems of current JSON features.
On Sat, Feb 6, 2016 at 11:50 PM, Bram Moolenaar wrote:
>
>> What do you think about this?
>
> I don't want to spend much time discussing this. v:null and v:none are
> needed just like JavaScript has null and undefined.
>
> I was thinking of taking this a step further to a more efficient
> encoding that is similar to Javascript. Unfortunately I haven't been
> able to find a specification. I thought it was used in combination with
> protocol buffers. Besides empty entries in an array, it also removes
> the quotes around object item names. It's more efficient and doesn't
> drop any functionality. We could add protocol buffer support, but let's
> leave that for some other time.
>
> Also keep in mind that when you want to stick to the JSON standard
> (well, one of them), you should not write the string yourself but use a
> library to create it. Arguments that it's hard to type or spot a
> mistake are hardly relevant.
Okay.
Now I know you seem to follow JavaScript syntax rather than JSON standard.
But please remind JSON is not only for JavaScript.
It might be used for a communication with Vim and scripts, external
commands, and so on.
And more, currently, 'jsonencode({"key": v:none})' produces output '{"key":}'.
This is not even a correct JavaScript syntax.
And as ZyX said, please delegate the role of human readable format to
other formats, like YAML.
JSON should do just a communication work with something outside Vim.
> you should not write the string yourself but use a
> library to create it.
Hmm, why?
>
>
> --
> hundred-and-one symptoms of being an internet addict:
> 154. You fondle your mouse.
>
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Why is v:none needed?
2016-02-06 17:50 GMT+03:00 Bram Moolenaar : > >> What do you think about this? > > I don't want to spend much time discussing this. v:null and v:none are > needed just like JavaScript has null and undefined. > > I was thinking of taking this a step further to a more efficient > encoding that is similar to Javascript. Unfortunately I haven't been > able to find a specification. I thought it was used in combination with > protocol buffers. Besides empty entries in an array, it also removes > the quotes around object item names. It's more efficient and doesn't > drop any functionality. We could add protocol buffer support, but let's > leave that for some other time. > > Also keep in mind that when you want to stick to the JSON standard > (well, one of them), you should not write the string yourself but use a > library to create it. Arguments that it's hard to type or spot a > mistake are hardly relevant. JSON is used not only for communication. All arguments like “hard to spot a mistake” apply to the configuration files that also can be written in JSON. Also when library is used argument like “this is twice as long” is hardly relevant because it only matters when using Vim over very slow channel or when sending a huge chunks of binary data, otherwise there is no difference what data is sent exactly as it does not reach the user, and even most likely fits in the same number of packets. And as I said, more space-efficient encodings are binary ones like msgpack (or protocol buffers). More human-readable is YAML. Also binary encodings are almost always parsed faster then text ones. > > > -- > hundred-and-one symptoms of being an internet addict: > 154. You fondle your mouse. > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ > ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org/// > \\\help me help AIDS victims -- http://ICCF-Holland.org/// > > -- > -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1263
Hi Bram,
2016-2-6(Sat) 6:37:07 UTC+9 Bram Moolenaar:
> Patch 7.4.1263
> Problem:ch_open() hangs when the server isn't running.
> Solution: Add a timeout. Use a dict to pass arguments. (Yasuhiro Matsumoto)
> Files: runtime/doc/eval.txt, runtime/doc/channel.txt, src/channel.c,
> src/eval.c, src/netbeans.c, src/os_win32.c, src/proto/channel.pro,
> src/testdir/test_channel.vim
I found conflict between document and source.
And I have a confirmation to specification.
ch_open() {argdict}'s waittime and timeout that the units are milliseconds.
But in fact, this is using as the seconds.
code>in channel.c
code>tv.tv_sec = waittime;
code>tv.tv_usec = 0;
Confirmation:
:h ch_open
doc> waittimeSpecify connect timeout as milliseconds.
doc> Negative means forever.
doc> Default: 0
What is the meaning of 0?
Infinite wait? or polling?
When `waittime` is set to 0, Current source code has become a polling (nowait).
It's not useful.
--
Best regards,
Hirohito Higashi (a.k.a h_east)
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Patch] GTK3 GUI
Hi, Christian Thank you for the comment. 2016-02-06 22:51 GMT+09:00 Christian Brabandt : > Hi Kazunobu! > > On Sa, 06 Feb 2016, Kazunobu Kuriyama wrote: > > > Patch updated. > > > > With this patch, I remove some causes which I think resulted in > excessive draw > > signals. > > > > It looks to me that CUP usage now reverts to normal. > > > > So, the issue I'm worried about is whether it is overkill or not. Are > redraws > > still working as expected for you? > > > > Known bugs are: > > (1) Cursors on unused windows sometimes fails to be cleared. > > (2) With :split, the scrollbar won't appear (More precisely, there is > something > > invisible but draggable; and dragging works to scroll the window. > Weird...). > > > > Both get normal by Ctrl+L, though. > > > > Please let me know if you find other issues, too. > > Thanks. Looks good now. Looks we've made good progress. > I still see occasional redrawing artifacts on > scrolling. If I do `:h` and start scrolling down using lines that > are empty, often have the content from the previous page. fixes > that however. > Comments like this which describe what one has seen are really helpful to me. Thanks. I suspect the code for scrolling still contains a bug, while that for drawing works correctly. I'll look into that. Regards, Kazunobu > > Mit freundlichen Grüßen > Christian > -- > Kein Mensch ist so beschäftigt, daß er nicht die Zeit hat, überall zu > erzählen, wie beschäftigt er ist. > -- Robert Lembke > > -- > -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why is v:none needed?
> What do you think about this? I don't want to spend much time discussing this. v:null and v:none are needed just like JavaScript has null and undefined. I was thinking of taking this a step further to a more efficient encoding that is similar to Javascript. Unfortunately I haven't been able to find a specification. I thought it was used in combination with protocol buffers. Besides empty entries in an array, it also removes the quotes around object item names. It's more efficient and doesn't drop any functionality. We could add protocol buffer support, but let's leave that for some other time. Also keep in mind that when you want to stick to the JSON standard (well, one of them), you should not write the string yourself but use a library to create it. Arguments that it's hard to type or spot a mistake are hardly relevant. -- hundred-and-one symptoms of being an internet addict: 154. You fondle your mouse. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Patch 7.4.1266
Patch 7.4.1266
Problem:A BufAdd autocommand may cause an ml_get error (Christian
Brabandt)
Solution: Increment RedrawingDisabled earlier.
Files: src/ex_cmds.c
*** ../vim-7.4.1265/src/ex_cmds.c 2016-01-31 14:55:35.223538514 +0100
--- src/ex_cmds.c 2016-02-06 15:21:16.845223019 +0100
***
*** 3268,3273
--- 3268,3274
int did_get_winopts = FALSE;
#endif
int readfile_flags = 0;
+ int did_inc_redrawing_disabled = FALSE;
if (eap != NULL)
command = eap->do_ecmd_cmd;
***
*** 3600,3605
--- 3601,3611
oldbuf = (flags & ECMD_OLDBUF);
}
+ /* Don't redraw until the cursor is in the right line, otherwise
+ * autocommands may cause ml_get errors. */
+ ++RedrawingDisabled;
+ did_inc_redrawing_disabled = TRUE;
+
#ifdef FEAT_AUTOCMD
buf = curbuf;
#endif
***
*** 3697,3705
/*
* If we get here we are sure to start editing
*/
- /* don't redraw until the cursor is in the right line */
- ++RedrawingDisabled;
-
/* Assume success now */
retval = OK;
--- 3703,3708
***
*** 3899,3904
--- 3902,3908
#endif
--RedrawingDisabled;
+ did_inc_redrawing_disabled = FALSE;
if (!skip_redraw)
{
n = p_so;
***
*** 3933,3938
--- 3937,3944
#endif
theend:
+ if (did_inc_redrawing_disabled)
+ --RedrawingDisabled;
#ifdef FEAT_AUTOCMD
if (did_set_swapcommand)
set_vim_var_string(VV_SWAPCOMMAND, NULL, -1);
*** ../vim-7.4.1265/src/version.c 2016-02-05 23:09:07.385093906 +0100
--- src/version.c 2016-02-06 15:22:18.948573112 +0100
***
*** 744,745
--- 744,747
{ /* Add new patch number below this line */
+ /**/
+ 1266,
/**/
--
hundred-and-one symptoms of being an internet addict:
153. You find yourself staring at your "inbox" waiting for new e-mail
to arrive.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [patch] calling :redraw in a BufAdd autocommand may issue E315 ml_get: invalid lnum
Christian Brabandt wrote: > Hi, > when calling :redraw in a BufAdd autocommand, this may cause several > E315 ml_get: invalid_lnum messages. Here is a backtrack > > Here is a backtrace: > > (gdb) bt > #0 ml_get_buf (buf=0xedf300, lnum=2, will_change=0) at memline.c:2469 > #1 0x004cf014 in plines_win_nofold (wp=0x897bf0, lnum=2) at > misc1.c:2008 > #2 0x004cefbf in plines_win_nofill (wp=0x897bf0, lnum=2, > winheight=1) at misc1.c:1991 [...] > #17 0x004979b6 in apply_autocmds (event=EVENT_BUFADD, fname=0x0, > fname_io=0x0, force=0, buf=0xedf300) at fileio.c:9033 > #18 0x00410bd5 in set_buflisted (on=1) at buffer.c:5805 > #19 0x0045adff in do_ecmd (fnum=4, ffname=0x0, sfname=0x0, eap=0x0, > newlnum=1, flags=1, oldwin=0x897bf0) at ex_cmds.c:3615 > #20 0x0045a555 in getfile (fnum=4, ffname=0x0, sfname=0x0, setpm=1, > lnum=1, forceit=0) at ex_cmds.c:3189 [...] > > Here is a patch, that disables redrawing for BufAdd autocommands. I am > not sure, this is the correct solution however. We already increment RedrawingDisabled a bit further down in do_ecmd. I think we should move it up. -- hundred-and-one symptoms of being an internet addict: 152. You find yourself falling for someone you've never seen or hardly know, but, boy can he/she TYPE!! /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Test failure on OS X
Manuel Ortega wrote: > On Fri, Feb 5, 2016 at 4:51 PM, Manuel Ortega wrote: > > > Vim 7.4.1262 and 7.4.1263 on Mac OS X 10.11.3 both fail the `make test` > > phase. I'm pasting the error message below. > > The failure is still there on 7.4.1264, but the output is different: I'll > paste it below: > > >From test_channel.vim: > Executing Test_communicate() > Executing Test_server_crash() > Executing Test_two_channels() > Executed 3 tests > 6 FAILED > > >From test_channel.vim: > Found errors in Test_communicate(): > Caught exception in Test_communicate(): Vim(let):E902: Cannot connect to > port: Connection refused @ function > Test_communicate[1]..3_start_server, line 34 > Found errors in Test_server_crash(): > Caught exception in Test_server_crash(): Vim(let):E902: Cannot connect to > port: Connection refused @ function > Test_server_crash[1]..3_start_server, line 34 > Found errors in Test_two_channels(): > Caught exception in Test_two_channels(): Vim(let):E902: Cannot connect to > port: Connection refused @ function > Test_two_channels[1]..3_start_server, line 34 > > Test results: > > > >From test_channel.vim: > Found errors in Test_communicate(): > Caught exception in Test_communicate(): Vim(let):E902: Cannot connect to > port: Connection refused @ function > Test_communicate[1]..3_start_server, line 34 > Found errors in Test_server_crash(): > Caught exception in Test_server_crash(): Vim(let):E902: Cannot connect to > port: Connection refused @ function > Test_server_crash[1]..3_start_server, line 34 > Found errors in Test_two_channels(): > Caught exception in Test_two_channels(): Vim(let):E902: Cannot connect to > port: Connection refused @ function > Test_two_channels[1]..3_start_server, line 34 > TEST FAILURE > make[2]: *** [report] Error 1 > make[1]: *** [test] Error 2 > make: *** [test] Error 2 This is most likely due to the timeout on connect(). That's tricky new code that might not work the same way on different systems. I had already added ignoring an error that seems Linux specific. I hope someone can debug this and make a fix. -- Although the scythe isn't pre-eminent among the weapons of war, anyone who has been on the wrong end of, say, a peasants' revolt will know that in skilled hands it is fearsome. -- (Terry Pratchett, Mort) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1263
Ken Takata wrote:
> 2016/2/6 Sat 6:37:07 UTC+9 Bram Moolenaar wrote:
> > Patch 7.4.1263
> > Problem:ch_open() hangs when the server isn't running.
> > Solution: Add a timeout. Use a dict to pass arguments. (Yasuhiro
> > Matsumoto)
> > Files: runtime/doc/eval.txt, runtime/doc/channel.txt, src/channel.c,
> > src/eval.c, src/netbeans.c, src/os_win32.c,
> > src/proto/channel.pro,
> > src/testdir/test_channel.vim
>
> I found some typos in the document:
>
> --- a/runtime/doc/channel.txt
> +++ b/runtime/doc/channel.txt
> @@ -93,7 +93,7 @@ The default is zero, don't wait, which i
> be running already. A negative number waits forever.
>
> "timeout" is the time to wait for a request when blocking, using
> -ch_sendexpr(). Again in millisecons. The default si 2000 (2 seconds).
> +ch_sendexpr(). Again in millisecons. The default is 2000 (2 seconds).
>
> When "mode" is "json" the "msg" argument is the body of the received message,
> converted to Vim types.
> @@ -104,7 +104,7 @@ possible to receive a message after send
>
> The handler can be added or changed later: >
> call ch_setcallback(handle, {callback})
> -When "callback is empty (zero or an empty string) the handler is removed.
> +When "callback" is empty (zero or an empty string) the handler is removed.
> NOT IMPLEMENTED YET
>
> The timeout can be changed later: >
Thanks. Now I see millisecons is also wrong.
--
hundred-and-one symptoms of being an internet addict:
150. You find yourself counting emoticons to get to sleep.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [patch] Add TagNotFound autocmd event
Anton Lindqvist wrote: > On Thu, Feb 04, 2016 at 09:36:21PM +0100, Christian Brabandt wrote: > > While I agree that this is useful, I have been thinking, if a more > > general approach would not be more useful. Something like an Error > > autocommand, that triggers on the EXXX numbers? > > I really like this idea, especially if would be the actual > error message since it would allow people to get creative. Having > limited experience with the Vim codebase: would it be feasible to > trigger the autocmd event somewhere along the call stack for the emsg > functions? At first glance it looks like that solution would require > less changes. Compared to adding a explicit call to apply_autocmds > prior calling any of the emsg functions. Although this sounds like a nice general solution, it will require the code that gives the error message to be prepared for an autocommand kicking in. Otherwise, whatever the autocommand does may completely mess up what the code was doing. We have had many autocommands cause trouble and still fixing more. So the code would explicitly check for an autocommand that handles the error. And since we need to do that, we might as well use a nicer name than the error number. That also helps for when there can be multiple errors. E.g. "tagnotfound" is much nicer than matching a list of error codes. And more error codes could be added later. An alternative would be to match the error code, but not trigger the autocommand yet. In the main loop we can then check for the matches and execute the autocommand. That is a lot safer and simpler. Nevertheless, you probably want to do something more clever, since after rebuilding the tags file you would want to search for a match again. -- hundred-and-one symptoms of being an internet addict: 151. You find yourself engaged to someone you've never actually met, except through e-mail. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Feature or bug? dw oddities
Hi Bram! On Sa, 06 Feb 2016, Bram Moolenaar wrote: > > Christian Brabandt wrote: > > > > > last line. I've since downloaded a proper version of elvis and it > > > > behaves the same as all the other clones apart from vim. > > > > > > > > > > Summarising this, you think vim is behaving differently than most > > > other vi derivates? > > > > > > Why is the comment quoted by Christian Brabandt telling, vim tries to > > > behave like vi? > > > > Well, we can perhaps use this patch. > > There are a few more places in the docs that need to point to this flag. > Also, plugin writers must be aware of the two different behaviors. Alright, I'll post an update later. > Is there a better character than "_" to use for this? Hm, not sure. We are slowly running out of characters there. I'll check that again. Perhaps we should start to use letters from other alphabets. I hear cyrillic has some beautiful letters ;) Best, Christian -- Realität in der höchsten Nützlichkeit (Zweckmäßigkeit) wird auch schön sein. -- Goethe, Maximen und Reflektionen, Nr. 1196 -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Patch] GTK3 GUI
Hi Kazunobu! On Sa, 06 Feb 2016, Kazunobu Kuriyama wrote: > Patch updated. > > With this patch, I remove some causes which I think resulted in excessive draw > signals. > > It looks to me that CUP usage now reverts to normal. > > So, the issue I'm worried about is whether it is overkill or not. Are redraws > still working as expected for you? > > Known bugs are: > (1) Cursors on unused windows sometimes fails to be cleared. > (2) With :split, the scrollbar won't appear (More precisely, there is > something > invisible but draggable; and dragging works to scroll the window. Weird...). > > Both get normal by Ctrl+L, though. > > Please let me know if you find other issues, too. Thanks. Looks good now. I still see occasional redrawing artifacts on scrolling. If I do `:h` and start scrolling down using lines that are empty, often have the content from the previous page. fixes that however. Mit freundlichen Grüßen Christian -- Kein Mensch ist so beschäftigt, daß er nicht die Zeit hat, überall zu erzählen, wie beschäftigt er ist. -- Robert Lembke -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Anybody has a BeBox or BeOS system?
In the code there are a few places with #ifdef __BEOS__. I wonder if compiling with BeOS still works. And if there is anybody doing that. I suspect not. It would clean up the code a little bit if we remove this. The last reference to it that I can find is for a patch to add Haiku support. That is apparently alive: https://www.haiku-os.org/ -- You are not really successful until someone claims he sat beside you in school. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Feature or bug? dw oddities
Christian Brabandt wrote: > > > last line. I've since downloaded a proper version of elvis and it > > > behaves the same as all the other clones apart from vim. > > > > > > > Summarising this, you think vim is behaving differently than most > > other vi derivates? > > > > Why is the comment quoted by Christian Brabandt telling, vim tries to > > behave like vi? > > Well, we can perhaps use this patch. There are a few more places in the docs that need to point to this flag. Also, plugin writers must be aware of the two different behaviors. Is there a better character than "_" to use for this? -- hundred-and-one symptoms of being an internet addict: 149. You find your computer sexier than your girlfriend /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] Add TagNotFound autocmd event
Hi Anton! On Sa, 06 Feb 2016, Anton Lindqvist wrote: > I am able to apply your patch and it works fine. Here's an example of a > potential use-case of mine: > > " Run ctags if the tag file is missing (E433) or the tag was not found > (E426) > augroup ctags > au! Error E4\(26\|33\)* silent exe '!ctags' > augroup END Great! > Are you aware of any bugs with your patch or other potential gotchas > that needs to be resolved? I think it was about some error codes not being caught, but I don't remember the details. However, if you got it working, please submit it. We might need to add some tests however. Best, Christian -- Tu erst das Notwendige, dann das Mögliche, und plötzlich schaffst Du das Unmögliche. -- Franz von Assisi -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why is v:none needed?
Neovim developers agree with me that neither v:none, nor extensions to
JSON should be added to Neovim. So another point is that plugins
willing to be compatible with Neovim and use json*() functions will
not use v:none or proposed syntax extensions.
2016-02-06 16:10 GMT+03:00 tyru :
>> Bram
>
> What do you think about this?
>
>
> On Thu, Feb 4, 2016 at 11:33 PM, tyru wrote:
>> On Thu, Feb 4, 2016 at 10:08 PM, tyru wrote:
>>> Hi Nikolay,
>>>
>>> Thanks for lots of follow-up examples :)
>>>
>>> On Thu, Feb 4, 2016 at 8:33 AM, Nikolay Aleksandrovich Pavlov
>>> wrote:
Since that thread is over I would reply here (did not reply previously
because I did not realize that json and channel features are
connected)
>>>
>>> BTW, I didn't understand why json and channel features are connected.
>>> I only talked about JSON feature.
>>>
> The question is what to do with items that can't be converted to JSON.
> I have been in doubt, whether to silently drop them or give an error.
>
> Although a missing item in an array is not according to the JSON
> standard, it is very useful in practice:
>
> [18]
>
> The missing items would be "undefined" in JavaScript. In Vim they are
> v:none. Proper JSON would be:
>
> [1,null,null,null,8]
>
> That's more than twice as long. Gets worse when there are more missing
> items, up to five times as long.
1. Arrays like `[1, null, null, null, 8]` are very rarely used when
communicating. So this is almost never “twice as long”. Especially
with the planned subfeatures of the channel feature.
2. `[18]` with the current parser is `[1, v:none, v:none, v:none,
8]`. If people are testing for null values using `if {val} is v:null`
the fact that it can be written like this is absolutely useless. If
people are using `if {val}` this can be as well written as
`[1,0,0,0,8]`.
3. I have no problems in counting three null values, but commas are
harder to count and they are usually visually skipped because of
having very low importance.
4. Computer has no problems with either variants, performance impact
is negligible.
5. Handling v:none in VimL in case somebody cares code adds *far* more
ticks then parsing `null` in C code.
6. It is easy to miss v:none in cases like
[
"1"
, "2"
, "3",
, "4"
]
>>>
>>> This is very likely probable case!
>>> The following JSON string leaves v:none at the end
>>> if it is parsed by current jsondecode().
>>>
>>> [
>>> "1",
>>> "2",
>>> "3",
>>> "4",
>>> ]
>>>
7. In msgpack the whole array is six bytes. JSON is more then three
times as long. Non-JSON you propose is still 1⅓ longer. For IPC it is
better. For user YAML is more readable (especially when one needs
multi-line strings), and almost always can be made less verbose then
JSON.
8. In javascript `[18]` is `[1,undefined,undefined,undefined,8]`,
not `[1,null,null,null,8]`.
>
> I propose to allow this extension to JSON. However, it should not be
> created accidentally, only when intentionally using v:none as an item.
If documentation states that channel accepts JSON, it should accept
JSON and not something else. I am not much fond of idea of
jsondecode() extensions, but do not create *yet another* standard in
interprocess communications, this action is worse then creating yet
another non-strict parser.
>
> So, we should probably give an error when using a function, instead of
> producing JSON that's not according to the standard.
2016-02-03 16:28 GMT+03:00 tyru :
> Dear Bram and Vimmers,
>
> I have read the below thread.
>
> [vim] jsonencode() does not work correctly with function references (#579)
> https://groups.google.com/forum/#!msg/vim_dev/9rf5_YmPn28/qZKB3rKvCAAJ
>
> But, I couldn't understand why Vim has had to add v:none variable.
>
>> Although a missing item in an array is not according to the JSON
>> standard, it is very useful in practice:
> I don't think so.
> If v:none variable has been added because *only* it is useful,
> it should not be.
> I don't think It should be added even breaking the JSON standard.
>
> Because, v:none and v:null is very similar.
> If a user mistake v:none for v:null,
> an invalid JSON (for strict JSON parser) will be generated!
I can also confirm that I need to constantly remind myself what
exactly I need to use.
>
> jsonencode([1,v:none,v:none,4])
>
> "undefined" and "null" in JavaScript is totally a bad part.
> Please don't follow that.
It would be better if you have shown (pointed to an article) what is
so bad here.
>>>
>>> "undefined" and "null" are to
Re: Why is v:none needed?
> Bram
What do you think about this?
On Thu, Feb 4, 2016 at 11:33 PM, tyru wrote:
> On Thu, Feb 4, 2016 at 10:08 PM, tyru wrote:
>> Hi Nikolay,
>>
>> Thanks for lots of follow-up examples :)
>>
>> On Thu, Feb 4, 2016 at 8:33 AM, Nikolay Aleksandrovich Pavlov
>> wrote:
>>> Since that thread is over I would reply here (did not reply previously
>>> because I did not realize that json and channel features are
>>> connected)
>>
>> BTW, I didn't understand why json and channel features are connected.
>> I only talked about JSON feature.
>>
>>>
The question is what to do with items that can't be converted to JSON.
I have been in doubt, whether to silently drop them or give an error.
Although a missing item in an array is not according to the JSON
standard, it is very useful in practice:
[18]
The missing items would be "undefined" in JavaScript. In Vim they are
v:none. Proper JSON would be:
[1,null,null,null,8]
That's more than twice as long. Gets worse when there are more missing
items, up to five times as long.
>>>
>>> 1. Arrays like `[1, null, null, null, 8]` are very rarely used when
>>> communicating. So this is almost never “twice as long”. Especially
>>> with the planned subfeatures of the channel feature.
>>> 2. `[18]` with the current parser is `[1, v:none, v:none, v:none,
>>> 8]`. If people are testing for null values using `if {val} is v:null`
>>> the fact that it can be written like this is absolutely useless. If
>>> people are using `if {val}` this can be as well written as
>>> `[1,0,0,0,8]`.
>>> 3. I have no problems in counting three null values, but commas are
>>> harder to count and they are usually visually skipped because of
>>> having very low importance.
>>> 4. Computer has no problems with either variants, performance impact
>>> is negligible.
>>> 5. Handling v:none in VimL in case somebody cares code adds *far* more
>>> ticks then parsing `null` in C code.
>>> 6. It is easy to miss v:none in cases like
>>>
>>> [
>>> "1"
>>> , "2"
>>> , "3",
>>> , "4"
>>> ]
>>
>> This is very likely probable case!
>> The following JSON string leaves v:none at the end
>> if it is parsed by current jsondecode().
>>
>> [
>> "1",
>> "2",
>> "3",
>> "4",
>> ]
>>
>>> 7. In msgpack the whole array is six bytes. JSON is more then three
>>> times as long. Non-JSON you propose is still 1⅓ longer. For IPC it is
>>> better. For user YAML is more readable (especially when one needs
>>> multi-line strings), and almost always can be made less verbose then
>>> JSON.
>>> 8. In javascript `[18]` is `[1,undefined,undefined,undefined,8]`,
>>> not `[1,null,null,null,8]`.
>>>
I propose to allow this extension to JSON. However, it should not be
created accidentally, only when intentionally using v:none as an item.
>>>
>>> If documentation states that channel accepts JSON, it should accept
>>> JSON and not something else. I am not much fond of idea of
>>> jsondecode() extensions, but do not create *yet another* standard in
>>> interprocess communications, this action is worse then creating yet
>>> another non-strict parser.
>>>
So, we should probably give an error when using a function, instead of
producing JSON that's not according to the standard.
>>>
>>> 2016-02-03 16:28 GMT+03:00 tyru :
Dear Bram and Vimmers,
I have read the below thread.
[vim] jsonencode() does not work correctly with function references (#579)
https://groups.google.com/forum/#!msg/vim_dev/9rf5_YmPn28/qZKB3rKvCAAJ
But, I couldn't understand why Vim has had to add v:none variable.
> Although a missing item in an array is not according to the JSON
> standard, it is very useful in practice:
I don't think so.
If v:none variable has been added because *only* it is useful,
it should not be.
I don't think It should be added even breaking the JSON standard.
Because, v:none and v:null is very similar.
If a user mistake v:none for v:null,
an invalid JSON (for strict JSON parser) will be generated!
>>>
>>> I can also confirm that I need to constantly remind myself what
>>> exactly I need to use.
>>>
jsonencode([1,v:none,v:none,4])
"undefined" and "null" in JavaScript is totally a bad part.
Please don't follow that.
>>>
>>> It would be better if you have shown (pointed to an article) what is
>>> so bad here.
>>
>> "undefined" and "null" are totally different things.
>> So "undefined === null" returns true, of course.
>
> oh sorry.
> of course "undefined === null" returns false :)
>
>> But both values mean often an absense of a value.
>> They are very confusing.
>>
>>>
Best wishes,
tyru
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are reply
Re: [patch] Add TagNotFound autocmd event
On Thu, Feb 04, 2016 at 10:04:44PM +0100, Christian Brabandt wrote: > On Do, 04 Feb 2016, Anton Lindqvist wrote: > > > On Thu, Feb 04, 2016 at 09:36:21PM +0100, Christian Brabandt wrote: > > > While I agree that this is useful, I have been thinking, if a more > > > general approach would not be more useful. Something like an Error > > > autocommand, that triggers on the EXXX numbers? > > > > I really like this idea, especially if would be the actual > > error message since it would allow people to get creative. Having > > limited experience with the Vim codebase: would it be feasible to > > trigger the autocmd event somewhere along the call stack for the emsg > > functions? At first glance it looks like that solution would require > > less changes. Compared to adding a explicit call to apply_autocmds > > prior calling any of the emsg functions. > > That's what my half working patch did. It is here: > https://github.com/chrisbra/vim-mq-patches/blob/master/error_aucmd > you might want to look into it. Never got around finishing it. Christian, I am able to apply your patch and it works fine. Here's an example of a potential use-case of mine: " Run ctags if the tag file is missing (E433) or the tag was not found (E426) augroup ctags au! Error E4\(26\|33\)* silent exe '!ctags' augroup END Are you aware of any bugs with your patch or other potential gotchas that needs to be resolved? -- :wq -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
