Cursors

[rob]

I use vim on windows and Linux.

How do I change the cursor shape between insert and normal modes? I don't want overstrike mode

Thx

--
rob
V...@drrob1.com

[Tony Mechelynck]

Changing the cursor shape works fully in gvim (all platforms) and for
height but not width in the Windows console (aka Dos Box). In
non-Windows console Vim (for instance in xterm) Vim cannot change the
cursor shape, its shape must be set in the underlying console. In all
cases the relevant setting is the 'guicursor' option, even in Windows
non-GUI Vim.

See :help 'guicursor'

Best regards,
Tony.

[Dominique Pellé]

It should be possible to honor 'guicursor' option in the terminal though
in theory, just like the terminal can now honor 'guicolors' with
`termguicolors`.

Many terminals support setting the shape of the cursor.
Try e.g. this in your terminal which I found at
https://stackoverflow.com/questions/4416909/anyway-change-the-cursor-vertical-line-instead-of-a-box

$ echo -e -n "\x1b[\x30 q" # changes to blinking block
$ echo -e -n "\x1b[\x31 q" # changes to blinking block also
$ echo -e -n "\x1b[\x32 q" # changes to steady block
$ echo -e -n "\x1b[\x33 q" # changes to blinking underline
$ echo -e -n "\x1b[\x34 q" # changes to steady underline
$ echo -e -n "\x1b[\x35 q" # changes to blinking bar
$ echo -e -n "\x1b[\x36 q" # changes to steady bar

I don't use neovim, but I recall trying it and noticing that it did
support 'guicursor' in the terminal unlike vim.

If I look at neovim help file options.txt, it says:

=== BEGIN QUOTE https://neovim.io/doc/user/options.html#'guicursor'
*'guicursor'* *'gcr'* *E545* *E546* *E548* *E549*
'guicursor' 'gcr' string (default "n-v-c-sm:block,i-ci-ve:ver25,r-cr-o:hor20")
global

Configures the cursor style for each mode. Works in the GUI and many
terminals. See |tui-cursor-shape|.
=== END QUOTE


Whereas for Vim, :help 'guicursor` says that it's for the GUI only:

=== BEGIN QUOTE https://vimhelp.org/options.txt.html#%27guicursor%27
'guicursor' 'gcr' E545 E546 E548 E549
'guicursor' 'gcr' string (default "n-v-c:block-Cursor/lCursor,
ve:ver35-Cursor,
o:hor50-Cursor,
i-ci:ver25-Cursor/lCursor,
r-cr:hor20-Cursor/lCursor,
sm:block-Cursor
-blinkwait175-blinkoff150-blinkon175",
for Win32 console:
"n-v-c:block,o:hor50,i-ci:hor15,
r-cr:hor30,sm:block")
global
{only available when compiled with GUI enabled, and
for Win32 console}
=== END QUOTE

Regards
Dominique

[rob]

I'm not clear. Do I need to type
Set gcr "long string"

How do I set the guicursor

--
rob
V...@drrob1.com

> --
> --
> You received this message from the "vim_use" 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_use" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to vim_use+u...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vim_use/1509991a-edde-4f57-aa37-d259e37dc7a8%40www.fastmail.com.

[Hưng Phạm]

Why cursor shape in terminal neovim can change but in vim not? Maybe something different in here.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXsTNhhSuGXtEteyo6fE8fRUL1Yb%2Be5iKRfTinenGCAwgg%40mail.gmail.com.

[Bram Moolenaar]

> Why cursor shape in terminal neovim can change but in vim not? Maybe
> something different in here.

It very much depends on the terminal. Neovim assumes a very recent
terminal, it won't work everywhere. It may mess up on some terminals.

What I use myself:

" Change the cursor color and shape depending on the mode.
if &term =~ "xterm" && $SSH_CLIENT == ''
let &t_SI = "\<Esc>]12;purple\x7" . "\<Esc>[5 q"
try
let &t_SR = "\<Esc>]12;darkred\x7" . "\<Esc>[3 q"
catch
endtry
let &t_EI = "\<Esc>]12;royalblue2\x7" . "\<Esc>[2 q"
endif

--
Why is "abbreviation" such a long word?

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Grant Taylor]

