Bug 95486 - Code folding with markers like in gvim or emacs' folding-mode
Summary: Code folding with markers like in gvim or emacs' folding-mode
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Applications
Component: syntax (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-19 22:05 UTC by Christian Kruse
Modified: 2014-09-13 22:04 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Kruse 2004-12-19 22:05:27 UTC
Version:            (using KDE KDE 3.2.3)
Installed from:    Compiled From Sources

I like folding with markers like it is used in gvim or emacs' folding mode (e.g. /* {{{ fold start */ ... /* }}} */). I don't know how complicated it is, but it would be _very_ nice (folding on code basis cannot work with complicated source, e.g. function defintions modified by #ifdefs).
Comment 1 Dominik Haumann 2004-12-19 22:22:23 UTC
kate supports region markers like this:
//BEGIN text
//END
We do not support /* }}} */ or something like that.
If your code confuses codefolding because of complicated #ifdefs I'd rather suggest so simplify it, as we will not remove folding for { ... } blocks.

Please tell us if the //BEGIN ... //END region markers is enough for what you need.
Comment 2 Christian Kruse 2004-12-19 23:49:27 UTC
Yes, I know about //BEGIN and //END. But in large projects than you have /* {{{ */ from people using emacs/vim and //BEGIN //END from people using kate. This is really bugging me. It would _really_ be nice if kate also supports vim-like markers.

Even, simplifying #ifdefs is not possible sometimes, why can't you just make it configurable to deactivate folding on code basis?
Comment 3 Dominik Haumann 2004-12-20 00:10:43 UTC
We cannot make it "configurable" because highlighting rules are defined in the syntax highlighting files. We could add vim like region markers (how do they work?).
Pros: compatibility for vim/emacs
Cons: speed issue: RegExpr rules are slow (compared to other rules).

Is /* {{{ */ a "fixed sequence" or is it variable like /* some more spaces {{{ */?

Anders, what do you think?
Comment 4 Christian Kruse 2004-12-20 00:17:42 UTC
It is /* sometext {{{ some text */ and /* sometext }}} sometext */ where sometext is optional.
Comment 5 Anders Lund 2004-12-20 11:41:08 UTC
On Monday 20 December 2004 00:10, Dominik Haumann wrote:
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>
> http://bugs.kde.org/show_bug.cgi?id=95486
>
>
>
>
> ------- Additional Comments From dhdev gmx de  2004-12-20 00:10 -------
> We cannot make it "configurable" because highlighting rules are defined in
> the syntax highlighting files. We could add vim like region markers (how do
> they work?). Pros: compatibility for vim/emacs
> Cons: speed issue: RegExpr rules are slow (compared to other rules).
>
> Is /* {{{ */ a "fixed sequence" or is it variable like /* some more spaces
> {{{ */?
>
> Anders, what do you think?

{{{ is quite common, jed uses it too, and if jowenn hadn't started using BEGIN 
and END, I'd have suggested that.

I think we should support it, and maybe even encourage using it (by replacing 
our current markers in our own files).

I wonder if it would be worth trying to make both versions mandatory or 
automatically supported.

-anders
Comment 6 Dominik Haumann 2004-12-20 17:25:17 UTC
Ok, I'd agree to replace BEGIN/END with {{{/}}}, but I don't know whether it's good to support both (I'd rather drop the old on then).
Is somewhere a page that exactly defines the syntax of {{{/}}}?
Comment 7 Anders Lund 2004-12-20 17:43:07 UTC
Emacs/vim/jed manuals? The only cli editor i use these days is nano, since I use kate or kwrite for most things :-)
I think we are somehow stuck with BEGIN/END since we have it, but we could make a survey of some sort. I'm personally not aware of usage outside kate code and my own files. 
One thing that I like about the current syntax in kate is the built in labelling -- the fact that the rest of the line is highlighted. But that could probably be easily kept, allthough I'm not aware if additional text on the line is supported by other editors.
Comment 8 Christian Kruse 2004-12-20 17:58:31 UTC
Vim and emacs do support. /* {{{ text */ ... /* }}} */ results in following:

http://www.defunced.de/pics/screenshots/2004-12-20-175644_2560x1024_scrot.png

(172K, sorry but I have no imaging software installed)
Comment 9 Anders Lund 2004-12-20 18:13:13 UTC
And what is the actual line? It looks like the '{{{' string is hidden?
As far as I can recall from jed, it doesn't require the '{{{' to be in a comment, that is only for the sake of the compiler. IIRC, it would take *any* matchhing '{{{' and '}}}' for a foldable region.

What we could do was creating a external file or virtual hl, and import that anywhere desired -- or maybe we could even force import into contexts with 'comment' in their names automatically, or based on a property.
Comment 10 Christian Kruse 2004-12-20 20:12:35 UTC
> And what is the actual line? It looks like the '{{{' string is hidden?

This is correct. The line itself looked like this:

/* {{{ This is a test */

> As far as I can recall from jed, it doesn't require the '{{{' to be in a comment, that is only for the sake of the compiler. IIRC, it would take *any* matchhing '{{{' and '}}}' for a foldable region. 

This is correct for gvim, but not for Emacs' folding-mode. In Emacs it has to be comment-marker {{{ (you can configure what comment-marker can be, e.g. my configuration for the folding-mode in emacs is as follows:

  (let* ((ptr (assq 'text-mode folding-mode-marks-alist)))
  (setcdr ptr (list "# {{{" "# }}}")))

This makes folding-mode also working in Perl and PHP). I think it would be ok to match 'comment-sign {{{' only, I didn't see any {{{ without comment sign before it neither I saw 'comment-sign test {{{'. But this is of course up to you.
Comment 11 Dominik Haumann 2004-12-21 00:23:08 UTC
As Anders already pointed out we have an extra color for region markers.
I think it would be easy to add a RegExp like \{\{\{.*(?=(\*/)) for a beginRegion and .*\}\}\} for an endRegion, then we still had the extra color.
What do you think?
Comment 12 Christian Kruse 2004-12-21 09:29:08 UTC
I think this would really be nice. I would be zealous.
Comment 13 Anders Lund 2004-12-21 10:53:13 UTC
Dominik: My main concern is that it needs to go in every file. Allready, even we pushed the BEGIN/END folding in many highlights, it is missing in some. I think that if this works in C/C++ files, it will be expected to work in any other file as well.
Comment 14 Dominik Haumann 2004-12-21 20:55:39 UTC
Yup, I thought about it: We can not include the rule with includeRues.
So every file has to be touched by hand (right now: 20 files). As I think compatibility with other editors has a high priority I'd volunteer to do this even in this year :)
It would go into KDE 3.4 then, if you agree.
Comment 15 Anders Lund 2004-12-21 21:07:45 UTC
In fact I consider if we can automate this completely.
I am allready considering how to make some sort of injection method, so that php and similar languages can have modified highlight objects created automatically, which means injecting a rule into the top of every context. Something similar could be used, just that in this case any comment context, or if noe found, context 0, should have a rule injected. It would make it work *allways* also for new highlights. But so far it's mostly a vague idea :)
Comment 16 Dominik Haumann 2004-12-30 19:14:44 UTC
I now tried to add {{{...}}} folding for c/cpp. It is not possible right now, example:
/* <- opens a comment folding
text {{{ <- opens a block folding
*/ <- closes the comment folding
...

This does not work because the */ closes the {{{ region marker.
So, as far as i can see: either we remove /* */ comment folding and drop {{{ }}} or the other way round.

Sure, I could add {{{...}}} support for // comments, but that won't really help, as they are widely used in /**/ comments (I looked in several files from the linux kernel).
...I'm sorry :(
Comment 17 Anders Lund 2005-03-24 11:53:45 UTC
can't we create a file that supports that, and import that into comment context in any file that wants t support it? simply,
'{{{<text>' starts a region, and '<text>}}}' ends one?
Comment 18 Dominik Haumann 2005-03-24 18:29:40 UTC
> can't we create a file that supports that, and import that into comment
> context in any file that wants t support it? simply, '{{{<text>' starts a
> region, and '<text>}}}' ends one?

In general: yes. But the code folding is too buggy in order to support it.
/* {{{ <- this starts two regions, where ...
*/     <- ... the one ends here, but the other goes on. This is *not*
          nested, and somehow leads to bugs (like in html: ok is
          <a><b></b></a> but <a><b></a></b> is not recommended)
Comment 19 Christian Parpart 2005-11-30 08:12:03 UTC
I would really like to make this bug alive just once again.

in fact, I'm a very happy long-term vim user, however, I'm trying to use kdevelop for the rather large project in favor of an integrated debugging environment (because I got impressed by Visual Studio 2005 for C#).

Though, I'm using {{{ and }}} extensivily as well, and no, my code is not unreadable because it's written shit. These are just complex (meaning: large) projects.

Furthermore, I do not believe that introducing //BEGIN and //END (w/o supporting already well known markers) had been a good idea, as, in fact, lots of users are already familar with {{{ and }}} anyways.


Folding code based on scope isn't just always what you want or even need.

Regards,
Christian Parpart.
Comment 20 Christian Kruse 2005-11-30 10:41:10 UTC
What should I say? I _totally_ agree with Christian Parpart. The lack of {{{ }}} markers are the most important reason, why I don't use kate/kdevelop.
Comment 21 Christian Parpart 2005-11-30 15:28:18 UTC
while reading back.... I'd like to highlight, that (at least 4 vim), the {{{ and }}} markers does certainly not require to be located within a comment like /* */ or //.

although, I'd like to note, that you may still support comment folding.
just layer the {{{ and }}} marker parsing atop the comment folding.

EBNF alike folding parser grammer:

Goal                 ::= [CCommentStyleFolds]...
CStyleFolds          ::= [ScopeStyleFolds] '/*' ScopeStyleFolds '*/'
ScopeStyleFolds      ::= [VimStyleFolds] '{' VimStyleFolds '}'
VimStyleFolds        ::= TextNoVimFoldMark '{{{' TextNoVimFoldMark '}}}'
TextNoVimFoldMark    ::= <any char except sequence '{{{' and '}}}'>

If my head isn't over heated now, then this little grammar should make us *all* happy with regards to support all the marks we want, and yet, the vim-style fold markers are parsed properly with respect to the scope and comment folds w/o loosing functionality.

regards,
Christian Parpart.
Comment 22 Christian Parpart 2005-11-30 15:31:47 UTC
please ignore my typo: s/CStyleFolds/CCommentStyleFolds/g - it's just meta anyways, sorry
Comment 23 Dominik Haumann 2005-11-30 18:27:01 UTC
Ok, it would be easily possible to add support for constructs like this:
(1) /* {{{ text */   and   /* }}} text */.

Right now, it is not possible to add support for constructs like
(2) /* text {{{ text */ or /* text }}} text */.

The reason why (2) is not possible is due some bugs in code folding, i.e. nested regions like
begin A
begin B
end A
end B
do not work very well.

So - is option (1) enough?
Comment 24 Christian Kruse 2005-11-30 18:33:15 UTC
Support of option (1) would be great.
Comment 25 Anders Lund 2005-11-30 18:51:26 UTC
FYI, I plan to add (if we can all agree in the kate developer team) a way to push a context into the beginning of ALL contexts in a highlight. The idea is to make generation of various PHP/ASP/EmbPerl/Mason etc highlights automatic and dynamic.

Such a mechanism would make adding support for {{{ and }}} very easy too, just one rule in the xml file.

As for the mixing, folding regsions are balanced by the folding system in kate, no worry needed for that.
Comment 26 Andrew O. Shadoura 2007-10-06 23:33:01 UTC
Any news about /* {{{ */ this /* }}} */?
Comment 27 Christoph Cullmann 2014-09-13 22:04:47 UTC
Git commit a4b952b32c4a0ee4300df4c2833de5dd81de2cbb by Christoph Cullmann.
Committed on 13/09/2014 at 22:01.
Pushed by cullmann into branch 'master'.

use alert hl to have generic {{{ / }}} folding support
bit of a hack, but better than introducing one more hl we include everywhere
that wish is close to 10 years old :)

M  +3    -1    src/syntax/data/alert.xml

http://commits.kde.org/ktexteditor/a4b952b32c4a0ee4300df4c2833de5dd81de2cbb