Re: gvim and ASCII glyphs

[Matěj Cepl]

On 2016-10-26, 22:23 GMT, Tony Mechelynck wrote:
> Don't make the too frequent error to believe that everyone 
> else, or at least most of them, has the same preferences as 
> you. The fact that we hardly ever see a post about whether or 
> not vimballs are the way to go does not necessarily mean that 
> everyone dislikes them the way you do. On the contrary, 
> I would intrpret that silence as meaning that the current 
> state of affairs is OK for most people, because if it weren't 
> they would complain. I hardly ever see such a complaint, yours 
> is a "once in a blue moon" thing.

I don’t think this is the case. I have been following a lot of 
vim-related news and communications in the last year or more, 
and I have found a lot of plugins which are just uploaded to 
vim.org/scripts/ (mostly tarballs or zip archives), and a lot of 
plugins which are in a git repo (99.9% cases in GitHub). This is 
the first vimball I see in a long long time.

And you are wrong if you except complains ... featuretitis 
doesn’t represent itself by complaints from users. Only by the 
rotting code, and emerging (security and other) bugs.

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
The state is the great fictitious entity by which everyone seeks
to live at the expense of everyone else.
  -- Frederick Bastiat

-- 
-- 
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: gvim and ASCII glyphs

[Tony Mechelynck]

