Regardless of in-parens-contin theres no ambiguity for either leadin token (##{ or /#) if the
block comment delimiters always suck up the entire line ( as per patch implementation).
(or if the 2 (or 3) char token is always distinguished from the single char ones that are its components)
Forums
Block or Multiline Comment
20 posts
• Page 2 of 2 • 1, 2
Re: Block or Multiline Comment
New patch on ticket#20 utilising /# and #/ instead of ##{ and ##} as suggested
- full line commenting including lines containing final #/
- full line commenting including lines containing final #/
- hopscc
- Posts: 632
- Location: New Plymouth, Taranaki, New Zealand
Re: Block or Multiline Comment
Your patch is applied. I also added support for nesting the block comments.
I'll eventually add support for inline /# ... #/ comments.
I'll eventually add support for inline /# ... #/ comments.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: Block or Multiline Comment
2 cents - I certainly vote for a multiline comment. In Python it is tiresome to highlight a section and get the editor to comment it rather than just typing something at the beginning and end. I'd also vote for them to be nestable. Unnestable multiline comments are a pain in the butt when commenting out large chunks of code temporarily.
seems as nice and Cobra/Pyhonesque as
But doesn't hae to worry about conflicting with divide + single line comment.
If using syntax highlighting it wont be confused with a single line comment because everything after will be coloured as a comment, especially if forgetting to put the /#. I'd be suprised editors can't handle that # and #/ are starting different types of comments, but I defer to others on that one.
- Code: Select all
#/ ... /#
seems as nice and Cobra/Pyhonesque as
- Code: Select all
/# ... #/
But doesn't hae to worry about conflicting with divide + single line comment.
If using syntax highlighting it wont be confused with a single line comment because everything after will be coloured as a comment, especially if forgetting to put the /#. I'd be suprised editors can't handle that # and #/ are starting different types of comments, but I defer to others on that one.
call me Nev.
- nevdelap
- Posts: 61
- Location: Buenos Aires
Re: Block or Multiline Comment
But Cobra has this already. My last comment was "I'll eventually add support for inline /# ... #/ comments" (note the word "inline") meaning the ability to say:
And we have that now.
I use block comments all the time. And the fact that they can be nested rocks.
x = /# -1 #/ * y
And we have that now.
I use block comments all the time. And the fact that they can be nested rocks.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: Block or Multiline Comment
Ah sweet!!! I searched for multiline comments and didn't find anything later than that post. I shouldn't have assumed when I'm reading couple of year old posts.
Thanks man.
The gedit cobra.lang doesn't handle nested comment syntax highlighting. I'll look into it.
Thanks man.
The gedit cobra.lang doesn't handle nested comment syntax highlighting. I'll look into it.
call me Nev.
- nevdelap
- Posts: 61
- Location: Buenos Aires
Re: Block or Multiline Comment
Cool. I use gedit from time to time and overall it's syntax highlighting of Cobra is pretty good. Working out the last few wrinkles would be great. Maybe Todd A can chime in as well--he did the current version.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: Block or Multiline Comment
I uploaded a cobra.lang that handles nested block comments. Was just a one line addition.
I also sorted the keywords, added par, and fixed where it said dynamiceach. I assumed this is a typo. I made it just each since gedit highlights dynamic like it highlights anything else after an as, rather than as a keyword.
I also added result and value. Please let me know if not having result and value was deliberate.
<context id="multiline-comment" style-ref="comment">
<start>\/#</start>
<end>#\/</end>
<include>
<span style="font-weight: bold"><context ref="multiline-comment"/></span>
<context ref="def:in-comment" />
</include>
</context>
I also sorted the keywords, added par, and fixed where it said dynamiceach. I assumed this is a typo. I made it just each since gedit highlights dynamic like it highlights anything else after an as, rather than as a keyword.
I also added result and value. Please let me know if not having result and value was deliberate.
call me Nev.
- nevdelap
- Posts: 61
- Location: Buenos Aires
Re: Block or Multiline Comment
That's great!
"result" and "value" are interesting in that they are semi-keywords. You could actually use them as parameters or local vars in a method. I don't know if GtkSourceView is sophisticated enough to distinguish the cases. "result" would be highlighted only under "ensure" and "value" would be highlighted only under "set".
If it can't be broken down like that then I suppose it's personal preference as to when they are highlighted. I would probably not highlight them differently than other local identifiers, but it's debatable.
Here's a handy link for our readers: wiki/GtkEditors
"result" and "value" are interesting in that they are semi-keywords. You could actually use them as parameters or local vars in a method. I don't know if GtkSourceView is sophisticated enough to distinguish the cases. "result" would be highlighted only under "ensure" and "value" would be highlighted only under "set".
If it can't be broken down like that then I suppose it's personal preference as to when they are highlighted. I would probably not highlight them differently than other local identifiers, but it's debatable.
Here's a handy link for our readers: wiki/GtkEditors
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: Block or Multiline Comment
Righto. I'll keep it in mind to investigate how to make it only high light them as keywords in the right places.
call me Nev.
- nevdelap
- Posts: 61
- Location: Buenos Aires
20 posts
• Page 2 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 37 guests