4 ms·
You wouldn’t believe how common it is for people using Emacs in a terminal to bump up against the limitations. Assigning a key binding to M-[ is a particularly
by db48x 4y ago
You wouldn’t believe how common it is for people using Emacs in a terminal to bump up against the limitations. Assigning a key binding to M-[ is a particularly bad idea (<https://emacs.stackexchange.com/questions/68703/m-causes-emacs-to-print-weird-possibly-escape-sequences https://emacs.stackexchange.com/questions/68703/m-causes-ema...>)!
- H4ZB7 4y agoterminal is useless garbage. i literally have PTSD from using the mouse scroll wheel while reading a man page because for the longest time there was some obscure misconfiguration or bug in my terminal or something above it: you would scroll and some random pieces of text here and there would not render. whenever i read a man page on that system, i would realize i missed an important part later on because the bug where that piece of text doesn't render was present. this isn't because graphics programming is hard, it's because the terminal is obscure error prone crap that nobody not even the most die hard hackers want to learn to configure properly (the most die hard only learn enough terminal stuff to look smarter than their peers, and stop at that) the idea of your program not doing graphics, but instead invoking and interacting with a simulated model of a teletype (a device nobody born after 1990 even knows what is) so then the graphics stack can render its behavior to screen is completely asinine, like on the "anyone who uses this in their work should be fired" level. i could never decide what's stupider, this or the C language. both were obsolete 30 years ago. yet diehard patriotic nostalgia tripping nerds who have no idea how software engineering works but just want to learn complicated things to look cool fought tooth and nail to keep this crap alive for decades. whenever someone says "the UN*X way", they really are saying, "I designed something modularily, you could have never thought of that", but what it really means are all these insane nonsense ideas that don't even begin to make sense, like: -a filesystem centric security model that doesn't even begin to address real world use cases -C -ad hoc encodings that never mattered like octal, everything being a int<my machine word size> -*sh -perl, tcl -terminal emulators -DNS -all these shitty little tools that compose horribly, like sed, where you have to pass --sandbox to make up for the fact that it indeed composes horribly -web and email, which are thoroughly embedded in UN\*X influence, and ergo, suck big time -X.509 this is why open source sucks and is barely a competitor to proprietary garbage running in your IoT device. in fact, every single vulnerability in them springs from these bad ideas. i have
- arp242 4y ago> this is why open source sucks It's not about "open source", it's about compatibility. Changing the terminal text protocol is akin to changing a public API and would break programs. Actually, it's worse than changing a public API as you get no error and either nothing happens or the wrong thing happens and there is no good way to signal versioning (you can do some communication in "raw mode", but in the default buffered/cooked mode you can't really). Almost all your gripes are about compatibility, really.
- H4ZB7 4y agoi said open source sucks because the community is on UN*X mentality. why does the console (it should be called console, as terminal refers to a setup that was obsolete 30 years ago) not have a proper input line? why does pasting a newline make it run? i should be able to type a command and edit it in a line that is a separate UI element from the text output. there is no compatibility argument here. only 0.001% of programs actually need to do anything other than be run and output text (and just text, not escape characters that do funny stuff). there's no dilemma that you love to imagine where changing it to work this way would cause massive incompatibility problems. we could even just make a new console called dumbtextconsole that works this way viewing some logs from the shell is annoying as hell because the input goes into the program and once the program exits the shell runs whatever you typed. this is obviously a bad UI design. you will always have this stupid invisible buffer that you have to keep track of in your head the number of times you accidentally typed a letter there. if you ssh or tmux in, then you are more likely to enter bogus characters by accident when mistyping a command to ssh/tmux. the argument that its needed for compatibility is still moot if you only want a console for running commands. you dont need those interactive commands either. those are the most bogus hacky scripts that serve no purpose. i dont need a terminal to edit files either, that can be done with a proper GUI that runs outside the console. it's also a security vulnerability the way shell input works. since you might paste something with a newline on the end and it will automatically execute. the idea that you should be responsible for what's in your clipboard is just bogus. you are resorting to some ad-hoc philosophy to argue this. if there was simple a proper input line where you pressed enter to run it, this wouldn't be a concern. that one python shell.. Dreampy does this, no problem. the insane user who thinks it's a thing for some function to hijack random parts of the terminal[1] has his program break, and the rest of stuff just continues to work this post also answers the "there are no alternatives" hackjobs in this comment chain. clearly there are alternatives, i just stated some, and once you follow this line of thought it actually leads to an entirely different OS (duh, why did i even have to state this, oh yeah, because you're disingenuous hackjobs). the fact that these people have the audacity to claim that UN*X, which is a absolutely highly specific way of designing things, that would never happen in isolation, is the only way to design an OS, proves how big of an issue this is in the software industry. 1. the insanity here being obviously that once you change random attributes about the global shared state, you have to assume other programs don't get the same idea as you and do stuff in conflicting ways