Neil Hodgson | 1 Sep 2005 03:18
Picon

Re: New SQL Lexer (was Re: Scintilla 1.66 released)

Philippe Lhoste:

> I saw my message was held because it was suspected of having a virus...
> Either all messages with a zip file are suspect, or the scanner is quite
> dummy... I suspect the former, so I suppose that sending even small
> files to the list is discouraged (or we should send them unzipped?).

   It is better to send files zipped so they arrive intact rather than
being munged by mail transfer agents. The filter is coarse but it
normally only leads to a delay which is a small price to pay to avoid
spam. If you choose a particularly dumb title like "best prices for
impotence drugs" then the message may get lost. This morning's
moderation page shows why most choices are made based only on title:
http://scintilla.sourceforge.net/mmfold.png

> I just noticed a bug: it doesn't fold on opening brace. I am not sure why.

   The current SQL lexer folds based upon indentation as well as
language features. This was tricky as the indentation folding was in
the lexer but other fold modifications were done in the folder. You
removed the indentation based code from your version of the lexer, so
the folding will be different. Since this wasn't mentioned in the
submission, its hard to work out what the intent of the change was.

   Neil
Neil Hodgson | 1 Sep 2005 04:34
Picon

Re: GTK CallTip issue

Iago Rubio:

> I finally was able to track it down to ScintillaGTK.cxx
> ScintillaGTK::CreateCallTipWindow(PRectangle rc):1350
> 
> gdk_window_resize(PWidget(ct.wCallTip)->window, rc.Width(), rc.Height
> ());
> 
> At this point PWidget(ct.wCallTip)->window is allways NULL despite of
> ct.wCallTip.Created() returning TRUE or FALSE, so despite of ct.wCallTip
> being initallized at the start of this function or not.

   This code is there to reduce the size of the calltip window when
starting a nested call. If we have an API

a(Window w,ErrorDescription e)
b(int x)

   and type "a(b(", then the long calltip window originally shown for
