Fans of original gangster editors, look away now: It's Tilde, a text editor that doesn't work like it's 1976 Tilde is a plain text editor for the Linux console. The difference is that even if you've never seen it before, you already know how to use this one. Tilde Click to enlarge One type of software where the world of Unix-like OSes has a positive embarrassment of riches is text editors. The problem is that too many of them are …
This post has been deleted by its author
What is the point though?
Nano is easy to use for a quick edit of a small file.
There are plenty of GUI editors if you want something more sophisticated.
If you need to edit something on a server, use a GUI editor that can edit files over sftp or similar (or an OS that can mount remote file systems in a similar way).
I am sure some peole will like it, but its very niche.
The point is that Nano's UI is unique to Nano, just as WordPerfect's was unique to WordPerfect etc.
Whereas the same keystrokes that work in Xed, Mousepad, Leafpad, Kedit, Kate, etc. all work in Tilde, so you don't need to remember that you're in some peculiar app and can use the same keystrokes that you would use in basically every GUI, on xNix or Windows or macOS.
Most of us work in GUIs almost all day every day. All GUIs have a common design, which is basically IBM CUA. There's no _need_ to remember a different one for your console editor, if you don't need that editor a lot.
What I don't understand is why there's no available keyboard that allows you to define control keys for cursor movement *across the board*. For example, ^H = one character left, ^J = one line down, ^N = one screen down, etc. Or the olde Wordstar key mapping. So you don't have to take your fingers off the alphabetic keyboard. And to repeat myself, it should work the same way in editors, word processors, file managers (to the extent that makes sense), spreadsheets, browsers (when entering text, including the URL bar), and so forth. It would not be difficult. But what do we have instead? Every app has its own mapping of control keys, and almost none bother to map the cursor keys to control keys. Bizarre.
On Windows I think you can use the utility "AutoHotkey" to intercept nominated keystrokes and substitute them with "standard" PC functional keys, or run macros, whatever. If you want to get fancy with it, you also can make it detect which program is in foreground, and vary the key mapping behaviour, such as by running the same macro but giving it a different output.
It should be the original vi and nothing more. vim is the mark of those who have strayed from the path of righteousness.
Actually, that initial look of betrayal and horror when someone realises that vi isn’t an alias to vim on a system, but is rather the original vi editor is priceless.
[esc]:wq
I beg to differ, Sir. I cut my teeth on vi but always found it to be a bit basic once I'd got addicted all the sugar added to vim.
Vi had an especially annoying 'feature' whereby if any single 'ex' command failed then it would finally exit with a non-zero status even if the later commands (e.g. :wq ) succeeded... This meant that when I was using it as my email editor within Pine that if I mistyped a command inside vi then it would see the non zero status as an editor failure and discard what I'd typed.
I guess the same would be true using classic vi to edit git commit messages - it would probably just abort.
On the other hand vim exits based on the most recent command status which makes so much more sense.
Well, no, the GUI most of us work in every day is derived from the Apple Human Interface Guidelines. IBM was late to the party and did a bad ripoff.
And the thing I don't like about this editor is that it's a text-mode text editor that tries to play mouse-style menus when it can't rely on a mouse being available. The Apple HIGs had an answer for that, and it was NOT top of screen menus. It was called the filecard interface, its best known appearance was in the original AppleWorks.
> This was partly because they all came from different original platforms, partly because such things weren't standardised yet, and partly because ...
Also they came from era of the Lotus 123 user interface copyright infringement lawsuits. Lotus won and that was enough to discourage others from copying anyone's existing interface too closely, regardless of whether the software was a spreadsheet or not.
First of all, note that even vi and EMACS have CUA compliant(ish) GUI interfaces, in Vim and Xemacs.
And of course Nano just rolled a rev., which proves that an editor doesn't have to be CUA compliant to be easy to use (also note that both vi and EMACS have Nano compatible settings(!!)).
The only time I use the built-in editor in mc is when I'm playing in the file system and notice or remember a file that needs updating or otherwise adjusting.
With that said, I strongly think that the more simple text editors the merrier ... if for nothing else than the fact that the person doing the coding has to actually think about the user interface, and how to use his/her language of choice to implement their vision. Both of these are sadly lacking in many programming classes these days. If you consider yourself a programmer and haven't tried to create your own text editor, I strongly suggest you try it. Just be careful, you might actually learn something(s).
First one was in assembler on a fine platform that everyone was migrating away from. Second one was written in Fortran and did full-screen editing on a platform where that was so radical no one knew what to do with it.
What did I learn? Programming, even miracles, was easy. Satisfying people is impossible.
At my first job (1987 to 1992), I used KEdit (in DOS). On leaving that job, and my paid-for copy of KEdit, I decided I'd just write my own text editor. (I was young and foolish.) 29 years later, I still use it, ported from DOS to Windows to Linux. I've posted source code for it, mostly so I can download/compile/install on other machines.
It does suit my needs nicely (and because I wrote it, I can modify it as needed). And you are correct about the process of writing it being educational. But no halfway sane person would ever use it.
Well done on the editor! An even better done (or is it more well done) on recognizing the fine but most important distinction between writing a piece of software for your own use and doing so for wider public.
If I were allowed to to rid the world of one sort of people, it would be those asking to be put in charge of software procurement because they sucessfully copypasted a PHP3 message board from an outdated Stack Overflow answer to their own Web page built in Front Page on their silver themed Windows XP ten years ago.
You are very welcome. :-)
To the bemusement of my colleagues at a Prominent German Linux Vendor a few years ago, it's been my go-to console editor for years now. Less cognitive friction when working in the terminal or over `ssh`.
I did link to the new-Nano-release story. ;-)
Yes, there are vaguely CUA-like modes for Emacs and Vim, but only in a GUI, not at the console. And at any rate, IMHO Tilde is a lot more CUA-compliant than Emacs with `cua-mode` installed, and about 1% of the size.
All true enough, but I think II'll stick with vi ... 40-odd years of muscle memory is kind of hard to ignore. I even use vi as my shell for one of my logins. When I'm writing I hate the bells and whistles of a gui getting underfoot. Always have, always will.
And seriously, I do appreciate the article. I "collect" free editors, so I can give newbies a choice. Not everyone likes the same thing, so the more the merrier!
Sorry, most web analytics platforms already track the movement of your mouse to generate heatmaps and increment the strength of interests, and if you take a moment to do some self-observation, you may find that your mouse often trails your vision on things you consider clicking or that interest you. It's a hard habit to break if you do it, hence why I block all analytics platforms...
If you don't have that problem though, then by all means continue waving.
Many years ago I got to grips with Emacs. But I moved to a MS-Windows shop and Emacs wasn't readily available so the muscle memory faded away. Emacs was powerful, but it had/has such a steep learning curve. Like any system, you have to use it regulalry to keep the memory of how to use it.
If unix text editors were military aircraft:
ed - early biplane with one machine gun mounted on top wing; stand up in cockpit to operate
ex - early biplane with two machine guns mounted ...
vi - biplane with machine gun firing synchronously through propellor
emacs - A10 with nose mounted electric auto cannon and lotsa rockets under the wings
A multi-role combat aircraft before its time.
...that was designed to be launched from an aircraft carrier with an always-too-short runway (but had a convenient bungee cord connecting the aircraft and carrier, so that you could sling it back around to the beginning of the runway if/when needed...).
You neglected to mention that the emacs aircraft -- while armed with truly impressive weaponry -- is controlled by a rotary telephone dial using 6118 unique and totally non-intuitive dial in codes.
(I actually use emacs because of the configurability and the broad capabilities of org-mode. But, I'd never, ever, recommend it to anyone else.)
Actually, Emacs is superb at writing and debugging VHDL (There's a couple of commercial offerings that come close, but no cigar).
My colleague in a previous life mapped most of the common key-bindings to function keys. Which was good. Also, I like the search and replace with regexps. The rest of Emacs - yeah well...
That Vi can blow your computer to bits with frustration, but EMACS can blow the entire house to bits, plus next door and then go on to take out your mates in a friendly fire incident.
All before you can find the stop command, since as the A10 is based on EMACS it doesn't use standard methods of communication like radio and implements it's own unique IFF codes. It does however recognise that this will drive it's users insane with rage and so comes with a built in shrink.
The best version was the Borland adaptation of FinalWord - as in it finally emulates Emacs, unlike MINCE (Mince Is Not Complete Emacs) - sold as Borland Sprint.
They had a *ix version to go with the DOS one, and developed a Windows version that showed the results of its very powerful markup language wysiwyg-style, but abandoned it before release.
No, Qedit is *not* the DOS editor. You are thinking of QBasic and the MS-DOS 5/6 editor that called the QBasic IDE for editing plain-text files. That was just called EDIT.EXE and was not available separately.
Qedit was a shareware DOS editor with a Pascal-like macro language, in the 1980s. It eventually became a paid program called The SemWare Editor, TSE:
https://en.wikipedia.org/wiki/The_SemWare_Editor
It's still available:
http://www.semware.com/
I _think_ they changed the name because of an older editor for HP minicomputers running MPE:
http://www.robelle.com/smugbook/qedit.html
One of the things that I immediately liked about Qedit was "drop anchor". What it meant was that it was a modal editor, but not modal in the same way as vi. Rather, when you dropped anchor (I think it was assigned to the ^Q key), the cursor movement keys became text selection keys. So if ordinarily, ^L moved the cursor one character to the right, if you had your anchor down, ^L selected the current char and moved one char to the right. You could continue selecting text until you hit ^C or ^X to copy or cut your selection; or ^Q again to raise (toggle) the anchor.
I found Edlin to be very useful back when I was doing technical support because I could predict exactly what was on the user's screen. You could also pipe commands into it from another file so a primitive form of script control. There was also a time when Edlin was the only thing you could be sure to find on someone else' computer. Same deal with Notepad on Windows. It's crude but it's always there.
I liked Vi because back when I was using it you could never be sure if the terminal you'd been dropped in front of had the correct mappings configured. Half the time you could forget anything 'clever' like arrow keys. Vi supported almost every terminal out of the box and even if it couldn't give you the full screen experience it would drop back to Ex mode and I was happy with that as well.
Funny thing was a few years back (but a couple of decades since I'd stopped using Unix) I had to edit a config file on a system so I fired up Vi and my fingers/brain still remembered the editing keys.
It demands that my fingers do interesting gymnastics for even the simplest tasks.
Two features that I use a great deal appear to be missing:
* ability to pipe a range of lines through an arbitrary pipeline of commands
* multiple copy/paste buffers
They might be available, but there's nothing behind the help menu except "About", so I can't find out how to do it. Even modern vi clones have decent help behind the :help command.
Another minor niggle - the hotkeys stop working when a menu is open. So, for example, Quit is CTRL-Q, but if I can't remember it I can use ALT-F to open the File menu, and there I can see that the hotkey is CTRL-Q. But at this point it's no longer CTRL-Q but Q. Unless you press CTRL-Q first :-(
Disclaimer: I recognise that choice of editor is a very personal thing. I've been using vi in various forms for so long that my fingers type the commands without me having to think about it. Elvis for preference; vim is OK (and essential for utf8 support.)
If you want to do that, sure, do it.
But I did specifically say:
> But what if you don't edit code and don't need syntax highlighting and all that jazz?
> What if you just need to occasionally tweak a config file?
It sounds to me like you want a high-powered editor for high-end stuff. In which case, I tried to specifically exclude such users. I don't think Tilde is trying to be such a tool for people like that, and I tried to say so.
But yes, it does multiple files fine; that is why there is a "Window" menu. To switch between windows. A file in each window. One of the reasons I like Tilde is it doesn't use weird 1970s Emacs-speak like, say, "buffers". In the rest of computing, a buffer is an area of memory used for temporary data storage, such as between processes or devices which work at different speeds: a printer buffer, or a disk buffer.
As for issues such as shortcut keys not working while you are in menus:
1. This seems like standard CUA behaviour to me. Take it up with the CUA authors and designers, if any of them are still alive.
2. If you need to check what Ctrl+Q means, then this is probably not the editor for you. Since it is a CUA keystroke, those of who use keyboard shortcuts in GUI apps all the time and have for about 30 years don't need to look that stuff up.
3. It sounds like you don't know GUI shortcuts but are more comfortable with Vi[m] ones. Fine; if you like Vim then use Vim. Why even look at alternatives? Personally I have been using Vi since 1988. I hated it then, and I hate it now. It's one of the nastiest editors I've ever used since DOS EDLIN. It's modal, which I dislike. It's cryptic, unfriendly, and unhelpful. I have about ⅓ of a century experience and I can't cut-and-paste in it, or do a search-and-replace, because it doesn't use the same UI as _every other editor invented since the late 1980s_. Which is the entire point of the article: you can edit files on the Linux console without using horrid 1970s tools such as Vi.
> But what if you don't edit code and don't need syntax highlighting and all that jazz?
Use Libreoffice
> What if you just need to occasionally tweak a config file?
Then it doesn't matter - since it is only occasional use. The secret is to learn the most common ONE, that is available on every platform. If that is vi or nano, so be it.
While all those "arcane" editors have many features, it is not obligatory or sensible to use them all. The only features an average user needs to know are how to open a file, navigate to the correct place (line), alter text and save the results.
"The only features an average user needs to know are how to open a file, navigate to the correct place (line), alter text and save the results."
That's all the average user knows. That's why they're average users. The average user might repeat that sequence a lot to change the same string in a lot of places because the average user doesn't know how to do an all instances change. If that was common knowledge amongst more users then you might be including it in the list of things the average user needs to know.
Repeat for all the other good tricks an advanced editor can do because a lot of users would find them useful from time to time. That way you raise the bar of what's average.
You should see the walnuts from my neighbours' tree. I picked some "fallers" up a few years back, eagerly anticipating lovely sweet, soft nuts just like the ones we used to get from "Auntie Pam"'s tree when I was a kid and nothing like the bitter, dry things you get in the supermarket. I had to use a bench vice to crack them. The bloody nuts were the size of peas; the rest was solid shell. Just for laughs I put one under the wheel of my car and drove over it - it survived intact.
Probably crossed with Macadamia nuts from Queensland, Australia. I have broken 3 hand operated crackers on the buggers. I once visited a factory where they shell them and they were in the process of changing from 4inch thick solid steel contra-rotating rollers to using lasers to cut them open.
From wikipedia "The nutshell ("coat") is particularly tough and requires around 2000 N to crack. The shell material is five times harder than hazelnut shells and has mechanical properties similar to aluminium. It has a Vickers hardness of 35."
Then again probably not, because macadamia have comparatively thin shells but they are truly the toughest I have ever tried to crack. Don't know if it was true but I was told they use the discarded shell as a road surface at pedestrian crossings because it lasts longer and has better friction for stopping than gravel.
https://www.nutworks.com.au/blog/the-uses-of-the-macadamia-shell
Interesting thought. I know they've used ground nut shells as an abrasive in the past, usually for sandblasting and the like, but this article here notes it also makes for good compost, filtration, or even outdoor cooking fuel.
We still use ground walnut shells as abrasives. Indispensable when restoring old farm equipment (steam powered, hit&miss, and pre-WWII tractors). Takes off paint, rust, dirt, grease & grime, leaves the metal behind. I always have three grits available. 50lb bags for about 70 bucks from Grainger. Recommended.
I stopped using walnut media on my brass ages ago ... I switched to wet tumbling with stainless steel media and have never looked back. The 5lbs of pins that came with the tumbler should last last long enough for my Granddaughter's kids to learn the art ... Compare that to constantly swapping out lead contaminated walnut dust, and, well, 'nuff said. Well worth the price of admission. Recommended.
A wet tumbler is on my list. I still need to get a chrony and a few other things first, though. I'm almost to the stage where I can cast for all of my pistol calibers (or at least the ones I'll reload - not planning to fuss with the .380 or the .32ACP, too small and fiddly for my aging eyes). You're fortunate if your kids/grandkids have an interest in this, I can't get mine to give half a damn about it.
Sounds like your neighbor's tree is a black walnut.
The meat is quite tasty, but very difficult to harvest. That's why I instead harvested the couple dozen or so on this property and turned them into furniture ... and in their place, I grafted the Ivanhoe varietal of English walnut onto a couple dozen "volunteer" black walnut seedlings. Why the Ivanhoe? Both because I like them, and because my brother had a tree to provide cuttings.
"...The only features thing an average user needs to know ..."
...is to USE LIBREOFFICE? (Which still, after twelve years in development, is not ready for prime time).
A 1/2 GB---that's "GB", as in "Gigabytes", folks--- "program" / "application" to perform simple text editing?
What are you, and all the cretins who up-voted you smoking?
You can't fix dumb.
"Consider how dumb the average person ["user"] is. Now consider the fact that half are dumber than that."---George Carlin
Completely missing the entire point of the article.
No, LibreOffice is not a tool for this role in any way.
1. It is a GUI app and needs a GUI. This is a console app.
2. LibreOffice is not a plain-text editor and does not include one.
This article is about plain-text editors for the console. It is not about office suites, which are an entirely different category of application.
And no, I disagree. If I am SSHed into a remote machine that is not mine and all I have is Vi, then of course I can use Vi. But I absolutely loathe it and have done since I first saw it in 1988. The article is about a tool you can install. If you can install software that implies that it's your computer. I would no more choose Vi to edit files on my own computers than I would choose to do my own fillings in the bathroom mirror.
This is about something comfortable and easy, not an exercise in DIY root canal work such as Vi.
Talking of weird UIs, what possessed the maintainers of the Xubuntu pdf/document viewer (Atril) to put the "File" and "View" menus top right instead of top left and give them both the same cogwheel (ie "Settings") icon?
And while I quite like the ribbon interface in Word, why does "File" bring a huge clunky side bar menu into play instead of just changing the ribbon like everything else?
"... possessed the maintainers of the Xubuntu..."
Just wait until you see how xfce ≥ 4.16 messes up the interface. OK, let's be honest and fair. The source of all this CSD madness is of course Gnome/ GTK. But whatever it may be, just be prepared for calls that "the thingy that used to be there isn't there any more" and wasting time to search for "exotic" and little used functions/ buttons like Print, Preferences, Cancel, OK... Why do simple, intuitive, or something that was described in that old timers manual "GUI for dummies?" in the 70s, right?
'Scuse me, but WordPerfect produced arguably the very best text edit (bundled with WordPerfect Office). It used all the familiar WordPerfect function key commands and navigation key sequences (home home down, etc.), and had reveal codes and Hex edit/display capability. Macros could be assigned to keys, so if you were masochistic enough you could emulate WordStar with it. Searching/replacing could be done across lines - whatever line break characters were used. One of its best features though was the ability to edit files up to max Operating System file size, regardless of how much memory was in the pc. Shame I no longer have a copy.
WordStar was the first editor I used extensively. Sometime later I started using VAX/VMS, and deleting lines in the editor was painful :-(
(The WordStar command to delete line was Ctrl-Y. On VMS Ctrl-Y was the interupt process...)
Me too. I liked the editing keys although they were easier to use on an old keyboard that had the ctrl on the middle row. But still I always claimed I was faster with WS keys because it kept your hands on the home row - no need to break off and reach for the arrow cluster.
Do you mean WordPerfect Editor?
That still exists and it is freeware, so you can still use it if you prefer.
http://texteditors.org/cgi-bin/wiki.pl?WordPerfect_Editor
I supported WordPerfect professionally in the 1990s and so was able to use it competently, but I never particularly liked the thing myself, because its UI was so idiosyncratic. However, later versions (e.g. 6 for DOS, 8 for Linux, anything this century for Windows) are perfectly standard GUI apps and by modern standards small and wicked fast. So I do very occasionally use them. I wrote a blog post that did very well on Hacker News this year on how to get the two legal freebie versions that are out there (for Classic MacOS and for Linux).
Finding this is left as an exercise for the reader. :-D
There was another early text editor which was reasonably good, but didn't last. Pluperfect Writer. It came with my KayPro II in 1982. It was the first non-mainframe, non "ed" type editor I used. Cat's meow!
Best wishes,
Bob
For the terminal I swear by a smallish editor called dte (by Craig Barnes). Small, and just powerful enough for the (rare) terminal edits I do. It also runs fine over SSH.
For real programmer's stuff there's nothing that beats CudaText, a sort of extended clone of Sublime Text. Multi-platform, fast, powerful, you name it.
I just tried dte.
I had to Google for how to exit the thing. Worse still, it was described in Emacs language. I am typing on a keyboard that will by 31 years old in a single-digit number of weeks. It does not have a Meta key, because when this keyboard was manufactured last century, no keyboards had Meta keys and hadn't had them for a decade or two.
This is *exactly* the kind of horrid cryptic xNix tool that after ⅓ century of using xNix professionally, I absolutely hate, and exactly the reason why I use Tilde and prefer tools such as Tilde.
So that is a huge NO NO NO NOPE NIET NÃO NON DO NOT WANT from the author.
No meta key? Well, that's interesting, because the first time I fired up tilde (after reading the article and installing it to take a look) it informed me that I could use Meta+<letter> to access the menus. Or Esc <letter>.
Another interesting thing (referring back to my earlier comment): After Esc F neither Q nor ctrl-Q work. Is that another useful feature of CUA?
The Meta key was invented at SAIL in 1970, with the Stanford Keyboard. Other folks in the AI community (notably Tom Knight and John Kulp at MIT) emulated, enhanced and extended Stanford's concept in ensuing years.
The first 101 (102, in some places) key keyboard was released by the imaginatively named Key Tronic Corporation in 1982.
IBM somewhat re-worked the 101/102 keyboard, bringing us the Model-M in 1985, which many believe to be the best "factory stock" keyboard ever invented.
I run a Model-M, with appropriate re-mapping of several keys to make movement from the home row unnecessary for most things. I have never found another combination that allows me to put my thoughts into ASCII faster or more accurately. Recommended.
Before vi, we used punch cards, but being a Yorkshireman we didn't waste money on machines to operate them, so we had to use really small scissors and cut the holes manually and then pass them to a guy called Nick who would use tiny magnets to write to the hard disk by hand. It was slow going but a nice milky cuppa and we were good to knuckle under and get it done
You joke, but my dad shared an anecdote years ago where they couldn’t work out why their programs were failing to load - one of the people in the office thought that using the punch cards once was a terrible waste, and was attempting to recycle them by pushing back in all the little bits.
The nearest computer at the time was in Australia - he was in NZ. So the round trip was weeks. I believe the culprit was not popular.
Its a lean programmer's editor with arguably one of the best search functions I know of.
As a programmer I've usually been forced to work on Windows desktops ("company policy") and part of the job would be trying to unravel a tangled ball of code which is some product that urgently needs a bug fix or new feature. Having code that can rapidly search through hundreds of files (and then search on the search results) is really useful. It also can search on regular expressions...luxury!
A lot of programmer editors try to understand program structure. They're really useful for unwrapping tortuous object hierarchies but you pay for the privilege because to do this they also want to organize ("take over") the project and build environment. You shouldn't need to use this to unravel your code -- the code should be well organized -- but its handy to try and figure out excessively tortuous source that's been put together by a clever programmer.
Of course, hardcore Linux types don't see this as a problem. It's worth learning some Byzantine editor because it gives you a big advantage editing code.
No no no no no....
It's worth learning the basics of Vi for that (vanishingly) rare occasion when you're presented with a hosed systen and a console from the dark ages as you can usually persuade it to work. At least enough to edit whateve you need to get things booting further.
Also, if you know vi it's quick to edit config files using SSH, but I'm not 100% sure if I do this because I always have. I suspect if I was starting out now I wouldn't be learning Vi. (I really should use pico or similar, but I just get sick of muscle memory adding :wq! in the middle of files...)
WTF are people doing programming in it though? My first job was a unix shop, everyone programmed in Vi.... then I arrived and showed them a windows based editor with FTP facilities..... I got told they were 'unreliable'.... I toggled the 'save as unix' box and all was well.
That was the early 2000s.
Was going to make the same point. Vi has the virtue of being installed *everywhere*, perhaps less of an issue now Linux has won the *nix wars but back in the day, it was the only one to learn as a jobbing contractor.
Still coding in it now, on our quarter-million line codebase. IDEs are for wimps.
If you've learned it that thoroughly, sure. I consider recommending Vim's arse-backwards way of thinking and dark cave UI to be a crime against the next generation.
WTF are people doing programming in it though?
Corporate IT policy manages to bork everything else - Windows desktop doesn't play well with servers, no accessible package manager on the server for mere mortals, firewall kills NFS which means you can't connect network drives on the PC to do remote editing in an IDE, server OS is RH 6 so it's impossible to compile anything vaguely modern due to dependencies. In the end you just give up and use vim (thankfully vim is available, otherwise it would be vi).
vi is for far more than config files or even coding. On and off over the years I've been using it to massage data files from one format to another. Fair enough, it could be done with sed but if you have to open the file anyway to see what you've got & what needs to be done it's just easier to use the built-in bulk updates.
> On and off over the years I've been using it to massage data files from one format to another
Yeps.
Recently, i had to take a column from a spreadsheet and convert it into a list of values I could plug into a query.
One quick copy-pasta into vi, and I could then:
1) add a single quote to the start of every line ( :1,$ s/^/'/)
2) add a single quote and a comma to the end of every line ( :1,$ s/$/',/)
3) concatenate every row into a single line (400J)
Now, I know I could do the same with a bit of cat and awk, or by faffing with function calls in a spreadsheet. But after a few decades of using Vi, the above is pretty much just muscle memory!
Used to do a lot of "data wrangling" back in the day, porting data between disparate systems - Access to MySQL anyone?
Waaay back in the day I would fire up Delphi and hack some quick code, later on WAMPserver and a bit of PHP on localhost did the trick.
Guilty admission - regular expressions make my head hurt.
1) & 2) can collapse to:
:%s/^\(.*\)$/'\1',/
% is the address shorthand for 1,$ i.e. Whole File. And the search pattern supports bracketed sub-expressions referenceable by position-number in the replacement string (although these all need \ escaping).
Depending on your vi implementation, you might be able to lose the ^ & $. Or you might be able to change the $ to a linefeed (might need g after the last / ?) and eliminate the 400J step (try ctrl-v RTN or ctrl-v ctrl-j, see if that works: ctrl-v escapes control characters). (I think I'm recalling the v correctly -- not something I use often and I'm not near a computer to check.)
While we're on vi geekery, I'll throw in a little-known but occasionally very useful trick when you're tweaking files: Marks can be used as addresses.
If you want to run s over just a subset of the file, instead of having to remember and retype 2 ctrl-g line numbers, you can just mark beginning and end of the subset then use those marks. Example: go to beginning of the region you want to modify and type m a, go to end of the region and type m b, then type:
:'a,'bs/wibble/splunge/
Hey presto, wibbles throughout the file remain unsplunged except where you meant them to be.
Windows and OS/2 both followed CUA, as did Motif on UNIX, and for a few decades harmony mostly reigned
Did it, are you sure about that? ;)
Coming from RISC OS (which has a style guide, and well followed conventions) the lack of conformaty in the Windows and Unix worlds in the 90s/2000s was a bit of a shock. Even little things like buttons not being consistent between apps.
I still have a RISC OS box sitting on the desk next to me. So, yes, I know what you mean. :-)
However, I must admit, coming back to it running on a Raspberry Pi after about a 25 year gap was a shock to the system, and I do not find it easy to use today. I feel a bit sorry for anyone trying to learn to use it for the first time in the 21st century.
I bought my Archimedes A310 with the salary from my first job – after paying off my student debt and buying a motorbike and a Psion, anyway. I learned RISC OS in the 1980s alongside DOS and Unix in my day job.
At that time, DOS didn't have a standard GUI yet. Windows was on version 2.01 and was rarely seen. Amstrad were just launching the PC1512 around that time, so GEM was a rare sight too. Classic MacOS was on v6 and didn't have that many standard keystrokes and things yet. So it's fair to say that GUI standardisation had not really begun yet, and compared to the chaos of 1980s DOS apps, RISC OS 2 was just fine and not particularly weird. Everything was weird and different from everything else then.
I am not sure if RISC OS 2 predated CUA, but Acorn Arthur did, and CUA had not yet started to catch on when RISC OS was at its peak.
So I reckon its eccentricity is excusable. :-)
Classic MacOS was on v6 and didn't have that many standard keystrokes and things yet.
What? MacOS 1.0 specified how menus should be laid out and which keyboard shortcuts went with the common menu items. That was the point of MacOS from the start - learn one application, know how to use the rest for free.
I remember I started with Watcom's Vi on PC-DOS. I had workflow issues dealing with complex filesystem hierarchies (it would change directory if you opened a new file, causing :make to run from the wrong directory). I then moved onto Vim (still on DOS at this point) but the DPMI host would conflict with the one I was using for the compiler (and ultimately our software DOS/4g). It was just too big and heavy for an editor.
Finally I moved to Vi (part of the MKS Toolkit) and DESQView for multiple buffers (rather than one editor instance handling everything like with Vim). This worked very nicely and I scripted it to open up a new "tab" when running Vi. This workflow on DOS was actually really comfortable even though we all saw UNIX as "the OS for big and professional people". DOS always felt like we were amateurs.
These days I use Vi and Tmux (both are in the base install on OpenBSD). The fact that I can just jump onto OpenBSD as a free UNIX feels so modern compared to back in the day where UNIX was so unobtainable for the masses.
So the moral of the story (minus the rambling) is that it is Vi, always has been and always will be. Some of my colleagues have had to get familiar with dozens of IDEs over the years where I have just... not had to. Arguably IDEs are a little bit retro and perfectly suited to DOS where you don't really multitask well and instead need one big fat program to do it all.
Actually the reason is that under Linux nobody can code a good IDE and have to get back to use a hell of separate lame programs to get tasks done. In turn that's why Linux as a desktop operating system is going nowhere, as coding even the simplest GUI application requires to fight with a hellish chain of separate tools that work together badly.
But in every outdated environment there are people who believe that making simple things difficult is a prove of "skill" when it's exactly the other way round. That's why IT is going backward with applications that lose features and become more difficult to use. Let's hope one day some bright young developers discovers CUA, and will promote it as the new outstanding innovation.
A customer of mine succeeded in getting over £100k in R&D grants from HMRC for an innovative system I wrote for them using XEx.
Legacy? How does one define legacy when something that has been written 20 years ago is still being actively developed? That is one of the advantages of Pascal-type languages, they don't go out of fashion quite as quickly as Silverlight, for example.
Because although Microsoft is moving to the command-line, and supporting SSH administration of Windows Server, a good CLI text editor for modern Windows is 404 in the base install. Which means I usually have to resort to gvim; and I've tried everything:
- YEDIT: not a real installer, not a self-contained executable, and not signed. The same author wrote what is by far the best alternative to CMD.EXE (YORI).
- Open Watcom VI: still exists in GitHub, unbundled from OpenWacom, but doesn't support UTF-8
- Kinesics Text Editor: needs Admin permissions to install, no UTF-8
- FTE: needs very old MSVC libraries
- Thomson-Davies Editor: no UTF-8
- Micro: Go port of Nano - but that's Nano, not CUA
>checks Tilde website
>no Windows binary
aw shucks.
Yes, you have a good point there.
I can't offer much – I barely use Windows any more.
http://www.kompx.com/en/windows-console-applications-text-editors.htm
← offers a few. FTE looks to be about the best, though. :-(
Sounds to me like a native Windows port of Tilde is in order, yes!
That was Micro Emacs, not a bad mini implementation of EMACS.
It's also not a very good implementation ... Kind of "meh", IMO.
It was included as the editor in Mark Williams Company's "Let's C", one of the first professional caliber C compilers for the IBM PC.
Nano, recently updated, is a descendant of uemacs, by way of Pico
It was ported to most of the micro operating systems of the mid to late '80s ... including Minix, where a young programmer named Linus used it to create a new un*x clone called "Linux". Rumo(u)r has it that he is still using uemacs for kernel coding.
I know that this package shoudln't work as well as it does and I'm also sure that MSFT is gunning for it, directly or indirectly, with its pseudo-Linux distribution and its new pseudo-bash shell but if you've ever used it then you'd wonder how you lived without it. It does a great job of simulating a 'ix' system, including taming the Microsoft file system. The standard shell is bash but the bonus feature -- for those not enticed to PowerShell or whatever MSFT is offering for its 'embrace, extend, extinguish' strategy -- is that all the standard Linux commands work from the DOS prompt.
Cygwin's other bonus used to be the graphical version. Although 'X' is now out of fashion Wincyg installs an X server so you could start X sessions from the Windows machine, anything from a simple shell to a complete desktop. (Here is a cultural difference -- Windows has always presumed that you're working on the physical machine you're typing on, its why its always struggled with the concept 'user' and its permissions. 'ix' makes no such assumptions.)
(Cygwin is still widely used because its how the specialist IDEs that support embedded processors and FPGA development are hosted. These are typically a customized Eclipse IDE with a bunch of specialized utilities that are kicked off by the IDE. These utilities often use TCL to organize them. If you run a Linux install of these systems you'll get an identical desktop; you might find some helper or tutorial applications don't work (developed using MSFT's VC++ or similar) but by and large the only differences will be that the environment will be a lot faster and the USB ports will work properly.)
Cygwin is pretty good, a massive coding effort.
I also like Cygwin as a programming resource; being used to POSIX, thumbing through Cygwin's source code is a good way of find out how to do things on Win32.
I did this once to find out how Cygwin had implemented select() (the proper version, one that understands file descriptors for serial ports, sockets, files, etc, not the Windows tamed-down version that knows only of sockets). This was amusing, because it lead to a thoroughly entertaining thread on the Cygwin developers forum about Windows, and the impossibility of properly implementing select() on it, because there simply is no mechanism in Windows that can support it. I recall the dawning horror in the discussion as it emerged that it was utterly impossible.
In the end what they did was to launch a thread per file descriptor, have each of those polling the underlying resource (something you can do in Windows), and raising some sort of event as appropriate. The result is that select() under Cygwin is unavoidably a CPU resource hog with threads aplenty spinning away...
So, when WSL version 1 came out I was very interested, because that meant that Microsoft must have implemented the Linux system calls that allows glibc's select() to work, which so far as was conventionally understood is something that Windows simply did not support. Yet, WSL 1 clearly had it. So, what did MS do to implement it, and is that new functionality exposed anywhere else (e.g. in Win32), and could other POSIX imlementations on Windows (like Cygwin) finally get a decent implementation of select() and other reactors? Was Windows now capable of being both a proactor and a reactor?
We'll never know. WLS 1 got ditched in favour of a hypervisor hosting ordinary Linux...
Thank <Deity> for Cygwin or there'd have been no good way to run rsync on Windows for ages. And rsync was this poor admin's backup tool of choice back in the noughties. A dozen or so hot-swappable SATA drives, a Kingwin hot-swap chassis and carriers, and you've got a decent backup system for little cost, way faster and cheaper than tape, and doesn't need anything fancier than a standard PC to read the backup in an emergency.
Ahh, life after DDS-4 and before Veeam. I miss those days of exploration, before everything became "best practice" (well, SOMEBODY's best practice, anyway).
As someone else has commented, it was a low footprint way of automating an editing session by piping a text file of commands into it. Providing of course you took a belt & braces approach to knowing what might and might not be contained in the file to be edited. Because of its speed, there was no issue with running it several times in succession with different scripts.
GEC4xxx computers: Now they were not fun to edit a document on. First IIRC you had to create a file of the correct maximum size. Then you had to load and run the EDIT process. Then connect Stream 3 of the editor to the input file (the tty the first time after creating the file), and stream 4 to the newly created file. Then you edited your document using a very limited vocabulary of commands. If you moved past the point in the document to be edited then you couldn't go back. You had to end the session, create another file (or empty a scratch file), copy the file to this scratch file, then repeat the process.
And there's that assumption again: "Intuitive" == "DOS/Windows".
Now that we've SystemD'd the core and all Linux-as-a-desktop initiatives wholeheartedly copy either Mac or Windows, it's time to start making sure all command line tools are exactly like Windows as well. :(
I say to you :P
This post has been deleted by its author
"Windows... followed CUA... the system: a menu bar, with File and usually Edit menus, a Help menu at the end" Except of course Microsoft Office chose to break that with the Ribbon. Now there are no menu items, only hieroglyphs. File still exists, but it inexplicably takes you away from the document you're editing to some weird "back room" where you can't see what you were writing. And there is no Help menu; <Alt>H takes you to the weirdly named "Home" toolbar. And if you want help, there's a "?" icon that you can click on (if there's a keystroke for it, I don't know what it is), but which launches you out on the web somewhere instead of having a decent helpfile.
Of course I'm preaching to the choir here.
Nope, I really like ribbon. It's fast, productive, I can easily find what I want, I have no trouble at all scouring through the options menu to get hidden commands turned on so that I can use them. It's an absolute delig...
...who am I trying to kid. It's dreadful, and takes up screen space. Thank goodness I can still remember most of the key press sequences to do the things I want...
And if you want help, there's a "?" icon that you can click on (if there's a keystroke for it, I don't know what it is)Tried the CUA "Help" keystroke -- [F1]?
Dunno if it's the same thing as that "?" icon -- I couldn't find it to test! -- but it thros up a familiar-looking little window with light-blue links, so I think it is.
I enjoy reading about a lot of different options & opinions on this topic..I may even try tilde...
For me, at the top of the list is cross-platform availability.. I am willing to (and can) learn any editor, the point being that it's just an editor, a tool and as such, I only want to spend my effort/time learning one. For me, that's been emacs (butterfly-effect and all) for the past ~25 (?) years or so. For the last couple of years I've been messing around with visual code (yeah, I know...) just for a change... YMMV
I know vi because it integrates well with sudo to provide capabilities in a restricted environment, not sure how many other editors have similar capabilities..
"The...software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exist."--Grady Booch, Object-Oriented Analysis and Design with Applications
“It is time to unmask the computing community as a Secret Society for the Creation and Preservation of Artificial Complexity."--Edsger W. Dijkstra
**********************************************************
There has existed for a very long time an extremely powerful text editor---with any type manipulation desired or required--- which occupies less than 25 MB.
Oh, and by the way: besides being an ASCII text format editor, it just happens to be an extremely powerful word processor, which saves in 27 or so other formats, including EPUB, pdf, all forms of HTML, palm, newsgroup, rtf, doc, odt...
< 25 megabytes.
AbiWord.
EDT on VAX/VMS (later OpenVMS) that I used starting in the early eighties was the best. Digital had the best before DOS or Microsoft even existed. Keypad editing, learning sequences, macros,... - lots of very useful bells and whistles. I don't know about CUA. It needed a VTxxx keyboard or mapping so that you could use the keypad editing keys under your right hand (wcf the Gold Key?). you could get really good and fast when editing with this. Still have a PC compatible VT220 keyboard and working editor (ED) on Linux. Who still has their EDT Editor Reference Card? Never cared much for follow-ons TPU and its sidekick EVE, because so long as I could continue editing EDT style, I was happy. What a shock it was when the migration to UNIXes started. WTF? vi? But I got used to it.
It still freaks me out that Digital is no longer a prominent computer company or brand name. DIGITAL!!! That, and the fact that EDT wasn't even mentioned in the article.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
