On a similar note, would it be acceptable to join the 'hlRun' and
'hlFocus' fields. Currently they are:
hlRun :: Scanner Point Char -> Point -> cache -> cache,
hlFocus :: Map WindowRef Region -> cache -> cache
It seems that we could allow simpler parsers (more on this later) if we
combined them into one:
hlRun :: Scanner Point Char -> Point -> Map WindowRef Region -> cache ->
cache
After my brief search through the code, it appears that these are run in
the main loop as follows
(in Yi.Core.refreshEditor):
pureM clearAllSyntaxAndHideSelection >>=
... (do layout stuff)
pureM focusAllSyntax >>=
... (display everything)
I don't see any reason why this couldn't be changed to
... (do layout stuff)
pureM runAndFocusAllSyntax >>=
... (display everything
which would allow merging hlRun and hlFocus as described above. In fact,
I tested this by moving the calls to 'pureM
clearAllSyntaxAndHideSelection' and 'pureM focusAllSyntax' next to each
other, and nothing appears to have been broken.
---
The reason for merging hlRun and hlFocus is as follows. For example,
suppose I have a simple parser which just recognises keywords based on
regexp-matching (I know it's bad, but it's just an example). If hlRun
and hlFocus were combined, my cache could be
type Cache = Map WindowRef [(Keyword, Point)]
or something similar. However, with hlRun and hlFocus separate, my cache
would have to remember the scanner:
type Cache = (Map WindowRef [(Keyword, Point)], Scanner Point Char)
so that hlFocus can access the buffer's text when it knows the window
regions.
If this last explanation is unclear, I can give some more detail. The
basic idea is that the parser should have access to both the visible
regions and the underlying text when parsing.
Cheers,
Reiner
On 27/06/11 00:18, Reiner Pope wrote:
Hi,
I was looking at the Highlighter data type in Yi.Syntax, and I'm
wondering about this:
data Highlighter cache syntax = SynHL {
...
hlRun :: Scanner Point Char -> Point -> cache -> cache,
...
}
What does this achieve over the following?
...
hlRun :: Rope -> Point -> cache -> cache
...
One advantage of the latter is that it should allow more efficient
lexers/parsers because they could access characters via the underlying
bytestring, rather than converting through an intermediate list.
Cheers,
Reiner
--
Yi development mailing list
yi-devel@googlegroups.com
http://groups.google.com/group/yi-devel