term reset causes display problems with :GPGViewRecipients

[ThomasAH]

bd3ebdff6cb18d09c4bdbb72e28e07841c5076eb (Force Vim to re-setup the terminal after running a command) introduced "let &term = &term" to work around a problem with pinentry-curses. Most of the changed behaviour of vim after this could be solved by using a TermChanged autocmd, only one problem occurs for me:

When using :GPGViewRecipients, the output is:

This file has following recipients (Unknown recipients have a prepended "!"):
recipient1@example.com (ID: ...)
recipient2@example.com (ID: ...)
recipient3@example.com (ID: ...)
Press ENTER or type command to continue

Without the term reset, all these lines are visible.

With the term reset, all output lines are printed on the same line (as if using a carriage return without a line feed on systems requiring both), so only recipient3 and "Press ENTER or type command to continue" is visible.

I have compared the output of ":set all" and ":set termcap" for both situations (with and without the term reset in gnupg.vim), both are binary identical, verified by using the viewoutput.vim plugin and checksumming the output.

While the list of recipients scrolls through, I see "^[[>41;312;0c" appearing in the top left corner of the terminal for a fraction of a second.

Only console vim is affected, when using gvim everything is fine, but as the term settings are irrelevant for gvim, this is no surprise.

It happens in rxvt and xterm, and even when removing my ~/.vimrc and ~/.vim directory (except gnupg.vim)

I am using vim 2:7.4.488-7+deb8u1 from Debian jessie.

(side note, the bug that is worked around by setting term again does not occur for me on Debian jessie after installing pinentry-curses 0.9.7-5~bpo8+1)

[jerri]

This line "set &term=&term" basically destroys color on my system for some strange reasons. term is initially set to

:echo &term
screen-256color

which looks ok (using TMUX in an ssh env). If I execute let &term=&term, the screen switches to black and white. Not sure if this is really related to this issue, but I have the feeling it also has to be considered.

[jerri]

OK. After some experimentation I realized, the problem vanishes, if I use set-option -g default-terminal 'xterm-256color' instead of screen-256color in my .tmux.conf. Strange, but true. Sorry for disturbing! Just adding this in case someone else has this problem.

[jamessan]

the problem vanishes, if I use set-option -g default-terminal 'xterm-256color'

That's not a good idea. Tmux should always advertise a screen* or tmux* value for $TERM.

[jerri]

I only found problems with mutt for now, where screen is necessary. Do you have any references why tmux should always advertise screen or tmux? let &term=&term didn't work with `screen-`. What would be an alternative?

[jamessan]

$TERM tells applications how to talk to the terminal in which they're running. When running inside screen/tmux, the applications need to speak the language that screen/tmux understand and screen/tmux will translate that to what the running terminal understands.

That is why $TERM should always be screen*/tmux* when running inside screen/tmux. As far as the let &term=&term hack, that will likely be able to be removed once I've implemented https://github.com/jamessan/vim-gnupg/projects/1#card-9280192.

[ThomasAH]

I noticed that I no longer need my workaround in v2.6.1. Bisect shows that this has been fixed by commit 7fcea1a08423da3012aac87f5224738c85d212a1

[ThomasAH]

To be more precise: The cause for the problem is not fixed, but the output is now produced differently, so now the only line that gets lost due to this is: This file has following recipients (Unknown recipients have a prepended "!"):

In other situation, e.g. selecting a key when an ambiguous recipient is specified, nothing gets lost.

I'd say this is good enough, but feel free to reopen in case you want to investigate further.