4 ms·

1) The user does not set TERM. 2) You keep track of a list of what TERM are hardware based that need this delay

phone8675309 3y ago
> You keep track of a list of what TERM are hardware based that need this delay How does this work for a terminal emulator? Say I'm using Kermit, and I'm using its VT100 emulation. My term would be VT100. So this delay would still be present because my terminal emulator is emulating the VT100, so looking at the TERM variable won't fix that.
- charcircuit 3y ago
  If you set your virtual terminal to emulate a physical terminal it shouldn't be surprising that software treats your terminal as a physical terminal.
  - phone8675309 3y ago
    It shouldn't be but it appears that concept has eluded some of the commenters on this article.
hnlmorg 3y ago
1. It’s just an env var and users frequently do fiddle with it 2. That’s great in theory, but in practice a lot of software is written expecting TERM to contain, for example, xterm. The TERM env var is actually worse than HTTP User-Agent for fingerprinting. And for all the same reasons why User-Agent is a hot ball of mess. The way capabilities between different hardware terminals are usually detected is via special interactive ANSI escape codes. But there isn’t currently one to ask if the terminal is hardware or software.
- charcircuit 3y ago
  >It’s just an env var and users frequently do fiddle with it If a user misconfigures what their current terminal is there isn't much that can be done. >but in practice a lot of software is written expecting TERM to contain, for example, xterm. It's not like the list of new terminals is constantly growing. The list of terminals could be periodically synced if needed.
  - hnlmorg 3y ago
    > If a user misconfigures what their current terminal is there isn't much that can be done. We aren't talking about people misconfiguring their terminal. We are talking about application developers abusing the $TERM command to detect terminal functionality rather than using ANSI escape sequences to detect a terminals support. And thus people then need to spoof $TERM strings to retain the same functionality. This is why you often see $KITTY, $MXTERM and other env vars in addition to $TERM. source: I wrote my own terminal emulator. $TERM these days is garbage. > It's not like the list of new terminals is constantly growing. The list of terminals could be periodically synced if needed. New terminal emulators do. Plus we already have ANSI escape sequences for detecting terminal functionality and it was purposely designed for hardware terminals in mind. Just doing the kids school run but I can share a link to them when i return
  - PennRobotics 3y ago
    From my experience, the list of new terminals IS always growing. Wayland? A developer wanting to flex their Rust or Go muscles? Poor Unicode or RTL support? Slow buffer? "I can GPU accelerate the terminal"? Tiling? Dropdown on tilde? Keypress customization? Better cross-platform compatibility? Sixel support? "We're a trendy yet ancient mega-corp that now supports open source please use our cloud product"? ... all reasons I've seen a new terminal or three. Last night, I ssh'd into a server that had a huge TERM list but alacritty was not on it, so I had no dircolors even when using --color=always. The only reason I'm even using alacritty is due to my last terminal not working well on new hardware. I don't have a better solution. Obviously the terminal should self-report its capabilities and everyone writes software respecting those, but that ship has sailed, so we're stuck with QWERTY as a keyboard layout (or whatever your country collectively uses; FR, DACH, etc), x86 as an architecture, and TERM as a variable.
- IshKebab 3y ago
  So you're advocating inflicting an annoying delay on tens of thousands of people because there might exist one person a) uses ancient hardware and b) uses recent software and c) messes with their TERM environment variable? Ridiculous
  - zaxomi 3y ago
    Every change breaks someone's workflow: https://xkcd.com/1172/ https://xkcd.com/1172/
    - IshKebab 3y ago
      So we should never change anything. Got it.
      - hnlmorg 3y ago
        You can change it though. Several people in this conversation have suggested ways to make that change. What you're asking is different. You want to make a global change to a core application in ways that are incompatible with existing, albeit extremely old, hardware. And the only justification is to speed up a non-standard use case for said tool. And you're pushing for this despite there already being purpose designed solutions to your exact problem. Linux (and GNU in general) frequently makes breaking changes. Like dropping 386 support. But it's done where there are actual real world problems. Like maintainability. Or security (why certain features were dropped from GNU Bash ~10 years ago). I get this delay is annoying for you but it's literally just a 1 (one!!) second sleep: (void) napms(1000); If 1000 milliseconds is that valuable to your productivity then why are you wasting millions of them arguing with strangers on the internet? If feels to me like there a real lack of objectivity in this thread.
        IshKebab 3y ago
        > If 1000 milliseconds is that valuable to your productivity then why the hell are you waste millions of them arguing with strangers on the internet? Yes it is that valuable to me, because it isn't a single 1s delay. I endure it many times per day (or I would if I didn't fix it for me). And of course you know that little delays cost more than their "raw time" because they interrupt flow. And I'm arguing with people on the internet about it because 1. It's fun to argue with people who are obviously wrong, and 2. I care about other people and I would like them to not have to endure this idiotic paper cut.