"a" needs to be reduced. At this point PWidget(ct.wCallTip)->window is
a valid window.

   It looks like it will all work with a simple guard condition:

	if (PWidget(ct.wCallTip)->window) {
            gdk_window_resize(...

   so this has been committed to CVS.

   Neil
(Continue reading)

Iago Rubio | 1 Sep 2005 12:24
Picon

Re: GTK CallTip issue

On Thu, 2005-09-01 at 12:34 +1000, Neil Hodgson wrote:
> Iago Rubio:
> 
> > I finally was able to track it down to ScintillaGTK.cxx
> > ScintillaGTK::CreateCallTipWindow(PRectangle rc):1350
> > 
> > gdk_window_resize(PWidget(ct.wCallTip)->window, rc.Width(), rc.Height
> > ());
> > 
> > At this point PWidget(ct.wCallTip)->window is allways NULL despite of
> > ct.wCallTip.Created() returning TRUE or FALSE, so despite of ct.wCallTip
> > being initallized at the start of this function or not.
> 
>    This code is there to reduce the size of the calltip window when
> starting a nested call. If we have an API
> 
> a(Window w,ErrorDescription e)
> b(int x)
> 
>    and type "a(b(", then the long calltip window originally shown for
> "a" needs to be reduced. At this point PWidget(ct.wCallTip)->window is
> a valid window.

Ah ! Now I see. In my tests I've never used nested calltips. That's why
I allways got that error.

Thanks for the hint.

>    It looks like it will all work with a simple guard condition:
> 
(Continue reading)

Philippe Lhoste | 1 Sep 2005 15:08
Picon

Re: New SQL Lexer (was Re: Scintilla 1.66 released)

Neil Hodgson wrote:
>> I saw my message was held because it was suspected of having a virus...
>> Either all messages with a zip file are suspect, or the scanner is quite
>> dummy... I suspect the former, so I suppose that sending even small
>> files to the list is discouraged (or we should send them unzipped?).
> 
>    It is better to send files zipped so they arrive intact rather than
> being munged by mail transfer agents. The filter is coarse but it
> normally only leads to a delay which is a small price to pay to avoid
> spam. If you choose a particularly dumb title like "best prices for
> impotence drugs" then the message may get lost. This morning's
> moderation page shows why most choices are made based only on title:
> http://scintilla.sourceforge.net/mmfold.png

OK, zips then.
I am plagued by spam too (who isn't?) but fortunately 90% of it is 
intercepted by the host of my e-mail address, with some reliable results.

>> I just noticed a bug: it doesn't fold on opening brace. I am not sure why.

The bug was actually between my chair and the screen... I didn't updated 
my latest lexer to my regular SciTE. It works now.

>    The current SQL lexer folds based upon indentation as well as
> language features. This was tricky as the indentation folding was in
> the lexer but other fold modifications were done in the folder. You
> removed the indentation based code from your version of the lexer, so
> the folding will be different. Since this wasn't mentioned in the
> submission, its hard to work out what the intent of the change was.

(Continue reading)

Phil Thompson | 4 Sep 2005 15:34
Picon

ANN: QScintilla v1.6 Released

Riverbank Computing is pleased to announce the release of QScintilla v1.6 
available from http://www.riverbankcomputing.co.uk/qscintilla/.

QScintilla is a port to the Qt toolkit of Scintilla, that includes the 
complete message based API and also a high-level API more familiar to 
existing Qt users.

Changes since the last release include:

    - based on Scintilla v1.65
    - support for the CSS, Diff, Makefile, POV, Properties and Batch lexers
      added to the high-level API.

Like Qt, QScintilla is available under the GPL (for UNIX, Linux and MacOS/X) 
and a commercial license (for Windows, UNIX, Linux and MacOS/X).
Carsten | 9 Sep 2005 10:17
Picon
Picon

Re: New SQL Lexer (was Re: Scintilla 1.66 released)

Philippe Lhoste wrote:

>>>> case SCE_SQL_IDENTIFIER:
>>>
> I had problems with SQL*Plus remark and prompt. Philipp's 
> implementation didn't worked for me. So I moved the code into
> [snip]
>
>>>
>> I meant the following lines:
>>
>> sc.ChangeState(SCE_SQL_SQLPLUS_COMMENT);
>> sc.SetState(SCE_SQL_SQLPLUS_COMMENT);
>> continue;
>>
>> I don't like this construct. Is there a better solution?
>>
>
> OK, I am not sure why it didn't worked, but I understand why your code 
> work... :-)
> So I took the idea, and improved it (I think...). I actually removed 
> altogether the MatchIgnoreCaseSubstring function, taking advantage of 
> the kw_sqlplus.InListAbbreviated call:
>
[snip]

> Note how I avoided the continue...
> In this code, I used the fact that first part of SQL*Plus keywords 
> must be unambiguous, so if the word is identified as being a SQL*Plus 
> one, testing only the part before the ~ is enough.
(Continue reading)

Neil Hodgson | 10 Sep 2005 01:58
Picon

Re: New SQL Lexer (was Re: Scintilla 1.66 released)

Philippe Lhoste:

> Oops, indeed, I missed this part!
> Now, since SQL is a free flowing language, ie. with no mandatory
> indentation, I am not sure this code is very useful, beyond enforcing
> good presentation practice.

   Having indentation based folding is OK as a fallback when you can't
do good keyword based folding. If good keyword based folding can be
achieved for SQL, it should take over.

> Currently, I fold stream comments, artificial fold points marked by
> --{   or -- {   for MySQL
> --}   or -- }
> and keywords (except 'if', deactivated because it can be found without
> matching end).

   I would think "if" is one of the most important folding keywords.

   Neil
Philippe Lhoste | 10 Sep 2005 02:26
Picon

Re: New SQL Lexer (was Re: Scintilla 1.66 released)

Neil Hodgson wrote:
>> Oops, indeed, I missed this part!
>> Now, since SQL is a free flowing language, ie. with no mandatory
>> indentation, I am not sure this code is very useful, beyond enforcing
>> good presentation practice.
> 
>    Having indentation based folding is OK as a fallback when you can't
> do good keyword based folding. If good keyword based folding can be
> achieved for SQL, it should take over.

Of course, and I saw now some complex, indented SQL requests, that could 
indeed use some folding.... :-)
I will restore this code.

>> Currently, I fold stream comments, artificial fold points marked by
>> --{   or -- {   for MySQL
>> --}   or -- }
>> and keywords (except 'if', deactivated because it can be found without
>> matching end).
> 
>    I would think "if" is one of the most important folding keywords.

Well, it is mostly a fast and bad hack to workaround the problem. We 
could use something like Carsten's patch, if that's the only case where 
an 'if' is used without an 'end'. Or I thought to end the if when 
meeting a semi-colon, although they may be optional in some dialects.

I will come back to this lexer later.

--

-- 
(Continue reading)

SourceForge.net | 10 Sep 2005 13:50
Picon
Favicon

[ scintilla-Bugs-1286548 ] latex export, no \scitel

Bugs item #1286548, was opened at 2005-09-10 11:50
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=1286548&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: fiffel (knutters)
Assigned to: Nobody/Anonymous (nobody)
Summary: latex export, no \scitel

Initial Comment:
If I export a c++ file as a latex file in scite in my
linux machine, the resulting tex file is faulty.
\scitel{std} is not defined.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102439&aid=1286548&group_id=2439
SourceForge.net | 12 Sep 2005 17:57
Picon
Favicon

[ scintilla-Bugs-1288857 ] SciTE fails when run from directory with dot '.' in path

Bugs item #1288857, was opened at 2005-09-12 08:57
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=1288857&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
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: SciTE fails when run from directory with dot '.'  in path

Initial Comment:
SciTE fails on Linux when it is started from the directory
which has dot '.' in the path like: /home/me/my.dir/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102439&aid=1288857&group_id=2439

Gmane