(not sure how reliable the mailing list/newsgroup gateway is at
the moment, so cc-ed to steve)
On Sun, 3 Aug 2003 15:56:11 +0000 (UTC), steve@watchfield.com wrote:
>Hi David,
>
>Thanks for your comments on Ved's shortcomings. I've got some of
>>No syntax colorizing has to be the top one,
>
>OK - not the "vi" I grew up with but one of the modern variants. I'm
>not mad keen on syntax coloring myself, as it happens, but it would be
>a nice generalization to make internally to Ved.
As it happens, last time I tried to start using ved again, syntax
colouring was the thing I missed first. (E.g. if it's red, it's a
typo.)
>At the moment, Ved's character attribute info (which includes colour)
>is saved as part of the file, effectively in-line with the character
>codes. And that's bad news because the Pop-11 compiler does not
>accept character streams with that info. So a syntax coloured file
>couldn't be loaded :-(
Bummer!
>So to make syntax colouring work you would need to write a decent
>algorithm, which would be easy-peasey, and EITHER add a new flag to
>Ved to say "don't bother saving character attribute info" OR add
>a flag to say "save/restore character attribute info in/from a
>separate file".
*Or* what I did: which was to toggle colour off manually. A bit
primitive, I know.
>The syntax coloring algorithm would significantly benefit by being
>given a FSM-state field for each line of the buffer. That would mean
>that the algorithm would only have to be applied from dirtied lines
>to where the state re-synchronizes.
Yeah, I wrote one, must be about a year? ago now. I was going to make
it available after I ironed out a few bugs. (You can guess what they
were - things like use of unmatched character quotes inside lists.)
Never did get around to fixing it.
>Ved doesn't really support the concept of user-actions on dirtied lines
>so a good first approximation would be to run the syntax colourer over
>all the lines of the screen after every keystroke - with the above
>line-based caching strategy the performance hit would be negligible
Well, the line caching is a good idea I didn't think of. So, for
information, re-parsing the whole ved buffer every keystroke was quite
acceptable for smallish files (say, 100 lines or so) on an ageing
450MHz machine. It would be bearable for considerably longer files
(a few hundred lines). Scale up by the speed of your machine.
>since it would typically do very little. [This isn't quite good enough
>because of buffers with multiple windows and operations that scroll
>"the other" window.]
I don't understand this last point - if you do it on every keystroke,
then scrolling a window doesn't change the colour of any characters,
so scrolling another window does just that: scrolls it. And then you
do some wasted work in your own window re-parsing the file. So? The
alternative is to exercise the idle loop.
>Sounds like a weekend project to me. If someone else wants to tackle
>the character attribute saving issue I'm prepared to implement the
>colourer. And eat my own words, no doubt.
Well, if you implement your own colourer, I expect it will be better
than mine, which is a bit ad-hoc. Alternatively *you* write better
save code, and you can have my colourer for free ...
It works by a heuristic mix of FSM and looking at the identprops()
of words (e.g. whether they are syntax words or not) -- you can't
just itemise the buffer because of comments.
The other problem with my colourer is that it's inside-out. For
fun. (Why write programs for any other reason?)
That is, instead of syntax analyser calling itemiser calling
character repeater, the character repeater occasionally calls
an item-consumer, which in turn occasionally calls a construct
consumer (e.g. for tracking lexical variable declarations). As
I said, inside-out and ad-hoc. Hmmmm. Maybe you *do* want to
write your own!
>Syntax colouring is, to my way of thinking, something of a "gimmick".
>So it is fascinating that you put it top of your list of priorities.
Not to me.
>Do you think is it specifically syntax _colouring_ that you value
>or would syntax _highlighting_ (differently weighted text) or simply
>interactive syntax _checking_ be adequate?
I'd rather have comments in a different font (e.g. italics) than
as, say, blue text on a black background. IMO, it's vital to be able
to customise the colours assigned to different syntactic categories
to your own preferences.
>In thinking about this, bear in mind that ~8% of Caucasian men are
>dyschromatopic (i.e. colour-blind). That's 2.4 boys in a class of
>30 boys, for example. Also today's monitors do not display mixed
>color text at equal levels of readability - making it very wearing to
>read for long periods of time. That's something I've come to appreciate
>quite directly as my vision has declined naturally with age!
See above about customising colours.
As an aside, it's speculated that some women may be tetrachromats.
They really ought to make monitors with four different phosphors
for them ;-). (It's possible that my mother was one, since although
I do have three different colour receptors, one of them (either the
red or the green, I'm not sure which) has the "wrong" frequency
response[*]. So I still see reds, oranges, yellows and greens, but
differently to the rest of you.
Since my brothers seem to have normal colour vision, it's likely
that the colour receptors on my mother's X chromosomes were different:
either two different reds, a green and a blue, or one red, two
greens and a blue. But that's speculation, and depends on the X
chromosomes which are switched off varying as a mosaic across the
retina.
Jonathan
(who never stays on-topic for too long, in case he gets bored)
[*] I see some wrong numbers in those little books of coloured
circles, with hidden digits, i.e. I didn't fail the test but
I didn't pass it either.
--
(To e-mail me, replace spam by jlc in the e-ddress)
|