headers
Neil Hodgson | 1 Jan 2009 03:19
Picon

Re: Warnings in lexers with GCC 4.3


   Committed updates for AU3, FORTRAN, Progress, TADS3 and Verilog.
These should have no functional changes, just stop some warnings.

   Neil

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-interest <at> googlegroups.com
To unsubscribe from this group, send email to scintilla-interest+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Balaam | 7 Jan 2009 08:19
Picon

Re: Auto Commenting out multiple lines on character pressed


That makes sense when I come back to this code, that's where I'll
start thank you.

On Nov 21 2008, 12:32 pm, "Neil Hodgson" <nyamaton... <at> gmail.com>
wrote:
> Balaam:
>
> > Now the problem I'm having is - which ever event I catch - the
> > selection data seems to have already gone.
>
>    Your application sees all the keys before Scintilla so you just
> need to implement the desired key in the application code. How you do
> so is platform dependent but you can look at how SciTE implements key
> commands.
>
>    Neil

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-interest <at> googlegroups.com
To unsubscribe from this group, send email to scintilla-interest+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Enrico Tröger | 7 Jan 2009 20:29
Picon
Favicon
Gravatar

[Patch] C89 comments in public header files

Hi,

attached is a patch which changes the used C++ style comments in the
public header files (all in include/) to C89 compliant comments (/* ...
*/).

This is not strictly necessary but enables users to compile the code
with C89 compilers which don't understand // ... in C code. Remember,
those header files are included in C source files when a C project is
using Scintilla.

So far we patched our Scintilla copy in Geany to use those C89 comments
but it'd be nicer if Scintilla itself would use them.

What do you think?

Regards,
Enrico

P.S.: I know C89 is pretty old and most modern compilers support C++
style comments but there are still people out there who want/have to
use real C89 compilers, existing bug reports on broken compilation have
proven this :(.

--

-- 
Get my GPG key from http://www.uvena.de/pub.asc
Attachment (scintilla_c89_comments.patch): text/x-diff, 26 KiB
Permalink | Reply | 3 comments |
headers
David | 7 Jan 2009 20:28
Picon

Margin markers not restored with Undo/Redo


Hello, I have written a modification of PyCrust that makes heavy use
of margin markers (PyCrust uses Scintilla's code via the
wxStyledTextControl).  Essentially, I use markers for code
organization and code folding.  The problem is that undo or redo can
destroy the markers and I can't think of a way to handle it on my end.

How hard would it be to make scintilla itself store and manage marker
information during undo and redo processes?  I have looked at the code
and could not easily tell for myself...

Alternatively, is it possible to easily track the undo history
externally so I can manage this information myself (essentially by
copying what scintilla does)?  I would prefer to build it into
Scintilla so others can use it, but this would suffice for my
purposes.

Thanks!
-David

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-interest <at> googlegroups.com
To unsubscribe from this group, send email to scintilla-interest+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 6 comments |
headers
Eric Promislow | 7 Jan 2009 23:25
Picon

Re: Margin markers not restored with Undo/Redo


Hey David,

You can track changes to the buffer using notifications like
SC_MOD_BEFOREDELETE, SC_MOD_INSERTTEXT,
SC_PERFORMED_USER, and SC_PERFORMED_UNDO
to capture the markers before they're about to be deleted,
and then work out ways to restore them if necessary.
I would squirrel away the markers with the actual associated
text on a BEFOREDELETE, and then if I see that I'm
about to insert text on an UNDO, and the line-numbers
and actual text match a saved marker, I'd restore it.
This sounds a bit hairy -- how long do you have to store these
markers for -- but there might be some potential here.

- Eric

On Wed, Jan 7, 2009 at 11:28 AM, David <david.n.mashburn <at> gmail.com> wrote:
>
> Hello, I have written a modification of PyCrust that makes heavy use
> of margin markers (PyCrust uses Scintilla's code via the
> wxStyledTextControl).  Essentially, I use markers for code
> organization and code folding.  The problem is that undo or redo can
> destroy the markers and I can't think of a way to handle it on my end.
>
> How hard would it be to make scintilla itself store and manage marker
> information during undo and redo processes?  I have looked at the code
> and could not easily tell for myself...
>
> Alternatively, is it possible to easily track the undo history
(Continue reading)

Permalink | Reply | 5 comments |
headers
David Mashburn | 8 Jan 2009 01:34
Picon

Re: Margin markers not restored with Undo/Redo


Eric,

Thanks for getting back to me so quickly.  My main concern is still to 
be able to either monitor or duplicate the undo history...  I don't have 
any problems monitoring when text is inserted or removed or when 
undo/redo's occur (PyCrust manually manages all keyed inputs, so I can 
just catch everything there).  And I really want to be able to make 
multiple undo/redo work properly or else the same problems will arise 
anyway after the first undo...

