Re: word wrap really slow

On Nov 23, 3:17 am, "Neil Hodgson" <nyamaton... <at> gmail.com> wrote:
> Marko Mahnič:
>
> > One solution would be to stop lexing just after the last visible
> > line and mark the rest of the file as "unlexed". The lexing would
> > then be redone when an unlexed line is accessed or displayed.
>
>    This is how it works but in order to determine the document height,
> all the following lines need to be measured which requires them to be
> lexed.
The document height calculation can be different. This is the key to
solve the problem.
The most obvious approach is to measure document height in text lines
and treat every wrapped text line segment as a distinct item.
This helps to keep vertical scrolling calculations simple. Another
simplification is to have all text lines have fixed height.
The drawback of this approach is that complexity of scroll
calculations is O(n), where n - number of text lines. So the bigger
text file you edit, the more time is needed to calculate vertical
scrolling, as you need to wrap all text lines to get vertical scroll
limit. And every time you resize the editor's window you need to apply
text wrap to entire file as well.

Another approach is to measure vertical scroll in bytes. This adds
extra complexity though doesn't suffer from the issues specific to the
first approach.
So the <scroll limit> = <text length in bytes> - <number of bytes that
fit in the screen when the first text byte is visible>. Scroll page is
fixed and equal to 1.

auto-scroll during drag'n'drop

Hello,

 

we are using scintilla and are particularly happy of it

we use the wxSTC component build on it, and we try to determine if scintilla has "auto-scroll during drag'n'drop" feature or not (could be disabled by default, or blocked by wxSTC). The fact is that currently when dragging near a limit (left/top/right/bottom borders) of the scintilla control nothing happens, so that we cannot easily drag'n drop to lines or columns around.

is this feature present?

 

Best regards

Armel Asselin

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Re: auto-scroll during drag'n'drop

On Thu, 4 Dec 2008 16:07:42 +0100
"Armel Asselin" <armel.asselin <at> elliecomputing.com> wrote:

> we use the wxSTC component build on it, and we try to determine if
> scintilla has "auto-scroll during drag'n'drop" feature or not (could
> be disabled by default, or blocked by wxSTC). The fact is that
> currently when dragging near a limit (left/top/right/bottom borders)
> of the scintilla control nothing happens, so that we cannot easily
> drag'n drop to lines or columns around. is this feature present?

I can confirm it isn't working on plain GTK too (GTK 2.8).

It is mentioned under bugs here:
http://www.scintilla.org/ScintillaToDo.html

Regards,
Nick

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Lexer for reStructuredText

I would like to see a lexer for reStructuredText, and am considering
taking a shot at writing one. I am more familiar with Python than C/C+
+ and would rather not invest the time if I would be duplicating
effort, so I wanted to ask if anyone knows if such a lexer is being
developed, and if not, could I get pointers on how to go about
submitting a new lexer for inclusion into Scintilla?

Thank you,
Darren

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Re: Lexer for reStructuredText

On Thu, 4 Dec 2008 20:13:59 -0800 (PST), Darren Dale
<dsdale24 <at> gmail.com> wrote:

>
>I would like to see a lexer for reStructuredText, and am considering
>taking a shot at writing one. I am more familiar with Python than C/C+

Cool. I also like to see a ReST lexer. if you need testers, just ping
me :).

>+ and would rather not invest the time if I would be duplicating
>effort, so I wanted to ask if anyone knows if such a lexer is being
>developed, and if not, could I get pointers on how to go about
>submitting a new lexer for inclusion into Scintilla?

I guess: write the lexer and post here when you are done.

Regards,
Enrico

--

-- 
Get my GPG key from http://www.uvena.de/pub.asc

Re: Lexer for reStructuredText

Darren Dale wrote:
> I would like to see a lexer for reStructuredText, and am considering
> taking a shot at writing one. I am more familiar with Python than C/C+
> + and would rather not invest the time if I would be duplicating
> effort, so I wanted to ask if anyone knows if such a lexer is being
> developed, and if not, could I get pointers on how to go about
> submitting a new lexer for inclusion into Scintilla?

Probably there isn't anyone working on one yet; I haven't heard of 
such an effort being mentioned on the list in the past year or two.

You can submit the lexer through the SF feature tracker. You can 
also probably fish for testers on the list, though from past 
experience, you'll likely get little response. Having a bunch of 
test cases is helpful; for example, I post my test cases for Bash 
and Perl to the file area of the group's website.

--

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Re: Fold Markers

Neil,

> When a SC_MARKNUM_FOLDEROPEN is hit, `int marks` has a value of
> -2147483648 and `marks &= vs.ms[margin].mask;` sets `marks` to the
> same value. Since marks is nonzero, this causes the Draw event, so the
> SC_MARKNUM_FOLDEROPEN is drawn as expected.
>
> After clicking it to collapse the fold, `int marks` has a value of
> 1073741824 and `marks &= vs.ms[margin].mask;` sets `marks` to 0. Since
> marks is zero, the Draw event is not called.

I figured out the issue. I converted SC_MASK_FOLDER to a long which
results in not 4261412864, but -2147483648 and called
SCI_SETMARGINMASKN. Using the value of -33554432 as suggested in
ScintillaDoc.html works as expected.

Sorry for the trouble,
-Mitchell;
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Additional 'SCI_NAMESPACE's needed

