[vim/vim] A few keycode issues (#1810)
zuloloxi
In vimgolf challenge Missing Library and a Typo we have noticed that <C-End> , Ctrl+End keystroke is displayed as <C-Home>. The problem come from patch 7.4.1433.
Could you rollback only the line 214 in src/keymap.h file before vim 7.4.1433, patch Problem: The Sniff interface is no longer useful, the tool has not been available for many many years, and Solution: Delete the Sniff interface and related code, like:
...
, KE_TAB /* unshifted TAB key */
, KE_S_TAB_OLD /* shifted TAB key (no longer used) */
, KE_SNIFF /* SNiFF+ input waiting (no longer used) re-added this line - 214 */
, KE_XF1 /* extra vt100 function keys for xterm */
, KE_XF2
, KE_XF3
...
Like KE_S_TAB_OLD, KE_SNIFF these Keys are (no longer used)...
Thanks in advance
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
Bram Moolenaar
zuloloxi wrote:
> In vimgolf challenge Missing Library and a Typo we have noticed that
> <C-End> , Ctrl+End keystroke is displayed as <C-Home>. The problem
> come from patch 7.4.1433.
>
> Could you rollback only the line 214 in src/keymap.h file before vim 7.4.1433, patch Problem: The Sniff interface is no longer useful, the tool has not been available for many many years, and Solution: Delete the Sniff interface and related code, like:
> ...
> , KE_TAB /* unshifted TAB key */
> , KE_S_TAB_OLD /* shifted TAB key (no longer used) */
>
> , KE_SNIFF /* SNiFF+ input waiting (no longer used) re-added this line - 214 */
>
> , KE_XF1 /* extra vt100 function keys for xterm */
> , KE_XF2
> , KE_XF3
> ...
>
> Like KE_S_TAB_OLD, KE_SNIFF these Keys are (no longer used)...
reproducible example?
--
From "know your smileys":
|-( Contact lenses, but has lost them
/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///
zuloloxi
Thanks for answer and the question ! I'm a vimgolf user, I could create a last solution with an example, you could see a <<C-Home> instead of <C-End> . To describe the problem, when I use a <C-End> keystrokes in vim, in vimgolf solutions web page it is displayed as <C-Home> string, I think because the vimgolf ruby scripts were made before vim patch 7.4.1433, and the keycodes was differents. I tested with vim 7.4.1432 it works, <C-End> is displyed in the web page as <C-End> , but does not work starting with patch 7.4.1433, it is displayed as <C-Home> string. I modified vim 8.0.647 with patch above and it works again. Here is the vimgolf issue : The keycodes have changed again
Nikolai Aleksandrovich Pavlov
The thing they are doing looks utterly wrong, there is a way both to get byte sequences out of \<> representation (that is, just use eval('"\' . '<C-Home>' . '"')) and the other way around, though latter is rather hacky:
function GetPrintableRepresentation(internal_representation) noautocmd tab new execute 'inoremap <buffer> a' a:internal_representation let ret = substitute(execute('imap <buffer> a'), '\C\v^.{-}\@', '', '') noautocmd tabclose return ret endfunction echo GetPrintableRepresentation("\x80k1")
Though it is better not use that, but ask @brammool to add some function that may do conversion: despite the fact that imap <buffer> a will show <F1> in this case all this means is that :imap is buggy: should you run
vim -u NONE -i NONE -N --cmd $'nmap x \x80k1|nmap <F1> :echomsg "foo"<CR>'
and type x there it will not run :echomsg "foo", it will do nothing (most likely “nothing” means “beep on invalid bytes”, I never saw or heard any beeps from Vim). So obviously <F1> should not be printed because rhs is actually <Char-0x80>k1.
Nikolai Aleksandrovich Pavlov
@zuloloxi So what I am saying is that they must not have that huge switch of theirs, they should obtain all needed values from Vim directly. And it would be nice to have the VimL function which does the conversion.
zuloloxi
Thanks a lot @ZyX-I
Example: I create a solution #33
Used this keystrokes in order :
<C-End>xP<C-Home><C-Right><C-Left>wwwwwwwwwwwwwwwwwwwwwwwwwwYpwwwRa<C-P><Esc>ZZ
but it display in the web text solution :
<C-Home>xP<C-Right><C-Left><C-Right>wwwwwwwwwwwwwwwwwwwwwwwwwwYpwwwRa<C-P><Esc>ZZ
The keys codes displayed by the vimgolf client:
<fd-57>xP<fd-56><fd-55><fd-54>wwwwwwwwwwwwwwwwwwwwwwwwwwYpwwwRa<C-P><Esc>ZZ
I noticed that:
<C-Home> and <C-Left> keystrokes display the same text : <C-Right> in the web solution,
but the keys codes of the vimgolf client are different for:
<C-Home> is <fd-56>
and for
<C-Left> is <fd-54>
Bram Moolenaar
> Thanks for answer and the question ! I'm a vimgolf user, I could create
> the question ! I'm a vimgolf user, I could create a last solution with
> keystrokes in vim, in vimgolf solutions web page it is displayed as
> patch 7.4.1433, and the keycodes was differents. I tested with vim
> starting with patch 7.4.1433, it is displayed as string. I modified
> vim 8.0.647 with patch above and it works again. Here is the vimgolf
> issue : The keycodes have changed again
They should not rely on the byte sequences of special characters to
always remain the same. It's just a list for internal use.
I would think the text can be obtained using :redir or execute().
But if that is difficult we could add a specific function.
Although the use case seems quite rare.
--
hundred-and-one symptoms of being an internet addict:
97. Your mother tells you to remember something, and you look for
a File/Save command.
/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///
—
Nikolai Aleksandrovich Pavlov
@brammool How this can be done with execute()? I only came up with abusing #1816, :echo[msg] "\<F1>" outputs ~@k1, something like <C-r>="\<F1>"<CR> runs :help even with set paste, <C-r><C-r>="\<F1>"<CR> outputs ~@k1 which is useless for the purpose of converting \x80k1 into <F1> without knowing what it is in advance. And I do not remember any other options which may help.
Actually I would like to see function like strtrans(s, "keys") which does conversion like "<\<F1>" into "<LT><F1>" (do not forget “Bug/non-determinism in output of maparg() and map commands” thread).
Nikolai Aleksandrovich Pavlov
And, BTW, how exactly vimgolf records its results? Based on the topic of discussion I thought about -w and I think that most logical variant to solve the issue is to add --record-input/--replay-input pair which works much like -w/-s except that resulting file format is completely documented and considered part of the Vim API (i.e. is a subject to keeping backwards compatibility).
Nikolai Aleksandrovich Pavlov
Though coming to think about it: you are breaking compatibility for all -w and macros users, this is not limited to vimgolf: if somebody is actually using -w to e.g. create large scale macros for batch editing or just keeps a number of his faviourite macros in viminfo and is using the keys which internal representation you touch then it may result in those macros corrupting of the files they are applied to after a new release.
Given that this is the first time I hear about issue then most likely either things like <C-End> are used only by the crazy vimgolfers out of all experienced users (inexperienced normally do not use macros), or people would rather write a VimL script then reuse macros stored anywhere.
In any case, do not forget: -w is using that internal representation. Recorded register (i.e. qa{actions}q) is using that internal representation as well and that is stored in viminfo. So there is a compatibility problem and it is better to stabilize and document the internal representation rather then say that vimgolf creators are wrong in what they do.
zuloloxi
Vimgolf client 0.4x was developed in 2012, I think was used the vim internal keycodes in keylog.rb
Adding the line deleted line 214 in vim 7.4.1432:
, KE_SNIFF /* SNiFF+ input waiting (no longer used) re-added this line - 214 */
rollback to the old vim internal codes (before vim 7.4.1432), and tested with patched KE_SNIFF line
vim 8.0.647, the display of vimgolf solutions are again ok !
Bram Moolenaar
Nikolai Pavlov wrote:
> Though coming to think about it: you are breaking compatibility for all `-w`
> and macros users, this is not limited to vimgolf: if somebody is actually
> using `-w` to e.g. create large scale macros for batch editing or just keeps
> a number of his faviourite macros in viminfo and is using the keys which
> internal representation you touch then it may result in those macros
> corrupting of the files they are applied to after a new release.
>
> Given that this is the first time I hear about issue then most likely either
> things like `<C-End>` are used only by the crazy vimgolfers out of all
> experienced users (inexperienced normally do not use macros), or people would
> rather write a VimL script then reuse macros stored anywhere.
>
> In any case, do not forget: `-w` is using that internal representation.
> as well and that is stored in viminfo. So there *is* a compatibility problem
> then say that vimgolf creators are wrong in what they do.
time. Either in a script or in a register. That does uses the internal
representation, so that it works in different terminals.
Hmm, that would mean we need to change the enum into using fixed numbers.
Adding a comment "do not change" isn't really sufficient (you don't see the
comment when making a change halfway).
--
Contrary to popular belief, Unix is user friendly.
It just happens to be selective about who it makes friends with.
-- Dave Parnas
Bram Moolenaar
Nikolai Pavlov wrote:
> @brammool How this can be done with `execute()`? I only came up with
> abusing #1816, `:echo[msg] "\<F1>"` outputs `~@k1`, something like
> `<C-r>="\<F1>"<CR>` runs `:help` even with `set paste`,
> `<C-r><C-r>="\<F1>"<CR>` outputs `~@k1` which is useless for the
> purpose of converting `\x80k1` into `<F1>` without knowing what it is
> in advance. And I do not remember any other options which may help.
let xx = "\<C-Home>"
echo xx[0]
echo xx[1]
echo xx[2]
> Actually I would like to see function like `strtrans(s, "keys")` which
> does conversion like `"<\<F1>"` into `"<LT><F1>"` (do not forget
> “Bug/non-determinism in output of maparg() and map commands” thread).
--
hundred-and-one symptoms of being an internet addict:
/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///
Nikolai Aleksandrovich Pavlov
This appears to work:
let xx = "\<C-Home>"
This absolutely does not help. The question is not how to convert <C-Home> to internal representation, the question is how to convert internal representation back to <C-Home>.
What would the one-line help for strstrans() be?
“When second argument is provided and equal to ‘keys’ it translates internal representation of special keys {here reference <xxx> under :h expr-quote} into printable form, suitable for being an ‘rhs’ of the mapping with default Vim 'cpoptions'. This includes translation of < into <lt> and trailing and leading spaces into <Space>.”
zuloloxi
@brammool commented
I think this means there is something wrong with Vim golf.
They should not rely on the byte sequences of special characters to
always remain the same. It's just a list for internal use.
I would think the text can be obtained using :redir or execute().
But if that is difficult we could add a specific function.
Although the use case seems quite rare.
Vimgolf client developer will try to correct the internal keycodes problem used in vimgolf, in conclusion, I drop this issue #1810.
Thanks a lot for your help.
Nikolai Aleksandrovich Pavlov
@zuloloxi I would not drop the issue, problem is that there are at least two places where the issue touches user which are not fixable in the current state without actually stabilizing the representation: first, “internal representation” is recorded as a macros which may be persisted e.g. via viminfo. Second, it is recorded with -w which looks like a thing that is able to create larger scale macros, and has other uses (most likely, including vimgolf). Both places break when vimgolf breaks as well.
zuloloxi
For me it's Ok, but VimGolf developer don't like to rollback the deleted line 214 in vim 7.4.1433 keymap.h file
zuloloxi
[it would be great...]
Thanks for answer and the question ! I'm a vimgolf user, I could create
a last solution with an example, you could see a **Thanks for answer and
the question ! I'm a vimgolf user, I could create a last solution with
an example, you could see a . To describe the problem, when I use a
keystrokes in vim, in vimgolf solutions web page it is displayed as
string, I think because the vimgolf ruby scripts were made before vim
patch 7.4.1433, and the keycodes was differents. I tested with vim
7.4.1432 it works, is displyed in the web page as , but does not work
starting with patch 7.4.1433, it is displayed as string. I modified
vim 8.0.647 with patch above and it works again. Here is the vimgolf
issue : The keycodes have changed again
@brammool commented
I think this means there is something wrong with Vim golf.
They should not rely on the byte sequences of special characters to
always remain the same. It's just a list for internal use.
I would think the text can be obtained using :redir or execute().
But if that is difficult we could add a specific function.
Although the use case seems quite rare.
It would be great if you could add a specific function to convert internal representation of special keys into printable form, like <C-Home>.
zuloloxi
Thanks a lot for the very nice work in :patch 8.0.0697: recorded key sequences may become invalid. I tested in vimgolf with vim 8.0.697, here the before last solution with 40 keystrokes : , text keycodes in solutions is OK again !
All the best !
zuloloxi
Also NICE, it would be to have a function to convert internal representation* of special keys into printable text form, like : <C-End>xP<C-Home><C-Right><C-Left>...
zeertzjq
keytrans() is implemented in patch 9.0.0449
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
closing then
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #1810 as completed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.