Hacker News Reader

Comment by drdaeman | Hacker News Reader

Sorry for negativity, but is it really a code editor or yet another notepad clone with syntax highlighting? There are too many of the latter and almost none of the former.

I believe code editor to be called one must be designed to work with the code and provide standard facilities to manipulate upon it. The rest is for particular language support module that'd recognize semantics and do the transformations.

For example, the very core must have option to bind language module-provided semantics data to text fragments, so, say, highlighter (a proper one, not a TextMate-like mess of regexps) would base its work upon knowing not only "syntax regexp says this is a variable" but "semantic analyzer says this is a variable `foo`, and it's also used here and there, too (but not there, it's another scope), if that matters", while remaining generic.

(Edited: minor re-formatting)

View on HN

This rant is a bit unfair, by your definition the only true code editors are big IDEs like Eclipse, Visual Studio or slim for emacs, and then only for a tiny subset of languages.

Most of us right now are probably writing code in "notepad clones" by your standards. I'm sure there is room for one more.

That being said, while reading the "Why Zed?" page[1] I kept thinking "emacs can already do that" all the way.

Well at least kudos for going open source, I wouldn't even consider investing time learning to use a closed source text editor, it's too important a tool to depend on the whims of the devs.

[1] http://zedapp.org/vision

  That being said, while reading the "Why Zed?" page[1] I   kept thinking "emacs can already do that" all the way.

IMHO people who think "emacs can already do that" will think that regardless of what the topic being discussed is.

"Oh here ... I have made a plane that flies"

"emacs can already do that"

classic.

That's because emacs can already do anything, if you're willing to learn how. Still though, it's not a very useful thing to say.

That wasn't my point really. Of course emacs lisp is turing complete so yeah, you could probably pilot an airplaine using an emacs AI, it's still pretty far fetched though.

On the other hand the features described in the page I linked are mostly already built into emacs, at most you need to flip a couple customization switches to get the same idea.

Basically: remove the toolbars, enable ido-mode, use tramp for remote editing. The splitting thing is built in although you'll need to redefine a couple functions to get the exact behaviour shown in the gif (nothing very fancy though).

I'm inclined to agree with the OP. There is huge power in having a semantic IDE. Many old timers will say that Smalltalk is the most productive language they ever developed in, precisely because of the power of its semantic IDE.

Just a few things you get cheaply when your IDE is semantic aware: - Complex refactorings with a single keystroke - Context aware code completion - Instant feedback on potential compilation errors/type errors

You can sort of hack these things into something not semantic aware, but it's not quite the same thing.

There is plenty of room for competition. Everyone has their own needs and wants for a code editor and I would disagree with your definition. In general I want my code editor to be simple rather than try to be smart; be fast, do basic syntax highlighting, provide nice search.

+1 on the search part. I think Sublime shines there. I cannot imagine spending $70 for an editor, but I would really like it if Emacs' code browsing was as smooth as sublime's @

Curious, how do you browse code in Sublime that you can't in emacs? I've seen coworkers using Sublime navigate code much the same as I do in emacs which is mostly just by using incremental search.

I use Emacs at home and ST2 at work, and there are two things that ST2 does much, much better, both related to browsing large projects. One is scrolling - Emacs always wants to jump too many lines at a time, so it's very difficult to get lines of code exactly where you want them. The other is tree navigation - speedbar is more powerful, but you can't see multiple directories at once, which makes it hard to get a feel for the structure of the project as a whole.

Many times, I find myself just 'C-s' or 'C-r' (searching) in Emacs to the piece of code I want, even if it's already visible, then doing 'C-l' to get it centered. And when org-mode is loaded, 'C-l' will cycle through making the current line vertically centered, top of buffer, and bottom of buffer. Not sure it's what you're looking for, but that's what I do, and I'm sure there's a way to customize how far emacs will scroll ('M-x customize-variable RET scroll TAB TAB' might be a good starting point for looking into this).

I also mostly navigate using C-s and C-r. Also, when you do that you can recursively use C-u C-SPACE which brings you back to where you were previously, this feature is really awesome, since most of the time you move in the code temporarily to adjust something somewhere else or even just to lookup something somewhere else.

WRT scrolling, this is what I use in my .emacs:

    (setq scroll-margin 0
      scroll-conservatively 100000
      scroll-preserve-screen-position 1)
    (setq mouse-wheel-scroll-amount '(3 ((shift) . 1))) ;; one line at a time
    (setq mouse-wheel-progressive-speed nil) ;; don't accelerate scrolling
    (setq mouse-wheel-follow-mouse 't)
    ;; scroll window under mouse
    (setq scroll-step 1)

I dislike accelerated scrolling and use searches or registers for moving in big files, so this works quite nicely for me.

I was specifically talking about C-r file@function_name All the parts are fuzzy. So if I wanted to go to function install_local_package in helper_functions.py, I can type C-r h_fu@ins_l_p (pretty much like we use ido)

While I use Emacs for all my editing, this would have been cool to have.

While I understand that it is useful to have semantic information (nothing stops Zed from having it from what I can see in its mode files which use ace-editor's modes currently), I don't really think a code-editor needs to come with semantic information for all languages it supports. I don't know if that is even possible in a generic way. I mean, the behaviour of scope itself isn't generic. There are dynamic-scoped languages (like elisp) vs block-scoped languages (Java) vs function-scoped languages (JavaScript) which are all syntax-highlighted by most popular editors. I would relegate such work to heavier IDEs.

Well, my point is not that multi-language code editor must provide semantic information for every language it can edit (that's just infeasible), but that editor's core must be designed with semantics in mind.

I.e., not "well, it's text and core has no idea what it is but plugins are free to do anything with that", but "well, core has no idea what that 'typeclass' thingy code analyzer says it is, but it's happy to keep track of it and provide standard interfaces to use this info so maybe highlighter or code folding parts would figure out how to use that information"

Then you could start with regexp mess-based parser that provides very basic understanding of the code and replace it with something that gives better code insight at later time, without rewriting the rest. And have generic refactoring module that can operate on many languages just by knowing about names and their possible scopes (whatever scoping type language is, in common cases I believe that still could be reduced to "in this text region").

You nailed it. Do you know of any editors which work this way, except emacs?

Unfortunately, not many.

I've heard LightTable is doing something like this, but never had a time to properly evaluate it and see for myself.

Also, JetBrains' IDEs (IntelliJ IDEA, PyCharm, etc.) are notorious to have good understanding of code semantics, both out of the box and through plugin system.

It seems to have at least autocompletion and ctags support. Not really something for me, but best of luck to the author.

Reply on news.ycombinator.com