Live data from Hacker News

Unix as IDE

sanctum.geek.nz

181–190 of 214 posts

Re: Unix as IDE

#181

Earlier quoted context omitted.

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.

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?

Re: Unix as IDE

#183
post #163

Earlier quoted context omitted.

> 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 sup…

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…

Does emacs support sam's structural regular expressions language?

Re: Unix as IDE

#184

Earlier quoted context omitted.

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…

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.

Re: Unix as IDE

#185
post #181

Earlier quoted context omitted.

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.

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.

Re: Unix as IDE

#186
post #182

Earlier quoted context omitted.

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.

Re: Unix as IDE

#187
post #184

Earlier quoted context omitted.

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…

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.

Re: Unix as IDE

#188
post #183

Earlier quoted context omitted.

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…

Does emacs support sam's structural regular expressions language?

Not AFAIK. Care to write it?

Re: Unix as IDE

#189

Earlier quoted context omitted.

The I is Emacs. It adds a heapload of tools on top of what's already there, integrates what is already there, and is a frankly awesome enviroment. It has most of what you described, but it starts faster than an IDE, and is generally better: I don't think and IDE will be beating Paredit and Slime/Geiser, or JS2, or gdb-mode, any time soon. Not to mention, compared to most IDEs, Emacs is trivial to extend. You know tho…

I've used emacs for years. I've invested a great deal of time in learning it. I'm not sure it was worth it. When I think about the opportunity cost involved in internalizing the kb shortcuts, apis, tuning emacs configs, getting various plugins working together, setting up this or that language support - and on and on - that time could have been better spent learning more useful things. This feeling is especially stro…

Difference is fitting the tool to your likes or fitting your likes to the tool. Some people prefer one of those, some prefer the other.

Re: Unix as IDE

#190
post #181

Earlier quoted context omitted.

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.
Post reply on HN