I added useful setdigraphs() and getdigraphs() functions to VimScript for the following reasons.
Currently, you cannot define digraphs that start with a white space because the :digraph command cannot handle the white space on the head of chars.
Providing a function to define digraphs, in other words adding setdigraphs() function, can solve this. Example:
call setdigraphs(' a', 'あ')
Space key is really suitable for assigning to a prefix key. So, it's worth to add setdigraphs() function.
There's two reasons why I added this function.
First, if VimScript has setdigraphs() function, most users expect that getdigraphs() function exists. Having setdigraphs() function but not having getdigraphs() function is confusing.
Second, if you have getdigraphs() function, it will be easy to implement custom textobjects that have a support for digraphs like below. If you have a way to define such custom textobjects, you can make much more convenient your environment for editing texts in non-English languages on Vim. So, it will be useful.
For these reasons, I decided to implement getdigraphs() function.
function! TextobjectBetweenCharacter() abort let char = getcharstr() if char ==# "\<ESC>" return '' elseif char ==# "\<C-k>" let digraph = '' for i in range(2) let char = getcharstr() if char ==# "\<ESC>" return '' endif let digraph ..= char endfor let char = getdigraphs(digraph) endif " Select text between `char`... return '' endfunction omap <expr> id TextobjectBetweenCharacter()
NOTE
I'm not sure whether the function names are good. Perhaps should they be setdigraph() and getdigraph()? What do you think about this?
https://github.com/vim/vim/pull/8580
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.![]()
Merging #8580 (90f046f) into master (20c370d) will decrease coverage by
87.56%.
The diff coverage is0.00%.
@@ Coverage Diff @@ ## master #8580 +/- ## =========================================== - Coverage 90.05% 2.49% -87.57% =========================================== Files 150 148 -2 Lines 168353 163130 -5223 =========================================== - Hits 151613 4068 -147545 - Misses 16740 159062 +142322
| Flag | Coverage Δ | |
|---|---|---|
| huge-clang-none | ? |
|
| huge-gcc-none | ? |
|
| huge-gcc-testgui | ? |
|
| huge-gcc-unittests | 2.49% <0.00%> (-0.01%) |
⬇️ |
Flags with carried forward coverage won't be shown. Click here to find out more.
| Impacted Files | Coverage Δ | |
|---|---|---|
| src/digraph.c | 0.00% <0.00%> (-97.78%) |
⬇️ |
| src/evalfunc.c | 0.00% <0.00%> (-96.25%) |
⬇️ |
| src/ex_docmd.c | 0.00% <ø> (-95.89%) |
⬇️ |
| src/float.c | 0.00% <0.00%> (-98.91%) |
⬇️ |
| src/gui_gtk_f.c | 0.00% <0.00%> (-97.54%) |
⬇️ |
| src/match.c | 0.00% <0.00%> (-97.13%) |
⬇️ |
| src/crypt_zip.c | 0.00% <0.00%> (-97.06%) |
⬇️ |
| src/sound.c | 0.00% <0.00%> (-97.00%) |
⬇️ |
| src/sha256.c | 0.00% <0.00%> (-96.94%) |
⬇️ |
| src/evalbuffer.c | 0.00% <0.00%> (-96.83%) |
⬇️ |
| ... and 139 more |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered by Codecov. Last update 20c370d...90f046f. Read the comment docs.
I think all Ex commands which have a non-trivial syntax should have a function counterpart. :digraphs is one of them; it needs a lot of code to be correctly highlighted:
syntax keyword vim9DigraphsCmd dig[raphs]
\ contained
\ nextgroup=
\ vim9DigraphsChars,
\ vim9DigraphsCharsInvalid,
\ vim9DigraphsCmdBang
\ skipwhite
syntax match vim9DigraphsCharsInvalid /\S\+/
\ contained
\ nextgroup=vim9DigraphsNumber
\ skipwhite
syntax match vim9DigraphsCmdBang /!/ contained
syntax match vim9DigraphsChars /\s\@<=\%([^ \t|]\|\\|\)\{2}\_s\@=/
\ contained
\ nextgroup=vim9DigraphsNumber
\ skipwhite
syntax match vim9DigraphsNumber /\d\+/
\ contained
\ nextgroup=vim9DigraphsChars,vim9DigraphsCharsInvalid
\ skipwhite
highlight def link vim9DigraphsChars vim9String
highlight def link vim9DigraphsCmd vim9GenericCmd
highlight def link vim9DigraphsNumber vim9Number
So, I think this feature is very useful.
I'm not sure whether the function names are good. Perhaps should they be setdigraph() and getdigraph()? What do you think about this?
The command is plural, but I think that's because it can set several digraphs in a single execution.
OTOH, this function would only set 1 digraph per invocation, right? If so, yes, I think the singular form would be better.
I think all Ex commands which have a non-trivial syntax should have a function counterpart. :digraphs is one of them; it needs a lot of code to be correctly highlighted:
I think so. (Actually, I was going to include it in the reasons, but at that time I was so sleepy that I forgot writing it. Thank you for commenting it. I added it to my top comment :))
The command is plural, but I think that's because it can set several digraphs in a single execution.
OTOH, this function would only set 1 digraph per invocation, right? If so, yes, I think the singular form would be better.
Yes, this function sets no more than 1 digraph for one call.
I didn't know that :digrpahs command can define multiple digraphs at once, so I thought these functions names should be plural form if I follow to the command name. But now I understand why the :digraphs command is plural form and think the singular form is better too. I'll change them. Thank you.
Based on similar functions for other features, there will be feature requests
to return all the digraphs and to set multiple digraphs in a single call.
What do you think about modifying getdigraph() to return all the digraphs
if no arguments are supplied? Another approach is to introduce a new
getdigraphlist() function for this.
Similarly you can introduce a setdigraphlist() function that takes a List
of digraphs and set multiple digraphs.
First, by considering type-checking in vim9script, I think it's better to introduce getdigraphlist() than modifying getdigraph() to make it return all digraphs when no arguments is given. When we return one digraph, the type should be string, but when we return multiple digraphs, the type should be list<dict<string>>. Since these types are different, providing these functions separately will lead to type-checking in vim9script more strict. So, let's add getdigraphlist().
Then, in this case, it's better to add setdigraphlist() for the following reasons. First is that users will expect Vim has setdigraphlist() if Vim has getdigraphlist(). In addition to this, similar to above, introducing setdigraphlist() function can make type-checking in vim9script more strict. Therefore, I would like to take the approach that introducing setdigraphlist().
I'm thinking the spec of getdigraphlist() as follows:
getdigraphlist([{list-all}])
What do you think of this, @lacygoill and @yegappan? Is it enough or should it be made more flexible?
It indeed seems best to have four functions, set one, set list, get one, get list.
For the arguments, instead of using a number, wouldn't it be better to use a string with one character?
The big advantage is that in a script file you can read the character. For a number you would have to convert it to know what character it is.
Example: setdigraph('ho', 'ほ')
Then another advantage is that the type of the list is a list of list of strings, instead of having a mix of string and number.
@brammool Thank you for reviewing.
It indeed seems best to have four functions, set one, set list, get one, get list.
Now I'm thinking to use dictionary to set/get multiple digraphs because digraph is a kind of mapping. Mapping functions such as maparg(), mapcheck(), and mapset() use dictionaries. Digraph functions should follow it.
However, I don't have good idea about the name for set/get list functions. Once I named them setdigraphlist() and getdigraphlist(), but the argument/the return value is dictionary, so it's confusing. Also, I thought setdigraphitems() and getdigraphitems() are not good. Do you have any good idea for this?
For the arguments, instead of using a number, wouldn't it be better to use a string with one character?
I strongly agree. Specifying a character by number is a bit confusing. Specifying characters as-is is awesome idea. I'll update the implementation.
I'm thinking the spec of getdigraphlist() as follows:
getdigraphlist([{list-all}])
- In default, it returns only the user-defined digraphs.
- But if {list-all} is specified and it is true, it returns all the digraphs, including the built-in digraphs.
- The type of return value is always dict.
What do you think of this, @lacygoill and @yegappan? Is it enough or should it be made more flexible?
—
You are receiving this because you commented.
Certainly. OK, I understood. Thank you. I'm going to add setdigraphlist() and getdigraphlist().
—
You are receiving this because you commented.
Works have done.
—
You are receiving this because you commented.
Sorry, I take it back. Some problems are still left.
—
You are receiving this because you commented.
Hi Bram, mityu and all.
Most functions added since Vim 8.0 are prefixed with feature name.
For example:
Channel functions has a "ch_" prefix.
JSON functions has a "json_" prefix.
Job functions has a "job_" prefix.
Timer functions has a "timer_" prefix.
...etc.
How about renaming the digraph functions in the same way?
digraph_get(), digraph_get_list(), digraph_set(), digraph_set_list().
Sorry for the late proposal🙇.
--
Best regards,
Hirohito Higashi (h_east)
Certainly, sign related functions also have sign_ prefix. It looks good to me.
Yes, but then only one underscore: digraph_getlist(), digraph_setlist().