headers
Jan Martin Pettersen | 1 May 2005 02:45
Favicon

Re: Trouble with indicators

On 29 Apr 2005 at 20:30, Robert Roessler wrote:

> Jan Martin Pettersen wrote:
> 
> > On 28 Apr 2005 at 12:52, Robert Roessler wrote:
> > ...
> > An example:
> > 
> > SCI_STARTSTYLING(0,INDICS_MASK)
> > SCI_SETSTYLING(20,INDIC0_MASK)
> > SCI_STARTSTYLING(oldstylepos,oldstylemask)
> > 
> > This would set the indicator 0 for the 20 next characters,
> > and if indicator 1 or 2 also was defined in those chars, then those
> > indicators would be removed for that length.
> > i.e the last indicator set for a length would be the ONLY indicator.
> > 
> > IBut if you use the INDIC0_MASK for the SCI_STARTSTYLING, THEN
> > you would just modify that indicator, and not the rest if any.
> > 
> > I had a little trouble with it myself, but found a solution, and it works..
> 
> Thanks for the help - none of my trouble was in setting the indicators 
> OR clearing them... it was ALL about how the "indicators" feature 
> plays with a lexer already handling the buffer! :)

:) All bits NOT used by the lexer (you'll see which it uses by the masks
used in Accessor::StartAt or StyleContext constructor calls inside the lexers) are available for
indicators, and isn't seen nor touched by them.. (starting with version 1.63, or was it 1.62).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Roessler | 1 May 2005 02:01
Favicon

Re: Trouble with indicators

Jan Martin Pettersen wrote:
> On 29 Apr 2005 at 20:30, Robert Roessler wrote:
> 
> 
>>Jan Martin Pettersen wrote:
>>
>>
>>>On 28 Apr 2005 at 12:52, Robert Roessler wrote:
>>>...
>>>An example:
>>>
>>>SCI_STARTSTYLING(0,INDICS_MASK)
>>>SCI_SETSTYLING(20,INDIC0_MASK)
>>>SCI_STARTSTYLING(oldstylepos,oldstylemask)
>>>
>>>This would set the indicator 0 for the 20 next characters,
>>>and if indicator 1 or 2 also was defined in those chars, then those
>>>indicators would be removed for that length.
>>>i.e the last indicator set for a length would be the ONLY indicator.
>>>
>>>IBut if you use the INDIC0_MASK for the SCI_STARTSTYLING, THEN
>>>you would just modify that indicator, and not the rest if any.
>>>
>>>I had a little trouble with it myself, but found a solution, and it works..
>>
>>Thanks for the help - none of my trouble was in setting the indicators 
>>OR clearing them... it was ALL about how the "indicators" feature 
>>plays with a lexer already handling the buffer! :)
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iago Rubio | 1 May 2005 09:58
Picon

Re: Scintilla for GTK on Windows style rendering problem?

On Sat, 2005-04-30 at 10:56 +0200, Philippe Lhoste wrote:
> Robert Roessler wrote:
> > Robert Roessler wrote:
> > 
> >> This is probably my "indicator" problem in slightly different guise...
> > 
> > For anyone looking at this thread, it was. :)
> 
> Out of curiosity, why are you using "Scintilla for GTK on Windows"?
> I mean, Scintilla is a native Windows component, so what is the interest 
> of using the GTK+ version on this platform?

I also use gtk scintilla on windows.

I do it because I wrote a Gtk application and don't have the time to
port the whole stuff to win32 API :)

May be a valid reason, isn't it ?

> I can guess some reasons, like "I don't know (well) Windows programming 
> while I master GTK+ coding", "For the uniformity of behaviour", "Because 
> I want my application to be pure GTK+ to avoid having an intermediate 
> platform layer" or similar stuff...

What about ... Because I don't have the time - or I'm lazy enough to
avoid - to port the whole stuff to Win32 API :-)

> I wonder if GTK+ has evolved much these last years. I used to use, two 
> or three years ago, Ethereal which is pure GTK+ running on Windows, and 
> I wasn't overly pleased by its look-and-feel. More by the slightly
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Roessler | 1 May 2005 11:40
Favicon

Re: Re: Still testing "deferred" scrollbar stuff

Neil Hodgson wrote:
> Robert Roessler:
> 
>>>   The names NotLazyEval and MustEvalForUndoRedo are too generic.
>>>Maybe something like CanDeferToLastStep and IsLastStep?

You got 'em. :)

>>Now, about the full Redraw on a multi-step sequence - how bad do we
>>(you) feel about this?  Clearly if the sequence is "long enough", we
>>are still way ahead - but how long is that?
> 
> 
>    If it only occurs in multi-step undo then it won't be a problem for
> most users but the motivating issue for this thread was your problem
> with a situation that I hadn't foreseen.

Here is my latest take on this -

I took out some of the "defer" tests, after looking at which MOD codes 
can actually appear when.

I allow changes WITHIN a line to be displayed right away.

In the Undo/Redo code in Document, I track whether a given Undo/Redo 
sequence has ANY multi-line changes... then a new flag 
SC_MULTILINEUNDOREDO (which is defined currently as 0x10000 to be well 
above the user-visible ones) is conditionally set along with 
SC_LASTSTEPINUNDOREDO.  This new flag feeds into the decision to do a 
Redraw in Editor::NotifyModified, so that "simple" Undo/Redo ops will
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Roessler | 2 May 2005 01:20
Favicon

More indicator display weirdness

Well, a strange one again - and *this* one seems to really be about 
the display code doing something funny for indicators that it doesn't 
for normal styles... :)

