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.
next prev parent 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.