3 ms·

Isn't this really just clever syntax highlighting? Emacs, for instance, can already draw boxes around things. I spent about 5 minutes and got close[1]. If you h

Isn't this really just clever syntax highlighting? Emacs, for instance, can already draw boxes around things. I spent about 5 minutes and got close[1]. If you had something like "pretty-symbols" installed [2] then you could probably make the quotes characters themselves not even show up at all. You could probably also do it with some font-lock code. If it's more than syntax highlighting, then how do you make the "quoted" text? What keypress to you use to start and end the markup that signifies quotes? Maybe the quote key ;-)? [1] http://i.imgur.com/BNO5fNJ.png http://i.imgur.com/BNO5fNJ.png [2] https://github.com/drothlis/pretty-symbols https://github.com/drothlis/pretty-symbols

mjburgess 12y ago
It's the opposite of syntax highlighting, it's highlighting which is syntax.
- __david__ 12y ago
  I guess I'm saying I don't see the distinction. How would you store that highlighting to disk?
  - tobr 12y ago
    In a .pdf? In seriousness, I think this kind of extreme highlighting could be an important step in making programming more accessible. There are only so many characters like ,;:.()[]{}<> available to use in code, and often most of them indicate completely different things in different places. Done the right way, and combined with live evaluation á la Bret Victor or the Swift playground, I think this has the potential to be the next paradigm of accessible programming, after Excel.
nichochar 12y ago
I agree with this (the second part). You HAVE to somehow make that string a string. So maybe you will only hit one key rather than 2 (quote, and quote again), but honestly you have macros that allow you to hit it only once. I think one big part of all of this is speed of execution: both maximum speed, but also the learning curve. And I'm not at all sure that we can do better than typing text. Hell we've been trying to get rid of the keyboard for years, and yet nothing is faster than a VIM ninja
leni536 12y ago
If the source file format for the language is not stored as plain text but it's already in a tree like file format then no, it's not just syntax highlighting but the natural way to handle this file. I could imagine a source file format where the nodes have different types for different literals. There would be much less parsing problem than parsing plain text, of course it would need a special editor.
- __david__ 12y ago
  Already in a tree format like lisp? Or some binary structure? Even if it's some fancy binary format, it's still going to have to be parsed by the compiler and the editor (and thoroughly checked for syntax errors), making it no better than what we already have now (just different). And unless those node types are "green round-rectangle", then I posit that it's still syntax highlighting, since the editor is deciding how to display "string node".
  - zeckalpha 12y ago
    Or JSON. Images could be even be embedded using base64.
  - ksrm 12y ago
    Wouldn't storing and editing source code as an AST make a lot of syntax errors impossible?
    - __david__ 12y ago
      User-created syntax errors, possibly. But it can't completely eliminate them: 5 ↤ "hello" Now you could argue that the editor might detect that and not allow it, but if your abstract syntax tree data structure can support it, then you will be handed it at some point and so you should detect it. But more importantly, the abstract tree itself has to be stored. Whatever the format (binary or otherwise), that has to be checked, too (unless you want buffer overflows or code execution exploits in your compiler/editor). All in all, it sounds like the same stuff compilers already have to deal with, so I don't think it wouldn't be a win there.

mjburgess 12y ago

It's the opposite of syntax highlighting, it's highlighting which is syntax.

__david__ 12y ago
I guess I'm saying I don't see the distinction. How would you store that highlighting to disk?
- tobr 12y ago
  In a .pdf? In seriousness, I think this kind of extreme highlighting could be an important step in making programming more accessible. There are only so many characters like ,;:.()[]{}<> available to use in code, and often most of them indicate completely different things in different places. Done the right way, and combined with live evaluation á la Bret Victor or the Swift playground, I think this has the potential to be the next paradigm of accessible programming, after Excel.

nichochar 12y ago

I agree with this (the second part). You HAVE to somehow make that string a string. So maybe you will only hit one key rather than 2 (quote, and quote again), but honestly you have macros that allow you to hit it only once. I think one big part of all of this is speed of execution: both maximum speed, but also the learning curve. And I'm not at all sure that we can do better than typing text. Hell we've been trying to get rid of the keyboard for years, and yet nothing is faster than a VIM ninja

leni536 12y ago

If the source file format for the language is not stored as plain text but it's already in a tree like file format then no, it's not just syntax highlighting but the natural way to handle this file. I could imagine a source file format where the nodes have different types for different literals. There would be much less parsing problem than parsing plain text, of course it would need a special editor.

__david__ 12y ago
Already in a tree format like lisp? Or some binary structure? Even if it's some fancy binary format, it's still going to have to be parsed by the compiler and the editor (and thoroughly checked for syntax errors), making it no better than what we already have now (just different). And unless those node types are "green round-rectangle", then I posit that it's still syntax highlighting, since the editor is deciding how to display "string node".
- zeckalpha 12y ago
  Or JSON. Images could be even be embedded using base64.
- ksrm 12y ago
  Wouldn't storing and editing source code as an AST make a lot of syntax errors impossible?
  - __david__ 12y ago
    User-created syntax errors, possibly. But it can't completely eliminate them: 5 ↤ "hello" Now you could argue that the editor might detect that and not allow it, but if your abstract syntax tree data structure can support it, then you will be handed it at some point and so you should detect it. But more importantly, the abstract tree itself has to be stored. Whatever the format (binary or otherwise), that has to be checked, too (unless you want buffer overflows or code execution exploits in your compiler/editor). All in all, it sounds like the same stuff compilers already have to deal with, so I don't think it wouldn't be a win there.