On Wed, Oct 26, 2016 at 8:32 PM, Matěj Cepl  wrote:
> On 2016-10-26, 17:26 GMT, Charles E Campbell wrote:
>> If you're using utf-8, its easy to get the glyph transform
>> with mathmenu.vim (comes with
>> http://www.drchip.org/astronaut/vim/index.html#MATH):  type  >=, select
>> with visual-block (ctrl-v), then press the "&" key.  Same sort of thing
>> for <=, too.
>> Lower case: select letter(s), press "_".  Upper case: select letter(s),
>> press "^".  Etc.
>
> Thank you very much.
>
> However, I have to say it. My first step was to create a git
> repo https://gitlab.com/mcepl/math-vba and use it via
> preferred pathogen-style package manager of my choice (vim-plug
> in my case). I know that vimballs are you baby, but isn't the
> time to admit defeat and give up on it and declare
> pathogen-style repos as a preferred way of dealing with vim
> plugins? It was an interesting idea, but it just didn't catch
> with the vim population it seems.
>
> Best,
>
> Matěj

Don't make the too frequent error to believe that everyone else, or at
least most of them, has the same preferences as you. The fact that we
hardly ever see a post about whether or not vimballs are the way to go
does not necessarily mean that everyone dislikes them the way you do.
On the contrary, I would intrpret that silence as meaning that the
current state of affairs is OK for most people, because if it weren't
they would complain. I hardly ever see such a complaint, yours is a
"once in a blue moon" thing.

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: [vim/vim] Vim hangs and segfaults with a scratch PHP buffer (#1200)

[h_east]

Hi ChrisBra, Lifepillar and list,

2016-10-27(Thu) 5:19:43 UTC+9 Christian Brabandt:
> If that is really the case, I wonder if we can't just get rid of those lines 
> https://github.com/vim/vim/blob/master/src/popupmnu.c#L585-L593
> 
> 
> I could prepare a patch.

How about an attached patch?
--
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.
diff --git a/src/popupmnu.c b/src/popupmnu.c
index d9d1fee..cf5bd16 100644
--- a/src/popupmnu.c
+++ b/src/popupmnu.c
@@ -582,7 +582,8 @@ pum_set_selected(int n, int repeat)
 
 	if (curwin->w_p_pvw)
 	{
-		if (curbuf->b_fname == NULL
+		if (curwin_save != curwin && curwin_save->w_buffer != curbuf
+			&& curbuf->b_fname == NULL
 			&& curbuf->b_p_bt[0] == 'n' && curbuf->b_p_bt[2] == 'f'
 			&& curbuf->b_p_bh[0] == 'w')
 		{

Re: JSON parsing problems

[Nikolay Aleksandrovich Pavlov]

2016-10-26 23:05 GMT+03:00 Dominique Pellé :
> Christian Brabandt  wrote:
>
>> On Mi, 26 Okt 2016, LCD 47 wrote:
>>
>>> * There is even a segfault:
>>>
>>> json_decode(repeat('[', 10))" segfault
>>>
>>
>> Oh, that one is nasty. I just made a backtrace:
>> #0  0x74d0bbab in _int_malloc (av=av@entry=0x7502bb00 
>> , bytes=bytes@entry=88) at malloc.c:3384
>> #1  0x74d0dd94 in __GI___libc_malloc (bytes=88) at malloc.c:2925
>> #2  0x004ea63a in lalloc (size=88, message=1) at misc2.c:942
>> #3  0x004ea565 in alloc_clear (size=88) at misc2.c:864
>> #4  0x004c3dff in list_alloc () at list.c:75
>> #5  0x004c3e62 in rettv_list_alloc (rettv=0x7f7ff230) at 
>> list.c:95
>> #6  0x0060c9e6 in json_decode_array (reader=0x7fffd1b0, 
>> res=0x7f7ff230, options=0) at json.c:388
>> #7  0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
>> res=0x7f7ff230, options=0) at json.c:732
>> #8  0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
>> res=0x7f7ff2f0, options=0) at json.c:408
>> #9  0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
>> res=0x7f7ff2f0, options=0) at json.c:732
>> #10 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
>> res=0x7f7ff3b0, options=0) at json.c:408
>> #11 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
>> res=0x7f7ff3b0, options=0) at json.c:732
>> #12 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
>> res=0x7f7ff470, options=0) at json.c:408
>> #13 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
>> res=0x7f7ff470, options=0) at json.c:732
>> #14 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
>> res=0x7f7ff530, options=0) at json.c:408
>> #15 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
>> res=0x7f7ff530, options=0) at json.c:732
>> #16 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
>> res=0x7f7ff5f0, options=0) at json.c:408
>> #17 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
>> res=0x7f7ff5f0, options=0) at json.c:732
>> #18 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
>> res=0x7f7ff6b0, options=0) at json.c:408
>> #19 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
>> res=0x7f7ff6b0, options=0) at json.c:732
>> #20 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
>> res=0x7f7ff770, options=0) at json.c:408
>> #21 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
>> res=0x7f7ff770, options=0) at json.c:732
>> #22 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
>> res=0x7f7ff830, options=0) at json.c:408
>> #23 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
>> res=0x7f7ff830, options=0) at json.c:732
>> #24 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
>> res=0x7f7ff8f0, options=0) at json.c:408
>> #25 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
>> res=0x7f7ff8f0, options=0) at json.c:732
>> #26 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
>> res=0x7f7ff9b0, options=0) at json.c:408
>> #27 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
>> res=0x7f7ff9b0, options=0) at json.c:732
>> #28 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
>> res=0x7f7ffa70, options=0) at json.c:408
>> #29 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
>> res=0x7f7ffa70, options=0) at json.c:732
>> #30 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
>> res=0x7f7ffb30, options=0) at json.c:408
>> #31 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
>> res=0x7f7ffb30, options=0) at json.c:732
>>
>> and goes on until:
>> (gdb) bt -1
>> #87314 0x0060e06b in main (argc=4, argv=0x7fffe2e8) at main.c:415
>>
>> That looks like some kind of memory corruption, however neither valgrind
>> nor asan return anything useful
>
>
> It's a stack overflow caused by a deep recursivity.
>
> If we can reduce the stack usage of functions json_decode_array()
> and json_decode_items(), then we can allow deeper recursivity.
> But it will still crash if with enough [  The only way to fix it
> would be to avoid recursive calls, but is it worth making it more
> complex for such unlikely edge cases?

Non-recursive JSON parser was already written, and it was done more
then once. Specifically Neovim’s non-recursive JSON parser is a “port”
(mostly the structure of the code, also prevented me from introducing
some bugs) of some javascript parser: apparently people there saw some
point in preventing stack overflows and it is not the only part of
Neovim which was (re)written by me to be non-recursive: why should I
make intentionally bugged code if I can do the other way around? Also
proper 

Re: JSON parsing problems

[Bram Moolenaar]

Lcd wrote:

> Today I stumbled upon this article about JSON:
> 
> http://seriot.ch/parsing_json.php
> 
> The article links to a set of tests:
> 
> https://github.com/nst/JSONTestSuite
> 
> A quick run of the "y" and "n" tests against Vim's json_decode()
> finds a few problems.  Not particularly ground-breaking, but perhaps
> worth fixing:
> 
> * These should be accepted, but aren't:
> 
> json_decode('{"a":"b","a":"c"}')" E685
> json_decode('{"a":"b","a":"b"}')" E685

Those should not be internal errors.  But even though it's valid json,
the duplicate key is still an error.

> json_decode('{"":0}')   " E474

Supporting an empty key has been reqeusted before.


> * These should be rejected, but aren't:
> 
> json_decode('["",]')" ['']
> json_decode('[1,]') " [1]
> json_decode('{1:1}')" {'1': 1}
> json_decode('{"id":0,}')" {'id': 0}
> json_decode('["\uD800\u"]') " ['']
> json_decode('["\uD800\u1"]')" ['<01>']
> json_decode('["\uD800\u1x"]')   " ['<01>x']
> json_decode('["\x00"]') " ['x00']
> json_decode('["\a"]')   " ['a']
> json_decode('[True]')   " [v:true]

Most are fine to accept.  The trailing \u seems wrong though.

> * There is even a segfault:
> 
> json_decode(repeat('[', 10))" segfault

Probably running out of stack.  Would be difficult to fix, would need to
make the parsing iterative instead of recursive.

> There are others, the above are just the main ones.  Also, for the
> "n" tests I was just checking that json_decode() rises an exception, not
> that the exception rised actually makes sense.

-- 
The problem with political jokes is that they get elected.

 /// 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: JSON parsing problems

[Dominique Pellé]

Christian Brabandt  wrote:

> On Mi, 26 Okt 2016, LCD 47 wrote:
>
>> * There is even a segfault:
>>
>> json_decode(repeat('[', 10))" segfault
>>
>
> Oh, that one is nasty. I just made a backtrace:
> #0  0x74d0bbab in _int_malloc (av=av@entry=0x7502bb00 
> , bytes=bytes@entry=88) at malloc.c:3384
> #1  0x74d0dd94 in __GI___libc_malloc (bytes=88) at malloc.c:2925
> #2  0x004ea63a in lalloc (size=88, message=1) at misc2.c:942
> #3  0x004ea565 in alloc_clear (size=88) at misc2.c:864
> #4  0x004c3dff in list_alloc () at list.c:75
> #5  0x004c3e62 in rettv_list_alloc (rettv=0x7f7ff230) at list.c:95
> #6  0x0060c9e6 in json_decode_array (reader=0x7fffd1b0, 
> res=0x7f7ff230, options=0) at json.c:388
> #7  0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
> res=0x7f7ff230, options=0) at json.c:732
> #8  0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
> res=0x7f7ff2f0, options=0) at json.c:408
> #9  0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
> res=0x7f7ff2f0, options=0) at json.c:732
> #10 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
> res=0x7f7ff3b0, options=0) at json.c:408
> #11 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
> res=0x7f7ff3b0, options=0) at json.c:732
> #12 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
> res=0x7f7ff470, options=0) at json.c:408
> #13 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
> res=0x7f7ff470, options=0) at json.c:732
> #14 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
> res=0x7f7ff530, options=0) at json.c:408
> #15 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
> res=0x7f7ff530, options=0) at json.c:732
> #16 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
> res=0x7f7ff5f0, options=0) at json.c:408
> #17 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
> res=0x7f7ff5f0, options=0) at json.c:732
> #18 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
> res=0x7f7ff6b0, options=0) at json.c:408
> #19 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
> res=0x7f7ff6b0, options=0) at json.c:732
> #20 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
> res=0x7f7ff770, options=0) at json.c:408
> #21 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
> res=0x7f7ff770, options=0) at json.c:732
> #22 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
> res=0x7f7ff830, options=0) at json.c:408
> #23 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
> res=0x7f7ff830, options=0) at json.c:732
> #24 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
> res=0x7f7ff8f0, options=0) at json.c:408
> #25 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
> res=0x7f7ff8f0, options=0) at json.c:732
> #26 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
> res=0x7f7ff9b0, options=0) at json.c:408
> #27 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
> res=0x7f7ff9b0, options=0) at json.c:732
> #28 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
> res=0x7f7ffa70, options=0) at json.c:408
> #29 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
> res=0x7f7ffa70, options=0) at json.c:732
> #30 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
> res=0x7f7ffb30, options=0) at json.c:408
> #31 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
> res=0x7f7ffb30, options=0) at json.c:732
>
> and goes on until:
> (gdb) bt -1
> #87314 0x0060e06b in main (argc=4, argv=0x7fffe2e8) at main.c:415
>
> That looks like some kind of memory corruption, however neither valgrind
> nor asan return anything useful


