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. . . .
unix || die
--
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_use/13a08f6b-21cb-618d-a73f-b2f3f9ca1464%40spamtrap.tnetconsulting.net.
