user configurable explicit fold points

[udo lechner]

> Options, like variables should be positively named rather than
> include a negation like fold.cpp.not.syntax.based. Note that all
> references inside Fold are negated again like:
>    if (!options.foldNotSyntaxBased

Goal of naming it inverted, was, to reach existing property files will run
with same behavior like before. Naming it positively needs to be add
fold.cpp.SyntaxBased=1
to existing porperty files, because OptionSet can't force empty string
to default to true like GetPropertyInt("...", 1) - therefore I suggested
to add this feature to OptionSet. Same problem also arise with
fold.cpp.comment.multiline (and has arised with fold.cpp.comment.explicit),
but the effects are not as crass in this case, if the corresponding
settings are missed.

But if this isn't a problem, I appreciate it to name it without the "not"!

I've also considered your other hints - hope my version of LexCPP.cxx
is now ready to be included in scintilla's code base?

I would then add these features to D, Basic and ASM lexers
(I've them almost ready). Further goals are to implement these features
to all lexers, which haven't any folding function yet, then to thoses
lexers, which folders are derived from C++ or Basic folder
- as desired, I will deliver a patch, which converts these lexers
to lexer objects first.

dlchr

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

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

# Folding
fold.cpp.syntax.based=1
fold.cpp.comment.multiline=1
fold.cpp.comment.explicit=1
#defaults for fold.cpp.explicit.start=//{ and fold.cpp.explicit.end=//}
#  can be replaced by defining custom strings, e.g. //[ and //]
#fold.cpp.explicit.start=//[
#fold.cpp.explicit.end=//]
#if fold strings are set to something like /*{{{ and /*}}} (Origami/WinF style fold strings),
#  enable fold.cpp.search.overall to search fold strings beyond line comment start
#fold.cpp.search.overall=1
#fold.at.else=1   

[dlchnr]

failed attempt to send a reply to a message from the e-mail account
in order to mail an attachment too - which subject has to be used,
the mail will be sorted under the original topic?

[KHMan]

If you use Reply-to, threads should work the standard way, but not
if a posting is started separately.

I don't believe I've ever tried posting attachments to the list
myself; my personal policy is to not occupy bandwidth like that.

There are a lot of other options -- you can use a free pix service
or a free website.

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

[dlchnr]

> If you use Reply-to, threads should work the standard way, but not
> if a posting is started separately.

I've used the Reply button from Gmail's Webinterface, which creates
a new thread
http://groups.google.com/group/scintilla-interest/browse_thread/thread/15a85866541d25ea#
with stupid topic, composing a new mail creates a second thread with
same topic.
I suppose now, first approach hasn't work, because I've selected daily
overview instead
separate e-mails.

>
> I don't believe I've ever tried posting attachments to the list
> myself; my personal policy is to not occupy bandwidth like that.
>
> There are a lot of other options -- you can use a free pix service
> or a free website.

But because it seems to be a bad idea, to attach files to the
messages,
I will do futhermore that, what I've considered to be a workaround
until now.

[Neil Hodgson]

udo lechner:

> to existing porperty files, because OptionSet can't force empty string
> to default to true like GetPropertyInt("...", 1) - therefore I suggested
> to add this feature to OptionSet.

You didn't comment on my explicit.diff patch to avoid SciTE sending
through properties that are not set. It will still forward properties
that are set to empty.

> I've also considered your other hints - hope my version of LexCPP.cxx
> is now ready to be included in scintilla's code base?

Getting closer. The explanation for fold.cpp.search.overall could
be improved a bit I think from
"Set this property to 1 to enable searching explicit fold points
beyond line comment start - "
"e.g. /*{{{ and /*}}} will be found only, if this option is enabled.");
to something more like
"Set this property to 1 to enable explicit fold points anywhere, not
just in line comments"
with maybe the name fold.cpp.explicit.anywhere

> # Folding
> fold.cpp.syntax.based=1

The convention in SciTE properties files is to include a commented
example setting which is different from the default. That way you can
alter the default behaviour by uncommenting the setting:
#fold.cpp.syntax.based=0

Neil

[dlchnr]

> You didn't comment on my explicit.diff patch to avoid SciTE sending
> through properties that are not set. It will still forward properties
> that are set to empty.

Sorry, I haven't realize, that you have continued my first thread
and solved the problem, which boss me. I was surprised, how fast
my proposal to extend Option.h, was rejected by you, now I can
understand that :-).

>> ... hope my version of LexCPP.cxx is now ready

>> to be included in scintilla's code base?

> Getting closer. ...

I've included your suggestions, they are better than my formulations.

dlchnr

http://dlchnr.dl.funpic.de/in/lxCPP.zip

# Folding
#fold.cpp.syntax.based=0
#fold.cpp.comment.multiline=0
#fold.cpp.comment.explicit=0

#defaults for fold.cpp.explicit.start=//{ and
fold.cpp.explicit.end=//}
# can be replaced by defining custom strings, e.g. //[ and //]
#fold.cpp.explicit.start=//[
#fold.cpp.explicit.end=//]
#if fold strings are set to something like /*{{{ and /*}}} (Origami/

WinF style fold strings), enable
# fold.cpp.explicit.anywhere, allowing explicit fold points being

anywhere, not just in line comments

#fold.cpp.explicit.anywhere=1
#fold.at.else=1

[Neil Hodgson]

dlchnr:

> I've included your suggestions, they are  better than my formulations.

OK, committed.

Neil