It's a stack overflow caused by a deep recursivity.

If we can reduce the stack usage of functions json_decode_array()
and json_decode_items(), then we can allow deeper recursivity.
But it will still crash if with enough [  The only way to fix it
would be to avoid recursive calls, but is it worth making it more
complex for such unlikely edge cases?

gcc and clang have similar stack overflows when parsing C on edge
cases.  I remember opening this old bug which causes gcc to crash with
many stars *** and it was not deemed worth fixing. See:

http://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg208512.html

12 years after opening this ticket, I see that both clang and gcc still
crash when trying to compile the c file attached in above bug.

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 

Re: JSON parsing problems

[Nikolay Aleksandrovich Pavlov]

2016-10-26 19:27 GMT+03:00 LCD 47 :
> Today I stumbled upon this article about JSON:
>
> http://seriot.ch/parsing_json.php
>
> The article links to a set of tests:
>
> https://github.com/nst/JSONTestSuite
>
> A quick run of the "y" and "n" tests against Vim's json_decode()
> finds a few problems.  Not particularly ground-breaking, but perhaps
> worth fixing:
>
> * These should be accepted, but aren't:
>
> json_decode('{"a":"b","a":"c"}')" E685

According to the spec, behaviour is implementation-defined in this
case. Error is acceptable and if tests state otherwise they are wrong.
Specifically *E685* error is not, it always indicates a bug.

Relevant quote from https://tools.ietf.org/html/rfc7159#section-4:

> When the names within an object are not
> unique, the behavior of software that receives such an object is
> unpredictable.  Many implementations report the last name/value pair
> only.  Other implementations report an error or fail to parse the
> object, and some implementations report all of the name/value pairs,
> including duplicates.


> json_decode('{"a":"b","a":"b"}')" E685

Same.

> json_decode('{"":0}')   " E474

Not too much time passed since Vim started to allow empty strings.
Though I agree that this is a bug now, this had a reason not to work.
Neovim uses special dictionaries in this case, but I could not
consider them easy to use.

>
> * These should be rejected, but aren't:
>
> json_decode('["",]')" ['']
> json_decode('[1,]') " [1]
> json_decode('{1:1}')" {'1': 1}
> json_decode('{"id":0,}')" {'id': 0}
> json_decode('["\uD800\u"]') " ['']
> json_decode('["\uD800\u1"]')" ['<01>']
> json_decode('["\uD800\u1x"]')   " ['<01>x']
> json_decode('["\x00"]') " ['x00']
> json_decode('["\a"]')   " ['a']
> json_decode('[True]')   " [v:true]

AFAIR Bram explicitly said that he is going to accept some
non-standard syntax when I raised the similar question.

>
> * There is even a segfault:
>
> json_decode(repeat('[', 10))" segfault

One of the reasons I did not import Vim implementation to Neovim: it
is recursive.

>
> There are others, the above are just the main ones.  Also, for the
> "n" tests I was just checking that json_decode() rises an exception, not
> that the exception rised actually makes sense.

Vim errors at 8.0.42 still suck, I did much better when writing
json_decode for Neovim.

>
> /lcd
>
> --
> --
> 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: JSON parsing problems

[Christian Brabandt]

Hi Dominique!

On Mi, 26 Okt 2016, Dominique Pellé wrote:

> http://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg208512.html
> 
> 12 years after opening this ticket, I see that both clang and gcc still
> crash when trying to compile the c file attached in above bug.

Interesting read.

BTW: Your test program shows a bug in Vim when viewed with breakindent. 
The cursor will be positioned after the last * (probably because the 
indented line is so long, that the first visible line does not show any 
indent).

Best,
Christian
-- 
DAU: "Gestern funktionierten meine Floppies einwandfrei, heute nimmer."
EDV: "Wie haben Sie sie gelagert?"
DAU: "Gelocht und in einen Leitz Ordner getan."

-- 
-- 
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: JSON parsing problems

[Christian Brabandt]

On Mi, 26 Okt 2016, LCD 47 wrote:

> * There is even a segfault:
> 
> json_decode(repeat('[', 10))" segfault
> 

Oh, that one is nasty. I just made a backtrace:
#0  0x74d0bbab in _int_malloc (av=av@entry=0x7502bb00 , 
bytes=bytes@entry=88) at malloc.c:3384
#1  0x74d0dd94 in __GI___libc_malloc (bytes=88) at malloc.c:2925
#2  0x004ea63a in lalloc (size=88, message=1) at misc2.c:942
#3  0x004ea565 in alloc_clear (size=88) at misc2.c:864
#4  0x004c3dff in list_alloc () at list.c:75
#5  0x004c3e62 in rettv_list_alloc (rettv=0x7f7ff230) at list.c:95
#6  0x0060c9e6 in json_decode_array (reader=0x7fffd1b0, 
res=0x7f7ff230, options=0) at json.c:388
#7  0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
res=0x7f7ff230, options=0) at json.c:732
#8  0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
res=0x7f7ff2f0, options=0) at json.c:408
#9  0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
res=0x7f7ff2f0, options=0) at json.c:732
#10 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
res=0x7f7ff3b0, options=0) at json.c:408
#11 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
res=0x7f7ff3b0, options=0) at json.c:732
#12 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
res=0x7f7ff470, options=0) at json.c:408
#13 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
res=0x7f7ff470, options=0) at json.c:732
#14 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
res=0x7f7ff530, options=0) at json.c:408
#15 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
res=0x7f7ff530, options=0) at json.c:732
#16 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
res=0x7f7ff5f0, options=0) at json.c:408
#17 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
res=0x7f7ff5f0, options=0) at json.c:732
#18 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
res=0x7f7ff6b0, options=0) at json.c:408
#19 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
res=0x7f7ff6b0, options=0) at json.c:732
#20 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
res=0x7f7ff770, options=0) at json.c:408
#21 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
res=0x7f7ff770, options=0) at json.c:732
#22 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
res=0x7f7ff830, options=0) at json.c:408
#23 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
res=0x7f7ff830, options=0) at json.c:732
#24 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
res=0x7f7ff8f0, options=0) at json.c:408
#25 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
res=0x7f7ff8f0, options=0) at json.c:732
#26 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
res=0x7f7ff9b0, options=0) at json.c:408
#27 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
res=0x7f7ff9b0, options=0) at json.c:732
#28 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
res=0x7f7ffa70, options=0) at json.c:408
#29 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
res=0x7f7ffa70, options=0) at json.c:732
#30 0x0060ca9e in json_decode_array (reader=0x7fffd1b0, 
res=0x7f7ffb30, options=0) at json.c:408
#31 0x0060d692 in json_decode_item (reader=0x7fffd1b0, 
res=0x7f7ffb30, options=0) at json.c:732

