Patch 8.1.2194

[Bram Moolenaar]

Patch 8.1.2194
Problem: ModifyOtherKeys is not enabled by default.
Solution: Add t_TI and t_TE to the builtin xterm termcap.
Files: runtime/doc/map.txt, src/term.c


*** ../vim-8.1.2193/runtime/doc/map.txt 2019-05-05 18:11:46.316590662 +0200
--- runtime/doc/map.txt 2019-10-20 19:21:07.285238563 +0200
***************
*** 20,26 ****
1.8 Examples |map-examples|
1.9 Using mappings |map-typing|
1.10 Mapping alt-keys |:map-alt-keys|
! 1.11 Mapping an operator |:map-operator|
2. Abbreviations |abbreviations|
3. Local mappings and functions |script-local|
4. User-defined commands |user-commands|
--- 20,27 ----
1.8 Examples |map-examples|
1.9 Using mappings |map-typing|
1.10 Mapping alt-keys |:map-alt-keys|
! 1.11 Mapping in modifyOtherKeys mode |modifyOtherKeys|
! 1.12 Mapping an operator |:map-operator|
2. Abbreviations |abbreviations|
3. Local mappings and functions |script-local|
4. User-defined commands |user-commands|
***************
*** 777,782 ****
--- 778,786 ----
always work. But in a terminal Vim gets a sequence of bytes and has to figure
out whether ALT was pressed or not.

+ If the terminal supports the modifyOtherKeys mode and it has been enabled,
+ then Vim can recognize more key combinations, see |modifyOtherKeys| below.
+
By default Vim assumes that pressing the ALT key sets the 8th bit of a typed
character. Most decent terminals can work that way, such as xterm, aterm and
rxvt. If your <A-k> mappings don't work it might be that the terminal is
***************
*** 814,820 ****
using other applications but not when inside Vim.


! 1.11 MAPPING AN OPERATOR *:map-operator*

An operator is used before a {motion} command. To define your own operator
you must create mapping that first sets the 'operatorfunc' option and then
--- 818,848 ----
using other applications but not when inside Vim.


! 1.11 MAPPING IN modifyOtherKeys mode *modifyOtherKeys*
!
! Xterm and a few other terminals can be put in a mode where keys with modifiers
! are sent with a special escape code. Vim recognizes these codes and can then
! make a difference between CTRL-H and Backspace, even when Backspace sends the
! character 8. And many more special keys.
!
! For xterm modifyOtherKeys is enabled in the builtin termcap entry. If this is
! not used you can enable modifyOtherKeys with these lines in your vimrc: >
! let &t_TI = "\<Esc>[>4;2m"
! let &t_TE = "\<Esc>[>4;m"
!
! In case the modifyOtherKeys mode causes problems you can disable it: >
! let &t_TI = ""
! let &t_TE = ""
! It does not take effect immediately. To have this work without restarting Vim
! execute a shell command, e.g.: `!ls`
!
! A known side effect effect is that in Insert mode the raw escape sequence is
! inserted after the CTRL-V key. This can be used to check whether
! modifyOtherKeys is enabled: In Insert mode type CTRL-V CTRL-V, if you get
! one byte then modifyOtherKeys is off, if you get <1b>27;5;118~ then it is on.
!
!
! 1.12 MAPPING AN OPERATOR *:map-operator*

An operator is used before a {motion} command. To define your own operator
you must create mapping that first sets the 'operatorfunc' option and then
*** ../vim-8.1.2193/src/term.c 2019-10-18 21:26:01.607768532 +0200
--- src/term.c 2019-10-20 19:04:11.227750515 +0200
***************
*** 912,917 ****
--- 912,919 ----
{(int)KS_TE, IF_EB("\033[2J\033[?47l\0338",
ESC_STR "[2J" ESC_STR_nc "[?47l" ESC_STR_nc "8")},
# endif
+ {(int)KS_CTI, IF_EB("\033[>4;2m", ESC_STR_nc "[>4;2m")},
+ {(int)KS_CTE, IF_EB("\033[>4;m", ESC_STR_nc "[>4;m")},
{(int)KS_CIS, IF_EB("\033]1;", ESC_STR "]1;")},
{(int)KS_CIE, "\007"},
{(int)KS_TS, IF_EB("\033]2;", ESC_STR "]2;")},
*** ../vim-8.1.2193/src/version.c 2019-10-20 18:45:59.716195126 +0200
--- src/version.c 2019-10-20 19:21:55.341075217 +0200
***************
*** 743,744 ****
--- 743,746 ----
{ /* Add new patch number below this line */
+ /**/
+ 2194,
/**/

--
ARTHUR: Old woman!
DENNIS: Man!
ARTHUR: Man. I'm sorry. Old man, What knight live in that castle over there?
DENNIS: I'm thirty-seven.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// 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 ///

[Paul Jolly]

FWIW - I have a stock Ubuntu 19.10 installation and I'm seeing some issues here.

Specifically I'm seeing issues using the fzf plugin which has <C-u>,
<C-p> and <C-n> mapped.

The only setup that works for me is to disable this feature via:

let &t_TI = ""
let &t_TE = ""

It's highly possible I'm doing something wrong here so any direction
would be appreciated because I would like to get this working.

I tried the following settings in my .Xsession:

XTerm*vt100.modifyOtherKeys: 1

Then I tried:

XTerm*vt100.modifyOtherKeys: 2

which broke bash. So it appears this setting does have an effect.

Then I tried setting:

let &t_TI = "\<Esc>[>4;2m"

let &t_TE = "\<Esc>[>4;m"

in my .vimrc.

But none of these combinations "worked".

As you can probably tell I'm not really sure what I'm doing here :)
But it does appear that the modifyOtherKeys setting change did have an
effect (because setting it to 2 broke bash)

