'$q q' shows at the first line

[littleylv]

:version
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Aug 22 2017 18:15:34)
MacOS X (unix) version
Included patches: 1-983
Compiled by Homebrew

I'm using vim version 8.0.983. Everytime i start up vim, it shows $q q at the first line.

This is what the command $ vim shows:

$q q
~                                                                               
~                                                                                                                                                                                        
~                                                                               
~                              VIM - Vi IMproved                                
~                                                                               
~                               version 8.0.983                                 
~                           by Bram Moolenaar et al.                            
~                 Vim is open source and freely distributable                   
~                                                                               
~                        Help poor children in Uganda!                          
~                type  :help iccf<Enter>       for information                  
~                                                                               
~                type  :q<Enter>               to exit                          
~                type  :help<Enter>  or  <F1>  for on-line help                 
~                type  :help version8<Enter>   for version info                 

And $ vim foo shows:

$q q
~                                                                               
~                                                                               
~                                                                               
~                                                                                                                                               
~                                                                               
"foo" [New File]

[nuko8]

As a tentative workaround, the following works for me:

if !empty($TERM_PROGRAM) && $TERM_PROGRAM == 'Apple_Terminal'
  set t_SH=
endif

Also, since $q q is not an actual entity in a buffer, CTRL-L in normal mode can be used to erase it.

[mkarpoff]

I ran into this and figured it was somesort of bug with plugins that I have installed. It happens on both ubuntu 16.04 and on WSL.

[vim-ml]

Hi Marcus and All, 2017-8-23(Wed) 21:09:33 UTC+9 Marcus Karpoff:

I ran into this and figured it was somesort of bug with plugins that I have installed. It happens on both ubuntu 16.04 and on WSL.

I also encountered the same issue. This issue has occurred from Vim 8.0.0973. My env: Vim on fedora 25 via PuTTY 0.70 on Windows 10 (64bit) Remarks: It does not happen if the terminal-emulator is GNOME-terminal or Tera Term.

…

-- Best regards, Hirohito Higashi (h_east)

[vim-ml]

2017-8-24(Thu) 0:43:18 UTC+9 h_east:

Hi Marcus and All, 2017-8-23(Wed) 21:09:33 UTC+9 Marcus Karpoff: > I ran into this and figured it was somesort of bug with plugins that I have installed. It happens on both ubuntu 16.04 and on WSL. I also encountered the same issue. This issue has occurred from Vim 8.0.0973. My env: Vim on fedora 25 via PuTTY 0.70 on Windows 10 (64bit) Remarks: It does not happen if the terminal-emulator is GNOME-terminal or Tera Term.

Additional notes: :echo $TERM xterm-256color

…

-- Best regards, Hirohito Higashi (h_east)

[nuko8]

As for macOS (the original issue), although the OP didn't mention it, the string $q q appears only when Vim runs on Terminal.app, but not on iTerm.app.

