Hacker News Reader

Comment by qwertyuiop924 | Hacker News Reader

>But I think that trying to shoehorn Vim or Emacs into becoming something that it’s not isn’t quite thinking about the problem in the right way.

...Well, this is clearly a Vim user. If you're never leaving Emacs, and you're writing plugins to do everything inside it, you're using Emacs exactly as intended.

View on HN

http://blog.vivekhaldar.com/post/3996068979/the-levels-of-em...

"It was all just text. Why did you need another application for it? Why should only the shell prompt be editable? Why can’t I move my cursor up a few lines to where the last command spewed out its results? All these problems simply disappear when your shell (or shells) simply becomes another Emacs buffer, upon which all of the text manipulation power of Emacs can be brought to bear."

This is Atom's great failing: it's trying to do the emacs thing, but it doesn't treat all buffers uniformly: your settings window, your terminal window, and the various text windows are fundamentally different. Until this is fixed, it's not even in the running as a usable editor for me.

> This is Atom's great failing: it's trying to do the emacs thing, but it doesn't treat all buffers uniformly

That's definitely a great failing, but I think it has two greater still: not being written in Lisp, and being written in JavaScript.

The former could be overcome (Alpha was an amazing editor for the Mac written in TCL), and after all there are plenty of great programmes not written in Lisp (emacs, for example, has a C core …).

But JavaScript‽ JavaScript: there's got to be a better way. JavaScript: warn your friends about it. JavaScript: dissatisfaction guaranteed.

JS is fine. It's got warts, yes, but so has elisp. It's also got proper lexical scoping, and real, function-equivalent lambdas, which are surprisingly rare.

This is of course such a transparently good idea that Acme and 9term adopted it too.

I was never as much a fan of Acme. It was a neat idea, but I don't think it was executed as well as Emacs was. And it doesn't work super well outside plan9. And I need to edit over SSH a lot. And keyboard > mouse, IMHO.

> And I need to edit over SSH a lot.

Try sshfs :) Surprising that someone who has tried Plan 9 hasn't come to love specialized filesystems!

I would, but in the locations I'm in, the only computer I can access is my school chromebook: no X. :-(

sshfs doesn't require X...? It's just a filesystem.

No, but Acme/Sam ports do. And emacs, vim, and sam and acme ports all require a POSIX api which the chromebook lacks.

Not all ports of Acme/Sam require X.

The mouse is pretty inherent to both designs. What TUI version of acme are you talking about? Because AFAIK, none exist.

The macOS, Plan 9, Windows and Inferno versions of acme do not require X.

...And were you not listening to the point which started this discussion, which is that I do most of my development on a Chromebook, and all that has is SSH.

It doesn't have vnc or similar screen-sharing functionality?

Yeah, but the SSH connection is slow enough as it is. VNC would be quite unpleasant. Also, this is laptop, so I've got a touchpad. Not the best thing for Acme.

I use Acme on and off. I will never be as productive with it as I am with Emacs (I depend way too much on autocompletion, contextual text wrapping, org-mode and magit), but the philosophy appeals to me.

UNIX as an IDE never truly made sense until I discovered Acme. It was truly a zen-like experience.

I generally use acme, but when I need to edit files on remote computers, I use sam. There's no better editor for that.

...until you're doing remote dev work, especially in Lisp, and need a repl, autoindent, or any other feature that Sam doesn't have. Given, it's an uncommon need, but one that I have every day.

> remote dev work

Not sure what you mean, I do remote development all the time.

> and need a repl

Why do you need a lisp repl in sam? The unix shell is a repl too, and I use it in a separate terminal, which talks to sam via the Plan 9 plumber.

I use multiple terminals and sometimes even multiple sam instances, and I consider this a big plus, rather than doing everything through a single program.

> autoindent

Sam supports autoindent just fine. But perhaps you mean some other form of "smart" indent though.

You're right that sam (and acme) don't have features. The functionality comes from programs interacting with each other through the plumber or some other method.

I was not aware that Sam had as many hooks as acme. If sam can send text to the terminal, than that's alright, I guess. But if you can't send program text to the interpreter...

As I'm running a Unix (Linux, at present), I really don't have the full power of the plumber at my disposal.