and goes on until:
(gdb) bt -1
#87314 0x0060e06b in main (argc=4, argv=0x7fffe2e8) at main.c:415

That looks like some kind of memory corruption, however neither valgrind
nor asan return anything useful


Best,
Christian
-- 
Des Schweines Ende ist der Wurst Anfang.
-- Wilhelm Busch

-- 
-- 
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: gvim and ASCII glyphs

[Matěj Cepl]

On 2016-10-26, 17:26 GMT, Charles E Campbell wrote:
> If you're using utf-8, its easy to get the glyph transform 
> with mathmenu.vim (comes with
> http://www.drchip.org/astronaut/vim/index.html#MATH):  type  >=, select
> with visual-block (ctrl-v), then press the "&" key.  Same sort of thing
> for <=, too.
> Lower case: select letter(s), press "_".  Upper case: select letter(s),
> press "^".  Etc.

Thank you very much.

However, I have to say it. My first step was to create a git 
repo https://gitlab.com/mcepl/math-vba and use it via
preferred pathogen-style package manager of my choice (vim-plug 
in my case). I know that vimballs are you baby, but isn't the 
time to admit defeat and give up on it and declare 
pathogen-style repos as a preferred way of dealing with vim 
plugins? It was an interesting idea, but it just didn't catch 
with the vim population it seems.

Best,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
The state is the great fictitious entity by which everyone seeks
to live at the expense of everyone else.
  -- Frederick Bastiat

-- 
-- 
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: gvim and ASCII glyphs

[Charles E Campbell]

Matěj Cepl wrote:
> So, for example how to make >= and <= be included so that they 
> translate into (glyphs from :digraphs):
>
> =< ≤  8804
> >= ≥  8805
>
> Matěj
>
Hello:

If you're using utf-8, its easy to get the glyph transform with
mathmenu.vim (comes with
http://www.drchip.org/astronaut/vim/index.html#MATH):  type  >=, select
with visual-block (ctrl-v), then press the "&" key.  Same sort of thing
for <=, too.
Lower case: select letter(s), press "_".  Upper case: select letter(s),
press "^".  Etc.

You'll also find an example with:
http://www.drchip.org/images/example_math.png .  Enable it by typing
":Math".

Regards,
Chip Campbell

-- 
-- 
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] improve ended-job check

[Ozaki Kiichi]

Additionally;

https://github.com/vim/vim/blob/46fceaa/runtime/doc/channel.txt#L601

> Vim checks about every 10 seconds for jobs that ended.

Maybe we can drop this line :)

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

