awesome feature (yet to be added?)

awesome feature (yet to be added?)

[Bric]

Hi, all

unless it already exists, I thought of an awesome time-saving command: 
invert-comment

this to be on a par with "comment-region" and "uncomment-region".

"invert-comment" would change something like this :

   /* int b_progress; */
    /* int i_seek; */
    /* hnd_t hin; */
    /* hnd_t hout; */

    int c_progress;
    int j_seek;
    hnd_e hin;
    hnd_f hout;


to:


    int b_progress;
    int i_seek;
    hnd_t hin;
    hnd_t hout;

    /* int c_progress; */
    /* int j_seek; */
    /* hnd_e hin; */
    /* hnd_f hout; */


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

not for all occasions, but can be very useful for some, it seems to me.

Maybe it's easily added with a scheme script or something.

thanks!

Re: awesome feature (yet to be added?)

[Bric]

I had some private responses that suggest my original post wasn't too clear; i
left my main idea obscurely implied:

I am suggesting an INVERSION or reversal of whatever commented/uncommented state
of EVERY LINE in the selected region.

See my example below:  the before and after states are inverted.  The before
state has a commented block then an uncommented block. 

My hypothetical command reverses that: the after state has an uncommented block
followed by a commented block.  That effect should take place in one command,
with the entire eight lines of code selected a single selected block to which to
apply the command.

hope this clarifies it...

> On May 3, 2014 at 2:47 PM Bric <bric@flight.us> wrote:
>
>
> Hi, all
> 
> unless it already exists, I thought of an awesome time-saving command: 
> invert-comment
>
> this to be on a par with "comment-region" and "uncomment-region".
>
> "invert-comment" would change something like this :
>
>    /* int b_progress; */
>     /* int i_seek; */
>     /* hnd_t hin; */
>     /* hnd_t hout; */
>
>     int c_progress;
>     int j_seek;
>     hnd_e hin;
>     hnd_f hout;
>
>
> to:
>
>
>     int b_progress;
>     int i_seek;
>     hnd_t hin;
>     hnd_t hout;
>
>     /* int c_progress; */
>     /* int j_seek; */
>     /* hnd_e hin; */
>     /* hnd_f hout; */
>
>
> -------------
>
> not for all occasions, but can be very useful for some, it seems to me.
>
> Maybe it's easily added with a scheme script or something.
>
> thanks!
>

Re: awesome feature (yet to be added?)

[Stephen Berman]

On Sat, 3 May 2014 21:23:37 -0400 (EDT) Bric <bric@flight.us> wrote:

> I had some private responses that suggest my original post wasn't too clear; i
> left my main idea obscurely implied:
>
> I am suggesting an INVERSION or reversal of whatever commented/uncommented state
> of EVERY LINE in the selected region.
>
> See my example below:  the before and after states are inverted.  The before
> state has a commented block then an uncommented block. 
>
> My hypothetical command reverses that: the after state has an uncommented block
> followed by a commented block.  That effect should take place in one command,
> with the entire eight lines of code selected a single selected block to which to
> apply the command.
>
> hope this clarifies it...

I don't know if it's worth adding to Emacs, but this seems to do what
you want:

(defun srb-comment-region-invert (beg end)
  "Comment lines in region if uncommented, uncomment them if commented."
  (interactive "r")
  (setq end (save-excursion (goto-char end) (point-marker)))
  (goto-char beg)
    (while (< (point) end)
      (let ((beg0 (line-beginning-position))
	    (end0 (line-end-position)))
	(if (progn
	      (skip-syntax-forward " " end0)
	      (looking-at (regexp-quote comment-start)))
	    (uncomment-region beg0 end0)
	  (when (> end0 beg0)(comment-region beg0 end0)))
	(forward-line)))
    (font-lock-fontify-region beg end))

Steve Berman

Re: awesome feature (yet to be added?)

[Andreas Röhler]