I guess the main issue is knowing for sure WHAT text is actually being 
included at each point in the undo buffer history.  I know scintilla 
uses a fairly sophisticated system for tracking which changes are 
considered to be part of the same action and which changes are part of a 
new action (my understanding of this is summarized below).

This was the reason that I wondered if duplicating this entire system 
(AND making sure everything matches up properly) might be more 
complicated than just adding marker memory to the CellBuffer's 
UndoHistory directly.

Any thoughts?  I'll be glad to help with coding changes to the scintilla 
source.  I'm pretty good with C++.  Or is scintilla's marker behavior 
that way intentionally?  It seems like other apps would benefit from 
this change, too...

Otherwise, would it be safe to say that I can assume that these are the 
rules for undo actions if I try to mimic the behavior myself in Python:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Neil Hodgson | 8 Jan 2009 03:03
Picon

Re: Margin markers not restored with Undo/Redo


David Mashburn:

> Any thoughts?  I'll be glad to help with coding changes to the scintilla
> source.  I'm pretty good with C++.  Or is scintilla's marker behavior
> that way intentionally?  It seems like other apps would benefit from
> this change, too...

   The current behaviour is intentional. For many uses of markers,
including them in Undo would be wrong. For example, in a debugging
session, I am unlikely to want a breakpoint reinstated if I return to
an earlier version. I am not opposed to adding a very simple way to
insert application actions into the Undo history.

> C: Cut/Paste/Selection Deleting actions are considered insertions or
> deletions.

   From the point of view of Undo all actions are insertions or deletions.

> D: I need to record the initial position of the cursor and the final
> position of the cursor for each action.  Upon undo, I go to the final
> position of the cursor and remove text backward (if inserted) or insert
> text forward (if deleted)

   The cursor position is not remembered in Undo. The position of the
insertion/deletion is. Not all actions are performed on the selection.
SCI_REPLACETARGET is often used because it doesn't affect the cursor.

   Neil
(Continue reading)

Permalink | Reply | 3 comments |
headers
Neil Hodgson | 8 Jan 2009 03:29
Picon

Re: [Patch] C89 comments in public header files

Enrico Tröger:

> attached is a patch which changes the used C++ style comments in the
> public header files (all in include/) to C89 compliant comments (/* ...
> */).

   Several of these (Accessor.h, KeyWords.h, Platform.h, PropSet.h,
SString.h, WindowAccessor.h) contains classes and are therefore C++ so
should never be compiled with a C89 compiler. Is there any benefit
from changing these? I'd prefer C++ code to produce errors when trying
to compile with a C compiler.

   Neil

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-interest <at> googlegroups.com
To unsubscribe from this group, send email to scintilla-interest+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 2 comments |
headers
Matt Sutton | 8 Jan 2009 19:09
Picon

Keyword lists that accept partial completion


Hello,
    I seem to remember seeing documentation somewhere regarding using
the ~ character inside a keyword list to denote that the characters
following the ~ are optional. For the life of me, I can't find that
piece of documentation.  Did I dream this up? Can someone point me to
the documentation if it exists?
Thanks,
Matt Sutton

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To post to this group, send email to scintilla-interest <at> googlegroups.com
To unsubscribe from this group, send email to scintilla-interest+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/scintilla-interest?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 1 comment |
headers
Neil Hodgson | 8 Jan 2009 22:59
Picon

Re: Keyword lists that accept partial completion


Matt Sutton:

>    I seem to remember seeing documentation somewhere regarding using
> the ~ character inside a keyword list to denote that the characters
> following the ~ are optional. For the life of me, I can't find that
> piece of documentation.  Did I dream this up? Can someone point me to
> the documentation if it exists?

   This is only used in lexers that want the feature. Currently only
the sql lexer allows this as SQL keywords can be abbreviated. The call
is WordList::InListAbbreviated.

   Neil

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

Gmane