At 2005-09-19 19:23 +1000 Monday, Neil Hodgson wrote:
>Anthony:
>
>> The text will display initially with the styling correctly displayed.
>> The problem is that if the user does an undo - then a redo, the
>> styling information is lost - it goes back to style 0!
>
> Yes, this is deliberate. Saving styling with undo/redo was one of
>the major reasons the Windows RichEdit control was very difficult to
>use for automatically styled source code documents. Scintilla was
>written to avoid this behaviour. Scintilla normally styles text
>automatically through calling container code or one of the supplied
>lexers.
...
>> Is it possible to have styling information restored on a redo?
>
> It should be possible to implement your own undo/redo code.
The grounds seem wrong, or too incomplete, or maybe there is too much
confidence or whatnot.
Also considerations on what happens to programs using syntax parsing
ought be subsequent and secondary. The instant that it is discovered
that syntax parsing has problems (e.g, a slowdown) when the alleged
bug is removed, then maybe there could be two REDO's and two UNDO's.
It seems that editors using Scintilla can hide the bug by using
syntax parsing. That was implied well by this message:
At 2005-09-19 11:20 +0200 Monday, Philippe Lhoste wrote:
...
>> Is it possible to have styling information restored on a redo?
>
> Just force a restyling. It is quite fast nowadays.
...
That presumption that restyling can be forced, can be false (the
Lex*.cxx files can be removed and before the compile with Microsoft
Visual C, "LexGen.py" can be double clicked on).
There could be confusion since:
(1) Suggesting that style checking is relevant. For the fraction of
users that implement an editor, suppose their language is not
supported by Scintilla, Then they could double-click on keywords
(but not read-only keywords since a double click will select a
token distant from the mouse pointer). Then the document is
in styled. Then a test with REDO or UNDO can show that those are
buggy. Also getting the styling redone all manually again, is
not found to be faste.
There might be an issue of having two types of styling;
i.e where the syntax parser destroys the styling information
added by the user.
An alternative case where there is no parser so no concealment of
the faulty design.
This style information would be saved in an array, and more interesting
is how the array can be private, and not disclosed to:
(1) the Windows clipboard
(2) the code of the enveloping program that is using Scintilla.
Perhaps the difficulty is more in getting the arguments looking
plausible, than in changing Scintilla.
--
I tried CUT then UNDO then REDO, and it seems that the CUT and UNDO
pair are buggy,
Doesn't Scintilla have control over when the parsing is done, and so
it can decide to not make an unnecessary call to the parser when the
CUT, UNDO and REDO bugs are fixed.
It could be much more complex if Scintilla modified the text of the
document (though with any change to the styling), in between the
CUT and UNDO.
However that case is definitely secondary and thouh the user may be
prepared to write code to handle it, if Scintilla is keeping
secret the clipboard array of style information, then hooking into
a REDO or UNDO may fail to fix the problem.
If there is "difficulty" with Win32 calls then perhaps that can be
explained here, since it is possible that a solution to the problem
of difficulty, was to shift that difficulty into userland.
Even for CUT and PASTE, the style information can be restored:
(1) when a cut is done, then a checksum of the text is saved, and
Scintilla secretly saves the style information.
(2) when a PASTE is done, the style information is not restored if
the checksums mismatch.
Here is a substantial example for the fraction of end users that made
Scintilla implement a text editor:
(1) A "begin" keyword is created by pressing Ctrl-Z and since a
bug was removed, it reappears as styled without any call to the
parser.
(2) then that "begin" is indented using 3 underlined spaces in
columns 1 to 3.
(3) Then the UNDO key is pressed.
So Scintilla either deletes the 3 spaces, or it deletes the "begin"
word.
In both cases it knows what x .. y range to snip out of the buffer
storing the characters. So Scintilla should be able to snip out the
same x .. y range a corresponding style array.
Isn't there one array containing where each component is a C-ishy
record containing an adjacent text and style field.
Such is the form of some input to "AddStyledText ()".
Scintilla might:
* actually save the style information
* save a checksum and leave it to Windows to save the data.
Now it checksums agree when they should not, e.g. when the data has
come from another program so Scintilla can't delete its checksums.
However Windows seems to have a "WM_DESTROYCLIPBOARD" feature that
keeps Scintilla informed well enough to allow it to invalidate the
saved the style information:
| To place information on the clipboard, a window first clears any
| previous clipboard content by using the EmptyClipboard function. This
| function sends the WM_DESTROYCLIPBOARD message to the previous
| clipboard owner, frees resources associated with data on the
| clipboard, and assigns clipboard ownership to the window that has the
| clipboard open.
It seems for the Scintilla bug to be successfully concealed, the
userland programmer has to write wrapping code for CUT, PASTE, COPY,
UNDO, REDO, that saves style information, and also new code around that
saves style information when data is written. That might be code around
SetTargetStart, SetTargetEnd, ReplaceTarget.
---
I have Scintilla implementing a user interface to a polytope and logic
solver (symbolic algebra), all coded in GNAT Ada 95
http://tope.tigris.org/source/browse/*checkout*/tope/src/Tope/tp-io.adb
http://tope.tigris.org/source/browse/*checkout*/tope/src/Tope/tp-io-gui.adb
http://tope.tigris.org/source/browse/tope/src/Tope/tp_gw_scintilla.ads
My program hid the CUT and PASTE (UNDO and REDO) 'style information loss'
failings of Scintilla, by having the style of input fields, be style 0.
Scintilla pastes back with style 0.
Craig Carey
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
