There are editors that parse the text they display according to the grammar of a programming language of some sort (C, C++, Java, SGML, ...), and that then display different syntactical elements of the language in different colors. For example, in certain versions of vi I use all my numbers are red, all keywords are grey, and so on.

Some languages don't lend themselves to this. When programming in m4 or (I think) in TCL, one frequently uses big chunks of code that are strings while one writes them; later on, the outside quotes get stripped, and the text inside becomes active as code; the piece that was just the letters 'i' and 'f' now is an if statement, and so on.

For those languages, I wish I had a syntax-aware editor that displays quotedness as haze. If it's right there and active, it's red; if it's a keyword after one layer of quotes has been stripped, it's a little bluer and darker; and so on to a distant grey haze that might, or might not, one day become a keyword.
-- jutta, Nov 30 2001

I understand what you're talking about [jutta] (or at least I think I do).

Visual FoxPro has this code mark-up capability (minus your idea, of course). The problem (if I understand what you're saying) is differentiating between what's a string and what's a property / method / procedure while in the IDE. (Once the code is compiled, it makes no difference)

One way to fix this might be to make a more intelligent IDE that recogizes objects and object references prior to runtime (or compiling). 'Course the IDE would automatically insert those missing parens and semicolons as well as resolve all nesting errors.
-- phoenix, Nov 30 2001


If I understand this correctly, I might want the haze-markup while I was debugging, but not while I was editing. Some coloring to distinguish quoting levels would be nice, but if I were actually writing the 'deeper' strings, not being able to see them would be too irritating.

If they came back into focus as soon as editing focus moved into them, that might work, or it might be really confusing.

Oo! In the debugger I'd also like to be able to distinguish code that was dynamically generated by some 'shallower' layer from code I'd put in as exact strings. Seems to me it would require a perfectly enormous debugger, though.
-- hello_c, Nov 30 2001


I thought you'd decided that color coding text on a continuous scale doesn't work.

LISP has the same "problem" with data/code mixing (it's usually described as a feature), and could presumably benefit from something similar. The common denominator is lists rather than character strings, of course.

Thing is, both LISP and M4 (but not Tcl so much) encourage you to create your own little microlanguages with their own syntax. It's not so much that data may be quoted code, but that it's quoted code in a different but related language. If the editor could somehow see through the transformation to do the appropriate thing (highlight M4 macro invocations?)...

<snarky> Alternatively, we could just take all these "yay, eval is so much fun!" languages out back and shoot them. Also, we could redesign transport agents whose configuration files require extensive macro preprocessing for humans to be able to work with them. But that's tangential. </snarky>
-- egnor, Nov 30 2001


Thinking about TCL, can you actually know for sure if something is going to be used as a keyword or a string literal? I don't think so, not without running a program. I guess the haziness would reflect this confusion (and my confusion about TCL -- amazing what you can forget in 3 months).

(Incidentally, given code for a syntax colouring editor, I reckon you could add this feature with about 30 lines of code, since you'll already have identified all the entities, and just need to colour them differently.)
-- pottedstu, Dec 01 2001


That would be interesting, too. (It doesn't have to be a 3D monitor, you could just render it.) It would have the advantage that you could fly into nested expressions and have a closer look at the stuff that seemed hazy at first.

I didn't really think of the haze as something that makes text fuzzy, more as guidance for the color scheme. Clearly, it shouldn't be so bad as to be in any way illegible.

As [pottedstu] points out, this isn't always a clear decision; you can't tell in advance whether something will be evaluated, or what the actual evaluated text will be.
-- jutta, Dec 01 2001


But the fact that it might be is useful information.
-- phoenix, Dec 01 2001


Possible to render your text with a widget that displays active code in thumbnails at screenside? The use of nesting quotes would then become superfluous, although continually challenging.
-- reensure, Dec 01 2001


I awfully like the 3-D rendering slant. The deeper you go, the (erm) deeper you go. Build it with skins so that you can view your code on Mars or 30 fathoms down (ie deeper levels recede into Martian landscape or blue-mottled depths) and you've got my ticket.
-- Dog Ed, Dec 02 2001


Here from random. While I have never used those languages, this sounds like it would be useful.

However, when I first saw the title, I thought it was something completely different. I thought it was for quoting what a person said before you in email or forum posts. The more deeply nested quotes would be blurred, because you're usually replying directly to the less deeply nested quotes.
-- notexactly, Mar 31 2017


Probably in an AI, the keyword and String literal determination will be at the current processing step and the run time assembler will be able to reconcile unclosed sections of code. Steps on the way to cognitive dissonance.

<tongue in cheek> Writing messier code might even give depth of character. Truly hazier code. </tongue in cheek>
-- wjt, Apr 01 2017



random, halfbakery