On 04.05.2014 03:23, Bric wrote:
>
> I had some private responses that suggest my original post wasn't too clear; i
> left my main idea obscurely implied:
>
> I am suggesting an INVERSION or reversal of whatever commented/uncommented state
> of EVERY LINE in the selected region.
>
> See my example below:  the before and after states are inverted.  The before
> state has a commented block then an uncommented block.
>
> My hypothetical command reverses that: the after state has an uncommented block
> followed by a commented block.  That effect should take place in one command,
> with the entire eight lines of code selected a single selected block to which to
> apply the command.
>
> hope this clarifies it...
>
>> On May 3, 2014 at 2:47 PM Bric <bric@flight.us> wrote:
>>
>>
>> Hi, all
>>
>> unless it already exists, I thought of an awesome time-saving command:
>> invert-comment
>>
>> this to be on a par with "comment-region" and "uncomment-region".
>>
>> "invert-comment" would change something like this :
>>
>>     /* int b_progress; */
>>      /* int i_seek; */
>>      /* hnd_t hin; */
>>      /* hnd_t hout; */
>>
>>      int c_progress;
>>      int j_seek;
>>      hnd_e hin;
>>      hnd_f hout;
>>
>>
>> to:
>>
>>
>>      int b_progress;
>>      int i_seek;
>>      hnd_t hin;
>>      hnd_t hout;
>>
>>      /* int c_progress; */
>>      /* int j_seek; */
>>      /* hnd_e hin; */
>>      /* hnd_f hout; */
>>
>>
>> -------------
>>
>> not for all occasions, but can be very useful for some, it seems to me.
>>
>> Maybe it's easily added with a scheme script or something.
>>
>> thanks!
>>
>
>

When code is marked as region,

M-x comment-dwim RET should do what you want.

Without region, this inverts also linewise:

ar-comment-or-uncomment-lor

available here:

https://launchpad.net/s-x-emacs-werkstatt

Re: awesome feature (yet to be added?)

[Le Wang]

I made this: https://github.com/lewang/try-code

The idea is developed a little further than what you propose.  I
decorate the code with markers so it's easy to choose the new or old
code.

Judging by the uptake.  We are the only two to think this is useful.  :)


On Sat, May 3, 2014 at 2:47 PM, Bric <bric@flight.us> wrote:
> Hi, all
>
> unless it already exists, I thought of an awesome time-saving command:
> invert-comment
>
> this to be on a par with "comment-region" and "uncomment-region".
>
> "invert-comment" would change something like this :
>
>    /* int b_progress; */
>     /* int i_seek; */
>     /* hnd_t hin; */
>     /* hnd_t hout; */
>
>     int c_progress;
>     int j_seek;
>     hnd_e hin;
>     hnd_f hout;
>
>
> to:
>
>
>     int b_progress;
>     int i_seek;
>     hnd_t hin;
>     hnd_t hout;
>
>     /* int c_progress; */
>     /* int j_seek; */
>     /* hnd_e hin; */
>     /* hnd_f hout; */
>
>
> -------------
>
> not for all occasions, but can be very useful for some, it seems to me.
>
> Maybe it's easily added with a scheme script or something.
>
> thanks!
>



-- 
Le

Re: awesome feature (yet to be added?)

[Davis Herring]

> Judging by the uptake.  We are the only two to think this is useful.  :)

I thought about implementing `invert-comment' a few years ago, but I
wasn't sure what to do about code like this:

  /* old_implementation_prepare (); */
  /* old_implementation_go (); */

  new_implementation_prepare ();
  /* The new implementation needs a buffer allocated. */
  char *p = malloc (new_implementation_size ());
  new_implementation_go (p);

What to do about the actual comment embedded in the "new" code?

  x = foo () + /* bar () + */ baz ();
  quux (x, x + 1);     /* quux now accounts for bar internally */

What does it mean to toggle commented-ness here?

Your idea of markers likely works out better than "toggle the comments"
because of cases like these.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: awesome feature (yet to be added?)

[Stephen J. Turnbull]

Davis Herring writes:
 > Le or Bric wrote:

 >> Judging by the uptake.  We are the only two to think this is
 >> useful.  :)

There is an ancient solution with ancient support:  use #ifdef, not
comments, to control the language translator, and use hideif to
control your Emacs display if you like.  hideif wouldn't take much
work to "grey out" instead of completely hide the "inactive" code, now
that everybody has GUI displays capable of that.

 > I thought about implementing `invert-comment' a few years ago, but
 > I wasn't sure what to do about code like this:

[omitted]

 > Your idea of markers likely works out better than "toggle the
 > comments" because of cases like these.

