SourceForge.net | 1 May 2007 23:14
Picon
Favicon

[ scintilla-Bugs-1710820 ] MSIMG32.DLL scite Invalid page fault

Bugs item #1710820, was opened at 2007-05-01 21:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102439&aid=1710820&group_id=2439

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: SciTE
Group: Bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: tim (timsoft)
Assigned to: Nobody/Anonymous (nobody)
Summary: MSIMG32.DLL scite Invalid page fault

Initial Comment:
I am regularly getting the following ipf with scite

SCITE caused an invalid page fault in
module MSIMG32.DLL at 017f:00d08dda.
Registers:
EAX=01010101 CS=017f EIP=00d08dda EFLGS=00010287
EBX=006bd4cc SS=0187 ESP=006bd244 EBP=006bd2a4
ECX=000000ff DS=0187 ESI=853adf00 FS=a57f
EDX=004909e0 ES=0187 EDI=85142100 GS=a556
Bytes at CS:EIP:
8b 06 c1 e8 18 83 c6 04 84 c0 74 77 3c ff 0f 84 
(Continue reading)

SourceForge.net | 2 May 2007 10:35
Picon
Favicon

[ scintilla-Bugs-1711085 ] folding confused by comments in C macros

Bugs item #1711085, was opened at 2007-05-02 08:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102439&aid=1711085&group_id=2439

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: SciTE
Group: Bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Felix Kater (fkater2)
Assigned to: Nobody/Anonymous (nobody)
Summary: folding confused by comments in C macros

Initial Comment:
Hi,

in C, the folding mechanism gets confused if there is a macro with a comment in it like this:

1 #if 1 /* test */
2
3  #define macro \
4    if(sth==TRUE){ \
5      /* comment */ \
6      return;}
7
(Continue reading)

mitchell | 3 May 2007 18:33
Picon

Performance issues of changing Accessor.h bufferSize?

Hi,

What would be the performance consequences of increasing bufferSize in 
Accessor.h?

Thanks,
-Mitchell;
Neil Hodgson | 4 May 2007 02:05
Picon

Re: Performance issues of changing Accessor.h bufferSize?

   Hi Mitchell,

> What would be the performance consequences of increasing bufferSize in
> Accessor.h?

   Increasing bufferSize is most likely to improve performance a
little. For most cases, I wouldn't expect it to be significant.
Notifications will be sent to the container for each flush of the
buffer, so if your container is performing a slow operation inside
that notification then lessening the number of notifications may
improve overall performance.

   The number of notifications can sometimes be an issue so for
Windows there could be an option to call the container directly rather
than using SendMessage similar to how SCI_GETDIRECTFUNCTION is used.
On GTK+, g_signal_emit is less likely to be a performance bottleneck
as it doesn't go through the operating system.

   Neil
Ian Smith | 4 May 2007 02:24
Picon

Scintilla for PowerBASIC

Greetings Scintilla users and developers,

I was bored today, and my boss is a PB enthusiast, so I've ended up developing some office utilities in it, and I quite enjoy myself. Some of it's development tools are lacking however, so I decided to see if I can get Scintilla working in PowerBASIC. It was actually pretty easy since you can access Scintilla entirely through windows messaging :)

I'll write some wrapper utilities later that will encapsulate Scintilla access so you can use a direct function pointer instead of SendMessage(aka CONTROL SEND)

You can download the the include files that I converted, as well as a sample program here:
http://robotbebop.dontexist.org/pbscintilla/

Enjoy!
Ian Smith

_______________________________________________
Scintilla-interest mailing list
Scintilla-interest <at> lyra.org
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
John Gabriele | 4 May 2007 08:12
Picon

Markdown support

