Discussion of the Scintilla free source code editing component

Lex Trotman | 1 May 2011 02:26

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)

headers

mnissl | 1 May 2011 10:07

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.

headers

Dave Brotherstone | 1 May 2011 10:37

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.

headers

Neil Hodgson | 1 May 2011 11:28

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.

headers

Neil Hodgson | 1 May 2011 12:50

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.

headers

Lex Trotman | 1 May 2011 13:31

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.

headers

Neil Hodgson | 2 May 2011 08:55

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.

headers

Neil Hodgson | 2 May 2011 09:13

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.

headers

mnissl | 2 May 2011 12:59

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.

headers

mnissl | 2 May 2011 13:11

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.

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

24	May 2013
79	April 2013
53	March 2013
88	February 2013
77	January 2013
20	December 2012
35	November 2012
38	October 2012
96	September 2012
55	August 2012
74	July 2012
121	June 2012
142	May 2012
87	April 2012
60	March 2012
49	February 2012
60	January 2012
61	December 2011
101	November 2011
51	October 2011
88	September 2011
96	August 2011
107	July 2011
96	June 2011
63	May 2011
170	April 2011
82	March 2011
72	February 2011
93	January 2011
45	December 2010
92	November 2010
77	October 2010
34	September 2010
150	August 2010
99	July 2010
59	June 2010
59	May 2010
38	April 2010
50	March 2010
55	February 2010
63	January 2010
16	December 2009
23	November 2009
37	October 2009
72	September 2009
85	August 2009
134	July 2009
40	June 2009
87	May 2009
66	April 2009
48	March 2009
45	February 2009
52	January 2009
25	December 2008
39	November 2008
23	October 2008
22	September 2008
85	August 2007
136	July 2007
141	June 2007
61	May 2007
36	April 2007
84	March 2007
132	February 2007
65	January 2007
51	December 2006
40	November 2006
77	October 2006
52	September 2006
85	August 2006
64	July 2006
101	June 2006
109	May 2006
78	April 2006
179	March 2006
151	February 2006
229	January 2006
179	December 2005
168	November 2005
117	October 2005
46	September 2005
156	August 2005
91	July 2005
134	June 2005
98	May 2005
195	April 2005
260	March 2005
167	February 2005
181	January 2005
98	December 2004
65	November 2004
100	October 2004
62	September 2004
85	August 2004
120	July 2004
136	June 2004
248	May 2004
152	April 2004
139	March 2004
160	February 2004
200	January 2004
105	December 2003
102	November 2003
166	October 2003
133	September 2003
134	August 2003
154	July 2003
53	June 2003
122	May 2003
218	April 2003
208	March 2003
120	February 2003
109	January 2003
96	December 2002
230	November 2002
129	October 2002
130	September 2002
87	August 2002
109	July 2002
116	June 2002
143	May 2002
136	April 2002
192	March 2002
210	February 2002
206	January 2002
140	December 2001
89	November 2001
66	October 2001