headers
Philippe Lhoste | 1 Jun 2005 02:09
Picon

Re: Re: Working towards OSX SciTE

Neil Williams wrote:
> I will continue to debug this. If I can find the 
> energy I will set up a Linux development 
> environment and do some back to back comparisons. 
> As always any words of wisdom or encouragement 
> would be greatly appreciated.

Yes! I follow this thread with interest.
My wife has an iBook for some time, and still own an old Mac (Mac OS 
9... alas), so when I made some small work on the iBook, I missed my 
dear editor... So, continue, even if I have no use currently, I would be 
  happy to have SciTE available on this platform if the opportunity 
comes again.

--

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --
Permalink | Reply | 0 comments |
headers
Robert Roessler | 1 Jun 2005 06:36
Favicon

Re: [scite] eiffel mode highlighting problem

Valéry Croizier wrote:

> There must be something wrong in the Eiffel lexer : after parentheses, 
> names starting with a dot are highlighted like numbers, which is very 
> annoying since this occurs frequenly. For instance :
> (a).abs -- ".abs" is highlighted like a number
> (a) .abs -- (one space before the dot) same problem
> (a). abs -- (one space after the dot) the dot is highlighted like a number

First, this type of question/comment probably is more a "Scintilla" 
issue, since it provides the lexing services to SciTE. :)

But yes, after looking at the LexEiffel.cxx source file, I could 
believe that something might be wrong...

1) '.' shows up in *both* isEiffelOperator() and IsAWordChar()

2) the "if (sc.state == SCE_EIFFEL_NUMBER)" state then proceeds to 
switch to SCE_EIFFEL_DEFAULT if the new char FAILS IsAWordChar()

3) when in the SCE_EIFFEL_DEFAULT state, a SCE_EIFFEL_NUMBER state may 
be entered if a '.' is seen

I do not use Eiffel, so 1) may not be a problem, but 3) is suspect and 
2) is likely a bug.

My USD 0.02.

Robert Roessler
robertr <at> rftp.com
(Continue reading)

Permalink | Reply | 3 comments |
headers
SourceForge.net | 1 Jun 2005 09:00
Picon
Favicon

[ scintilla-Feature Requests-1212471 ] <%' comment%> problem

Feature Requests item #1212471, was opened at 2005-06-01 07:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=352439&aid=1212471&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
Priority: 5
Submitted By: Edward Yang (neo_in_matrix)
Assigned to: Nobody/Anonymous (nobody)
Summary: <%' comment%> problem

Initial Comment:
Try this simple ASP file:

start of document
<%' this is a comment%>
normal html content

It seems the lexer does not consider the comment in all
cases (in this case, it thinks the starting ' is a
starting single quote).

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

You can respond by visiting:
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 1 Jun 2005 09:44
Picon
Favicon

[ scintilla-Feature Requests-1212501 ] Rebol lexer

Feature Requests item #1212501, was opened at 2005-06-01 09:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=352439&aid=1212501&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
Priority: 5
Submitted By: Prodoc (prodoc)
Assigned to: Nobody/Anonymous (nobody)
Summary: Rebol lexer

Initial Comment:
At the moment Scintilla doesn't have support for Rebol
syntax highlighting, does it? There's no list of all
supported languages on the Scintilla website so I can
only judge by the languages supported in Notepad++.

It would be nice to see Rebol support in Scintilla
though ;-)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=352439&aid=1212501&group_id=2439
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 1 Jun 2005 18:53
Picon
Favicon

[ scintilla-Feature Requests-1212868 ] Option to remove command and exit code from output.

Feature Requests item #1212868, was opened at 2005-06-01 09:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=352439&aid=1212868&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
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Option to remove command and exit code from output.

Initial Comment:
I often use SciTE to write little ruby scripts to parse and 
spit out a bunch of text. I would like an option to remove 
the command-line which is prepended to the output, and 
the exit code which follows it (if the exit code was 0).

I realize that enabling this option would make it 
impossible to reliably distinguish between the output of 
multiple non-cleared runs. I would be willing to give up 
this feature for the ability to easily select all and copy 
the output.

----------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Sutton | 2 Jun 2005 01:50
Favicon

Auto completion question

Hello,

I would like to know if it is possible to display, in effect, a call tip window right justified against an auto completion dropdown.  The purpose of the window is to supply additional information regarding the current selection in the auto completion dropdown. Furthermore, I would like the height of the window to be the same as the height of the auto completion dropdown.  Right now, it doesn't appear to me that this is currently possible in Scintilla; however, since I haven't used the control extensively, I'm posing the question to the list to gain clarification.  The other requirement that I have is to modify the contents of this box whenever the selection in the auto completion list changes.  I have a screen capture I can send to whomever is interested which displays this functionality in a commercial editor.  If this is currently not possible, I think it would be a nice addition.  If it is currently possible, a little direction would be appreciated. Assuming it is not possible, I would also like to hear what other people think about the idea, how much effort it would likely take, where to start, etc...  Lastly, in an attempt not to sound ungrateful, I also realize the tremendous effort that has gone into Scintilla and would like to be clear that I am not unappreciative.   

Thanks for your help,

Matt Sutton

_______________________________________________
Scintilla-interest mailing list
Scintilla-interest <at> lyra.org
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
Permalink | Reply | 1 comment |
headers
Neil Hodgson | 2 Jun 2005 02:33
Picon

Re: [ scintilla-Feature Requests-1210337 ] Perl POD highlighting and folding

