Lex Trotman | 1 May 02:26 2011
Picon

Re: Re: C++ Question: switch / case vs. "chained" if elses for dealing with the ASCII character set

On 1 May 2011 07:45, Philippe Lhoste <PhiLho <at> gmx.net> wrote:
> On 30/04/2011 00:51, Lex Trotman wrote:
>>
>> 2. Scintilla does not parse a file from beginning to end, it can start
>> anywhere, since the parser methods above generate state as they parse,
>> they cannot start at an arbitrary point
>
> To be clear: AFAIK, Scintilla always lexes the document from the start.
> There is no other way to know in which state it is in the middle of the
> file.
> Perhaps you wanted to mean that a Scintilla lexer can resume lexing from the
> middle of the document because it can look at the state just before, keeping
> the information in memory.

Yes, I was only thinking about the re-lexing as edits occur (after all
thats most of the time lexing will occur).  Scintilla tells the lexer
from where to re-lex from.  And the saved state used by most current
Scintilla lexers is minimal, often the style of the character before
is sufficient.  In particular they don't keep a recursive descent
stack at every character or every token of the file, which was the
real point. Recursive descent and Yacc parsers are interested in much
more detail and so have much more state, and so are much less
appropriate for restarting at an arbitrary point.

Cheers
Lex

>
> --
> Philippe Lhoste
(Continue reading)

mnissl | 1 May 10:07 2011

How to set the document modified?

Hello,

there's the message SCI_SETSAVEPOINT which tells Scintilla that the state of the document is unmodified.

Is there a counterpart which tells Scintilla that the buffer is modified?

Background information: in our software, if you remove symbol declarations, this will invalidate existing code. So, with our previous editor component (Scintilla replaces it :-) we opened the buffer and set it to modified -- the user can only save and close the buffer if it compiles again.

As a workaround, I had the idea to use SCI_APPENDTEXT to add a space character at the end of the buffer, remove it again and then call SCI_EMPTYUNDOBUFFER. But how to erase text at a given position (and not where the cursor currently is)? But that's not such a nice solution, anyway.

Any hints appreciated,
thanks in advance
Markus

--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-interest <at> googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
Dave Brotherstone | 1 May 10:37 2011
Picon

Re: How to set the document modified?

On Sun, May 1, 2011 at 10:07 AM, mnissl <nissl.markus <at> googlemail.com> wrote:
> Hello,
> there's the message SCI_SETSAVEPOINT which tells Scintilla that the state of
> the document is unmodified.
Not that I know of, maybe someone else has an idea on that.

> As a workaround, I had the idea to use SCI_APPENDTEXT to add a space
> character at the end of the buffer, remove it again and then
> call SCI_EMPTYUNDOBUFFER. But how to erase text at a given position (and not
> where the cursor currently is)?

Set the target (SCI_SETTARGETSTART and SCI_SETTARGETEND) to the text
you wish to remove, and call SCI_REPLACETARGET with an empty
replacement.
I'm not sure if it's dangerous or not, but you could
SCI_SETUNDOCOLLECTION(false), add and remove the character, then
SCI_SETUNDOCOLLECTION(true). In theory the document is in the same
state, so the undo buffer should still be valid. That way you'd keep
your undo history.

Dave.

--

-- 
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-interest <at> googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.

Neil Hodgson | 1 May 11:28 2011
Picon

Re: How to set the document modified?

mnissl:

> Is there a counterpart which tells Scintilla that the buffer is modified?

   No.

   If you want a more complex definition of 'modified' then maintain
your own state reflecting what the user has done, say 'userModified'
and then use (userModified || scintillaModified) as the 'modified'
state. That way you can more easily return to a non-modified
situation, with the Scintilla save point still valid, if the user
performs the appropriate command ("validate the symbol definitions"
for you perhaps).

   This has been asked enough times so if anyone wants to implement a
very simple  SCI_SETNOSAVEPOINT that sets the save point position to
-1, then I'll accept it.

   I'm sure that will lead to questions about how to return the save
point to a particular place.

   Neil

--

-- 
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-interest <at> googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.

Neil Hodgson | 1 May 12:50 2011
Picon

Re: Getting ready for GTK+ 3.0 - upgrading deprecated calls

   The modifications needed to make Scintilla work on GTK+ 3.0 are now
available from Hg.

   The code has been tested on GTK+ 2.8, 2.22, and 3.0.

   Drawing surfaces are initialised on 3.0 differently to 2.x when
using Cairo. That is, there are now 3 initialisation paths: GDK
(original), GdkDrawable+Cairo (recent 2.x) and Cairo. This is because
3.0 changes to a new drawing callback 'draw' which provides a cairo_t*
and not the GdkDrawable* provided by the 2.x 'expose-event'. The
Scintilla type SurfaceID is a cairo_t on 3.0 and a GdkDrawable on 2.x.

   The 'draw' callback, unlike 'expose-event' does not provide any
