Comment by silentbicycle | Hacker News Reader

Comment by silentbicycle | Hacker News Reader

Parent Full thread

Contextual refactoring isn't present in vi because vi was meant to be used in conjunction with the Unix shell, pipes, and so on. It's not a full environment unto itself the way Emacs is. Search, refactoring, and the like would be handled by shell scripts, awk, perl, parsers made with lex & yacc, etc. Unix itself IS an integrated development environment!

There are lots of plugins for vim, but I'm not up on what would be specifically relevant because I do major editing in Emacs. (Also, I think when most developers need that kind of tool support to use a language it speaks volumes about it, but that's me.)

I like Emacs's extensibility and multi-buffer design, but prefer vi's modal keyboard interface. I like its brevity and orthogonality. Number of commands is less important when each combines cleanly with the others. I would love to see a synthesis of the strong parts of vi and Emacs, though I don't expect it to ever happen - Emacs's giant bundle of elisp has way too much inertia for a full rewrite.

How useful are IntelliJ and Resharper for (say) Erlang, by the way? While I haven't used either, those editors look like they're more tightly focused on Java and C#, whereas vi is for editing any kind of text, and Emacs has had at least passible support for every language I've ever used (except Joy). Comparing vi to an editor specifically designed for Java is a bit misleading.

Refactoring could be handled by perl, awk, in theory. Or you could, in theory, right a parser to do it. But I don't know of anyone who has. A simple search and replace, on a big code base simply isn't going to work. You want to add a parameter to a method on class Foo, when 20 other classes have that same method name? What about when Foo is an interface, and you have to do it for the 10 classes with that method name that implement Foo, but not the 50 that dont?

  m.foo( bar baz);

Does this foo need to be changed? You can't know without knowing what type 'm' is. Good luck writing an awk script for that. This isn't a debate about whether or not it could be done. Its about whether or not you can do it faster than I type Ctrl-F6.

If such a tool exists that I can run from bash, please let me know. Otherwise you guys have advanced from type-writer to the early dedicated word-processors that existed in the 80s, but no further.

Jetbrains have refactoring tools for C#, Java, Javascript, Python, Ruby, PHP, Adobe Flex, as well as "basic" language support for most others (but no Erlang I'm afraid).

As you say, vi is about editing text. But the author is a member of the Ruby on Rails core team and a core contributor to Ruby projects, and I put it to you that most people using vim dont use it to edit just text: they edit text that happens to be a language with a formal grammar, and structure both with the file, and outside it: i.e. contextual. Hence, a good IDE will always be better than vim.

I also dispute the idea that, given a new language, vim will be better at editing it. My IDE will likely be able to do exactly the same things vim can do, using the keyboard only, and with (on average) the same number of clicks. However, the IDE will most likely be intuitive, obvious, and easy to learn (e.g. by giving visual feedback), meaning that in reality, even though vim could do as much as my IDE for an expert user, for the average user it wont and never will.

Also, I agree that trying to refactor (say) C++ with awk would be hopelessly quixotic. I'm not an idiot. (I have written parsing and static analysis tools for an in-house language, though, just not one as screwed up as C++.) I was explaining the historical reason for vi lacking such features - grammatically ambiguous, overloading-heavy languages that combine static typing with OOP hadn't been invented yet.

I think it's bad design to have refactoring tools be a part of the editor, proper, rather than as a standalone tool the editor calls. It's more a matter of static analysis (or runtime introspection) issue than editing per se.

As someone about to open-source something that does Java refactoring from the command-line (as a small part of a larger research project related to optimisation) I feel like I ought to respond. :)

You make a good point about refactoring. It's useful, and I should do it more. But this comment goes a bit too far:

> [people edit projects, not text, therefore] a good IDE will always be better than vim

This is an unassailable assertion. If anybody manages to come up with an example in which Vim is better than an IDE, it is always possible to respond with "that's not a good IDE", possibly with qualifications ("you shouldn't be editing Java in that IDE").

One possible response goes to the definition of "better": I contend that Vim is, in fact, a better environment for creating, debugging, and generally editing files. This is actually a large part of what I do, so I appreciate it. I have been using Eclipse quite a bit recently, because it's the standard IDE for Android app development, and while it provides some great refactoring tools, it is not nearly as good as Vim is for actually editing code. I don't really understand what you mean w.r.t. "formal grammar": even Vim and Emacs can be trained to do things that rely on language-specific syntactic knowledge (examples: code completion, code folding, context-specific search). What's missing in non-IDE editors is a concept of a "project", and semantic knowledge for refactoring. That is not the same as grammar.

A command line java refactoring tool? That would be cool. Is it possible to extend it to other languages? Do you have a link - even if its to a "coming soon" page?

Let me reduce "good ide" to IntelliJ or Eclipse if that helps.

By "formal grammar" I mean that both Eclipse and IntelliJ have full Java parsers. So they can successfully rename a method on an interface, all its implementations and all its uses. This can be done if and only if the tool can correctly identify which text symbols represent a class, interface, variable declaration and method invocation, and further it can infer the type the variable in a method invocation using information from that variables declaration, even though it may be in another file.

That needs a parser. So you are correct in that you don't have to write a formal grammar to do it. You can hand role your parser. I used "formal grammar" to imply a level of complexity. Does vim have a tool of such complexity?

Reply on news.ycombinator.com