all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@IRO.UMontreal.CA>
Cc: 7509@debbugs.gnu.org
Subject: bug#7509: 24.0.50; doc for `comment-style' and `comment-styles'
Date: Tue, 30 Nov 2010 14:36:41 -0800	[thread overview]
Message-ID: <27E6B536A09248629C372671995E7E97@us.oracle.com> (raw)
In-Reply-To: <jwvk4juv5jf.fsf-monnier+emacs@gnu.org>

> > I came across some variable definition weirdness (unrelated to this
> > bug):
> 
> I must say I have no idea how you got into such a mess.  My only
> explanation would be that some part of the patch did not 
> apply properly.

No, I did not mean to suggest that this had anything to do with your patch.
(And I just "applied" the patch by hand editing.)

> AFAIK, none of those things occur in my usage.

I won't worry about it.  If I have time I'll report it.  I don't have the time
now.

> > What's the magic to competely undo a defcustom or defconst 
> > - `makunbound' doesn't seem to be enough.
> 
> There's no such magic.

Are you saying that `makunbound' should take care of it?

It's pretty easy to see at least some of the problems, I think.  Put these in
different files:

(defcustom foo 1 "The first definition"
 :type 'integer)

(defcustom foo 2 "The second definition"
 :type 'integer)

Then eval the first, then the second, then maybe the first again, using C-M-x.
Use C-h v and see if you don't see at least the wrong file name mentioned at
some points.  I do right away, using the latest Windows binary (built today by
Sean) and emacs -Q.

But all this is outside of bug #7509.  I didn't mean to suggest it had anything
to do with your patch.

> From memory: feel free to test them in a C-mode buffer.

I'll go by your memory.  Someone can correct them later if your memory isn't
perfect.

> plain:
> /*      blabla */
> /*      bla */
> 
> indent
>      /* blabla */
>      /* bla */
>      
> multi-line
>      /* blabla
>       * bla */
> 
> extra-line      
>      /*
>       * blabla
>       * bla
>       */
> 
> aligned
>      /* blabla */
>      /* bla    */
>      
> box
>      /**********/
>      /* blabla */
>      /* bla    */
>      /**********/
> 
> box-multi     
>      /**********
>       * blabla *
>       * bla    *
>       **********/
> 
> When comment-end is the empty string,
> indent=multi-line=extra-line=aligned and box=box-multi.

Thanks.  That helps a lot.  Below are some suggestions.

Also, it wouldn't hurt to include such tiny diagrams in the doc string for
`comment-styles' (esp. since it is a defconst).  In this case, a set of pictures
is worth more than a set of one-liner descriptions.

BTW, why are all of the various possibilities (align, extra, box etc.) defined
only for indented comments?

plain      - Start in column 0 (do not indent)
indent     - Full comment per line, ends not aligned
aligned    - Full comment per line, ends aligned
box        - Full comment per line, ends aligned, + top and bottom
extra-line - One comment for all lines, end on a line by itself
multi-line - One comment for all lines, end on last commented line
box-multi  - One comment for all lines, + top and bottom

And the descriptions make more sense if presented in this order, IMO.

The doc string for `comment-styles' can also point out:

1. That all except for `plain' indent the comment to the current indent level.
2. That when `comment-end' is empty...

Those general rules help understanding and recollection.

HTH.






  reply	other threads:[~2010-11-30 22:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-28 19:42 bug#7509: 24.0.50; doc for `comment-style' and `comment-styles' Drew Adams
2010-11-28 21:01 ` Stefan Monnier
2010-11-28 22:34   ` Drew Adams
2010-11-28 22:49     ` Drew Adams
2010-11-30 18:15       ` Stefan Monnier
2010-11-30 19:13         ` Drew Adams
2010-11-30 22:06           ` Stefan Monnier
2010-11-30 22:36             ` Drew Adams [this message]
2010-12-01  2:57               ` Stefan Monnier
2010-12-01  4:10                 ` Drew Adams
2010-12-03 23:16                   ` Stefan Monnier
2010-12-03 23:34                     ` Drew Adams
2010-11-29  1:38     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27E6B536A09248629C372671995E7E97@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=7509@debbugs.gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.