JSON parsing problems

[LCD 47]

Today I stumbled upon this article about JSON:

http://seriot.ch/parsing_json.php

The article links to a set of tests:

https://github.com/nst/JSONTestSuite

A quick run of the "y" and "n" tests against Vim's json_decode()
finds a few problems.  Not particularly ground-breaking, but perhaps
worth fixing:

* These should be accepted, but aren't:

json_decode('{"a":"b","a":"c"}')" E685
json_decode('{"a":"b","a":"b"}')" E685
json_decode('{"":0}')   " E474

* These should be rejected, but aren't:

json_decode('["",]')" ['']
json_decode('[1,]') " [1]
json_decode('{1:1}')" {'1': 1}
json_decode('{"id":0,}')" {'id': 0}
json_decode('["\uD800\u"]') " ['']
json_decode('["\uD800\u1"]')" ['<01>']
json_decode('["\uD800\u1x"]')   " ['<01>x']
json_decode('["\x00"]') " ['x00']
json_decode('["\a"]')   " ['a']
json_decode('[True]')   " [v:true]

* There is even a segfault:

json_decode(repeat('[', 10))" segfault

There are others, the above are just the main ones.  Also, for the
"n" tests I was just checking that json_decode() rises an exception, not
that the exception rised actually makes sense.

