Neil Hodgson | 6 Feb 08:13 2010
Picon

Writing lexers in Lua

   There is now some experimental support for writing lexers in Lua.
The API is similar to the StyleContext class used in LexCPP although
the low level calls from Accessor are also available. It is very
likely that the API will change and it may still be 'experimental'
when included in a release of SciTE so that the API can be fixed after
more experience.

   The documentation is at
http://www.scintilla.org/ScriptLexer.html

   Iteration is by character rather than byte and styler.Current(),
styler.Next(), and styler.Previous() return strings containing all the
bytes in multi-byte characters. If the document is in UTF-8 with the
value "«" then the initial value of styler.Current() is "«" which is
the same as "\xc2\xab". If the document is in Latin-1 then "«" is
"\xab". This makes it easy to write lexers for a particular encoding
in that encoding as code can be written naturally like
styler.Match("«"). Lexers for languages that depend on characters
outside ASCII for syntax and that have to deal with multiple encodings
will be more complex. The API still uses byte positions for Position()
and other calls since it is costly to convert byte positions to
character positions and vice versa.

   Another change from previous lexers is that there is an imaginary
extra NUL ('\0') character at the end of the document when using
styler.More() .. styler.Forward(). This makes it easier to treat the
end of the document as if it was the end of a line which means the
normal code for determining that an identifier is a keyword will
trigger. This avoids the common lexer problem of keywords at the end
of the document not highlighting.
(Continue reading)

Keith | 6 Feb 08:27 2010
Picon

Colour scheme unification

Would it be possible to update the lexers to allow a user to change, for 
example, function colour in one place and have it change in all 
languages? At present it seems that each lexer pretty much redefines all 
of it's colours, making customizing colours for multiple languages a 
real pain.

If a unified system is decided on I'd be happy to update the languages I 
use (html/xml, php, js, sql, python).

Thanks,

Keith

--

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

Philippe Lhoste | 6 Feb 10:49 2010
Picon
Picon

Re: Colour scheme unification

On 06/02/2010 08:27, Keith wrote:
> Would it be possible to update the lexers to allow a user to change, for
> example, function colour in one place and have it change in all
> languages? At present it seems that each lexer pretty much redefines all
> of it's colours, making customizing colours for multiple languages a
> real pain.

There is already something like that in SciTEGlobal.properties: see

# Give symbolic names to the set of colours used in the standard styles.
colour.code.comment.box=fore:#007F00
colour.code.comment.line=fore:#007F00
colour.code.comment.doc=fore:#3F703F
colour.code.comment.nested=fore:#A0C0A0
colour.text.comment=fore:#0000FF,back:#D0F0D0
colour.other.comment=fore:#007F00
colour.embedded.comment=back:#E0EEFF
colour.embedded.js=back:#F0F0FF
colour.notused=back:#FF0000

colour.number=fore:#007F7F
colour.keyword=fore:#00007F
colour.string=fore:#7F007F
colour.char=fore:#7F007F
colour.operator=fore:#000000
colour.preproc=fore:#7F7F00
colour.error=fore:#FFFF00,back:#FF0000

section, just below the general font definitions which contribute too to 
unification.
(Continue reading)

missdeer | 6 Feb 12:57 2010
Picon

Re: Writing lexers in Lua

Sounds good.
Well, that's only a syntactic sugar which will push styler table
itself as
the first argument for the method,  no more differences.  You just
need
getting one more argument first from the Lua stack in those C
closures.

On Feb 6, 3:13 pm, Neil Hodgson <nyamaton... <at> gmail.com> wrote:
>    The implementation is not great due to my not understanding section
> Chapter 28 of "Programming in Lua"http://www.lua.org/pil/28.html.
> Rather than producing a new Lua type, I made the styler a table and
> then had the 'methods' use closures to access a C struct containing
> the state. This means that the call is styler.More() rather than
> styler:More() which would be more expected. I hope someone understands
> this aspect of Lua better than me and can fix the code.
>
>
>    Neil

--

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

Neil Hodgson | 6 Feb 23:08 2010
Picon

Re: Re: Colour scheme unification

   There could be some extension of the colour.* and font.* properties.

   Languages are often quite different and those differences are
reflected in the types of elements that people want highlighted and
the way they use colours and other style parameters for those
elements. I don't want to be unifying styles where the distinctions
are important to users of the language.

   Neil

--

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

Neil Hodgson | 6 Feb 23:12 2010
Picon

Re: Re: RFE: allow relative paths in session files (at user's discretion)

   Given the limited response to allowing relative paths in session
files, it would be reasonable to scale back the proposal to just have
it controlled by a property. User interface changes have a much bigger
maintenance cost.

   Neil

--

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

Philippe Lhoste | 7 Feb 16:14 2010
Picon
Picon

Re: Colour scheme unification

On 06/02/2010 23:08, Neil Hodgson wrote:
>     Languages are often quite different and those differences are
> reflected in the types of elements that people want highlighted and
> the way they use colours and other style parameters for those
> elements.

I agree. In general, I appreciate to have, say, keywords and numbers in 
the same colours in all languages. But sometime, colour juxtapositions 
don't work well in some languages (color density/spreading), so I might 
adjust them for better contrast.

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --

--

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

Philippe Lhoste | 7 Feb 16:17 2010
Picon
Picon

Re: RFE: allow relative paths in session files (at user's discretion)

On 06/02/2010 23:12, Neil Hodgson wrote:
>     Given the limited response to allowing relative paths in session
> files, it would be reasonable to scale back the proposal to just have
> it controlled by a property.

I haven't commented on this one, but sometime I think such feature can 
be useful. For example, working on a set of related files, on several 
sessions. Having relative paths, I would be able to put the session file 
in VCS (or just transport it) and continue to work on another computer 
with a different path scheme.
Of course, search/replace works too, but relative paths can be convenient.
Having that controlled by option is OK.

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --

--

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

Lor | 7 Feb 16:32 2010
Picon

Re: RFE: allow relative paths in session files (at user's discretion)


Neil:

>     Given the limited response to allowing relative paths in session
> files, it would be reasonable to scale back the proposal to just have
> it controlled by a property.

OK, I agree.
It's also my POV: better a less general solution than
a maintenance nightmare in the codebase.
So probably the property would be:

session.file.userelativepath=<yes|no> (or <true|false>)

This solves the main inconvenience of the current
implementation (at least for what I'm concerned).
This is also more coherent with other "on|off" properties
in SciTE (one less value range to remember! That's good! :-)

Thank you Neil.

Philippe:

> I haven't commented on this one, but sometime I think such feature can
> be useful.
> [...snip...]
> Having that controlled by option is OK.
Thank you for the feedback.

Lorenzo
(Continue reading)

Neil Hodgson | 7 Feb 22:12 2010
Picon

Re: Re: RFE: allow relative paths in session files (at user's discretion)

Lor:

> session.file.userelativepath=<yes|no> (or <true|false>)
>
> This solves the main inconvenience of the current
> implementation (at least for what I'm concerned).
> This is also more coherent with other "on|off" properties
> in SciTE (one less value range to remember! That's good! :-)

   The standard for SciTE properties is to use 0|1 for true|false.
While yes|no or true|false are more explanatory, users are likely to
try 0|1 because of experience with other properties.

   Neil

--

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


Gmane