easy way to find out what parts of the window really need to be
redrawn - the 'damaged' region. Scintilla depends on this information
to optimize drawing. The actual drawing will be clipped away by the
context object (cairo_t) but Scintilla does work to prepare for the
drawing and can often just update the line that has changed. There is
probably a way to retrieve the damaged region from the cairo_t but I
haven't found it yet.

   The palette code has been disabled as GTK+ 3 does not appear to
have any support for paletted displays which are quite unusual now.

   The Bait test program works and looks like this:
http://scintilla.org/bait3.png. Notice how the scroll bars don't go
right into the corner. I don't know why this is and at one point
changed the code to include the corner in both scrollbars but this
problem does not occur in SciTE so I removed that tweak. The
scrollbars also look rather old, from some time around 1997.
   The Bait source code, slightly modified for GTK+ 3 can be
downloaded from http://scintilla.org/bait.tgz

   The changes for GTK+ 3.0 are in Hg change sets 3627 to 3640.

   SciTE modified for GTK+ 3 should appear in a day or so.

   I'm happy to release the GTK+ 3 support in an unoptimized and
perhaps buggy form as experimental code since it allows downstream
projects to start to move towards supporting GTK+ 3. I'm more worried
that the many changes have introduced bugs on 2.x, so please watch out
for any regressions.

   Neil

--

-- 
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-interest <at> googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.

Lex Trotman | 1 May 13:31 2011
Picon

Re: Re: Getting ready for GTK+ 3.0 - upgrading deprecated calls

> drawing and can often just update the line that has changed. There is
> probably a way to retrieve the damaged region from the cairo_t but I
> haven't found it yet.
>

Hi Neil,

My understanding from talking to some people experimenting with GTK3
(not from personal knowledge) is that the clip region of the cairo
context is set to the damage region, so you could get that by
cairo_copy_clip_rectangle_list or cairo_clip_extents for a single
bounding box.

Might be worth a try.

Cheers
Lex

--

-- 
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-interest <at> googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.

Neil Hodgson | 2 May 08:55 2011
Picon

Re: Re: Getting ready for GTK+ 3.0 - upgrading deprecated calls

Lex Trotman:

> My understanding from talking to some people experimenting with GTK3
> (not from personal knowledge) is that the clip region of the cairo
> context is set to the damage region, so you could get that by
> cairo_copy_clip_rectangle_list or cairo_clip_extents for a single
> bounding box.

   That works.

   Neil

--

-- 
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-interest <at> googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.

Neil Hodgson | 2 May 09:13 2011
Picon

Re: Getting ready for GTK+ 3.0 - upgrading deprecated calls

     The modifications needed to make SciTE work on GTK+ 3.0 are now
available from Hg.

  The code has been tested on GTK+ 2.8, 2.22, and 3.0.

  The changes for GTK+ 3.0 are in Hg change sets 3468 to 3480.

   There is an issue with scroll bars first noticed in the Bait demo.
When a scrollbar overlaps the resizing widget in the corner of the
application window, it is shrunk back by the size of its arrow button
to avoid the overlap.

   The divider between the panes can not be seen while it is moving.
Since it appears difficult to draw over all the windows, this may be
changed to live resizing like on Windows. This was tried in the early
days of SciTE on GTK+ and was too slow then but it may be OK now.

   Neil

--

-- 
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-interest <at> googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.

mnissl | 2 May 12:59 2011

Aw: Re: How to set the document modified?

   If you want a more complex definition of 'modified' then maintain
your own state reflecting what the user has done, say 'userModified'
and then use (userModified || scintillaModified) as the 'modified'
state. That way you can more easily return to a non-modified
situation, with the Scintilla save point still valid, if the user
performs the appropriate command ("validate the symbol definitions"
for you perhaps).

Thanks for this hint ... looks like a workaround that I can implement in the meanwhile.

   This has been asked enough times so if anyone wants to implement a
very simple  SCI_SETNOSAVEPOINT that sets the save point position to
-1, then I'll accept it.

 Is this up to me to implement or is there any Scintilla developer out there to take this over?

--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-interest <at> googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.
mnissl | 2 May 13:11 2011

Feature request: new message to retrieve an IDocument pointer directly?

Hello,

in our software, we wrote a lexer for Scintilla that uses the IDocument interface.

Outside the lexer, we also wanted to use the IDocument interface, so we wrote a method to retrieve the IDocument interface pointer for an existing document:

Scintilla::IDocument *COurView::GetIDocument()
{
  return (Scintilla::IDocument *) (Document *) m_Edit.GetDocPointer();
}

Alas, this is bound very tightly to a specific version of the SciLexer.dll whose source code was used to compile the above mentioned method.

Do you think Scintilla could feature a new message that allows retrieving the IDocument pointer directly?

--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-interest <at> googlegroups.com.
To unsubscribe from this group, send email to scintilla-interest+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en.

Gmane