vty
vty copied to clipboard
jtdaugherty
Parity between xterm and terminfo drivers
Something that surprised me was that the xterm and terminfo drivers differ in features. For example, while xterm-like terminals will enable bracketed paste, terminals that use the terminfo driver will not since bracketed paste is not advertised by terminfo.
I'm not familiar with all the xterm extensions that are not advertised as terminfo capabilities, but it would be nice to have parity between the two drivers. For bracketed paste, enabling it is harmless even if it's not available to a terminal since it's just the escape sequence \E[?2004h (which will be ignored if it's not supported).
Hi @travankor, you raise a good point; it's true that there are quite a few features that don't get advertised in terminfo (and probably never will). That, combined with the fact that it is not possible to be certain that all xterm features will be harmless if offered by the terminfo driver, is why the terminfo driver is more limited and why I cannot promise more parity between the two. The terminfo driver is also only used when the xterm driver isn't, i.e., when the value of TERM doesn't look sufficiently xterm-like. In practice I doubt it gets used much, but I don't have data on that.
As far as bracketed paste is concerned, I am curious how you can be certain that it will always be harmless when unsupported. Have you confirmed that to be the case with specific emulators?
In practice I doubt it gets used much, but I don't have data on that.
Some non xterm-like examples are alacritty, foot, konsole, mtm, and st.
What kind of issues do you foresee from sending the escape sequence? Text editors like vim already send this sequence by default.
I think that other escape sequence-triggered features could also be enabled.
Some non xterm-like examples are alacritty, foot, konsole, mtm, and st.
But presumably those mostly use TERM=xterm or some other xterm variant like xterm-256color, right? In which case they will use the Xterm driver in Vty. This is why I suspect the Terminfo driver rarely gets used.
What kind of issues do you foresee from sending the escape sequence? Text editors like vim already send this sequence by default.
It's not that I'm worried about a specific problem, but rather an inability to know what an escape sequence will do in the case where the terminal doesn't support it. Any non-terminfo escape sequence that is not explicitly supported may give undefined, unexpected, or undesirable behavior.
I think that other escape sequence-triggered features could also be enabled.
The purpose of the Terminfo driver is to enable behaviors that comply with what Terminfo advertises. Any behaviors that are not advertised by Terminfo should not be enabled by default. I would be open to considering an API to enable those behaviors, though.
What value of TERM is in use in your case that is triggering the Terminfo driver to be used?
I should also note that if it is desirable, you can override the value of TERM that Vty uses to choose a driver by setting termName in the Vty Config. The default is Nothing, which means "choose the value of TERM from the environment." This way, you can decide that no matter what, your users will always get the Xterm driver when they run your application.
But presumably those mostly use TERM=xterm or some other xterm variant like xterm-256color, right? In which case they will use the Xterm driver in Vty. This is why I suspect the Terminfo driver rarely gets used.
Alacritty and foot have their own terminfos by default. I haven't used the others in a while though, but I thought they ship a custom terminfo as well.
The purpose of the Terminfo driver is to enable behaviors that comply with what Terminfo advertises. Any behaviors that are not advertised by Terminfo should not be enabled by default. I would be open to considering an API to enable those behaviors, though.
This makes sense although the issue is that these features are orthogonal to what terminfo advertises. Having an API independent of terminfo would be nice.
What value of TERM is in use in your case that is triggering the Terminfo driver to be used?
I've tested alacritty and foot, and neither enable vty's bracketed paste ability. In contrast, kitty avoids this issue since it uses xterm-kitty for TERM.
I should also note that if it is desirable, you can override the value of TERM that Vty uses to choose a driver by setting termName in the Vty Config.
This could work although it is technically wrong. Why bother with the Terminfo driver in the first place if we can assume everything these days is close enough to Xterm?
This could work although it is technically wrong.
I feel angry in response to this, because my suggestion to use the Vty config was my attempt to help you with what I perceived to be your problem right now -- using the terminfo backend and not getting the features you want -- without waiting until we reach some kind of agreement about what to do here. It would be helpful to me if you can clarify the request you are making in this ticket.
@jtdaugherty
I should take a step back and first of all thank you for your work and dedication to this library. Vty is beautifully documented, which surely suggests a lot of love and care have gone into maintaining this library. Secondly, it may seem like these tickets are a thankless and soulless task, but they are very helpful to users like me. So please, don't take a terse (and slightly rushed) response the wrong way when there is absolutely no ill will intended.
Secondly, thank you for clarifying your feelings since this is valued and respected by me. I would have had no idea unless you otherwise had told me directly. Again, I apologize for unknowingly upsetting you, as this is very much contrary to what should be achieved here! There was absolutely no intention of trying to insult you, your work(s), or your knowledge of this field. In fact, I very much appreciate your input and knowledge!
Coming to the specific points, I didn't understand you were suggesting this as a temporary fix, rather than as a robust solution. This is what annoyed me because this indirectly suggests that this ticket is a waste of time since I should just fix the code on my end. You also have suggested that the terminfo driver is "rarely" used, which I don't think is a good assumption either, while basically stating that the existing behavior in the library won't be changed. I think there is room for improvement in this area, and insinuating that this is a "won't fix" makes me quite upset (Why would I open this to waste your or my own time?). Right now, I can achieve the same effect as the suggestion by prefixing the application with TERM=xterm-256color, which is what I have been doing so far. Still, I very much appreciate all suggestions and comments in and of themselves since they help educate me on the matter.
I'm not a terminal guru and was hoping that you could inform me of what Xterm features are out there without terminfo capability equivalents. Obviously, bracketed paste is one of them. I think it would be awesome if there was an API outside of terminfo for these features since they don't fit neatly with terminfo. If you don't like this idea, please let me know as well. However, there is no rush or time-limit for this since it's FOSS (I appreciate your timely responses but don't feel burdened or annoyed at having to respond since I can wait a while).
Thanks for your kind words, @travankor - and thanks for clarifying your position!
I'll try to respond to the main points I saw above:
I think there is room for improvement in this area, and insinuating that this is a "won't fix" makes me quite upset (Why would I open this to waste your or my own time?).
Any time we open tickets to report problems, it is always a possibility that the maintainer will be unwilling to do what we ask. It could be because we are not aware of other solutions, or because the maintainer needs to make different trade-offs. Ideally, though, we can either get what we want or at least get an understanding of why the answer is "no" if that is the case. And maintainers may not respond well to demands from users assuming their demands are perfectly reasonable. 😊 As for my specific position on this ticket, I'll say more about that below.
I didn't understand you were suggesting this as a temporary fix, rather than as a robust solution. This is what annoyed me because this indirectly suggests that this ticket is a waste of time since I should just fix the code on my end.
Your annoyance makes sense, and I didn't explicitly say why I was recommending that. So I'm sorry for the confusion.
You also have suggested that the terminfo driver is "rarely" used, which I don't think is a good assumption either
I was actually very specific in my wording: "This is why I suspect the Terminfo driver rarely gets used." I am open to being wrong about that, and that's why I was asking you questions in case I my suspicion was not right.
I'm not a terminal guru and was hoping that you could inform me of what Xterm features are out there without terminfo capability equivalents. Obviously, bracketed paste is one of them.
Another such feature is mouse mode. Both bracketed paste and mouse modes can already be enabled regardless of driver by setting mouseMode and bracketedPasteMode in the Vty Config, or by calling setMode explicitly on the Vty handle.
For other features, that's why it'll help if you come across specific ones you would like an API for. Without a specific recommendation, I'm just left with debating the general principle. When possible I'm okay with having an API to manage specific features (like the ones mentioned here). But otherwise I cannot guarantee feature parity between the drivers because in some cases we just don't know what the right sequence is, and in other cases because I think it's best to maintain a conservative position in the library and not emit things that we don't know will work. Terminals can behave very badly when they get escapes they don't expect.
Another idea that we could entertain here is to add more drivers to Vty. If it turns out that, say, Konsole users would be better off with a specific feature set enabled by default, then there is nothing in the way of us adding a Konsole-specific driver to Vty and using TERM to choose it by default. Frankly I think using Xterm for most everything makes things really messy, and with terminfo being stuck in the dark ages, that isn't a good option, either.
Along the same lines as bracketed paste and mouse modes, there is also this, which can be used to enable other modes that don't work everywhere:
http://hackage.haskell.org/package/vty-5.32/docs/Graphics-Vty-Output-Interface.html#t:Mode
For what it's worth, neovim unconditionally turns on bracketed paste mode regardless of what TERM is. But maybe the decision to do that is best left to the application.
It would be nice if you could force-set mouse and bracketed paste to on without pretending the terminal is xterm since there's no way to tell if a terminal supports bracketed paste or mouse from the terminfo (from my understanding)
It would be nice if you could force-set mouse and bracketed paste to on without pretending the terminal is xterm since there's no way to tell if a terminal supports bracketed paste or mouse from the terminfo (from my understanding)
I can see how this would be useful, but your point about terminfo is pretty much why things are written as they are now. (But read below for a solution that should work now.) The terminfo-based Vty driver is intended to support only what can be gleaned from terminfo (although I wouldn't be surprised if that's not entirely true; there may be hacks that do otherwise). With the prevalence of xterm-like terminals, the Xterm driver probably ends up being used the most often and takes a "turn on all the things and assume they'll work" approach that the terminfo driver doesn't.
With that said, all backends' Output have a outputByteBuffer function that can output arbitrary bytestrings. That can be combined with the exported control strings for various modes (such as requestFocusEvents, disableFocusEvents, requestMouseEvents, etc. in the various modules) to do what you are wanting right now without any modification to the library.
In doing a ticket review I came across this one and see that it hasn't been active for some time. I'm not sure there's much we can do to vty to change things as originally requested, since the same concerns I had at the time are still relevant (i.e. the point of the terminfo driver is to do things as advertised by terminfo, and since terminfo does not advertise a lot of things, that driver necessarily won't know how to do them). If you need more functionality, I suggest using the Xterm driver. If there's a specific capability that you need from the terminfo driver that is advertised in terminfo, I'm open to updating the terminfo driver to look for that capability string!