On 6/15/22 9:58 AM, Bram Moolenaar wrote:
> if &term =~ "xterm" && $SSH_CLIENT == ''

Why do you check to see that SSH_CLIENT is unset / empty?

Wouldn't that preclude SSHing from a shell running in Xterm?

I'm just curious.



--
Grant. . . .
unix || die

[Bram Moolenaar]

> On 6/15/22 9:58 AM, Bram Moolenaar wrote:
> > if &term =~ "xterm" && $SSH_CLIENT == ''
>
> Why do you check to see that SSH_CLIENT is unset / empty?
>
> Wouldn't that preclude SSHing from a shell running in Xterm?
>
> I'm just curious.

The terminal that I use to run ssh does not support it.
I am using the Secure Shell extension for Chrome.
I actually haven't tried recently, they keep improving it.

--
ERIC IDLE PLAYED: THE DEAD COLLECTOR, MR BINT (A VILLAGE NE'ER-DO -WELL VERY
KEEN ON BURNING WITCHES), SIR ROBIN, THE GUARD WHO DOESN'T
HICOUGH BUT TRIES TO GET THINGS STRAIGHT, CONCORDE (SIR
LAUNCELOT'S TRUSTY STEED), ROGER THE SHRUBBER (A SHRUBBER),
BROTHER MAYNARD
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Grant Taylor]

On 6/15/22 11:55 AM, Bram Moolenaar wrote:
> The terminal that I use to run ssh does not support it.

Hum.

This sounds like a potential problem in the terminal. Specifically that
the terminal should set TERM to the terminal that it's actually emulating.

I consider it a bug if a terminal emulator claims that it's emulating a
terminal that's more capable than it actually is. E.g. claiming XTerm
when it's really VT100 level capabilities.

I also use answer back for some things like this. I define the answer
back on specific systems via the ~/.Xdefaults file. I usually set the
answer back to be the host name that the terminal emulator is running on.

So, between the contents of the TERM environment variable and the value
of the answer back, I can have my servers choose how they configure the
interactive environment.

> I am using the Secure Shell extension for Chrome.

