Summary: | Code folding with markers like in gvim or emacs' folding-mode | ||
---|---|---|---|
Product: | [Applications] kate | Reporter: | Christian Kruse <ckruse> |
Component: | syntax | Assignee: | KWrite Developers <kwrite-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | trapni |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/ktexteditor/a4b952b32c4a0ee4300df4c2833de5dd81de2cbb | Version Fixed In: | |
Sentry Crash Report: |
Description
Christian Kruse
2004-12-19 22:05:27 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. 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? 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? It is /* sometext {{{ some text */ and /* sometext }}} sometext */ where sometext is optional. 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 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 {{{/}}}? 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. 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) 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. > 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. 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? I think this would really be nice. I would be zealous. 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. 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. 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 :) 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 :( 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? > 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)
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. 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. 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. please ignore my typo: s/CStyleFolds/CCommentStyleFolds/g - it's just meta anyways, sorry 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? Support of option (1) would be great. 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. Any news about /* {{{ */ this /* }}} */? 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 |