161–170 of 214 posts
Earlier quoted context omitted.
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.
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.
I generally use acme, but when I need to edit files on remote computers, I use sam. There's no better editor for that.
Earlier quoted context omitted.
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.
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.
This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. Which is exactly what a good tool should be. When IDEs (the kind that comes as a GUI'ed bundle of things thought to be the most appropriate for the purpose by committee of someones, somewhere) started becoming popu…
That's a really stupid requirement.
Earlier quoted context omitted.
...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 sup…
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.
This was how Unix was presented to me when I was first introduced to me. I was told it was like industrial machinery - designed for those who know how to use it, efficient, dangerous if you aren't careful. Which is exactly what a good tool should be. When IDEs (the kind that comes as a GUI'ed bundle of things thought to be the most appropriate for the purpose by committee of someones, somewhere) started becoming popu…
Neal Stephenson expressed this same idea very eloquently:
Earlier quoted context omitted.
The difference is IDEs understand the underlying structure of the code, including relationships between entities, symbol types in their context, indexes for searching, and so on. That allows you to express transforms that can't be expressed if everything is just a text stream. I can grab a chunk of a function in resharper and do an "extract method", and it can figure out data dependencies, or I can do a "find usages"…
The article mentioned ctags, which actually gets you quite far in this regard. Combined with CtrlP (a vim plugin) and the Silver Searcher, I navigate large codebases quite quickly. I do agree that full blown IDEs probably have better support for refactoring code, but so far the advantages of using vim/tmux/unix commands are much more valuable to me: - it's more natural for me to have a shell as a starting point and j…
Java does seem to be the big exception in that 1) it's so overly verbose it almost requires an IDE to handle all of the boilerplate, 2) has enough static typing to allow deterministic refactoring, 3) is popular enough to support massive IDE engineering efforts.
I use IntelliJ for Java (and sometimes Scala), and Emacs for pretty much everything else.
Earlier quoted context omitted.
There is nothing about text streams that prohibit tools from understanding whatever language you're writing in. Unless you have an very interesting compiler, your IDE is processing text, too. But also, you seem to believe that somehow communication between applications is somehow limited to pipes, which makes the comparison inapt. Ignoring the category error (text format in a data file vs. server application + storag…
I am not the parent you reply to, but see my previous reply for the capabilities you miss in 'dumb' editors. "here is nothing about a text streams that prohibit tools from understanding whatever language you're writing in" Well it might be true that you can deduce the language of some text stream but you need to make a big step in order to interpret it. You are talking about a compiler. Well a compiler takes a compil…
And at that point, it would be an IDE.
Earlier quoted context omitted.
Which tools do you know that will handle automatic refactoring in, say, java, from the command line? Genuinely curious, I've wanted something for this
gofmt is an example of a tool for refactoring on the command line. There isn't much demand for a similar tool for Java, but I have no doubt that a few months of effort could build one out of Eclipse. Its startup time probably wouldn't be great though. We already have eclim, that treats Eclipse as a daemon serving refactoring APIs to clients, to mitigate the configuration and startup problems.
What empirical evidence do you have for this?
At one point I looked very hard for good Java tools for Unix and/or Emacs, and found nothing. I imagine many others have done similar investigations and came up empty.
So I think its an open question whether Java refactoring tools for Unix don't exist because there is no demand, or whether there are engineering and productivity reasons why such tools work better as part of an IDE.
(I will say, though, the existence of similar command line tools for Go indicate similar tools might be possible for Java, also. Or maybe this is just due to Go being designed to be easy to parse?)
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…