h a l f b a k e r yIt's as much a hovercraft as a pancake is a waffle.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
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.
[link]
|
| |
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. |
|
| |
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. |
|
| |
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> |
|
| |
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.) |
|
| |
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. |
|
| |
But the fact that it might be is useful information. |
|
| |
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. |
|
| |
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. |
|
| |
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. |
|
| |
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> |
|
| |