Any ideas?

> --
> --
> 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 vim_dev+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/201910201753.x9KHrqlK020027%40masaka.moolenaar.net.

[Bram Moolenaar]

Paul Jolly wrote:

> FWIW - I have a stock Ubuntu 19.10 installation and I'm seeing some
> issues here.
>
> Specifically I'm seeing issues using the fzf plugin which has <C-u>,
> <C-p> and <C-n> mapped.
>
> The only setup that works for me is to disable this feature via:
>
> let &t_TI = ""
> let &t_TE = ""

I wonder why those mappings don't work. Can you reproduce this with a
simple script?

> It's highly possible I'm doing something wrong here so any direction
> would be appreciated because I would like to get this working.
>
> I tried the following settings in my .Xsession:
>
> XTerm*vt100.modifyOtherKeys: 1
>
> Then I tried:
>
> XTerm*vt100.modifyOtherKeys: 2
>
> which broke bash. So it appears this setting does have an effect.

Bash won't be able to handle the escape sequences that Ctrl keys produce
when modifyOtherKeys is enabled.

> Then I tried setting:
>
> let &t_TI = "\<Esc>[>4;2m"
> let &t_TE = "\<Esc>[>4;m"
>
> in my .vimrc.
>
> But none of these combinations "worked".

In what way?

> As you can probably tell I'm not really sure what I'm doing here :)
> But it does appear that the modifyOtherKeys setting change did have an
> effect (because setting it to 2 broke bash)

I fixed a couple of problems related to modifyOtherkeys, there might be
one more. There is one open issue related to the terminal debugger that
I haven't been able to figure out yet.

--
Everybody wants to go to heaven, but nobody wants to die.

[Paul Jolly]

Apologies for the delay in replying.

> I wonder why those mappings don't work. Can you reproduce this with a
> simple script?

I haven't been able to reproduce this, no.

> Bash won't be able to handle the escape sequences that Ctrl keys produce
> when modifyOtherKeys is enabled.

Noted, thanks.

> > As you can probably tell I'm not really sure what I'm doing here :)
> > But it does appear that the modifyOtherKeys setting change did have an
> > effect (because setting it to 2 broke bash)
>
> I fixed a couple of problems related to modifyOtherkeys, there might be
> one more. There is one open issue related to the terminal debugger that
> I haven't been able to figure out yet.

I've raised https://github.com/junegunn/fzf.vim/issues/900 to get
expertise from the fzf side on this as well.

Thanks

[Bram Moolenaar]

The problem with the Terminal debugger has been fixed. This was part of
the terminal window support, thus if you are not using a terminal window
it's unlikely to have any effect.

--
George: "I just got a new set of golf clubs for my wife!"
John: "Great trade!"

[Paul Jolly]

Bram - I wonder whether one solution here is to "wrap" fzf in a command that it puts the terminal in the correct mode for fzf, calls fzf, then returns the terminal back to the state it was in (for Vim), with the wrapped fzf consuming stdin, and writing to stdout and stderr etc.

Would that be possible?

I'm afraid my terminal knowledge here is close to zero. 

If you could help point me in the right directions for the escape codes I would need to try this then that would be great.

Best,

Paul

[Bram Moolenaar]

Paul Jolly wrote:

> Bram - I wonder whether one solution here is to "wrap" fzf in a command
> that it puts the terminal in the correct mode for fzf, calls fzf, then
> returns the terminal back to the state it was in (for Vim), with the
> wrapped fzf consuming stdin, and writing to stdout and stderr etc.
>
> Would that be possible?
>
> I'm afraid my terminal knowledge here is close to zero.
>
> If you could help point me in the right directions for the escape codes I
> would need to try this then that would be great.

When starting a shell with ":sh" or ":!cmd" then Vim will set the
terminal to "cooked" mode, that is what normal commands expect.
When running a terminal inside Vim this doesn't happen, since Vim still
needs the raw keys, e.g. for mouse events. We can't really change that
without breaking quite a lot of things.

I wonder how fzf is started in the terminal. It might help to wrap it
in a shell, so that the shell initializes the terminal.

--
TIM: To the north there lies a cave, the cave of Caerbannog, wherein, carved
in mystic runes, upon the very living rock, the last words of Olfin
Bedwere of Rheged make plain the last resting place of the most Holy
Grail.

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Paul Jolly]

> When starting a shell with ":sh" or ":!cmd" then Vim will set the
> terminal to "cooked" mode, that is what normal commands expect.
> When running a terminal inside Vim this doesn't happen, since Vim still
> needs the raw keys, e.g. for mouse events. We can't really change that
> without breaking quite a lot of things.
>
> I wonder how fzf is started in the terminal. It might help to wrap it
> in a shell, so that the shell initializes the terminal.

Thanks - I think we're talking about the same thing - at least I'm
intending that my wrapper be the thing that will initialize the
terminal, which is I think what you're referring to when you say "so

that the shell initializes the terminal".

(I think) my question is: how should the shell initialize the terminal?