An editor I'm using (Geany http://geany.uvena.de/Main/HomePage) uses
Scintilla, and I'd like to be able to have some syntax highlighting
for Markdown (http://daringfireball.net/projects/markdown/) in it.
Markdown is simple, and quite readable without syntax highlighting (it
was designed for that), but would be even nicer to work with if there
was some highlighting.

My guess is that maybe Scintilla could use a Markdown lexer. Is anyone
currently working on one for Markdown?

Is anyone interested in seeing Markdown support in Scintilla?

Is this: http://scintilla.sourceforge.net/Lexer.txt the main tutorial?

BTW, you might want to add Geany to the list at
http://scintilla.sourceforge.net/ScintillaRelated.html under "Projects
using Scintilla".

Thanks,
---John
Josiah Carlson | 4 May 2007 09:16
Picon
Favicon

Re: Markdown support


"John Gabriele" <jmg3000 <at> gmail.com> wrote:
> An editor I'm using (Geany http://geany.uvena.de/Main/HomePage) uses
> Scintilla, and I'd like to be able to have some syntax highlighting
> for Markdown (http://daringfireball.net/projects/markdown/) in it.
> Markdown is simple, and quite readable without syntax highlighting (it
> was designed for that), but would be even nicer to work with if there
> was some highlighting.
> 
> My guess is that maybe Scintilla could use a Markdown lexer. Is anyone
> currently working on one for Markdown?

Doubtful.  Though if someone is or has worked on one for
reStructuredText, markdown looks like a stripped down variant of it and
could probably borrow some of its code.

 - Josiah
Philippe Lhoste | 4 May 2007 10:01
Picon

Re: Markdown support

John Gabriele wrote:
> I'd like to be able to have some syntax highlighting
> for Markdown (http://daringfireball.net/projects/markdown/) in it.
> Markdown is simple, and quite readable without syntax highlighting (it
> was designed for that), but would be even nicer to work with if there
> was some highlighting.

That's funny, I (re)discovered Markdown quite recently and was seduced 
by its simplicity and "natural" look (Wiki syntax, for example, doesn't 
feel natural...).
So naturally I though of making such lexer, but it is currently only a 
vague project buried under lot of others...
It might not be too hard to do (but it will heavily depends on the style 
of the previous line) so I can give it a shot, but don't hold your breath...

--

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --
Neil Hodgson | 4 May 2007 13:39
Picon

Experiments with run segmentation and a position cache

   There have been problems with Scintilla drawing long runs of text
with some platforms crashing, or failing to display or drawing
incorrectly. Other times, its just slow. A while ago some hard limits
were added to some platform layers but these don't solve the problems
very well. To solve this better, I've added some code to the
LineLayout class that tries to break runs longer than 500 bytes into
segments less than 100 bytes long in a consistent way. To avoid
problems with multi-byte and combining characters, it tries first to
break after a space and if no spaces are present breaks before low
ASCII characters that should not be part of combinations (its
currently wrong, testing < 'a' rather than < 'A'). This results in a
large speed improvement (particularly on GTK+) where there are very
wide lines of text that are not lexed into small runs because runs
that are completely outside the drawing area do not go through any of
the text drawing code. The code will currently fail on long runs
containing only multi-byte characters.

   SinkWorld has been using a position cache for a while now and this
is now ported to Scintilla. The position cache holds a fixed size set
of pieces of text along with the positions of each character relative
to the start of the text. This is similar to the existing LineLayout
cache but uses much less memory for good results. It decreases the
number of calls to the platform layer's text measurement method by
around 90% with 1024 entries. It only holds short (<30 character)
pieces of text to avoid large memory use and churning the cache for
pieces of text that only occur once. Wrapping all of SciTEBase.cxx on
GTK+ takes around one quarter of the time that is required without the
cache. When displaying large amounts of text in wrapped mode, using
the LineLayout cache with the whole document cached gives much better
results than using the PositionCache. Because the PositionCache adds
complexity and overlaps the LineLayout cache, I'm not sure whether to
commit this change.

   These two changes have not been committed but can be found in
http://scintilla.sourceforge.net/scite.zip

   Neil
Neil Hodgson | 4 May 2007 13:48
Picon

Re: Markdown support

John Gabriele:

> Is this: http://scintilla.sourceforge.net/Lexer.txt the main tutorial?

   Yes but most people rely more on using the bundled lexers as examples.

> BTW, you might want to add Geany to the list at
> http://scintilla.sourceforge.net/ScintillaRelated.html under "Projects
> using Scintilla".

   OK, included.

   Neil

Gmane