Also: A terminal-based text editor written on top of node using parts of Atom.
Well, I'll give it a try if I have some time. I'm very curious what those "amazing features that make you drop Emacs" might be ;-)
Edit: Actually, does anyone know what the problem with a single core might be? If it's written in Javascript, it can't be that strongly relying on concurrency, can it? Or is it just the fact that it has to share "its" CPU core with the rest of the system?
Edit2: TIL: There's a library providing react-bindings for terminal interfaces[1]. I have to admit, I would've never expected that.
Agreed! I wish the sources of CygnusEd (Amiga) were open. Those guys nearly 30 years ago made a graphical text editor which on a 16 bit CPU clocked at 8MHz run circles around most today editors on 32/64 bit CPUs clocked over two orders of magnitude higher.
Do we have to count optimization as a forgotten art, at least among non system developers?
Only programmer time/effort matters anymore, to hell with the end users time, productivity, battery life and whatever other applications they happen to be running.
This brought memories! There's a video on Youtube showing CED in action...
Ladies and gentlemen, this is how a graphical text editor scrolled text 30 years ago on a 8 MHz 16 bit machine!
Nitpicking, but the Motorola 68000 was/is a 32 bit CPU, with 8 32-bit data registers (D0-D7) and 8 32-bit address registers (A0-A7, the latter used as a stack pointer). But CygnusEd probably took advantage of the Amiga co-processors for its gorgeous smooth scrolling effect...
Totally correct. For some reason I was thinking of the 68008 used in the Sinclair QL and thought "hah! that is the 8 bit version, then the 68K is 16 bit!". Yeah, but that was about addressing, not data registers width. ...Big oooops! (and I learned Amiga programming with 68K asm... (ducks and covers) :-)
About the coprocessors, surely Amiga offered a lot in this context, but I can't believe that today video cards cannot do the same with specialized hardware a hundred times faster (if we only take pure clock speed into account). There is something wrong with today software: machines get faster and faster, yet basic stuff like manipulating graphical elements didn't gain much in usability although more speed must have at least brought better granularity in dealing with events.
OS complexity surely plays a role, AmigaOS occupied hundreds of Kilobytes -that's about 1/1000 of a modern OS core- but come on.... having to stuff a multicore 1GHz+ CPU plus fast GPU just to have a browser surf the net without dying is plain ridiculous.
yeah, I clicked to the colored bar to see the distribution of languages in the repo, expecting to see C/C++ or even Pyhthon, and was shocked to see that 96.5% is javascript.
Well, that explains such an extensive list of features, I guess..
I'm not saying that JavaScript is an efficient choice, especially when likely depending on a gazillion NPM modules... but do you realise that python is actually an order of magnitude slower than JavaScript these days? unless the body of your performance sensitive code is within a python library python is very slow. I find the problem with most slow javascript is poorly written code and an unnecessarily deep dependency tree (NPM are not flat dependencies !).
Every one of the listed features is also available in Vim. I fail to see how this is either Sublime-like besides the keybindings (since a file pane is available on both Emacs and Vim) or will cause me to leave Vim or Emacs behind. That said, I can definitely see this replacing Nano for some folks.
I think the benefit is exactly the keybindings. And the fact that it is non-modal. It works like a text field in a desktop GUI, there is almost no state. You can't mess the state up. Contrast it to vim, where I got into the habbit of bashing ESC three times to be sure I'm not in a mode. Or emacs, which is nice until it's abstractions leak, and you accidentially start editing a configurations pane or something.
I am a part time vim user, and generally like it, but sometimes I find the mental load of the key bindings too high. Anything more complex than d<End>, and I have to stop a moment and think about it. In that time, I can just hit the cursor keys (and Home, PgDn, ...) a couple of times.
It's a trade-off: Do I use a bit of mental power, and save some finger movement? Then I go for the vi way. Or do I use less mental power, and delegate tasks to my fingers and eyes to do autonomically? Then I go for the sublime / notepad / VS way. I might press the arrow key a couple of times, overshoot, go back, ... it may look inefficient, but it's not slower, just a different use of resources.
I've been looking for a Sublime style editor for the terminal for ages. Actually, way before sublime, I've been looking for an edit.com style editor - Nano is one thing, but I want one that respects CUI-like conventions. Shift for selecting, CTRL+C for copy, .... I will definitely check this out.
> It's a trade-off: Do I use a bit of mental power, and save some finger
movement?
hammerandtongs already suggested this: it's not a trade-off, you just didn't
get to learn Vim appropriately (you say yourself that you're "part time vim
user"). Vim is so convenient for its regular users not because it saves them
keystrokes, but because it saves them this mental power you talk about.
I don't think what commands I want to execute. I think where I want to get in
the file or what should the text look like, and then the logic behind the
structure of vi/Vim commands takes me there.
It's very similar to proficiency in any other editor, except Vim has so much
more to offer with regard to editing (both in first-order commands and in
composing the commands). So much more that watching how a proficient Vim user
edits a file is akin to observing a stage magician. Most of the people cannot
keep up with the changes to the text.
Macros are the best part of vim for me. They allow me to transform large quantities of text which would be difficult to do using a regular expression even. Also, after enough use (I'd say 4 weeks in my case) a lot of the commands become muscle memory and I don't have to think about what I'm hitting. I think about a goal and know what to do to get there.
>I don't think what commands I want to execute. I think where I want to get in the file or what should the text look like, and then the logic behind the structure of vi/Vim commands takes me there.
this is gibberish unless vim comes with some sort of spinal cord dongle. either it's muscle memory or thinking but you still have to have practiced the keystrokes.
Muscle memory is not using some brain power as the GP says. Once you are used to it (2-3 weeks), it feels very natural, I think "Oh I need to change the end of this sentence" and my fingers will take me there. It really is an extension of touch typing.
He's describing how it feels to be a good vim user, not how it works in reality. A great tennis player might say "I don't think about how to hit the ball, I just think about where I want it to go and it goes there", and that would be reasonable. Then you come in and say no that's gibberish, unless he has a spinal cord dongle hooked up to a robot that hits it for him, he has to be thinking about doing the actions, they're not automatic after all!
> unless vim comes with some sort of spinal cord dongle
cerebellum is largely responsible for your muscle memory but premotor cortex stll needs to initialize those commands (what keys to press) then the cerebellum adjusts the precision i.e touch-typing part of it guess...
Which ones? All I see is just a handful of distinct commands. Those
commands take arguments, and they are called with those arguments over and
over again, but there's very little magic in the article. And, in fact, very
little of the commands available to and regularly used by Vim user were shown.
(And I think this was the point of the article.)
It's like you were arguing that printf("foo\n") and printf("bar\n") were some
fundamentally different magic incantations in C that you need to remember
separately.
That's right. You've made a great point. Learning vim is like learning a new language. Which isn't trivial for most people as exemplified by software like nano and the new micro.
"Or emacs, which is nice until it's abstractions leak, and you accidentially start editing a configurations pane or something."
I've been using emacs for decades and I don't think I've never done this. I've written my own elisp functions, packages etc (nothing too fancy, mostly text-oriented transformations) I guess I'm curious what you mean by 'editing a configuration panel'.
About vim and the mental load, even though one of its great features is its precision, sometimes we should pour a bit of sloppiness into it. And as vim users, we shouldn't feel ashamed. This user puts it in a great way:
https://news.ycombinator.com/item?id=12645523
Because becoming fluent has a cost value trade off, and I think there are a lot of people who simply don't think time invested in that is worth it.
I touch a terminal a lot, and I don't value vim enough to become fluent. I certainly know how to use it, and I know a fair bit of the commands, but it's nowhere close to my preferred workflow.
Plus, there's a huge array of tools out there to allow me to work with files in the editor of my choice, even when working on remote machines.
Finally, I grew up playing video games and using a computer, complete with modern input. The mouse is a first class input device, and I know how to use it effectively, quickly, and precisely to perform a wide variety of actions. I prefer an editor that treats the mouse like it's useful, rather than an add on that you can enable with extensions if desired.
> Finally, I grew up playing video games and using a computer, complete with modern input.
Funny you bring this up, since this reminds me of another discussion: I played a lot of videogames using keyboard and mouse, whereas some of my friends still own consoles and play (more or less) precision-based shooters using gamepads. Every now and then we used to have a couple of multiplayer matches locally on someone's PS. I still tend to skip my turns and just watch the others as gamepad based aiming in shooters tends to get me really frustrated. I'm used to the mouse and forcefully having removed the additional speed and precision it gives you while aiming feels terrible. I get the same feeling if I have to use an editor without Vim-style bindings, although I'm by no means an expert Vim user.
The interesting thing there is that you won't ever find a precision-based first person shooter with crossplay between PC and consoles, because the mouse gives PC players that much of an advantage.
> The mouse is a first class input device, and I know how to use it effectively, quickly, and precisely to perform a wide variety of actions.
I agree with you there, but so far I've come to the conclusion that it's strengths don't really show if you mainly edit text. The mouse is amazing for precision-based positioning, much like an analog stick can be superior to WASD because it's not limited to 8 axes and has more than just an on/off nature.
I find your other point far more important, though:
> I don't value vim enough to become fluent.
If you're not paid for the speed with which you edit text (and those jobs have become really rare nowadays), that's perfectly valid. Not everyone is interested in investing so much in a fringe activity, and we certainly would get far less done collectively if every tool would force a Vim-style learning curve on people.
> I still tend to skip my turns and just watch the others as gamepad based aiming in shooters tends to get me really frustrated.
This is why I liked the controls in goldeneye, perfect dark and timesplitters. They had consoles in mind from the ground up so the embraced the lack of precision controls with things like auto aiming and level design (mostly flat). Every other console shooter (including all since Halo) has tried to use controllers as though they're a keyboard/mouse.
The control scheme was also modal, where you'd have to hold down a button and not move if you wanted precision aiming.
>Finally, I grew up playing video games and using a computer, complete with modern input. The mouse is a first class input device, and I know how to use it effectively, quickly, and precisely to perform a wide variety of actions. I prefer an editor that treats the mouse like it's useful, rather than an add on that you can enable with extensions if desired.
Go figure.
Roguelikes, UT, Doom, Quake , and the like from my past pushed me more than anything into learning and loving emacs keyboard bindings.
No other way to experience that sort of speed-of-thought and precision in a UI/UX for me, and certain actions within emacs very much remind me of muscle-twitch maneuvers like rocket-jumping, bunnyhopping, or reload-canceling.
I can see where you're coming from when it comes to comfort with the mouse, though I don't think you should emphasize it too much if you've never experienced some kind of "never leave the keyboard" system that you're fluent in. It may or may not be faster than a mouse, but it's faaaaar more precise and for me feels very satisfying in a tactile sense.
Though in my experience, once you go all in, you start trying to get it to work on everything; in my case that means vim keybindings for everything, including web browser, and it can be a bit jarring to give it up when you use someone else's computer.
yeah, i recently downloaded intellij idea for the first time (i generally eschew IDEs) to try my hand at kotlin, and when the "use vim keybindings? " option popped up during setup i was like "(very satisfied and refreshed) ahhhh..." works well too for a slim .vimrc user like myself.
I'm always confused as a 30 year emacs user, in which "Normal mode" is insert mode as it is in every other text editor/word processor. Vi[m] is backwards in comparison and while clearly it's possible to learn it to the point it makes sense, I think for people who use it only occasionally it's very awkward.
I had a rather long argument with someone who can't stand vim and his points were mostly salient. Vim comes with a lot of baggage (or features, depending on how you look at it) from having been designed before Windows and the assorted userland became the dominant platform. Because of that, its shortcuts aren't CUA-compliant [1]. And that is just scratching the surface. Vim and Emacs are written by people who expect them to behave like Vim and Emacs, not like Sublime or any other "standard" application with a "standard" interface and shortcuts. You can definitely fight their design and rebind your keys to work as you expect, but through it all you're fighting decades of entrenched design. Those editors aren't maintained by people who think like you, so you'll always be a second citizen. Micro isn't for people who like Vim, micro is for people who want their editor to work in the expected mainstream fashion.
I think GNU nano should probably also have a commandline switch to behave like a normal CUA-compliant editor and distros should have that enabled by default. It isn't compatible with anything but pico and someone who grew up with today's machines would have never seen pico.
On the other hand, I would guess it's not just the maintainers being entrenched: If you were to redefine something like C-v to perform "+p by default, you would upset every guy that has been using Vim for some time. Not only that, but you would also really ruin the day for everyone that regularly uses it through SSH and counts on Vim's default behavior. I would guess the reactions would be orders of magnitude more vile than those to, say, systemd.
So, leaving such rebindings as opt-in possibilities to newcomers seems like a much more sane decision to me.
Whenever I need nano I'm on a machine where installing stuff is cumbersome, so installing npm on top of it would be overkill. Better learn to use vim (I'm personally an emacs person, but with vim keybindings) and use it when needed.
Is this a joke? A command line text editor, written in JS and Node? The sad? "Slow on single cores, Raspberry Pi"
How low will the software development world stoop to?
Same here. That is, until I find out that only vi's there and not full-on vim. While vi is smaller and even more ubiquitous, it pains me that it lacks visual mode.
Visual mode is a crutch! I'm used to vi so I never use it. There are faster, more flexible ways of doing anything you'd do in visual mode with plain vi commands.
How do you compare two pieces of code side-by-side? I suppose you could create terminals and arrange then how you like but that's not much different than vim. I use gtk emacs with three frames arranged side-by-side on a 40" monitor. Not being able to compare code this way would really slow me down.
I use tmux. It works extremely well with vi. It's no problem at all to arrange 3 panes side by side in tmux. You're not even restricted to that, of course. You could be tailing a log file in one of the panes, reading a man page in another, and coding in the middle one.
With the substitute command and an appropriate range. This sort of operation is extremely rare, though, so it's not the sort of thing you worry about when you're using a limited environment that has vi with no ability to install vim.
Besides, it's far more common that you'd want to do an operation like this but the columns happen to be misaligned. Then you're reaching for substitute anyway. Might as well master the more flexible tool.
I wish this or a similar editor was written in a language like Nim. Then you could just compile it on an older version of CentOS, link statically, and cp it anywhere you need it. Or something that supports simple ./configure && make.
Some systems you can't install anything; they're locked down. So, knowing VIM and nano is very helpful. Actually, this is the major reason I never try other editors; I have to work with legacy, locked down systems (on occasion), so it is easier for me to just stay with one editor that I know.
How often are you in situations where you can't run the editor/IDE you want? I haven't encountered this for years except the rare times I'm forced to do some editing over SSH (which is far too low-level for server management than I'd like).
No need to pass -nw :) I usually install it in docker containers on servers. It's quite small (well, I think it's around 28M to install usually), since it's just an emacs built without gui support.
Poe's law: Without a winking smiley or other blatant display of humor, it is utterly impossible to parody a [software developer] in such a way that someone won't mistake for the genuine article.
I can definitely dig the thought behind multi-cursors, and I think the people downstream comparing the use case to regex is a little off. I think a better analogy in vim is macros, considering you could run a macro ripping through the results of a string search (which, sure, could be regex), but you could also use it for appending/prepending to lines and patterns, which is really useful in certain cases.
The ability to use multiple cursors is one of Sublime Text's defining features, so describing an editor as being Sublime-like without that feature is somewhat of a letdown.
Find and replace on steroids, meaning the flexibility of moving the cursors around in all instances of a find and making edits near the beginnings and ends of lines, for example.
Not trying to diminish the use of multiple cursors (I have certain fondness for them despite not using them extensively due to my choice of editor), but using regexes you can still do that (i.e. with /^/ and /$/, which I use constantly with vim-style search and replace)
Pressing ctrl-d a couple of times, seeing what will change, and typing something is most of the time easier and faster than thinking about a regex. At least that's how I feel
Yep, I can see that being easier depending on what you prefer, I just wanted to point out that the feature wasn't unique to multiple cursors, since it was being described as "find and replace on steroids".
Similar use to reg ex based find and replace but with less thought needed. Useful for those that prefer just editing rather than composing regular expressions.
I use ne for a terminal-based CUA editor right now, though this slap project looks promising.
sudo apt install ne
In the past I've used nano with some sane key bindings, but they would often be missing on remote machines. Ten+ years ago I built a turbovision work-alike from setedit.
I'm afraid that the node requirement and lack of Debian repo would rule it out in many situations, like remote editing. Too much work to get it installed on ephemeral boxes. Could someone start a project like this with C and Python plugins? I'd like to contribute.
Guess I'll stick with ne or sshfs and main editor for now.
A text editor that is slow on 1GHz single-core machines. What a time to be alive.