XTerm: It's Better Than You Thought • Hacker News Board

Re: XTerm: It's Better Than You Thought

#151

Post by jd3 » Wed, Jan 13, 2021, 2:56 AM UTC

3np wrote: post #94

jd3 wrote: post #50

Something that I noticed recently is that the latency/input lag feels lower in xterm compared to unicode-rxvt. I used urxvt from ~2011 until a couple of months ago and I have been really liking the speed and simplicity of xterm since then.

Maybe we have some difference in configuration, but I don't have any perceivable difference between the two - still on urxvt since way back. Background transparency is the one feature keeping me from considering xterm. I like the URL handling hack in OP, but I'm also a bit married to some urxvt plugins (URL handler, trimming whitespace when copying)

> Maybe we have some difference in configuration, but I don't have any perceivable difference between the two - still on urxvt since way back.

I think the entirety of my ~/.xresources xterm config is

  #include ".Xresources.colors"

  !! xterm
  ! https://invisible-island.net/xterm/
  ! https://linux.die.net/man/1/xterm
  !XTerm.vt100.faceName: Monaco:pixelsize=11
  XTerm.scrollTtyKeypress: true
  XTerm.scrollTtyOutput: false
  XTerm.utf8:    true

  XTerm.vt100.boldMode: false
  XTerm.vt100.locale: false
  XTerm.vt100.scrollbar.width: 8
  XTerm.vt100.scrollBar: true
  XTerm.vt100.utf8: true

I'll try to take a video of the difference at some point — I use xorg 1.20.8 on macOS 11.1 and it definitely feels noticeable when I type quickly with vsync disabled (through Quartz Debug.app).

> Background transparency is the one feature keeping me from considering xterm.

That's fair. The macOS xorg server has never supported the COMPOSITE extension/xcompmgr/compiz, so transparency/compositing have always been out of the question for me.

> I like the URL handling hack in OP, but I'm also a bit married to some urxvt plugins (URL handler, trimming whitespace when copying)

I sympathize with this — I used urxvt for years and grew to like how it could easily extend itself using perl. Thankfully, I have been able to mirror all of my urxvt functionality in xterm since I switched back. It also helped me simplify my ~/.xresources, which shrank from ~300 lines 10 years ago to 50 (for both my xterm and urxvt configs excluding color definitions, which live in ~/.Xresources.colors).

Re: XTerm: It's Better Than You Thought

#152

Post by fulafel » Wed, Jan 13, 2021, 5:52 AM UTC

MayeulC wrote: post #124

fulafel wrote: post #87

Earlier quoted context omitted.

A tangent but where could I find a good evaluation of Wayland stack (including Weston etc) security? I know the design is often brought up but most vulnerabilities are implementation errors and bugs, and there doesn't seem to be any mention of security (advisories, etc) on the Wayland web site nor does a web search bring up anything that woudl indicate there's any active security focus. What I'd expect to find is som…

Well, you can read the Wayland book, for instance: https://wayland-book.com/ Of course, security is subject to implementation details. But as far as I know, the protocol is sound, and I can't recall vulnerabilities. How each implementation handles theirs is up to them. At least, we have multiple implementations of the protocol. With X, not so much.

I didn't find answers to my questions about implementation level security on the wayland-book.com site unfortunately.

Having multiple young codebases implementing the spec doesn't really provide security assurance at this point, though it can have other benefits.

Re: XTerm: It's Better Than You Thought

#153

Post by enriquto » Wed, Jan 13, 2021, 7:12 AM UTC

pjmlp wrote: post #137

beagle3 wrote: post #129

Earlier quoted context omitted.

Most of them have no effective way of automating their work. Every piece of software (Excel? Word? Outlook? Autocad? Photoshop?) has its own system of automation if it has one at all, with many of the skills complicated to learn on one hand, and not transferable on the other. On tablets, automation is essentially nonexistent. Whereas on Unix, there's a mostly-unified system of automation (shell), with mostly transfer…

IDEs for scripting languages with graphical REPL.

> graphical REPL

Those are useful and beautiful, but they are particular cases of "command lines", aren't they? A bit limited, in that they are only useful for developing on that IDE, and not as a general interface for your computer, but useful command lines nonetheless. I thought you were opposed to command lines.

Re: XTerm: It's Better Than You Thought

#154

Post by mcguire » Wed, Jan 13, 2021, 8:54 PM UTC

ddingus wrote: post #66

DonHopkins wrote: post #60

Earlier quoted context omitted.

Sure: xterm a client of your display and keyboard and mouse, remote input and output services that the X11 server provides over the network. And at the same time, a web browser is the client of computing and data servers in the cloud, provided over the network. In reality, there can be many different client/server relationships existing in different directions over the same full duplex network connection. It's really…

Only the server, actually serves the graphics to the user. Within the context of the X Window System, the server is the body of code responsible for delivering the display to the user viewing it.

Think of it in terms of a print server. It's a long-running process that other processes connect to, in order to request a service. It handles the "impedance mismatch" between the clients and the hardware it controls---in the case of a print server, it demultiplexes requests and translates them into something the printer can deal with; in the case of X, it displays the information as requested by the client and provides notifications of events as requested by the client.

Re: XTerm: It's Better Than You Thought

#155

Post by dang » Thu, Jan 14, 2021, 7:27 AM UTC

znpy wrote: post #131

zelly wrote: post #108

Earlier quoted context omitted.

X11 is a keylogger, for one. Network transparency is a vulnerability, not a feature.

Oh shut up.

Please don't do this. We ban accounts that post like this, and have had to ask you not to before.

I'm not going to ban you because you've mostly been posting good comments lately, which is cool. But comments like this do more damage than good comments add value, so please don't do that anymore.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html, we'd be grateful.