I don't see why it would.  The markers would need to be user-
maintained to handle the cases you presented.  And therefore, highly
problematic[1], even if you provide high-level helper commands.  Finally,
there's another case you didn't mention: overlapping "togglable"
comment regions.

If one really wants to use comments for such cases (whether because of
personal preference or because of a style guide that doesn't allow or
strongly discourages random #ifdefs, or a language that doesn't have
them[2]), (1) you could use C++ and be consistent about which comment
convention is for comments and which for poor-man's ifdefs, or (2) you
could hack up VC support (ie, each toggleable comment configuration
would be a separate branch).

Solution (2) probably requires insane amounts of branching and merging
(combinatorial explosion of "#ifdef branches" since each local
alternative would require a pair of branches on top of each existing
#ifdef branch-pair -- could be lazy, but still...), so only git could
really support it, and you'd need to have substantial automatic
support for picking the right branches when switching for the same
reason (especially if "lazy", you'd need to merge on-the-fly).


Footnotes: 
[1]  I wonder if such development techniques weren't involved in
the recent embarrassing gnutls and openssl authentication bugs.

[2]  Although all languages should support a conditional statement
that could be used the same way with some decrease in runtime
performance!

Re: awesome feature (yet to be added?)

[Robert Thorpe]

Davis Herring <herring@lanl.gov> writes:

>> Judging by the uptake.  We are the only two to think this is useful.  :)
>
> I thought about implementing `invert-comment' a few years ago, but I
> wasn't sure what to do about code like this:
>
>   /* old_implementation_prepare (); */
>   /* old_implementation_go (); */

Here's an alternative approach.

Dale Snell pointed out that this can be done with rectangle commands.
Give your commented code a name.  Mark region with the mark and point in
the first column.  Then do

C-x r t ;; foo: RET

The region will look like
;; foo: some code ();
;; foo: some more code ();

You can do the same for other experiments that are commented out.  Then
later on you can enable them by using

M-% ;; foo: RET RET

And you can put a ! at the end of that if you like.  I know this doesn't
solve all the problems discussed.

BR,
Robert Thorpe

Re: awesome feature (yet to be added?)

[Thorsten Jolitz]

Davis Herring <herring@lanl.gov> writes:

>> Judging by the uptake.  We are the only two to think this is useful.  :)

No, I would really like to see a generic `invert-comment' function in
Emacs. My use case is outorg.el that converts programming language buffers
(structured the outshine way, i.e. with outcommented Org-mode headers)
temporarily to org-mode for text editing and then back to the
programming major-mode. 

That means all the comment sections of the source file are uncommented
when converting to Org, and outcommented again when converting back to
the original major-mode. I do this linewise, and in fact outorg can't
handle those special multiline comments like in C or Java. 

A robust generic (= major-mode agnostic) `invert-comment' function as
part of Emacs that knows how to handle multiline comments too would come
very handy.

> I thought about implementing `invert-comment' a few years ago, but I
> wasn't sure what to do about code like this:
>
>   /* old_implementation_prepare (); */
>   /* old_implementation_go (); */
>
>   new_implementation_prepare ();
>   /* The new implementation needs a buffer allocated. */
>   char *p = malloc (new_implementation_size ());
>   new_implementation_go (p);

IMO such a function should only act on comments that start at the
beginning of line, indented comments should remain untouched.

> What to do about the actual comment embedded in the "new" code?
>
>   x = foo () + /* bar () + */ baz ();
>   quux (x, x + 1);     /* quux now accounts for bar internally */
>
> What does it mean to toggle commented-ness here?

Again, IMO these comments should remain untouched. E.g. when converting
source files to org-mode, code section are enclosed in source-blocks

#+begin_src lang
  x = foo () + /* bar () + */ baz ();
 quux (x, x + 1);     /* quux now accounts for bar internally */
#+end_src

and the embedded comments clearly belong to the code. 

> Your idea of markers likely works out better than "toggle the comments"
> because of cases like these.

It would indeed be very useful if there is a way to further act on the
region/line that was inverted after the function has done its job. So
returning start/end position, set markers or running a hook or so would
be nice.

There were quite a lot of proposals in this thread. Any chance that this
is actually outdiscussed and included in Emacs any time soon?

-- 
cheers,
Thorsten

Re: awesome feature (yet to be added?)

[Stefan Monnier]

> Emacs. My use case is outorg.el that converts programming language buffers
> (structured the outshine way, i.e. with outcommented Org-mode headers)
> temporarily to org-mode for text editing and then back to the
> programming major-mode.

After uncommenting, how do you know which lines should be recommented?
Do you remember them in some variable?  Or do you wrap the code parts in
those (ugly) +begin...+end "brackets"?
Do you uncomment all comments, or only those that "look like Org stuff"?

> the original major-mode. I do this linewise, and in fact outorg can't
> handle those special multiline comments like in C or Java. 

Why do it line-wise?

> A robust generic (= major-mode agnostic) `invert-comment' function as
> part of Emacs that knows how to handle multiline comments too would come
> very handy.

It looks like the exact meaning of such a function is slightly different
for every one, so such a function would need lots of hooks and config
vars to cover all cases.

But you can write your own function starting with

   (defun my-uncomment-region (beg end)
     (let (spt)
       (while (and (< (point) end)
                   (setq spt (comment-search-forward end t)))
         (let ((ept (progn
		      (goto-char spt)
		      (unless (or (comment-forward)
			          ;; Allow non-terminated comments.
			          (eobp))
		        (error "Can't find the comment end"))
		      (point))))
           (uncomment-region spt ept)))))


-- Stefan

Re: awesome feature (yet to be added?)

[Andreas Röhler]

On 30.05.2014 23:35, Thorsten Jolitz wrote:
> Davis Herring <herring@lanl.gov> writes:
>
>>> Judging by the uptake.  We are the only two to think this is useful.  :)
>
> No, I would really like to see a generic `invert-comment' function in
> Emacs. My use case is outorg.el that converts programming language buffers
> (structured the outshine way, i.e. with outcommented Org-mode headers)
> temporarily to org-mode for text editing and then back to the
> programming major-mode.
>
> That means all the comment sections of the source file are uncommented
> when converting to Org, and outcommented again when converting back to
> the original major-mode. I do this linewise, and in fact outorg can't
> handle those special multiline comments like in C or Java.
>
> A robust generic (= major-mode agnostic) `invert-comment' function as
> part of Emacs that knows how to handle multiline comments too would come
> very handy.
>
>> I thought about implementing `invert-comment' a few years ago, but I
>> wasn't sure what to do about code like this:
>>
>>    /* old_implementation_prepare (); */
>>    /* old_implementation_go (); */
>>
>>    new_implementation_prepare ();
>>    /* The new implementation needs a buffer allocated. */
>>    char *p = malloc (new_implementation_size ());
>>    new_implementation_go (p);
>
> IMO such a function should only act on comments that start at the
> beginning of line, indented comments should remain untouched.
>
>> What to do about the actual comment embedded in the "new" code?
>>
>>    x = foo () + /* bar () + */ baz ();
>>    quux (x, x + 1);     /* quux now accounts for bar internally */
>>
>> What does it mean to toggle commented-ness here?
>
> Again, IMO these comments should remain untouched. E.g. when converting
> source files to org-mode, code section are enclosed in source-blocks
>
> #+begin_src lang
>    x = foo () + /* bar () + */ baz ();
>   quux (x, x + 1);     /* quux now accounts for bar internally */
> #+end_src
>
> and the embedded comments clearly belong to the code.
>
>> Your idea of markers likely works out better than "toggle the comments"
>> because of cases like these.
>
> It would indeed be very useful if there is a way to further act on the
> region/line that was inverted after the function has done its job. So
> returning start/end position, set markers or running a hook or so would
> be nice.
>
> There were quite a lot of proposals in this thread. Any chance that this
> is actually outdiscussed and included in Emacs any time soon?
>

AFAIU instrumenting `comment-dwim' should provide all you need here.

Grüße,

Andreas

Re: awesome feature (yet to be added?)

[Thorsten Jolitz]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Emacs. My use case is outorg.el that converts programming language
>> buffers
>> (structured the outshine way, i.e. with outcommented Org-mode
>> headers)
>> temporarily to org-mode for text editing and then back to the
>> programming major-mode.
>
> After uncommenting, how do you know which lines should be recommented?
> Do you remember them in some variable?  Or do you wrap the code parts
> in
> those (ugly) +begin...+end "brackets"?

Yes, ugly or not, the +begin...+end "brackets (i.e. code-blocks) are
quite convenient since they allows easy conversion between source code
buffers and org buffers: in source code buffers, code is code and text
is hidden behind comment chars, in org buffers text is text and source
code is hidden in those code blocks. Just two views on the same (well
structured) file, and in each view all buffer content is in one of only
two 'states': hidden (as comment or code block) or not.

> Do you uncomment all comments, or only those that "look like Org
> stuff"?

only comments that start at beginning of line, all other comments
(indented, at the end of line ...) are usually part of the code and
should not be touched (i.e. should go into the code-blocks together with
the code).

>> the original major-mode. I do this linewise, and in fact outorg
>> can't
>> handle those special multiline comments like in C or Java.
>
> Why do it line-wise?

Because it was easy and major-mode agnostic (I just mark the line and
call comment-region and uncomment-region on it), although I needed a few
variables to keep track of the current context (inside comment-section?
inside code-section?). Would comment-search-forward be much faster? But
it would probably find all kinds of comments not only those that start
at the beginning of line. 

>> A robust generic (= major-mode agnostic) `invert-comment' function
>> as
>> part of Emacs that knows how to handle multiline comments too would
>> come
>> very handy.
>
> It looks like the exact meaning of such a function is slightly different
> for every one, so such a function would need lots of hooks and config
> vars to cover all cases.
>
> But you can write your own function starting with
>
>    (defun my-uncomment-region (beg end)
>      (let (spt)
>        (while (and (< (point) end)
>                    (setq spt (comment-search-forward end t)))
>          (let ((ept (progn
> 		      (goto-char spt)
> 		      (unless (or (comment-forward)
> 			          ;; Allow non-terminated comments.
> 			          (eobp))
> 		        (error "Can't find the comment end"))
> 		      (point))))
>            (uncomment-region spt ept)))))
>

Thanks, thats indeed a good starting point.

-- 
cheers,
Thorsten

Re: awesome feature (yet to be added?)

[Thorsten Jolitz]

Andreas Röhler <andreas.roehler@online.de> writes:

>> There were quite a lot of proposals in this thread. Any chance that
>> this
>> is actually outdiscussed and included in Emacs any time soon?
>>
>
> AFAIU instrumenting `comment-dwim' should provide all you need here.

This could indeed work well if I had a function that marks the whole
comment section ahead once I found the starting point of a comment at
BOL, no matter if its outcommented linewise or with special multi-line
syntax.

-- 
cheers,
Thorsten

Re: awesome feature (yet to be added?)

[Andreas Röhler]

On 31.05.2014 12:52, Thorsten Jolitz wrote:
> Andreas Röhler <andreas.roehler@online.de> writes:
>
>>> There were quite a lot of proposals in this thread. Any chance that
>>> this
>>> is actually outdiscussed and included in Emacs any time soon?
>>>
>>
>> AFAIU instrumenting `comment-dwim' should provide all you need here.
>
> This could indeed work well if I had a function that marks the whole
> comment section ahead once I found the starting point of a comment at
> BOL,

You might try

ar-forward-comment-atpt
ar-backward-comment

Added by a (bolp) etc.

It's delivered by

thing-at-point-utils.el

at

https://launchpad.net/s-x-emacs-werkstatt/

Re: awesome feature (yet to be added?)

[Thorsten Jolitz]

Andreas Röhler <andreas.roehler@online.de> writes:

> On 31.05.2014 12:52, Thorsten Jolitz wrote:
>> Andreas Röhler <andreas.roehler@online.de> writes:
>>
>>>> There were quite a lot of proposals in this thread. Any chance that
>>>> this
>>>> is actually outdiscussed and included in Emacs any time soon?
>>>>
>>>
>>> AFAIU instrumenting `comment-dwim' should provide all you need here.
>>
>> This could indeed work well if I had a function that marks the whole
>> comment section ahead once I found the starting point of a comment at
>> BOL,
>
> You might try
>
> ar-forward-comment-atpt
> ar-backward-comment
>
> Added by a (bolp) etc.
>
> It's delivered by
>
> thing-at-point-utils.el
>
> at
>
> https://launchpad.net/s-x-emacs-werkstatt/

Wow, 3164 defuns only in thing-at-point-utils.el, thats impressive. 
Thanks for the hint! 

-- 
cheers,
Thorsten

Re: awesome feature (yet to be added?)

[Andreas Röhler]

On 31.05.2014 22:04, Thorsten Jolitz wrote:
> Andreas Röhler <andreas.roehler@online.de> writes:
>
>> On 31.05.2014 12:52, Thorsten Jolitz wrote:
>>> Andreas Röhler <andreas.roehler@online.de> writes:
>>>
>>>>> There were quite a lot of proposals in this thread. Any chance that
>>>>> this
>>>>> is actually outdiscussed and included in Emacs any time soon?
>>>>>
>>>>
>>>> AFAIU instrumenting `comment-dwim' should provide all you need here.
>>>
>>> This could indeed work well if I had a function that marks the whole
>>> comment section ahead once I found the starting point of a comment at
>>> BOL,
>>
>> You might try
>>
>> ar-forward-comment-atpt
>> ar-backward-comment
>>
>> Added by a (bolp) etc.
>>
>> It's delivered by
>>
>> thing-at-point-utils.el
>>
>> at
>>
>> https://launchpad.net/s-x-emacs-werkstatt/
>
> Wow, 3164 defuns only in thing-at-point-utils.el, thats impressive.

BTW you may reimplement that part using shipped thingatpt.el, no need to load the whole stuff then.

The point of interest starts in thingatpt-utils-base.el, line 2341

;; Comment
(put 'comment 'beginning-op-at
[ ... ]

Cheers,

Andreas

Re: awesome feature (yet to be added?)

[Thorsten Jolitz]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Emacs. My use case is outorg.el that converts programming language
>> buffers
>> (structured the outshine way, i.e. with outcommented Org-mode headers)
>> temporarily to org-mode for text editing and then back to the
>> programming major-mode.
>
> After uncommenting, how do you know which lines should be recommented?
> Do you remember them in some variable?  Or do you wrap the code parts in
> those (ugly) +begin...+end "brackets"?
> Do you uncomment all comments, or only those that "look like Org stuff"?
>
>> the original major-mode. I do this linewise, and in fact outorg can't
>> handle those special multiline comments like in C or Java. 
>
> Why do it line-wise?

While trying to reimplement outcommenting and uncommenting in outorg
based on the recommendations of this thread and the function below I
figured out that there was another reason to do it line-wise: the
special case of 'oldschool' elisp headers:

,--------
| ;;;; Level 2
`--------

instead of 

,----------
| ;; ** Level 1
`----------

With the usual outshine convention (outshine headers are outcommented
org-mode headers) it does not really matter if a comment line is a
headline or not (as long as it starts at BOL): conversion simply means
outcomment or uncomment.

But with the special case 'oldschool elisp headers' I have to look at
every line, decide if its an oldschool headline, and then convert e.g.

,--------
| ;;;; Level 2
`--------

into 

,--------
| ** Level 2
`--------

for editing in org-mode, and vice versa for copying back the edits. 

I don't really see how to avoid this. Its still pretty fast, ca. 4 sec
for an 8000 lines init.el, almost instantly for smaller files with just
a few hundred lines (org -> elisp is easier and thus much faster than
elisp -> org, ca. 0.1 sec for 8000 lines).

So I could only try to support multi-line comments too, but it seems a
function or variable identifying them (with point on a comment) like
`comment-multi-line-p' or so is missing?

>> A robust generic (= major-mode agnostic) `invert-comment' function as
>> part of Emacs that knows how to handle multiline comments too would come
>> very handy.
>
> It looks like the exact meaning of such a function is slightly different
> for every one, so such a function would need lots of hooks and config
> vars to cover all cases.
>
> But you can write your own function starting with
>
>    (defun my-uncomment-region (beg end)
>      (let (spt)
>        (while (and (< (point) end)
>                    (setq spt (comment-search-forward end t)))
>          (let ((ept (progn
> 		      (goto-char spt)
> 		      (unless (or (comment-forward)
> 			          ;; Allow non-terminated comments.
> 			          (eobp))
> 		        (error "Can't find the comment end"))
> 		      (point))))
>            (uncomment-region spt ept)))))

-- 
cheers,
Thorsten

Re: awesome feature (yet to be added?)

[Stefan Monnier]

> a function or variable identifying them (with point on a comment) like
> `comment-multi-line-p' or so is missing?

In the code I suggested you can simply compare `ept' with
line-beginning-position to see if this comment spans multiple lines or not.


        Stefan