Neil,

For compiling on Mac OSX with GTK, the following files also need the
'#ifdef SCI_NAMESPACE' wrapper:
* gtk/PlatGTK.cxx
* gtk/ScintillaGTK.cxx
* src/Document.cxx

Patch is as follows (google groups wont let me attach it?):

--- scite-cvs/scintilla/gtk/PlatGTK.cxx	2008-10-30 21:15:56.000000000
-0400
+++ scite-tools/branches/scite-st/src/scintilla/gtk/PlatGTK.cxx
2008-11-07 23:34:41.000000000 -0500
 <at>  <at>  -41,6 +41,12  <at>  <at> 
 #pragma warning(disable: 4505)
 #endif

+// added by Mitchell
+#ifdef SCI_NAMESPACE
+using namespace Scintilla;
+#endif
+// end added by Mitchell
+
 enum encodingType { singleByte, UTF8, dbcs};

 struct LOGFONT {
 <at>  <at>  -673,7 +679,11  <at>  <at> 
 	id = 0;
 }

+#ifdef SCI_NAMESPACE
+class Scintilla::SurfaceImpl : public Surface {
+#else
 class SurfaceImpl : public Surface {
+#endif
 	encodingType et;
 	GdkDrawable *drawable;
 	GdkGC *gc;
--- scite-cvs/scintilla/gtk/ScintillaGTK.cxx	2008-10-30
21:15:56.000000000 -0400
+++ scite-tools/branches/scite-st/src/scintilla/gtk/ScintillaGTK.cxx
2008-11-07 23:34:41.000000000 -0500
 <at>  <at>  -88,6 +88,12  <at>  <at> 
 #define OBJECT_CLASS GObjectClass
 #endif

+// added by Mitchell
+#ifdef SCI_NAMESPACE
+using namespace Scintilla;
+#endif
+// end added by Mitchell
+
 extern char *UTF8FromLatin1(const char *s, int &len);

 class ScintillaGTK : public ScintillaBase {
--- scite-cvs/scintilla/src/Document.cxx	2008-10-30 21:15:56.000000000
-0400
+++ scite-tools/branches/scite-st/src/scintilla/src/Document.cxx
2008-11-07 23:34:41.000000000 -0500
 <at>  <at>  -1657,16 +1657,14  <at>  <at> 

 #ifndef SCI_OWNREGEX

+// modified by Mitchell
 #ifdef SCI_NAMESPACE
-namespace Scintilla {
-#endif
-
+RegexSearchBase *Scintilla::CreateRegexSearch(CharClassify
*charClassTable) {
+#else
 RegexSearchBase *CreateRegexSearch(CharClassify *charClassTable) {
+#endif
+// end modified by Mitchell
 	return new BuiltinRegex(charClassTable);
 }

-#ifdef SCI_NAMESPACE
-}
-#endif
-
 #endif
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Out of Memory behaviour

Hi,

A crash bug recently filed against Programmer's Notepad appears to be
caused by memory exhaustion when trying to allocate more memory for
the undo stack:

SciLexer.dll!UndoHistory::EnsureUndoRoom()
SciLexer.dll!UndoHistory::AppendAction(actionType at=insertAction, int
position=22313243, char * data=0x64742610, int lengthData=1, bool &
startSequence=false)
SciLexer.dll!CellBuffer::InsertString(int position=22313243, const
char * s=0x647423f8, int insertLength=1, bool & startSequence=false)
SciLexer.dll!Document::InsertString(int position=22313243, const char
* s=0x647423f8, int insertLength=1)
SciLexer.dll!Editor::ReplaceTarget(bool replacePatterns=true, const
char * text=0x00000000, int length=1)

The code in question appears to be:

Action *actionsNew = new Action[lenActionsNew];
if (!actionsNew)
    return;

In all conformant C++ compilers new will throw std::bad_alloc when it
fails to allocate memory, and will not return null. This is what
happened in the crash log I looked at.

Is there any way to guard against this in Scintilla? I'm aware that
historically there were reasons not to use exceptions in the code -
are these still valid? If so, perhaps in these cases we could use a
platform method to safe allocate and return null on allocation
failure. On VC this can use nothrow or can handle std::bad_alloc.

If we can handle the exception, will the undo stack drop old items in
order to continue to work?

Thanks,

Simon.
--
Programmer's Notepad - http://pnotepad.org/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Re: Out of Memory behaviour

From: "Simon Steele" <simon.steele <at> gmail.com>
Subject: [scintilla] Out of Memory behaviour

> A crash bug recently filed against Programmer's Notepad appears to be
> caused by memory exhaustion when trying to allocate more memory for
> the undo stack:
>[..]
> Is there any way to guard against this in Scintilla? I'm aware that
> historically there were reasons not to use exceptions in the code -
> are these still valid? If so, perhaps in these cases we could use a
> platform method to safe allocate and return null on allocation
> failure. On VC this can use nothrow or can handle std::bad_alloc.
the 'c++ way' to avoid exception handling on new is : new (std::nothrow) 
MyObject
nothrow is not VC specific.

it could be a good idea to use it indeed.

> If we can handle the exception, will the undo stack drop old items in
> order to continue to work?
I suspect that a first step would to avoid exceptions and get NULL pointers, 
changing the entire code to be exception safe (another way that it already 
does) is a large job...

JMHO
Armel

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---