2017-03-24 19:02 GMT+03:00 Pavol Juhas <[email protected]>:
> What for? Initialization of table is very fast anyway. And Vim has to parse
> commands
> almost immediately, when source .vimrc for example.
>
> To avoid hashing every possible abbreviation of builtin commands and to
> handle user commands. hash table can be seeded with fully spelled commands
> and with their standard abbreviations (e.g., :s, :p, etc.). If .vimrc has
> other command abbreviations these would be parsed just once with STRNCMP and
> found in the hash table thereafter. I doubt there would be any noticable
> slowdown.
This would be tricky to use with user commands: every new added user
command may alter minimal abbreviation of other user commands. I
though would be fine with “user command defined first wins shortest
ambiguous abbreviation” (example below), but to do even this you need
to populate that hash table with user commands immediately at
definition or whether or not user command wins some specific
abbreviation will depend on when abbreviation is used relative to when
commands were defined.
Though there are possible fixes: e.g. when user command is defined
clear out all prefixes from the hash table in question.
Implementation looks easier if you do not use laziness, so I would not
say that this suggestion should be implemented. Still voting for
either constructing a prefix tree (memory efficient, but lookup is
going to be slower then other variant and this is harder to implement)
or hash with all possible variants of calling the command (CPU
efficient, easier to implement, but not memory-efficient).
---
Example: with
command FooBar :call FooBaz()
command FooBaz :call FooBar()
FooBar will win F, Fo, Foo, FooB and FooBa simply because it came
first, even though after FooBaz was defined all of these abbreviations
became ambiguous (current Vim behaviour).
>
> BTW, this would likely be quite fast even without seeding the hash table;
> such variant would avoid hassles maintaining a list of what should be
> pre-seeded.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
>
> --
> --
> 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.