/lcd

-- 
-- 
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: [vim/vim] syntax/bibtex.vim: breaks if for example howpublished = {{ \$ }} (#1197)

[Dr. Bernd Feige]

Am Mittwoch, den 26.10.2016, 02:13 -0700 schrieb Konfekt:
> The highlighting stops if an entry contains an escaped `$`, for
> example
> ```tex
> @Book{book
>   title ={book},
>   year = {2000},
>   author =   {author}
>   howpublished = {editor DM 72.00; \$ 34.30 (1981)}
> }
> ```

Could you try the attached patch?

Best,
Bernd

-- 
-- 
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.
=== modified file 'bib.vim'
--- bib.vim	2016-09-13 12:55:18 +
+++ bib.vim	2016-10-26 10:30:20 +
@@ -81,7 +81,7 @@
 syn match bibKey contained /\s*[^ \t}="]\+,/hs=s,he=e-1 nextgroup=bibField
 syn match bibVariable contained /[^{}," \t=]/
 syn region bibComment start=/./ end=/^\s*@/me=e-1 contains=@bibCommentContents nextgroup=bibEntry
-syn region bibMath contained start=/\$/ end=/\$/ skip=/\(\\\$\)/
+syn region bibMath contained start=/[^\\]\$/ end=/\$/ skip=/\(\\\$\)/
 syn region bibQuote contained start=/"/ end=/"/ skip=/\(\\"\)/ contains=@bibVarContents
 syn region bibBrace contained start=/{/ end=/}/ skip=/\(\\[{}]\)/ contains=@bibVarContents
 syn region bibParen contained start=/(/ end=/)/ skip=/\(\\[()]\)/ contains=@bibVarContents