[Redirected back to list in case there are opinions on  verbatim 
paragraphs.]

    Hi Kein-Hong,

> Attached is a patch for folding pod headings. It doesn't fold the entire 
> pod section anymore.

    OK, committed.

> There are 2 style slots (16, 31) left to put the style for verbatim 
> paragraphs before the number of style bits for Perl need to be changed, 
> so one (31?) can be used for verbatim paragraphs. I suppose Piotr 
> prefers a fixed-width font for verbatim paragraphs.
> 
> Are there any objections or comments to having a style for verbatim 
> paragraphs? If it is a Go, I will take a stab at it shortly.

    There hasn't been any feedback so this looks fine to me. Not using 
Perl, I don't have a good feel for which syntactic elements need to be 
distinguished.

    Neil
Permalink | Reply | 1 comment |
headers
Neil Hodgson | 2 Jun 2005 02:52
Picon

Re: Auto completion question

Matt Sutton:

> I would like to know if it is possible to display, in effect, a call tip
> window right justified against an auto completion dropdown.  

   There is no support for this in Scintilla. It may be possible to
implement it yourself in the container application.

> The purpose of
> the window is to supply additional information regarding the current
> selection in the auto completion dropdown. 

   There is no notification when selection changes in the
autocompletion list. You could use platform features (such as
subclassing on Windows) to watch the list.

> Assuming it is not possible, I would also like to hear what
> other people think about the idea, how much effort it would likely take,
> where to start, etc...  

   Each platform would have to be modified to detect autocomplete
selection changes. Once the platform code is there adding a new
notification is simple. If you want to implement this for just one
platform, that is OK.

   If the extra window was just a small variation of the current
calltip code with the ability to be visible at the same time as the
autocompletion then that should be easy and OK. I don't want to
incorporate a new type of tool window as I think bundling autocomplete
and calltips so tightly with Scintilla was a mistake as it makes it
harder for applications to modify these or add similar features. A
better approach would have been to provide generic interfaces for
these features so that they could be implemented as required by
containers and then some implementations could be included in the
Scintilla package.

   Neil
Permalink | Reply | 0 comments |
headers
Neil Hodgson | 2 Jun 2005 03:11
Picon

Re: Patch for GET properties V2

Robert Roessler:

> I had a need for a "mini properties database" in an app which is using
> Scintilla, and decided that the Scintilla one is up to the task -
> especially with its macro expansion/replacement capabilities. :)

   I'm still undecided about this so don't want to ask you to do more
work yet, but ...

> SCI_GETPROPERTYEXPANDED(const char *key, char *value)
> 
> Functions the same as SCI_GETPROPERTY, except that the returned string
> will have all defined macro expansion/replacement performed.

   This needs to say what macros look like.

> A note on my implementation: as Scintilla currently classifies
> SCI_SETPROPERTY as one of the functions conditionally included by
> SCI_LEXER, I have added the above three functions to this same
> grouping.  But given that [at least] I see these as being useful
> independent of lexers, one (i.e., Neil) might want to consider moving
> all FOUR of the Scintilla "properties" functions out of this grouping
> - or not.

   The SCI_LEXER variant is the big fat Scintilla which
resource-constrained applications can choose not to enable.

   APIs should be defined in Scintilla.iface.

   Neil
Permalink | Reply | 4 comments |
headers
Robert Roessler | 2 Jun 2005 06:13
Favicon

Re: Patch for GET properties V2

Neil Hodgson wrote:

> Robert Roessler:
> 
> 
>>I had a need for a "mini properties database" in an app which is using
>>Scintilla, and decided that the Scintilla one is up to the task -
>>especially with its macro expansion/replacement capabilities. :)
> 
> 
>    I'm still undecided about this so don't want to ask you to do more
> work yet, but ...

Perhaps I misconstrued your previous reply to me?

"If you really want to do this and there is no large increase in code 
   then it can go in due to symmetry."

>>SCI_GETPROPERTYEXPANDED(const char *key, char *value)
>>
>>Functions the same as SCI_GETPROPERTY, except that the returned string
>>will have all defined macro expansion/replacement performed.
> 
> 
>    This needs to say what macros look like.

Since they are using Scintilla's existing "properties" facility, they 
look exactly like... Scintilla property macros - perhaps we are just 
having a naming-based confusion here (given that you do not use the 
word "macro" for this replacement operation)?

In any case, they are defined in the documentation for the current 
SCI_SETPROPERTY function... and at such time as these new calls become 
"standard" in Scintilla, I will add the appropriate text to 
ScintillaDoc.html... as I have for most (all?) of the features/changes 
implemented or requested by me to date - although the site is not 
being updated to reflect said changes. :)

>>A note on my implementation: as Scintilla currently classifies
>>SCI_SETPROPERTY as one of the functions conditionally included by
>>SCI_LEXER, I have added the above three functions to this same
>>grouping.  But given that [at least] I see these as being useful
>>independent of lexers, one (i.e., Neil) might want to consider moving
>>all FOUR of the Scintilla "properties" functions out of this grouping
>>- or not.
> 
> 
>    The SCI_LEXER variant is the big fat Scintilla which
> resource-constrained applications can choose not to enable.

As you would say, "OK".

>    APIs should be defined in Scintilla.iface.

I have added an updated Scintilla.iface to the getprops.zip on my 
site.  I am a little unsure about the get/fun usage here - I used get, 
but maybe these should use fun?

Robert Roessler
robertr <at> rftp.com
http://www.rftp.com
Permalink | Reply | 3 comments |

Gmane