I appreciate the effort that went into writing the article but it conflates different concepts missing some historical context and technical distinctions.
For example, TUI (text user interface) and CLI (command-line interface) are quite different. "CLI Text Editor" sounds more like someone editing a file using ECHO commands.
This new editor is actually a reimplementation of the classic MS-DOS 5 EDIT program from 1991. At that time, VIM was still very new, so "VIM memes" weren't yet part of the tech landscape.
Before VIM, there was vi. In Usenet posts - about 15 years before Google - people used to add a pithy humorous sentence at the bottom called "tagline" - here is one: "How do you exit vi? Reboot the system."
And Notepad was not the only option for Windows devs. We've had EDIT, DR-DOS EDITOR, Brief, WordPad, EditPad, Notepad++, and more.
> This new editor is actually a reimplementation of the classic MS-DOS 5 EDIT program from 1991
MS-DOS 5 EDIT is actually just a stub which runs QBASIC in editor mode, in which all the BASIC-related features are disabled.
Windows 95 EDIT was different, it actually had BASIC removed from the binary. I don't know if it was a rewrite or if they just deleted (or even #ifdef-ed) out the BASIC parts out of the source code.
QBASIC was basically just a cut-down build of QuickBASIC with some features disabled. The TUI part was provided by the "Character Windows" (aka "Character-Oriented Windows", CW or COW) library, a TUI-mode analog to the Windows 3.x API for DOS TUI apps, it was also used by some other Microsoft products such as Word for DOS. It would be great were Microsoft to open source it (although from what I've heard, significant chunks of this stuff have already been included in various leaks of DOS and Windows source code, but it would be nice to have it publicly available in a completely kosher way)
The target market for this editor seems infinitesimal. Who on Windows these days groks the terminal on Windows, wants a terminal editor instead of Notepad++ or VSCode, and finds Neovim overwhelming? And certainly no one on Ubuntu is looking for this.
That said, give me QuickBasic back in the terminal on Windows, Mac, and Linux, and now you’ve got my attention…
> That said, give me QuickBasic back in the terminal on Windows, Mac, and Linux, and now you’ve got my attention…
There are already open source clones of QuickBasic which provide what you want, plus a whole lot more, such as QB64 and FreeBASIC.
While I'd love it were Microsoft to some day open source QuickBasic/QBasic/PDS/VB for DOS/etc, that would largely be of historical rather than practical benefit.
I've long quit using vim on a daily basis, but the "how to exit Vim?" jokes are still somehow funny. A recent encounter was an old tweet by @iamdeveloper: "I've been using Vim for about 2 years now, mostly because I can't figure out how to exit it."
I've always used :x or :x! and no longer remember why. Probably it's a bad idea like without actually looking right now I think it might mean to ignore permissions (if you're root enough) and just write even if perms would have blocked it. Hm, maybe x means wq and just the ! means force.
The fact that everyone says the meme is dead, but in this small thread there are 5 different people posting how to exit, and none of them are the same says there is still pretty good substance behind that meme.
I feel like the default behavior should be to not write unless changes have been made. I may be misunderstanding here, but what would be getting written if nothing's been changed?
or they should just make sure emacs can work with the machine thru ssh, then there is nothing to install ;)
if no ssh, then nano is not a bad option, though i would go with joe (https://joe-editor.sourceforge.io/) which can also show the shortcuts, but much much more powerful, yet it's just a single ~700kbyte exe (or 1.5MB with some optional syntax highlighting grammars and docs)
>or they should just make sure emacs can work with the machine thru ssh, then there is nothing to install ;)
While (neo)vim doesn't have TRAMP and dired, it has netrw, which does the same stuff (on a basic level). You can do the following to edit a remote file:
vim scp://user@hostname/path-to-file-here
You can also replace user@hostname with an ssh alias you've configured, which makes it easier to work with multihop ssh and different keys and users. One useful usage of the remote editing is to combine it with opening multiple files to compare two files on different machines:
vim -O ~/.config/mpv/mpv.conf scp://htpc/.config/mpv/mpv.conf
To browse a directory instead of a specific file, just put the dir instead of a non-dir file and it will open a filebrowser view where you can then pick a file to open. In the above examples, leave off mpv.conf and you'll then be able to pick either your mpv.conf or input.conf or files related to your mpv scripts.
Before vim was vi. Befote vi was ex. (Before ex was ed - the first editor for unix)
Vim has ex built in - `Q` in normal mode to enter Ex mode, 3-5 command lines will show at the bottom and you can Ex away. I don't know of practical uses, I've only done it for the novelty.
Obligatory: To exit Ex mode use `:vi[sual]` - and that's probably where Vi got its name.
my biggest problem with azure was also the fact that they couldn't stick to industry-standard terminology, but they has to invent their own. it made azure docs tremendously confusing.
The problem is that the nomenclature and conventions differed, and this many years later people tend to conflate them.
BBS networks like ILink had tearlines, optional taglines, and mandatory origin lines. FidoNet had tearlines and origin lines because it shared roots and sometimes nodes with the BBS networks; so they were there for compatibility. Usenet mainly had signatures, with all of its equivalents to the other stuff in headers.
In echomail they were known as "Origin" because the intended purpose of that line was to identify the originating node. It looked like this:
* Origin: any random text (12:34/56.78)
The text was supposed to be the name or description of the node, but this wasn't mandated by the rules, and the address at the end unambiguously identified the node anyway for anyone who cared, so people quickly repurposed it for taglines.
I find it interesting that everyone is using TUI when I've always seen CUI (Character User Interface). I come from a DOS and Windows background, and it seems like TUI comes from the *nix world.
And Notepad was not the only option for Windows devs.
Dr Dobbs and other tech magazines used to have ads for a variety of editors. And linkers, which were the bane of 80s programmers' lives. There was a whole era of programmer-oriented software that seems to have been largely forgotten.
My understanding is that CUI includes both TUI and CLI, and refers to the interface of a text-mode screen (as opposed to a graphical screen — a GUI), where you can use both CLI commands and TUI programs.
So, technically, if you’re using a TUI in a graphical terminal window within a GUI, you’re strictly speaking not in a CUI, but are emulating a CUI within a GUI. And the CLIs and TUIs are running within that CUI.
I don't agree with that. I first heard CUI used to describe software like the Turbo Pascal IDE. I believe that "CUI" came about when GUI was coined to describe the modern graphical interface like Windows and Macintosh. That was in the latter 80s and early 90s. I've never heard TUI until literally today.
Additionally, TUI is either Text or Terminal User Interface. Either way, it seems to be heavily associated with ncurses. As I understand it, ncurses essentially outputs a stream, which includes things like ANSI escape sequences for position and color. By contrast, CUIs like Turbo Pascal wrote directly to video memory.
It’s true that TUI is a newer term than GUI and CUI. However, it isn’t exactly a new term either, its Wikipedia page was created in 2004. Look at the screenshots for illustration of what is considered a TUI: https://en.wikipedia.org/wiki/Text-based_user_interface
The technical means of how the contents of the TUI is established (character stream with special codes, or direct writes to text-mode video buffer) is largely irrelevant for the term. The essential characteristic is that the visual “state space” of the interface is a character matrix, and that the program treats it as such (instead of just unidirectional line-based output).
Maybe you are right that CUI actually doesn’t cover CLI. The Unix System V documentation uses “Character User Interface” for curses-based interfaces (https://books.google.com/books?hl=en&id=idAmAAAAMAAJ). Then CUI and TUI are roughly synonymous, though TUI is the widespread term nowadays.
It'd still say ed is more of a TUI than CLI, albeit kind of old-school since it doesn't redraw the screen, just continuously show output and let you enter commands. Maybe "REPL" comes closer, because it's not interactive in the typical TUI way.
I fail to see the difference between REPL and CLI here. Any line-based interactive interface where you type commands is a CLI, like for example the ftp or mysql clients in interactive mode. Or, indeed, ed.
Personally I usually make the distinction based on whether the process has to switch the tty to raw mode and overwrites the full screen (typically using ncurses), but it sounds like the person you are replying to makes the distinction in whether the program needs user input while executing. I guess such programs are more likely to work in pipelines or shell scripts
Unix shells “need user input while executing” in that sense. A program not being a Unix shell doesn’t make it non-CLI. A shell constitutes a CLI due to its interactive line-based user interface. Any other program with such an interface counts as being a CLI program for the same reason.
I don’t agree, it’s consecutive line output vs. screen-based rendering and repositioning. Regardless, ed was developed for and used on actual teletypes. It’s entire interface is geared towards that usage.
I think ed also served the function of sed and patch. Ie you could record a bunch of edits into a file and it could read the script and perform all the edits to some input file. So it was more useful than an interactive line based editor sounds.
This is the same distinction as between running commands with bash -c (or just by executing a regular Bash script) and running them manually in an interactive Bash session. It’s pretty much an inherent feature of command-line interfaces that you can script them.
It's different. Grep was a function of ed ('g/re/p') that was later extracted into its own program to search files that could not fit in memory. Sed then came along and implemented the 's/re/substitution/' functionality from ed for the streaming use case.
But as to that, it's slightly different than merely being able to play back a recording of commands. It IS that, but that can be applied in a way that acts more like the examples I said like sed or patch, or expect, where the script can apply some funcion to different inputs, not just playing back a recording. I'm not denying the implimentation, how the job gets done, is technically still just a recording of commands.
They are obviously "command line interfaces" in that the interface is that you enter lines of commands.
They are equally obviously different from the non-interative interface where all input is provided in the command line arguments and other shell syntax (pipes, redirection).
ls is a cli app. bash is an interative app that provides the cli environment in which you use ls.
I fail to see what is gained by trying make the meaning of "cli app" unclear when it definitely has an understood meaning, just because you can technically assemble the same words to mean other things. Sure in certsin contexts where you are speaking more geneticslly and more abstractly like in some research paper you may refer to a wide range of things all as "command line interface". But so what? How does noting that help in this context? (It does not)
I disagree that it is well-understood in the way you describe. I agree that there are two distinct concepts: 1. Programs that can be run as a CLI command, often without further user interaction (but consider cases like rm -i, which are quite common), and 2. programs that expose their functionality by providing their own interactive CLI.
In the case of 1, the program’s argument syntax can be referred to as the program’s “command-line interface”. But the abbreviation “CLI” usually means the interactive interface as in 2.
The latter is analogous to the notion of how TUI programs provide their own interactive interface. When making the distinction between CLI and TUI, it’s the latter that is meant, i.e. is it a line-oriented or screen-oriented user interface.
Saying “CLI editor” doesn’t imply that the editor commands are necessarily invoked as non-interactive shell commands, as opposed to the editor providing a CLI of its own.
Technically, every program can serve as a “CLI command”, since you can invoke it with arguments. However, “command line” is generally understood to mean the user interface where the user types commands, as opposed to non-interactive program invocation. When invoking a program with arguments from another program with exec or similar, you don’t call that a CLI.
Is it actually important that we come up with a formal definition of these things, though? They are colloquial terms, there is some overlap, and people are always going to use one or the other “incorrectly” according to you. It’s more important that we recognize that’s a potential source of differing terminology and ignore that rather than fixating on it.
Probably because most of us don't think it's correct at all.
TUI apps aren't common anymore, which adds to the confusion as a lot of people didn't grow up with them and don't grasp the difference. A TUI app takes control of the terminal and redraws different parts of the screen to present a consistent, non-scrolling experience. If you've ever used a system where your interface was an IBM 3270 emulator (or better, an actual 3270 terminal), that's TUI. vi/vim and non-GUI Emacs are also TUI.
A CLI app just prints its output at the cursor and the output scrolls off the top of the screen as you go. The Bourne, Korn, Bourne Again, and C shells are all CLI, as are most REPLs and the majority of interactive non-GUI UNIX programs (including ed) these days.
Ye gods, I had managed to bury that memory! Went from Slackware to Solaris, and then used killall while teaching a UNIX class. Everyone got a laugh and a smoke break, and I got knocked down a peg.
Interestingly enough, the weird re-boosting to get more views thing that Hacker News sometimes does is making it seem like I said all of that 5 hours ago.
MicroEmacs is small and lightweight. I port it to whatever machine I'm using, and it works nicely in a remote tty window. It doesn't need a customization language, as I just change the source code.
Recently, I added color syntax highlighting to it, and support for unicode characters.
I understand the categorization you want to draw, but I don't think convention and usage are going to back you up well enough to solidify it.
Sometimes people use CLI to mean something you're literally doing at the shell prompt, and sometimes people use CLI to mean anything that isn't a GUI. And the Venn diagram of those meanings has significant overlap when both of those meanings are contextually valid and the end result of the meaning is functionally identical.
If I say, "instead of Firefox I'm using lynx, a CLI web browser," it's not really so ambiguous what I mean that you're confused. You can do backflips and dodge context to arrive at being confusing, but you really have to cross into disingenuous reading to get there.
The fact that you CAN draw a difference does not actually mean that the author needs to in order to communicate effectively.
> For example, TUI (text user interface) and CLI (command-line interface) are quite different. "CLI Text Editor" sounds more like someone editing a file using ECHO commands.
Sounds like ed, or edlin for the DOS oldies, to me.
I forgot how the punchline is phrased, so apologies for the atrocious delivery, but I like the one about “I do all my coding in VIM, because I don’t know how to exit VIM”
For example, TUI (text user interface) and CLI (command-line interface) are quite different. "CLI Text Editor" sounds more like someone editing a file using ECHO commands.
This new editor is actually a reimplementation of the classic MS-DOS 5 EDIT program from 1991. At that time, VIM was still very new, so "VIM memes" weren't yet part of the tech landscape.
Before VIM, there was vi. In Usenet posts - about 15 years before Google - people used to add a pithy humorous sentence at the bottom called "tagline" - here is one: "How do you exit vi? Reboot the system."
And Notepad was not the only option for Windows devs. We've had EDIT, DR-DOS EDITOR, Brief, WordPad, EditPad, Notepad++, and more.