As for autoindent, I was talking about Lisp code, which most autoindenters don't indent properly. This is one of several reasons that the original vi had a dedicated mode for editing lisp code. Yes, really. You can look it up.

Anyways, I'm an emacs user. Saying we do everything through one program is like saying that every Smalltalk program is the same: we do everything through one VM. It's not as elegant, true, but it works right now. And outside of plan 9, acme and sam are a little hit and miss by comparison.

Does emacs support sam's structural regular expressions language?

Not AFAIK. Care to write it?

Actually it was done in 1993. https://github.com/bvito/misc/blob/master/sam.el

Oh, hey. Neat.

For pointing to a location in 2-dimensions, a mouse is hard to beat with a keyboard; when locating a point on a map to someone, do you say "Start at the bottom left, then up two inches and over four inches to the right" or do you just point?

For inputting and manipulating a set of characters, the keyboard is hard to beat. And it works well enough for navigation.

Well no one is suggesting that you'd input characters any other way, and acme supports sam's structural regular expression command language for keyboard-based editing; so acme supports the keyboard features you're looking for and also has, as you've admitted, better navigation, via the mouse. I suggest you give acme (and/or sam) another try without the prevailing pro-keyboard bias of those people commenting on HN.

Doing a lot of switching between keyboard and mouse will slow you down, IMHO. But that's just me. You're free to have your opinion.

But as I've asked elsewhere, does acme have the ability to send text to an external repl on systems other than plan9 (a continuously running one, not a freshly-spawned one), preferably one running in another terminal window? Does it have indentation for Lisp? does it have syntax highlighting (not necessary, but handy)? does it have colorscheme customization (you'd be surprised how many programs generate illegible text in white-on-black terminals, and I've become quite fond of Solarized)? Can it look up documentation for the functions I'm using (very handy at times)?

I've got the tools I'm used to, and they provide things that Acme never will for me. Maybe I'm not experiencing ultimate Unix Philosophy Zen. Maybe using the mouse is a bit more efficient. But at the end of the day, I'm here to edit text, and Emacs works in my environment, and has some pretty good tools for that.

But my opinion regarding the mouse being faster is supported by research; the opinion that the keyboard is faster or that context switching slows you down is factually incorrect.

http://plan9.bell-labs.com/wiki/plan9/mouse_vs._keyboard/ind...

Okay. First off, I can use the mouse with Emacs in most contexts. Second off, the time I'm wasting may well be more than the time I'm gaining from all the features I use that Acme doesn't have. Finally, I use my editor over SSH a lot, so Acme is a non-option for me, even if it is so unbelievably brilliant (it isn't).

xiki

Not the same thing at all.

I vaguely remember the C64 had something like this. You could move the cursor up to an old line, modify the line, then press RETURN to run it. Mind you I was like 8 years old.

Yeah, emacs would be a great operating system, if only it came with a decent text editor.

(ducks)

Someone fixed that. My emacs came with good modal editing out of the box. Maybe your emacs is broken. Try spacemacs.org.

(runs)

And if you don't want to deal with hellish complexity, and have a DIY mindset, you can grab evil, and build the modal system you want.

(dodges)

Spacemacs is a whole bunch of things, nobody needs it for a simple (evil-mode +1) (not that I call it useless, but Vi emulation is part of base Emacs).

Modal? I want composable.

With evil-mode, which is what spacemacs is based on, you get it.

Interesting. Does it have text objects?

While I don't know if it has programmable text objects, it does have the standard Vim ones from what I've seen last time I tried it.

Just checked the docs: Not only does it include text objects, you can write your own, if you don't mind getting your hands dirty with some elisp.

Yes. It includes most of the standard vim text objects, as well as providing an api for you to write your own. It also has the usual motions, plus an api to add your own. There are existing extensions for the more common vim plugin-provided motions as well.

I bet Emacs has a plugin that makes it like Vim, so Emacs is not that bad.

:-)

Of course it does! :).

Multiple.

Evil mode: it's the basis of spacemacs. If you don't want the complexity of spacemacs and you don't mind writing a bit of elisp to get your bindings working, it's worth looking at.

Am I missing something here? That's like an asthma drug whose side effect is shortness of breath.

You're missing something. Spacemacs defines a lot of keybindings for many plugins and so on. Evil only defines the basic Vim keybindings. If you want more, you have to write it yourself.

Reply on news.ycombinator.com