unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: emacs-devel@gnu.org
Subject: Re: Undocumented hyperlinks in doc strings.
Date: Sat, 11 Oct 2003 22:34:42 -0500 (CDT)	[thread overview]
Message-ID: <200310120334.h9C3Ygk26986@raven.dms.auburn.edu> (raw)
In-Reply-To: <E1A8CQq-0001B7-D9@fencepost.gnu.org> (message from Richard Stallman on Sat, 11 Oct 2003 01:36:48 -0400)

Richard Stallman wrote:

	 This means that a simple M-q can easily enable or disable
       several hyperlinks.  This does not seem good.  The change in
       `help-xref-symbol-regexp' treats newlines as any other whitespace.

   Thanks for noticing and fixing this bug.  Please install your change.

   Meanwhile, it might be another bug to allow more than one whitespace
   character between words like `function' and the function name.
   Multiple spaces never happen in normal text, only when there is
   a sort of deliberate paragraph breaking or tabular structure.
   In those cases, going across paragraphs or fields would probably
   be a mistake.

and:

   Three or more semicolons are the convention for comments that should
   start at the margin, and that is our standard way of commenting out
   code.  Like anything, it could be changed, but that is a rather
   heavy change to make and I would hesitate to do it on account of
   outline-minor-mode.

That leaves two questions to be addressed before I install my change.

In as far as the first one goes, one could replace the occurrences of
[ \t\n]+ and [ \t\n]* (the latter probably would have to be changed to
[ \t\n]+ anyway, for consistency) in my patch by [ \n].  (If one does
not allow multiple spaces, it seems consistent not to allow tab
either.)  That would mean that the author would have to be careful
about "space related sloppiness" like trailing whitespace or an
inadvertent inappropriate double space inside a sentence.  _As long as_
the author is careful to check his documentation strings with a C-h v
or C-h f (I always do, but I do not know about other people) that
would be an advantage, because the lack of hyperlink would immediately
point out the problem.

In as far as the second goes, I infer from your response that you
prefer the three semi-colon solution of my original patch over the two
semi-colon re-indentation I proposed in a reply to Stefan.  (I do not
believe that the _current_ two semi-colon indentation makes sense,
since it is "C-M-q instable".)

Just in case, what about a convention to follow ;;; by a single space
if one wants the line two be considered a "heading line" by
outline-minor-mode and by at least two spaces if one wants it to be
considered a "body line".  The three semi-colons are mostly important
for commented out code _inside_ a function and apart from an initial
comment (;;; this used: , in the code at issue) and possibly commented
out parts of the documentation string, at least two spaces usually
follow the semi-colons anyway.  So, in the code in question, one just
would have to replace:

;;; this used:

with:

;;;  this used:

without any other change to the original three semi-colon solution.

With:

";;;;* [^ \t\n]\\|(" instead of the current ";;;;* \\|(" as
outline-regexp in emacs-lisp-mode, none of the commented out code
would be considered a heading line by outline-minor-mode.

Sincerely,

Luc.

  reply	other threads:[~2003-10-12  3:34 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-09  0:50 Undocumented hyperlinks in doc strings Luc Teirlinck
2003-10-09 21:16 ` Richard Stallman
2003-10-10  3:27   ` Luc Teirlinck
2003-10-10 14:14     ` Stefan Monnier
2003-10-10 15:31       ` Luc Teirlinck
2003-10-10 16:29         ` Luc Teirlinck
2003-10-10 17:23         ` Stefan Monnier
2003-10-10 18:21           ` Luc Teirlinck
2003-10-10 19:24             ` Stefan Monnier
2003-10-11 17:12       ` Richard Stallman
2003-10-14 21:03         ` Stefan Monnier
2003-10-15  1:38           ` Luc Teirlinck
2003-10-15 20:00             ` Richard Stallman
2003-10-15 23:52               ` Luc Teirlinck
2003-10-16 23:06                 ` Richard Stallman
2003-10-16 14:06             ` Richard Stallman
2003-10-17  3:32               ` Luc Teirlinck
2003-10-17 13:47                 ` Stefan Monnier
2003-10-18 23:06                   ` Richard Stallman
2003-10-19  1:14                     ` Luc Teirlinck
2003-10-20  1:48                       ` Richard Stallman
2003-10-20  2:24                         ` Luc Teirlinck
2003-10-20 14:44                           ` Stefan Monnier
2003-10-20 15:22                             ` Luc Teirlinck
2003-10-21 14:47                             ` Richard Stallman
2003-10-11  5:36     ` Richard Stallman
2003-10-12  3:34       ` Luc Teirlinck [this message]
2003-10-13  5:03         ` Richard Stallman
2003-10-14  3:23           ` Luc Teirlinck
2003-10-17 20:46             ` Richard Stallman
2003-10-17 23:30               ` Luc Teirlinck

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=200310120334.h9C3Ygk26986@raven.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=emacs-devel@gnu.org \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).