Yegappan wrote:
> > > > > > > Thinking about this some more, we should modify the existing
> > > > > > > sign_place() function to always accept a List argument
> > > > > >
> > > > > > Just to say, I don't have any strong feelings either way. I'll defer
> > > > > > to those with more experience of the Vim API and how changes are
> > > > > > made.
> > > > >
> > > > > The current sign_place() function is basically mimicking ":sign
> > > > > place".
> > > > > One of the quirks is that it takes a file name, not a buffer number.
> > > > >
> > > >
> > > > The sign_place() function accepts either a buffer name or a buffer
> > > > number. The {expr} argument to sign_place() is same as the {expr}
> > > > argument to bufname().
> > > >
> > > > >
> > > > > It also has an optional {id}, where zero means it's not passed in.
> > > > >
> > > >
> > > > Yes. Converting sign_place() to accept a List of dicts will make this
> > > > simpler.
> > > >
> > > > >
> > > > > Adding a new function that takes a list of dictionaries could be a
> > > > > good
> > > > > alternative. We then do need to validate the entries to check if the
> > > > > required keys are included. It will then be possible to either pass a
> > > > > buffer number or a file name.
> > > > >
> > > >
> > > > I have the changes for this ready to go (including the check for
> > > > existence
> > > > of the required keys). I will merge my local changes with the recent
> > > > changes to sign.c/evalfunc.c and create a pull request.
> > > >
> > >
> > > I have created PR #4602 (https://github.com/vim/vim/pull/4602) for this.
> > > I have simplified the sign_place(), sign_unplace() and sign_getplaced()
> > > functions. Took some time to make these changes as the sign tests heavily
> > > use these functions. Note that this change is not backward compatible.
> >
> > The sign functions were added more than half a year ago. I don't think
> > a change that is not backward compatible will be appreciated.
> >
> > I think for sign_define() we can support both the old arguments and a
> > list argument. for sign_getplaced() we don't need changes. For
> > place/unplace add a new "list" function:
> >
> > sign_define({name} [, {dict}])
> > sign_define({list})
> >
> > sign_getplaced([{expr} [, {dict}]])
> >
> > sign_place({id}, {group}, {name}, {expr} [, {dict}])
> > sign_placelist({list})
> >
> > sign_unplace({group} [, {dict}])
> > sign_unplacelist({list})
> >
> > Does that sound reasonable?
> >
>
> Instead of adding the new sign_placelist() and sign_unplacelist() functions,
> how about modifying the existing sign_place() and sign_unplace() functions
> to also accept a {list} argument (similar to the sign_define() function
> above)?
> So the new set of functions will be like below:
>
> sign_define({name} [, {dict}])
> sign_define({list})
>
> sign_getplaced([{expr} [, {dict}]])
>
> sign_place({id}, {group}, {name}, {expr} [, {dict}])
> sign_place({list})
>
> sign_unplace({group} [, {dict}])
> sign_unplace({list})
Hmm, it would work, of course, but is it better? I don't think so. The
documentation for sign_place() would be two complete different sections,
one explaining the first set of arguments and one explaining the {list}
argument. That doesn't make it simpler for the user.
It's true that having both sign_place() and sign_placelist() makes the
list of functions longer, but since the meaning is obvious I don't think
it matters much.
--
'I generally avoid temptation unless I can't resist it."
-- Mae West
/// Bram Moolenaar -- [email protected] -- 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/201907051217.x65CH4qH032509%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.