> You keep track of a list of what TERM are hardware based that need this delay How does this work for a terminal emulator? Say I'm using Kermit, and I'm using its VT100 emulation. My term would be VT100. So this delay would still be present because my terminal emulator is emulating the VT100, so looking at the TERM variable won't fix that.

charcircuit 3y ago
If you set your virtual terminal to emulate a physical terminal it shouldn't be surprising that software treats your terminal as a physical terminal.
- phone8675309 3y ago
  It shouldn't be but it appears that concept has eluded some of the commenters on this article.

hnlmorg 3y ago

1. It’s just an env var and users frequently do fiddle with it 2. That’s great in theory, but in practice a lot of software is written expecting TERM to contain, for example, xterm. The TERM env var is actually worse than HTTP User-Agent for fingerprinting. And for all the same reasons why User-Agent is a hot ball of mess. The way capabilities between different hardware terminals are usually detected is via special interactive ANSI escape codes. But there isn’t currently one to ask if the terminal is hardware or software.

charcircuit 3y ago
>It’s just an env var and users frequently do fiddle with it If a user misconfigures what their current terminal is there isn't much that can be done. >but in practice a lot of software is written expecting TERM to contain, for example, xterm. It's not like the list of new terminals is constantly growing. The list of terminals could be periodically synced if needed.
- hnlmorg 3y ago
  > If a user misconfigures what their current terminal is there isn't much that can be done. We aren't talking about people misconfiguring their terminal. We are talking about application developers abusing the $TERM command to detect terminal functionality rather than using ANSI escape sequences to detect a terminals support. And thus people then need to spoof $TERM strings to retain the same functionality. This is why you often see $KITTY, $MXTERM and other env vars in addition to $TERM. source: I wrote my own terminal emulator. $TERM these days is garbage. > It's not like the list of new terminals is constantly growing. The list of terminals could be periodically synced if needed. New terminal emulators do. Plus we already have ANSI escape sequences for detecting terminal functionality and it was purposely designed for hardware terminals in mind. Just doing the kids school run but I can share a link to them when i return
- PennRobotics 3y ago
  From my experience, the list of new terminals IS always growing. Wayland? A developer wanting to flex their Rust or Go muscles? Poor Unicode or RTL support? Slow buffer? "I can GPU accelerate the terminal"? Tiling? Dropdown on tilde? Keypress customization? Better cross-platform compatibility? Sixel support? "We're a trendy yet ancient mega-corp that now supports open source please use our cloud product"? ... all reasons I've seen a new terminal or three. Last night, I ssh'd into a server that had a huge TERM list but alacritty was not on it, so I had no dircolors even when using --color=always. The only reason I'm even using alacritty is due to my last terminal not working well on new hardware. I don't have a better solution. Obviously the terminal should self-report its capabilities and everyone writes software respecting those, but that ship has sailed, so we're stuck with QWERTY as a keyboard layout (or whatever your country collectively uses; FR, DACH, etc), x86 as an architecture, and TERM as a variable.
IshKebab 3y ago
So you're advocating inflicting an annoying delay on tens of thousands of people because there might exist one person a) uses ancient hardware and b) uses recent software and c) messes with their TERM environment variable? Ridiculous
- zaxomi 3y ago
  Every change breaks someone's workflow: https://xkcd.com/1172/ https://xkcd.com/1172/
  - IshKebab 3y ago
    So we should never change anything. Got it.
    - hnlmorg 3y ago
      You can change it though. Several people in this conversation have suggested ways to make that change. What you're asking is different. You want to make a global change to a core application in ways that are incompatible with existing, albeit extremely old, hardware. And the only justification is to speed up a non-standard use case for said tool. And you're pushing for this despite there already being purpose designed solutions to your exact problem. Linux (and GNU in general) frequently makes breaking changes. Like dropping 386 support. But it's done where there are actual real world problems. Like maintainability. Or security (why certain features were dropped from GNU Bash ~10 years ago). I get this delay is annoying for you but it's literally just a 1 (one!!) second sleep: (void) napms(1000); If 1000 milliseconds is that valuable to your productivity then why are you wasting millions of them arguing with strangers on the internet? If feels to me like there a real lack of objectivity in this thread.
      - IshKebab 3y ago
        > If 1000 milliseconds is that valuable to your productivity then why the hell are you waste millions of them arguing with strangers on the internet? Yes it is that valuable to me, because it isn't a single 1s delay. I endure it many times per day (or I would if I didn't fix it for me). And of course you know that little delays cost more than their "raw time" because they interrupt flow. And I'm arguing with people on the internet about it because 1. It's fun to argue with people who are obviously wrong, and 2. I care about other people and I would like them to not have to endure this idiotic paper cut.