On 25 January 2016, Nikolay Aleksandrovich Pavlov <[email protected]>
wrote:
> 2016-01-25 12:51 GMT+03:00 LCD 47 <[email protected]>:
[...]
> >
> >     First example: syntastic.  Syntastic is a plugin that runs
> > various linters against a file, parses their output, and puts it in
> > a quickfix list.  Some of these linters produce more precise reports
> > when told to output JSON, and syntastic uses this function to parse
> > said reports:
> >
> >         https://goo.gl/ca8Tzb
> >
> >     The result is a list of error items, intermingled with
> > statistics, pointers to docs, and the like.  Syntastic filters
> > the useful parts out of it, sorts the items, and reformats it for
> > setloclist().  If I were to switch from the function above to
> > jsondecode(), I'd have to either redo sorting to accomodate for
> > v:true and v:false, or normalize the list to use 0 and 1 instead.
>
> Can you show the sorting code? With default sorting algorythm used
> it is OK to have `string(v:true) == 'true'` and `string(v:false) ==
> 'false'` as long as `'false' <# 'true'` which is true. This will not
> change when switching from `'false'` to `'v:false'`.

    It's more complicated than I implied above, since each checker
has to do its own processing, and sorting is mixed with a few other
transforms.  The main problem I was thinking of is this:

        https://goo.gl/ThCenV

    I added the explicit stringification of keys, and this might work.

[...]
> > Granted, most of this (but not all) could be done in Python, but the
> > point is, the v:null in jsondecode() is complicating things.
>
> v:null? Or v:none?

    v:null, I want it to expand to the empty string.

> >     In both cases I'll probably keep using the scrub and eval()
> > function to parse JSON.  It's fast, it does proper error validation,
> > and the output is easy to work with.  If I'd need to save and
> > restore states to disk as JSON, I'd probably also do it with a
> > Python function over jsonencode() and jsondecode().
>
>
> It would be more useful if you performed just one test: replace the
> function you referenced with the below code and say what breaks:
> 
> ```
> function! s:_decode_JSON(json) abort " {{{2
>     try
>         return empty(a:json) ? [] : jsondecode(a:json)
>     catch
>         return ''
>     endtry
> endfunction " }}}2
> ```
[...]

    I'll probably do exactly this at some point.  The problem is, I'm
only using a tiny minority of these checkers myself.  For the others, I
looked at the sources when I wrote the code and I played with each of
them for a few hours, but reproducing interesting cases for each checker
now may or may not be straightforward.  The result of broken parsing
would be that some issue are silently discarded, and people might not
notice that until much later. :( In the mean time, the function above is
well tested.  But this has nothing to do with Vim, of course.

    /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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui