2016-05-15 15:16 GMT+03:00 Björn Linse <[email protected]>:
>
>> No. It is the usualy automatic string-to-number conversion,
>> timer_stop("2") is not expected to be an error.
>
> really? the argument here is not "some random number the user wants" but the
> retval of timer_start which is always a number. The user could specify the
> callback name here as a mistake, for instance.
Really. This return value may be used e.g. as a dictionary key. E.g.
if I added support for timers in frawor it could look like a function
that creates a timer (basically a wrapper around timer_start), saving
arguments into a dictionary looking like `{timer_start_result :
{'callback': callback, 'options': options, 'times_executed': 0}}`,
which will be used in one of the two ways:
1. When timer is run frawor wrapper is actually run, which uses this
dictionary to invoke actual callback. `times_executed` is used to
determine when to remove dictionary entry.
2. When plugin is unloaded the following is done
for tid in keys(a:plugdict.g._timers)
call timer_stop(tid)
endfor
Obviously in this case tid will be a string because dictionary
keys are automatically converted into strings.
There are other possible use-cases when timer id may be converted into
a string: e.g. passing it to some job via an environment variable. In
all cases you may just use `+` to convert it back, but still in these
cases tid will be stored as a string.
Also this is a convention: almost everywhere where number is expected
string may be used instead.
If you want to get exactly the output of timer_start you need to
create a new variable type like was done with jobs. With all the
resulting problems: you cannot store job_start output anywhere, but
exactly in the Vim session it was run, it cannot be serialized and
then deserialized.
>
>> In any case, e_invarg is the worst choice of the error message.
>
> No, an error message that is not already used for precisely this error
> (invalid argument type) would be worse.
It would be invalid choice and thus useless to discuss. Worst of the
valid choices if you want.
> Anyway, I was expecting Bram to change the error message if it was wrong.
I would not expect Bram to be that sane. Check error messages in json*
functions implementation (there are exactly two: e_invarg… and
e_invarg, but postponed until eval.c; also third e_intern2 which like
assert() indicates a bug in Vim and thus should not be counted) and
compare them with error messages from Neovim implementation.
You may also check how many new error messages are present in my
luaviml branch of Neovim.
>
> --
> --
> 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.
--
--
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.
