-
-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
customizable statusbar #687
Comments
FYI, there's a whole section on the workings of the status line in the DEC STD-070 manual, assuming you have a copy of that. It's in chapter 14 - labelled as 14-001 in the PDF table of contents, or starting around page 1036 of the PDF. |
@j4james do you have any plans in adding something like this (implementing the two VT seqs above) for WT maybe too? I am currently PoC-implementing this, and I actually see not just some potential example for shells (host writable status line) but also a user-configurable per TE config, similar to what tmux can do. The indicator status-line could also be of great use for power users (or TE devs?) showing the actual UTF-8 sequence of the grid cell under the current mouse cursor and other states. |
Ultimately I'd like to implement most of the DEC VT sequences, and I believe the status display extension is a requirement for level 3, so it's definitely on my TODO list. It's not a priority at the moment, though, so it'll probably be a while before I get to it. |
@j4james luckily the DEC STD 070 (chapter 14, thx btw) is explicitly only giving recommendations of what an indicator line should display. There's not really anything mandatory. The above screenshot shows how it looks like for Contour for now. Especially the format of the status line isn't formalized. So the implementor has quite some freedom (which I personally find good). What wonders me is the fact that they say the status line (host writable or Indicator) is |
That's looking good. I'm not sure about the multi-line status thing though. I vaguely recall some of the DEC terminals having an additional line for keyboard status below the main status line, so that's possibly what they were referring to. I don't think that line was writeable though. Btw, if you want to look at how other terminals emulators have implemented this, there are quite a few that I know of:
The last four don't support the "Indicator status" option, though - they only allow the "Host-writable" option or nothing. I also know that both Kermit and IBM Personal Communications have some kind of "indicator status" line by default, and in theory it should be host-writable too, but I couldn't get either of them to work. It's possibly just a config option somewhere, but I didn't spend much time trying to figure it out. |
@j4james Reviving an oldish ticket here. I don't see why the indicator statusline should be host writable, because that's what the host writable statusline is there for. However, I'm planning to finally make the indicator statusline actually customizable, finally, because we want to give it a little bit more prominence in our TE, as I see some value in having one. :) I am actually considering supporting displaying both, indicator as well as host writable at the same time (host writable's content could be embedded into the middle of the indicator one, e.g., or both lines at full with stacked vertically). I feel it is really hard to check indicator statusline support that against other TEs because it's hard to find some, despite the list above that you provided to me thanksfully. But they all seem to be corporate. However, I think it would be "okayish" to deviate from the standard (as far as indicator statusline is concerned), because I don't think that this is some software that'll be connected with a power plant or so (just saying) that would fire up when the statusline would not look like specced by DEC :) p.s.: You said you have that on your TODO list. Any updates on that? And did you refer to WT in that context? If not, which TE then? |
That sounds like a nice idea.
Stacked is possibly OK, but I'm not sure embedding would work. Any app that is using the host writeable status line is going to expect that they have the full width of the screen to work with. Things are likely to break if the content is getting clipped earlier than it should be.
Those that aren't free should have a trial version you can download and try out for a couple of weeks. That should be plenty of time, if you just want to test their status line functionality.
I was actually thinking about this recently. I've just been adding paging support to Windows Terminal, and I thought that architecture might turn out to be a good base on which to build the status line. The problem is I don't see how I can get it to work over conpty, so it may only be usable in conhost. And if that's the case, I'd probably keep it in my private fork, because I don't think the MS devs are keen on conhost-only features. |
Configuration
Format specifiers
{InputMode}
NORMAL
orINSERT
, ...{Shell:COMMMAND}
{Date:Format}
{Date:%H:%M:%S}
{fg:NAME}
{fg:#RRGGBB}
{bg:NAME}
{bg:#RRGGBB}
{Reset}
{Bold}
{Italic}
{Underline:STYLE}
normal
,curly
, ...{Title}
{DECModes:Pm}
{ANSIModes:Pm}
{Cell:UTF8}
{Cell:UTF32}
{Cell:SGR}
{Session:IdleTime}
{Session:Uptime}
For
{fg:NAME}
and{bg:NAME}
the name are color names likered
,green
etc or their numbers as found in the color palette (a value between0
and264
(inclusive) for indexed color palette access).The text was updated successfully, but these errors were encountered: