headers
Keith | 6 Feb 08:27
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.
Permalink | Reply | 3 comments |
headers
Philippe Lhoste | 6 Feb 10:49
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.

It is already used in some common lexers, for example the cpp.properties:

# Comment: /* */.
style.cpp.1=$(colour.code.comment.box),$(font.code.comment.box)
# Line Comment: //.
style.cpp.2=$(colour.code.comment.line),$(font.code.comment.line)
# Doc comment: block comments beginning with /** or /*!
style.cpp.3=$(colour.code.comment.doc),$(font.code.comment.doc)
# Number
style.cpp.4=$(colour.number)
# Keyword
style.cpp.5=$(colour.keyword),bold
# Double quoted string
style.cpp.6=$(colour.string)
# Single quoted string
style.cpp.7=$(colour.char)
# UUIDs (only in IDL)
style.cpp.8=fore:#804080
# Preprocessor
style.cpp.9=$(colour.preproc)
# Operators
style.cpp.10=$(colour.operator),bold

Now, some lexers have more states than standard colours (Perl for 
example), some people might prefer to have distinct colour schemes (to 
distinguish JavaScript work from C++ work for example), and so on.
Moreover, each lexer's properties is made by contributors, reflecting 
their preferences.
These colour schemes are provided as "reasonable base", made to be 
customized by everybody.

Now, I can't talk for Neil, but I think that you can do your unification 
on your preferred languages for yourself, preferably based on these 
standard colours, then propose the changes. They might be approved... or 
not, or with changes.
IIRC, that's how I proposed these standard colours (or extended them, I 
don't recall exactly).

-- 
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.
Permalink | Reply | 2 comments |
headers
Neil Hodgson | 6 Feb 23:08
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.
Permalink | Reply | 1 comment |
headers
Philippe Lhoste | 7 Feb 16:14
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.
Permalink | Reply | 0 comments |
headers
Neil Hodgson | 6 Feb 08:13
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.

   Configuring a script lexer is indicated by using a lexer name that
starts with "script_". There can be multiple script lexer languages
mentioned in the properties files at once although there is only one
OnStyle. All script languages use the same numeric lexer ID
SCLEX_CONTAINER. The lexer name is available as a member of the styler
object.

   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.

   The current code has *not* been committed to CVS. It is available from

http://www.scintilla.org/scite.zip Source
http://www.scintilla.org/wscite.zip Windows executable

   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.
Permalink | Reply | 2 comments |
headers
missdeer | 6 Feb 12:57
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...@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.
Permalink | Reply | 1 comment |
headers
Neil Hodgson | 7 Feb 22:40
Picon

Re: Re: Writing lexers in Lua

missdeer:


*



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


   OK, uploaded a version that works like that along with updated
documentation. It does seem added complexity and also a bit wasteful
to have both the closure pointing to the C struct as well as the
table.

   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.
Permalink | Reply | 0 comments |
headers
Neil Hodgson | 28 Jan 06:11
Picon

GTK+ 2.02 does not respond while executing tool

   When running a tool from SciTE on GTK+ 2.02, it is no longer
possible to interact with the user interface such as selecting some
text with the mouse. It is easy to reproduce this: type the command
"sleep 5" into the output pane. This was caused by the change from
using a FIFO to using anonymous pipes. If the FIFO code is restored
then SciTE is responsive again. Observed on Fedora 11.

   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.
Permalink | Reply | 3 comments |
headers
Leledumbo | 28 Jan 07:54
Picon
Favicon

Re: GTK+ 2.02 does not respond while executing tool

Does it have any impact on Windows?

On Jan 28, 12:11 pm, Neil Hodgson <nyamaton...@gmail.com> wrote:

*



>    When running a tool from SciTE on GTK+ 2.02, it is no longer
> possible to interact with the user interface such as selecting some
> text with the mouse. It is easy to reproduce this: type the command
> "sleep 5" into the output pane. This was caused by the change from
> using a FIFO to using anonymous pipes. If the FIFO code is restored
> then SciTE is responsive again. Observed on Fedora 11.
>
>    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.
Permalink | Reply | 1 comment |
headers
Neil Hodgson | 28 Jan 08:09
Picon

Re: Re: GTK+ 2.02 does not respond while executing tool

Leledumbo:


*



> Does it have any impact on Windows?


   No.

   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.
Permalink | Reply | 0 comments |
headers
Neil Hodgson | 29 Jan 02:23
Picon

Re: GTK+ 2.02 does not respond while executing tool

   There is now a modification in CVS to set the pipe file descriptor
read by SciTE to O_NONBLOCK. This seems to have fixed the problem.

   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.
Permalink | Reply | 0 comments |

Gmane