One of the differences between them is that, while iTerm.app recognizes the DECSCUSR control sequences, i.e., CSI Ps SP q, where CSI denotes Esc [, Ps = 0, 1, 2, 3, 4, 5 and 6, and SP denotes space, Terminal.app does not respond to any of them at all.

On Terminal.app, :set t_SH? gives t_SH=^[[%p1%d q by default, and that's why I set it to an empty string for the purpose of erasing $q q on the initial window at startup. It should also be noted that iTerm.app has the same t_SH value as that of Terminal.app.

Both of the terminals return xterm-256color for :echo &term, so it seems that we need to have some mechanism to distinguish DECSCUSR-aware terminals from others when the both kinds of terminals nominally call themselves xterm*, but I'm not sure if it's possible to have such a mechanism other than having our own database.

UPDATE: Previously, I wrote DECSCURS, but it should read DECSCUSR (the order of the last two letters is transposed).

UPDATE2: I forgot to mention why I think $q q is related to DECSCUSR: The control sequence DCS $ q SP q ST, where DCS (Device Control String) denotes Esc P, and ST (String Terminator) denotes Esc \, is the Request Status String (DECRQSS) for DECSCUSR. It looked to me that $q q was part of it.

[nuko8]

It seems that any updates within a single comment in a GitHub issue are not sent to vim_dev. Please refer to the updated comment for the comment which was sent to vim_dev previously. It includes minor corrections and follow-ups.

[chdiza]

Bisection reveals that 8.0.973 is the first bad patch:

patch 8.0.0973: initial info about blinking cursor is wrong
    
    Problem:    initial info about blinking cursor is wrong
    Solution:   Invert the blink flag.  Add t_VS to stop a blinking cursor.

[chrisbra]

It seems that any updates within a single comment in a GitHub issue are not sent to vim_dev

That is because for updated comments, there is no notification sent from github.

[vim-ml]

Hirohito Higashi wrote:

2017-8-24(Thu) 0:43:18 UTC+9 h_east: > Hi Marcus and All, > > 2017-8-23(Wed) 21:09:33 UTC+9 Marcus Karpoff: > > I ran into this and figured it was somesort of bug with plugins that I have installed. It happens on both ubuntu 16.04 and on WSL. > > > I also encountered the same issue. > This issue has occurred from Vim 8.0.0973. > > My env: > Vim on fedora 25 via PuTTY 0.70 on Windows 10 (64bit) > > Remarks: > It does not happen if the terminal-emulator is GNOME-terminal or Tera Term. Additional notes: :echo $TERM xterm-256color

This is the usual problem of setting 'term' to "xterm", while the terminal is not actually xterm compatible. You have to set 'term' to the right value.

…

-- hundred-and-one symptoms of being an internet addict: 9. All your daydreaming is preoccupied with getting a faster connection to the net: 28.8...ISDN...cable modem...T1...T3. /// Bram Moolenaar -- Bram@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 ///

[vim-ml]

Hi Bram, 2017-8-24(Thu) 7:06:51 UTC+9 vim-dev ML:

Hirohito Higashi wrote: > 2017-8-24(Thu) 0:43:18 UTC+9 h_east: > > Hi Marcus and All, > > > > 2017-8-23(Wed) 21:09:33 UTC+9 Marcus Karpoff: > > > I ran into this and figured it was somesort of bug with plugins that I have installed. It happens on both ubuntu 16.04 and on WSL. > > > > > > I also encountered the same issue. > > This issue has occurred from Vim 8.0.0973. > > > > My env: > > Vim on fedora 25 via PuTTY 0.70 on Windows 10 (64bit) > > > > Remarks: > > It does not happen if the terminal-emulator is GNOME-terminal or Tera Term. > > Additional notes: > > :echo $TERM > xterm-256color This is the usual problem of setting 'term' to "xterm", while the terminal is not actually xterm compatible. You have to set 'term' to the right value.

This problem is not directly related to `:terminal`. It also happens Vim that made in configure without specifying `--enable-terminal`. $ cd /path/to/vim $ make distclean $ ./configure --enable-gui=gnome2 --enable-fail-if-missing $ make $ cd src $ ./vim --clean (same result with ./vim -Nu NONE -i NONE) `$q q` is displayed on the first line immediately after Vim starts up.

…

-- Best regards, Hirohito Higashi (h_east)

[k-takata]

@h-east Bram doesn't say about the terminal feature.
He says that the terminal you using (PuTTY) is not fully compatible with xterm.

[chrisbra]

For putty, you should set $TERM to some putty value, I believe (e.g. putty-256color)

[vim-ml]

Hi Ken and Christian, 2017-8-24(Thu) 14:04:13 UTC+9 Christian Brabandt:

For putty, you should set $TERM to some putty value, I believe (e.g. putty-256color)

Thank you for suggesting. I set to putty-256color to $TERM and my issue was solved.

…

-- Best regards, Hirohito Higashi (h_east)

[nuko8]

@chdiza

I confirmed it with my macOS. That saved me my time, and I created a tag in my repo so that I can visit the issue with the relevant commit at any time. Thank you!

@littleylv

Aside from the t_SH hack, the issue can resolved by setting$TERM to an appropriate value, as Bram suggested.

How to change $TERM for Terminal.app: Open Terminal.app. Then, from the menu bar, follow Terminal -> Preferences... -> Profiles -> [On the left-side list, choose and click the profile in use] -> Advanced.　At the item Terminfo, you'll find a pull-down menu to the right of the label Declare terminal as. (Side Note: As indicated by this, the right $TERM value does not exist for the terminal in question, although all the default profiles (=settings) set it to xterm-256color.)

By clicking the menu, you'll see there are several terminal names you can choose as $TERM:

name	Does $q q appear?
ansi	No
dtterm	No
nsterm	No
rxvt	Yes
vt52	(makes reflow broken)
vt100	No
vt102	No
xterm	Yes
xterm-16color	Yes
xterm-256color	Yes

Note that any of those values doesn't alter the capabilities of Terminal.app; but they rather determine what the terminal looks like to applications running on it.

Hence, if xterm-256color is chosen, Vim believes it as such and sends an xterm termcode to the terminal. But it doesn't know how to respond to it. As a result, $q q appears on the startup window.

True, you can choose any of ansi, dtterm, nsterm, vt100 or vt102 to resolve the issue, but as the names indicate, they don't support colors or font styles as fully as recent xterm does. Consequently,'termguicolors' may not work properly. Itaic/Bold may be displayed with an underline or in reverse color mode. And so on...

Also, although I didn't all try them out myself, it wouldn't be a surprise if some programs such as ls, gcc, tmux, cmake might lose or break colors in their output when $TERM is set to any value other than xterm and its family. Sadly, that's the cost of doing the right thing.

That said, if you can live with those conservative terminal capabilities, choosing $TERM among them gives you the most reasonable, clean solution.