Re: XTerm: It's Better Than You Thought

#156

Post by majewsky » Sat, Jan 16, 2021, 12:24 PM UTC

selfhoster11 wrote: post #143

majewsky wrote: post #138

Earlier quoted context omitted.

You might be surprised how often you trigger that second code path. For just one example, an increasing number of CLI programs use emoji in their output, whether you like it or not.

I'm actually a great fan of using emoji to spice up terminal output. Most of these would be fixed width too, isn't it? I know there are wide emoji, but most times I see them around one char wide.

Emoji are square, which makes them overwide under most (all?) monospace fonts.

Re: XTerm: It's Better Than You Thought

#157

Post by bitwize » Mon, Jan 18, 2021, 1:56 PM UTC

alanbernstein wrote: post #148

rvense wrote: post #111

Earlier quoted context omitted.

Same as adhering to any standard? The software you want to run produces VT-compatible output, the terminal consumes that and provides a display.

What i mean is, many other computer standards become obsolete and get replaced. What is so special about this standard from the 1970s that has given it so much staying power? It is a software standard, influenced by hardware, which has outlasted nearly every other hardware and software standard of its time. Doesn't that strike anyone else as bizarre?

The VT standard is roughly to the application layer what RS232 is to the physical layer: open, easy to implement, and damn near ubiquitous. It makes a nice Schelling point for when you want to throw up a rudimentary UI.

Example: I once worked for a robotics firm that built its own custom batteries. The battery engineers wanted an easy way to monitor battery health and status. So they added code to the firmware to make the tiny microcontroller that monitored and controlled the battery to periodically spit out screenfuls of health information in VT standard. Then, all they had to do was attach a laptop to the battery over serial and start up Windows HyperTerminal, and they had a full (text mode) status display.

This could not be done so easily without a terminal standard that's nearly universally recognized.

Re: XTerm: It's Better Than You Thought

#158

Post by alanbernstein » Tue, Jan 19, 2021, 5:10 AM UTC

bitwize wrote: post #157

alanbernstein wrote: post #148

Earlier quoted context omitted.

What i mean is, many other computer standards become obsolete and get replaced. What is so special about this standard from the 1970s that has given it so much staying power? It is a software standard, influenced by hardware, which has outlasted nearly every other hardware and software standard of its time. Doesn't that strike anyone else as bizarre?

The VT standard is roughly to the application layer what RS232 is to the physical layer: open, easy to implement, and damn near ubiquitous. It makes a nice Schelling point for when you want to throw up a rudimentary UI. Example: I once worked for a robotics firm that built its own custom batteries. The battery engineers wanted an easy way to monitor battery health and status. So they added code to the firmware to mak…

That's a really interesting example. I think I'm having a hard time articulating my question, partly because I don't fully understand the entire stack of software and standards underlying a modern terminal app on a desktop. I feel like there is a lot of historical baggage in that stack, but I don't know where exactly, or why. I was using "the VT standard" as a sort of proxy for that historical baggage, but maybe that's not accurate.

Re: XTerm: It's Better Than You Thought

#159

Post by xXx_sauron_xXx » Wed, Jan 20, 2021, 10:09 PM UTC

pjmlp wrote: post #137

beagle3 wrote: post #129

Earlier quoted context omitted.

Most of them have no effective way of automating their work. Every piece of software (Excel? Word? Outlook? Autocad? Photoshop?) has its own system of automation if it has one at all, with many of the skills complicated to learn on one hand, and not transferable on the other. On tablets, automation is essentially nonexistent. Whereas on Unix, there's a mostly-unified system of automation (shell), with mostly transfer…

IDEs for scripting languages with graphical REPL.

I am not an expert of *NIX OS, but in my two years of learning the philosophy of the OS I noticed that almost every implementation of a GUI concept or idea has it origin from CLI, the GUI is just a manner of automating things in a way that once you know what to write to the computer to do what you want to achieve, that task remains in the form of that button, but again in my opinion a button is just another abstraction of an "alias" in the CLI for a command or just a text file whit a script, it is useful for some cases to have buttons, for example editing a video in CLI is not a optimal choice for that task, I mean you can but probably will take you much more time, specially if you don't know the tool, but in the other hand, almost every video editing GUI app uses "ffmpeg" ( a CLI app and library) as it backed, so probably learning ffmpeg will teach you how to use almost every app of video editing out there. Text editing in my opinion is so slow in a GUI except for some programs like emacs, gvim and others (but whit proper extensions), and with a bit of knowledge you can achieve the same or maybe if you are persistent and develop the love for the CLI a more powerful "button" for your development environment that fits exactly your needs, and it immediately gives you more freedom, you never will to wait until the next version of your spyder or what ever IDE out there to make something you want to do, and if it fails you know how to fix it because you wrote it, that said, REPL came from "SLIME" that means "Superior Lisp Interaction Mode for Emacs", ergo, emacs users have been using REPL long time ago before, even before spyder or any "modern" IDE we actually have, that said, there is a plugin for vim too called vim-slime inspired by SLIME, where you can send words, lines, block or whole text files from your editor to other app, lets say tmux, your browser or any others, so vim, vim-slime plugin, tmux and a script to send text from your editor to shell executing python or ipython3 console or python-qtconsole gives you the REPL feature that is so acclaimed these days, and I want to say that since I implemented it for python development until now, it never crashed, so really I do not miss nothing from any IDE out there jeje, I hope some one who read this out there, expanded his main a bit and break some limitations with these little tip!. I'm currently changing mi mind for a better life in the shell, so any useful resource you want share with me or correction to me, will be received gracefully.