271–280 of 607 posts
Earlier quoted context omitted.
Failure of Linux Desktop you mean. RDP works great and GUI tooling for Windows and macOS is quite comparable to using VB, Delphi, Smalltalk like experiences.
X could do that before RDP was even a project. I think OP is meaning something different.
Earlier quoted context omitted.
The Magit experience is due to the use of the transient package for its UI. Some other packages also use it. Most notably for my personal usage is the gptel package.
> The Magit experience is due to the use of the transient package for its UI. (I'm the author of Magit and Transient. (Though not the original author of Magit.)) The transient menus certainly play an important role but I think other characteristics are equally important. A few years ago I tried to provide an abstract overview of Magit's "interface concepts": https://emacsair.me/2017/09/01/the-magical-git-interface/ .…
Earlier quoted context omitted.
To navigate a Turbo-Vision-style IDE and explore its functionality, you basically only need to know how the Alt and Tab keys work (okay, and Return and Esc and arrow keys), as alluded to in TFA. Emacs doesn’t quite have that base level of operating uniformity I think.
The base input of emacs is ‘M-x’. From there, any command is accessible. And you have ‘M-:’ for evaluating any bit of elisp code. There’s a few UI concepts to learn (frame, window, buffers, point, mark, region,…), but that would fit in a single sheet of paper.
Earlier quoted context omitted.
Yeah. I used to work as a phone surveyor, the one you hate. Our software is a terminal connected to a mainframe. I got used to it after a few weeks and was very productive. Costco Canada vision shops still use a terminal connected to an AS/400 machine as I snooped around last month.
In the late 90s I was required to slowly replace dumb terminals with PCs. One of the older ladies taking phone orders was most put out by this, understandably. She was lightning fast on that terminal. She'd never used a PC (I hit on the idea of using solitaire to learn to use a mouse, which worked amazingly well), and was never able to get to the same speed with one as she'd done on her dumb terminal. It's hard to be…
The arguments for using TUI IDEs are just very poor. Developers should not be relying on something as loaded with legacy bloat like the terminal, to do development. Zed has remote editing support and is open source. Resource consumption is a bizarre proposition, considering what abstractions the terminal has to be forced into to behave something like a normal window. Really, TUIs are not very good. I get it, I use th…
Terminals are full of legacy bloat, but TUIs don’t have to be. I don’t think Borland IDEs used ANSI.SYS. How is graphical vim even different from TUI vim? At least Emacs can render images.
Earlier quoted context omitted.
When people love an IDE product so much that they can't work without it, they have overspecialised to their detriment. And possibly to the detriment of the code itself. > As for terminal IDEs The GNU/Linux terminal is the killer app . Multiple terminals in a tiling window manager is peak productivity for me. (Browser in a separate virtual workspace.) And modern scaling for a big display is unbeatable for developer er…
> When people love an IDE product so much that they can't work without it, they have overspecialised to their detriment. I think you are wrong. https://en.wikipedia.org/wiki/Muscle_memory Being extremely good at something increases the gap between said something and everything else. That doesn't mean being extremely good at the first thing is "over-specialization to detriment". If someone is equally mediocre at every…
You're also potentially over-specializing at one level while at the same time neglecting other levels.
Musicians run into this problem when, for example, they rely solely on muscle memory to make it through a performance. Throw enough stress and complicated music at them and they quickly buckle.
Meanwhile, a more seasoned performer remembers the exact fingers they used when drilling the measure after their mistake, what pitch is in the bass, what chord they are playing, what inversion that chord is in, the context of that chord in the greater harmonic progression, what section of the piece that harmonic progression is in, and so forth.
A friend of mine was able to improvise a different chord progression after a small mistake. He could do this because he knew where he was in the piece/section/chord progression and where he needed to go in the next measure.
In short, I'm fairly certain OP is talking about these levels of comprehension in computer programming. It's fine if someone is immensely comfortable in one IDE and grumpy in another. But it's not so fine if changing a shortcut reveals that they don't understand what a header file is.
(Article is from 2023, so the title should be updated to say "32 years ago", or something) The biggest loss in TUIs is the latest wave of asynchronous frameworks, which bring the joy of dropped keypresses to the terminal. In any TUI released before the year 2000, if you press a key when the system wasn't ready, the key would just wait until the system was ready. Many TUIs today still do this, but increasingly frequen…
[flagged]
Also, people should stop playing 2D games. It is pretty silly to base your entertainment on ancient technology when modern GPUs can render super-complex 3D scenes.
And don't make me start on people who still buy vinyl...
Earlier quoted context omitted.
May 1988 -- Smalltalk/V 286 -- on IBM-PC, PS/2 or compatible, with an 80286 or 80386 "INTRODUCTION TO THE SMALLTALK/V 286 ENVIRONMENT" http://stephane.ducasse.free.fr/FreeBooks/SmalltalkVTutorial...
That was my introduction to Smalltalk.
So much better than the TUI Smalltalk/V
But this brings up something I think about every now and again: resource bloat.
When Turbo Pascal was currently it'd be common for PCs to have 1MB of RAM. In fact with the DOS memory model you had to do weird stuff to use more memory than that (IIRC it was called "large mode").
Obviously running in a graphical environment is going to use more memory but we had pretty capable Windows environments with Win 95/98/SE/NT3.5/NT4/XP with not much RAM (256MB to 1GB depending on year).
Now with modern windowing systems we have capabilities that didn't exist in early windowing OSs like scalable rather than bitmapped fonts, UI scaling, etc. But we've had those things for 20+ years now and the resource requirements still keep going up.
Yes we have Javascript UIs running in a browser now and that will never be as cheap as native apps but we've also had those for ~20 years now (GMail is ~20 years old).
In the 90s we had graphical X Windows systems on Linux with 4-16MB of RAM. I know. I ran them.
Why do resource requirements keep going up? Is there demand for a low resource OS that could be user-facing? I know hardware is particularly cheap with Raspberry Pis and similar. We have ARM CPUs for a few dollars now that would've cost millions in the 1990s. So maybe that's why there's no demand.
But this is really something I expected to top out at some point and it just hasn't.
I think these modern TUIs are a testament to the general failure of modern GUIs. It's not like they're particularly easier to write these. But since there's no remote GUI option, much less a portable remote GUI option, particularly one that's not just a video of an entire desktop, we're stuck with these. WHo wants to fire up an entire desktop to get open a simple utility app? Obviously the Web satisfies much of the d…
> But since there's no remote GUI option ssh -X and waypipe both work perfectly fine. And to your point about portability, if you're stuck on an OS other than Linux, VNC/RDP aren't pretty but they'll get the job done.
If you can make them working. Sorry you can't connect if user is logged on this computer. Whoops RDP session is active, so I will show you this black screen after typing your username and password until user disconnects (Why not kick out the user?). VNC is even bigger pain when you need to boot up server from SSH and sometimes restart it when it gets stuck.
While on Windows you can just install TightVNC and it works. No screwing with screens. On MacOS you can just tick Remote Screen Sharing, put your VNC password and it just works. Even Android can do that droidVNC-NG, But Linux is such a PITA to make VNC or RDP working.
And RDP also assumes that you are running X11 and not Wayland.