http://lighttable.com/2012/04/12/light-table-a-new-ide-conce...

I have looked into this. It is kind of criminal that for most real world languages (Ruby[1], C[2] etc), it's not possible to just define a grammar and throw it at a standard parser generator for them - they generally have one or two quirks which make this infeasible.

In my ideal alternate universe it would be considered unthinkable to publish a language without also publishing a grammar in a standard format for said language, which can then be plugged into your favourite text/semantic/tree editor. Our tools should dictate our languages, not the other way around.

[1] http://programmingisterrible.com/post/42432568185/how-to-par...

[2] https://en.wikipedia.org/wiki/The_lexer_hack

[1] Mainly due to begin..end blocks, curly braces or indentation (as in Python)

My days of fiddling with writing parsers are long ago (https://www.codeproject.com/Articles/7035/A-Java-Language-ID...) but if I remember correctly most languages aim for at most a LL(2) grammar, meaning they are designed so the parser doesn't have to peek more than two tokens ahead before being able to make a correct determination.

a * b;

Is either: a times b if a is a var, or declare a varible b with type a. If a is a typedef.

Also:

some_type b = {a, b, c, d};

Is only valid if some_type is an array or a struct. Which is possibly defined elsewhere in the source.

(I tend to see this syntax in some code bases (some_type) { a, b, c, d }, which is a bit better).

CPP (Pre-processor) aside, C is not context free due to typedef making identifiers ambiguous. Also if-then-else? Since C++ templates are turing-complete, the grammar is probably unrestricted.

Python is not context free due to

    if ...:
        stmt1
        if ...:
           stmt2
        stmt3

It was kind of neat, but also led to a lot of clicking around. It's one of those Holy Grail ideas people have been talking about forever, but I'm not convinced it's actually that superior given all of the ecosystem downsides there are to moving away from text.

I think you probably could do something better than text files, but it has to be a lot better to get over the chasm of losing all of your familiar editors, command line text utilities like grep, easy copy/paste, etc.

Text is a lowest common denominator medium. People get hung up on the "lowest" part, but the "common" part is pretty damn convenient.

http://graydon2.dreamwidth.org/193447.html

https://news.ycombinator.com/item?id=8451271

Maybe not, but I have a hard time to believe that it can be considered even a slight annoyance to anyone but people just learning how to program. The same people that are annoyed by it probably benefits from it anyway, forces them to actually think about what they are doing.

Also makes it easier to get an overview of the code using just a text editor. KISS.

Slight annoyances pile up. Ergonomics matter even for seasoned pros. Just because they have learned to ignore the garbage, doesn't mean their room is clean.

And human factors matter. In the context of language design, they're the only things that matter - the entire function of a programming language is to make a complicated task fit a human brain as neatly as possible.

Disagree.

The usability engineering of old-school VB (of which VBA is the modern representative) was frankly top-notch, and I feel no shame following their footsteps in the https://anvil.works code editor.

But as to the single feature you mentioned, see for example Code Bubbles:

https://www.youtube.com/watch?v=PsPX0nElJ0k