HN user

gcatlin

113 karma
Posts0
Comments16
View on HN
No posts found.
macOS Monterey 5 years ago

For those who are wondering what the config setting is:

Finder -> Preferences -> Advanced -> When performing search: Search the current folder

I don't want a general purpose tree editor. I want a general purpose text editor that understands the semantics of the text I'm editing. One that understands all the various not-necessarily-sexp-based code I'm editing is a tree and supports (ParEdit style) operations on that tree. Especially with languages in the Algol/C family. I think this can be accomplished (eventually) via language servers and editors that speak the Language Server Protocol (LSP) [0].

But I don't need a UI oriented around visually displaying tree-like things. Expanding / collapsing nodes is very meh. Moving / splitting / joining nodes is much more interesting and useful.

As a simple concrete example: changing the order of the parameters (and their type) in a function definition. Wouldn't it be great to 'swap-with-prev-node' or 'swap-with-next-node' rather than copy/paste and dealing with commas? The same operations could swap the order of two fields in a struct or two functions or two classes or any pair of adjacent nodes in a tree.

Or how about moving an 'if' block inside the 'for' block that follows it? Just execute the 'move-node-inside-next-node' (or whatever) command.

This only requires editors that (indirectly) understand the semantics of the text you're editing. Thus far the biggest barrier is all wheel re-invention needed for the cartesian product of all editors and all languages. But that's the wrong approach. We need each language to provide a tool that each editor can use via a common protocol.

This is precisely the point of the LSP. The functionality only needs to be written once per language and per editor. This is totally tractable. I don't know if LSP currently supports the specific tree-manipulation functionality I mentioned, but I'm confident it could.

Does anyone knowledgeable about LSP know if this is already possible, feasible, and/or generally desirable? Are there deal breakers that make this hard / not worthwhile?

[0] http://langserver.org/

Getting Past C 10 years ago

I think that's why Stroustrup says "zero overhead" instead of "zero cost". There are costs to many of these abstractions; some at compile time and some at run time. For me, "zero overhead" conveys this a little better.