BTW, in a reply to Neil right after he had explained about saving and 
restoring the "end_styled" position, I suggested using a previous 
STYLE with the start_styling call to restore things, rather than a 
MASK (which is what is needed there).  Sigh - that obviously makes no 
sense. :(

Anyway, I am finding that setting an INDICATOR (0x80 or 0x40) on the 
second char of a line always displays it starting on the first char 
(the third position on works fine)... if I use the exact code (with 
0x1F instead of 0xE0 as the mask) to display a STYLE (2) in the same 
position, it displays correctly!

It does not matter what the character/style already in the first 
position is, the "extra" indicator WILL appear there.  Note that if I 
fetch the style from the first position on the line AFTER the bogus 
indicator appears, it is still what it was before - the style byte has 
NOT been corrupted.

The previous observation probably explains why I cannot see anything 
wrong in the actual styling code - things get messed up later, in the 
painting or layout code possibly?  I spent a while looking, but that 
stuff is HUGE.

A PNG is attached for the more visual-oriented; note that the leading 
chars are in fact tab chars - one fails, two works. :)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Neil Hodgson | 2 May 2005 04:15
Picon

Re: More indicator display weirdness

Robert Roessler:

> Anyway, I am finding that setting an INDICATOR (0x80 or 0x40) on the
> second char of a line always displays it starting on the first char
> (the third position on works fine)... if I use the exact code (with
> 0x1F instead of 0xE0 as the mask) to display a STYLE (2) in the same
> position, it displays correctly!

   This is a Scintilla drawing bug. The code that extracts indicator
ranges from styling is a bit complex. In SciTE, the following settings
and scripts can help reproduce the problem:

command.name.0.*=Highlight 1 and 2
command.mode.0.*=subsystem:lua,savebefore:no
command.0.*=Highlight1And2
command.name.1.*=Remove highlights
command.mode.1.*=subsystem:lua,savebefore:no
command.1.*=RemoveHighlight

function UnderlineText(pos,len,ind)
  local es = editor.EndStyled
  editor:StartStyling(pos, INDICS_MASK)
  editor:SetStyling(len, ind)
  editor:StartStyling(es, 31)
end

function Highlight1And2()
  for i = 0, editor.Length do
    if (editor.CharAt[i] == 49) or (editor.CharAt[i] == 50) then
      UnderlineText(i, 1, INDIC0_MASK)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Neil Hodgson | 2 May 2005 04:27
Picon

Re: Scintilla for GTK on Windows style rendering problem?

Philippe Lhoste:

> Speaking of GTK+ SciTE (on Debian Linux), I was surprised not to see a
> Tab setting dialog box. I use it sometime when I get a text with
> tab-separated fields needing large tab values to accomodate all field
> sizes. 

   I only rarely use that dialog so there is no motivation to
implement it on GTK+. Coding dialogs in GTK+ is reasonably easy so you
might want to try this one as a learning exercise.

   Neil
Permalink | Reply | 0 comments |
headers
Neil Hodgson | 2 May 2005 07:01
Picon

Re: Styling (coloring) using SCLEX_CONTAINER lexer

Zoran Todorovic:

> When a file is loaded and displayed, only the first line is styled. 

   Trace all SCN_STYLENEEDED notifications to see what your container
is being asked to lex.

> I tried with SCI_COLOURISE message sent upon openning the document or after
> replacing part of it but it does not work. 

   Check that you are using 1.63 as there was some work done on this.

   Neil
Permalink | Reply | 0 comments |
headers
Robert Roessler | 2 May 2005 09:18
Favicon

Re: More indicator display weirdness

Neil Hodgson wrote:

> Robert Roessler:
> 
> 
>>Anyway, I am finding that setting an INDICATOR (0x80 or 0x40) on the
>>second char of a line always displays it starting on the first char
>>(the third position on works fine)... if I use the exact code (with
>>0x1F instead of 0xE0 as the mask) to display a STYLE (2) in the same
>>position, it displays correctly!
> 
> 
>    This is a Scintilla drawing bug. The code that extracts indicator
> ranges from styling is a bit complex. In SciTE, the following settings
> and scripts can help reproduce the problem:
> ...
>    The OCaml lexer fails with an assertion in debug builds as it tries
> to style one beyond the end of the buffer with
> 
> 	styler.ColourTo(i, state);

Cool... I think.  If I have this right, it is a "Scintilla drawing 
bug" - that leads LexCaml into evil ways?  Well, even if that is the 
correct interpretation, lexers shouldn't fail with even remotely 
reasonable input - or at all, if you want to be that way about it. :)

So I can start on it from that end... but if this is well enough 
understood to have reproducible test cases at hand (and still isn't 
fixed), then - it must be *really* difficult to work on Editor:Paint 
and friends. :(
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Roessler | 2 May 2005 09:28
Favicon

Re: SCN_MODIFYATTEMPTRO semantics?

Neil Hodgson wrote:

>    Robert:
> 
> 
>>Next, I tried to use SCN_MODIFYATTEMPTRO notifications to remove the
>>indicators... ultimately, this does not work out either, since Undo
>>does NOT trigger this notification! :(
> 
> 
>    Mark Hammond implemented this notification so that he could check
> the file out of source code control when the user tried to edit it.
> Thus the file was expected to start out in read-only mode so undo
> would not be relevant.
> 
> 
>>I believe this to be fixable, and am willing to do so... does anyone
>>see a problem with issuing this notification (attempting to Undo/Redo
>>with a doc that is AT THAT TIME set read-only)?  All I am proposing is
>>just issuing the expected "NO" when trying to do something that
>>already is being blocked anyway.
> 
> 
>    It should be OK.

BTW, in case my "Undo/Redo" performance thread did not make it clear, 
this code is "completed" / ready for NH review.  It does exactly what 
*I* need, BTW. :)

The key is having the ability to get a notification about changing the
(Continue reading)

Permalink | Reply | 2 comments |

Gmane