The Secure Shell 0.47 (in a tab) that I have installed for work seems to
have an option to specify the TERM environment variable via Secure Shell
(icon) -> Options -> Terminal Settings -> Miscellaneous. If it doesn't
actually support xterm-256color (what mine's defaulted to) I'd file a
bug with them. If that didn't work, I'd change it to something less
capable; xterm base, or even vt100. That way the value of the TERM
environment variable would be more believable.

I feel like the purpose of the TERM environment variable is slipping
into obscurity and people are setting it to something they've always
seen, e.g. xterm, and not realizing that it actually has a specific
meaning. Instead they are defaulting and having to re-invent the wheel.

> I actually haven't tried recently, they keep improving it.

ACK

I just tried the Secure Shell for the first time in a long time and I
can't get it to connect to anything. :-/ I'm not upset b/c I found it
so inferior and frustrating. That being said, I'm an Xterm power user
and expect more than the average person from my terminal emulator.

[Gary Johnson]

On 2022-06-15, 'Grant Taylor' via vim_use wrote:
> On 6/15/22 11:55 AM, Bram Moolenaar wrote:
> >The terminal that I use to run ssh does not support it.
>
> Hum.
>
> This sounds like a potential problem in the terminal. Specifically
> that the terminal should set TERM to the terminal that it's actually
> emulating.
>
> I consider it a bug if a terminal emulator claims that it's emulating
> a terminal that's more capable than it actually is. E.g. claiming
> XTerm when it's really VT100 level capabilities.

Yeah, but...

A problem is that if somebody comes out with a new Whizbang terminal
that does everything an Xterm does but so much more, and they set
TERM=whizbang, then everyone with scripts and configurations looking
for TERM=xterm* complains that their tools don't work anymore. As
far as they're concerned, it looks like an Xterm so they want it to
identify itself as an Xterm. The same goes for terminals that work
mostly but not quite like an Xterm but have some "better" features.

HP had this problem about 40 years ago when they introduced
a successor to the 2645 terminal. Its ID string was something like
"HP2647" and customers raised Cain that their systems did work right
with the new terminal, so HP changed it to report itself as an
"HP2645".

You can't win either way. I don't know what the right answer is.
Some HP products tried to use capability strings instead of product
IDs with limited success.

> I also use answer back for some things like this. I define the
> answer back on specific systems via the ~/.Xdefaults file. I usually
> set the answer back to be the host name that the terminal emulator is
> running on.

That would help a lot. Is that what Vim refers to as the
termresponse? I use that when it matters what the terminal really
is.

Regards,
Gary

[Bram Moolenaar]

[...]

I'm using this on MS-Windows, where things are quite different...

> I feel like the purpose of the TERM environment variable is slipping
> into obscurity and people are setting it to something they've always
> seen, e.g. xterm, and not realizing that it actually has a specific
> meaning. Instead they are defaulting and having to re-invent the wheel.

Yes, that is indeed a problem. Lots of terminal emulators keep popping
up, many with the same or similar base, and adding one more feature.
They don't bother distributing a correct termcap/terminfo entry and just
use something like "xterm" for $TERM.

I have been thinking of a way to just ignore termcap/terminfo and let
the terminal tell us what it's features are. Xterm does this partially,
but there can be artifacts (e.g. when Vim exits very quickly). I
haven't found the right solution yet.

> > I actually haven't tried recently, they keep improving it.
>
> ACK
>
> I just tried the Secure Shell for the first time in a long time and I
> can't get it to connect to anything. :-/ I'm not upset b/c I found it
> so inferior and frustrating. That being said, I'm an Xterm power user
> and expect more than the average person from my terminal emulator.

It works well compared to other solutions (e.g. Putty). If you can't
get it to connect double check the settings. It works for me (when I
get the domain or IP address and port right).

The problem I sometimes run into is that mouse events stop working
without a clue why.

--
The MS-Windows registry is no more hostile than any other bunch of state
information... that is held in a binary format... a format that nobody
understands... and is replicated and cached in a complex and largely
undocumented way... and contains large amounts of duplicate and obfuscated
information... (Ben Peterson)

[Grant Taylor]

On 6/15/22 2:43 PM, Gary Johnson wrote:
> Yeah, but...

IMHO there's no but about it.

> A problem is that if somebody comes out with a new Whizbang terminal
> that does everything an Xterm does but so much more, and they set
> TERM=whizbang, then everyone with scripts and configurations looking
> for TERM=xterm* complains that their tools don't work anymore.

I believe that these terminals should default to whizbang or whatever
their name is.

They can optionally support xterm personality / emulation.

> As far as they're concerned, it looks like an Xterm so they want it
> to identify itself as an Xterm. The same goes for terminals that work
> mostly but not quite like an Xterm but have some "better" features.

I think that the more people that pile onto the Xterm terminal type the
muddier the water will get.

This seems reminiscent of the User-Agent header for web browsers.

IMHO we should /own/ the terminal type that we are using. Either create
a new whizbang terminal and give it an xterm personality / emulation
capability -or- stick with venerable xterm / vt100 and not expect more
than the specifications define.

> HP had this problem about 40 years ago when they introduced
> a successor to the 2645 terminal. Its ID string was something like
> "HP2647" and customers raised Cain that their systems did work right
> with the new terminal, so HP changed it to report itself as an
> "HP2645".

IMHO HP made the wrong choice. It sounds like they bowed to marketing
pressure and made their new HP2647 terminal lie and say that it was an
HP2645. Maybe the marketing / support types have more clout than the
technical types.

I recently copied an xterm definition so that it could be used for
xterm-color because that's what my terminal reported as and the 20 year
old system I was connecting to didn't know what xterm-color was.

> You can't win either way.

Either you can own the terminal type and do your best / the work to keep
it pure. Or you can have a completely unrelated web web browser lie and
say that it's a 20 year old piece of software that's long since dead, a
la. User-Agent headers.

If we're going to ignore what the value actually means, then we might as
well make it a random opaque token.

> I don't know what the right answer is. Some HP products tried to
> use capability strings instead of product IDs with limited success.

My vote is to actually use the value for what it's meant to be and
actively /own/ the maintenance.

> That would help a lot. Is that what Vim refers to as the
> termresponse?

I don't know.

> I use that when it matters what the terminal really is.

I often find that the answer back is unset / null or that the terminal
(emulator) completely fails / ignores it.

[Grant Taylor]

On 6/15/22 2:44 PM, Bram Moolenaar wrote:
> Yes, that is indeed a problem. Lots of terminal emulators keep popping
> up, many with the same or similar base, and adding one more feature.
> They don't bother distributing a correct termcap/terminfo entry and
> just use something like "xterm" for $TERM.

I wonder how much of that is by conscious choice vs ignorance.

> I have been thinking of a way to just ignore termcap/terminfo and
> let the terminal tell us what it's features are. Xterm does this
> partially, but there can be artifacts (e.g. when Vim exits very
> quickly). I haven't found the right solution yet.

I'm curious. Though that is probably even further off topic.

> It works well compared to other solutions (e.g. Putty). If you can't
> get it to connect double check the settings. It works for me (when
> I get the domain or IP address and port right).

I suspect that my problem is related to the super tight security
settings that $CORP_IT has put in place since the last time I tried to
use it.

[Gary Johnson]

On 2022-06-15, 'Grant Taylor' via vim_use wrote:

> On 6/15/22 2:43 PM, Gary Johnson wrote:
> >Yeah, but...
>
> IMHO there's no but about it.

[...]

Points well made and well taken.

> >HP had this problem about 40 years ago when they introduced
> >a successor to the 2645 terminal. Its ID string was something like
> >"HP2647" and customers raised Cain that their systems did work right
> >with the new terminal, so HP changed it to report itself as an
> >"HP2645".
>
> IMHO HP made the wrong choice. It sounds like they bowed to
> marketing pressure and made their new HP2647 terminal lie and say
> that it was an HP2645. Maybe the marketing / support types have more
> clout than the technical types.

I think they did. That was true for HP-UX as well.

> >I use [termresponse] when it matters what the terminal really is.

>
> I often find that the answer back is unset / null or that the
> terminal (emulator) completely fails / ignores it.

Fortunately, all the terminals I use support it. My Chromebook's
Crosh Window uses the same termresponse string as an Xterm 256
emulating a vt100, but I don't have any of those Xterms, so it
works.

Regards,
Gary

[Grant Taylor]

On 6/15/22 3:17 PM, 'Grant Taylor' via vim_use wrote:
> I suspect that my problem is related to the super tight security
> settings that $CORP_IT has put in place since the last time I tried to
> use it.

While talking about this with a coworker, it came to my attention that
my problem is related to the program not working Apple's M1 processor.

[Bram Moolenaar]

> On 6/15/22 2:44 PM, Bram Moolenaar wrote:
> > Yes, that is indeed a problem. Lots of terminal emulators keep popping
> > up, many with the same or similar base, and adding one more feature.
> > They don't bother distributing a correct termcap/terminfo entry and
> > just use something like "xterm" for $TERM.
>
> I wonder how much of that is by conscious choice vs ignorance.

It is a conscious choice. Someone making a new terminal emulator wants
it to get popular quickly, doesn't care about doing things that make it
harder to have it adopted. "If it works for 99% that is good enough".
And then spend years fixing that last percent (or just ignoring it).

> > I have been thinking of a way to just ignore termcap/terminfo and
> > let the terminal tell us what it's features are. Xterm does this
> > partially, but there can be artifacts (e.g. when Vim exits very
> > quickly). I haven't found the right solution yet.
>
> I'm curious. Though that is probably even further off topic.

With xterm Vim will request the actual escape sequences used. This
matters, because even when the $TERM value is correct and the
terminfo/termcap entry is found, there are runtime options that can
change the behavior. "8 bit controls" can completely mess things up.

Problem is that between requesting the entry and receiving it there is a
delay, which can go to a few hundred msec for a remote terminal. Then
the response may end up in the shell instead of with Vim. It's not a
final solution.

> > It works well compared to other solutions (e.g. Putty). If you can't
> > get it to connect double check the settings. It works for me (when
> > I get the domain or IP address and port right).
>
> I suspect that my problem is related to the super tight security
> settings that $CORP_IT has put in place since the last time I tried to
> use it.

It's possible the protocol to connect disallows using a password.
I don't know how to do something else, such as a key/challenge exchange.

--
(letter from Mark to Mike, about the film's probable certificate)
For an 'A' we would have to: Lose as many shits as possible; Take Jesus
Christ out, if possible; Loose "I fart in your general direction"; Lose
"the oral sex"; Lose "oh, fuck off"; Lose "We make castanets out of your
testicles"

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

[Dominique Pellé]

Bram Moolenaar wrote:

> > Why cursor shape in terminal neovim can change but in vim not? Maybe
> > something different in here.
>
> It very much depends on the terminal. Neovim assumes a very recent
> terminal, it won't work everywhere. It may mess up on some terminals.
>
> What I use myself:
>
> " Change the cursor color and shape depending on the mode.
> if &term =~ "xterm" && $SSH_CLIENT == ''
> let &t_SI = "\<Esc>]12;purple\x7" . "\<Esc>[5 q"
> try
> let &t_SR = "\<Esc>]12;darkred\x7" . "\<Esc>[3 q"
> catch
> endtry
> let &t_EI = "\<Esc>]12;royalblue2\x7" . "\<Esc>[2 q"
> endif

I use something along those lines too.
But why the try/catch? I don't have it and did not notice issues.
Doing :help termcap-cursor-shape also shows how to set colored
cursor, but that help entry does not have the try / catch either.
Perhaps it should be added there if it solves something.

A bit off topic but related: on macOS, I use iTerm2 (with
TERM=xterm-256color) and cursor color does not change unfortunately.
I have not found workarounds. Yet it it's a popular terminal on macOS.
I find it quite bad, and I don't find any good terminals on macOS in fact
whereas on Linux, most terminals work well in general. Things that do not
work well with iTerm2:

* can't change cursor color (I can choose cursor colors in
settings, but vim can't dynamically change it later)
* underline and squiggly lines have no colors
* several bugs with tmux (version next-3.4, the real tmux, not the
crappy one built-in in iTerm2) e.g. bugs when trying to copy paste
in window pane while another pane is outputing text, slowness
dragging window pane separators.

Regards

Dominique

[Bram Moolenaar]

Dominique wrote:

> Bram Moolenaar wrote:
>
> > > Why cursor shape in terminal neovim can change but in vim not? Maybe
> > > something different in here.
> >
> > It very much depends on the terminal. Neovim assumes a very recent
> > terminal, it won't work everywhere. It may mess up on some terminals.
> >
> > What I use myself:
> >
> > " Change the cursor color and shape depending on the mode.
> > if &term =~ "xterm" && $SSH_CLIENT == ''
> > let &t_SI = "\<Esc>]12;purple\x7" . "\<Esc>[5 q"
> > try
> > let &t_SR = "\<Esc>]12;darkred\x7" . "\<Esc>[3 q"
> > catch
> > endtry
> > let &t_EI = "\<Esc>]12;royalblue2\x7" . "\<Esc>[2 q"
> > endif
>
> I use something along those lines too.
> But why the try/catch? I don't have it and did not notice issues.
> Doing :help termcap-cursor-shape also shows how to set colored
> cursor, but that help entry does not have the try / catch either.
> Perhaps it should be added there if it solves something.

If I remember correctly, I wrote this around the time that t_SR was
added. Using an older Vim version would throw an error. It's not
generally useful, unless you might use an old Vim version occasionally.

[Agree with no good terminal found for Mac, but I don't have one now]


--
The chat program is in public domain. This is not the GNU public license.
If it breaks then you get to keep both pieces.
-- Copyright notice for the chat program