From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: emacs-devel@gnu.org
Subject: Re: info
Date: Fri, 31 Jan 2003 19:22:45 -0600 (CST) [thread overview]
Message-ID: <200302010122.TAA12524@eel.dms.auburn.edu> (raw)
In-Reply-To: <E18eghy-0000PR-00@fencepost.gnu.org> (message from Richard Stallman on Fri, 31 Jan 2003 14:20:14 -0500)
Richard Stallman wrote:
In this case, it would be good for RET to get an error.
Probably it should take a single menu item to consist
of the * line followed by all successive indented lines,
including blank lines when further indented lines follow
but excluding blank lines that would be at the end of the
menu item.
Problems occur in situations like:
* Sample .emacs File::
--- Indices ---
* Concept Index::
I see the problem, but don't worry about it too much.
It doesn't have to be perfect, just better.
It would be better to make occasional rare mistakes like this
than to fail frequently on multi-line menu items.
Yes, but I have found worse examples since and the problem cases do
not seem to be that rare at all. Two examples among the many I found:
Example 1:
* Menu:
* Interactive Customization::
* Permanent Customization::
* Hooks::
* Styles::
* Advanced Customizations::
---------- Footnotes ----------
(1) Available in Emacs 20 and later, and XEmacs 19.15 and later.
(2) Obviously, you use the key binding interactively, and the
function call programmatically!
(3) There is however a variable `c-strict-syntax-p' that, when set
to non-`nil', will cause an error to be signaled in that case. It's
now considered obsolete since it doesn't work well with some of the
alignment functions that now returns `nil' instead of zero to be more
usable in lists. You should therefore leave `c-strict-syntax-p' set
to
`nil'.
(4) You can try this interactively in a C buffer by typing the text
that appears in italics.
My comments:
The described algorithm would still go "* Advanced Customizations::"
at the end of the first line of footnote (2) and, even then, we are
lucky that footnote (2) is multi-line. Worse could have happened.
Example 2:
* Other Commands::
See also *Note Text Filling and Line Breaking::, for commands concerning
that bit.
My comments:
With point after "concerning", the algorithm would still go to
"* Other Commands::", even though there is a cross-reference in between.
As I said such examples are not rare.
I see at least three solutions that would be better than the algorithm
you propose:
1. Take over the stand-alone behavior, maybe with an improved error
message.
Advantage: Never produces confusion, if the error message is
sufficiently clear.
2. The second proposal I made, namely do whatever mouse-2 would,
otherwise whatever "m RETURN" would do by default, otherwise
nothing.
Advantage: Always does the obvious thing if there is one.
Disadvantage: can look very unnatural, but only in situations where
pressing RETURN is very unnatural to begin with, and is completely
consistent and predictable.
3. Use Kai's algorithm.
The reason why I believe that 2. is relatively better than the
solution you propose, is that a surprised user could at least easily
figure out what the behavior is, using C-h k or by experimentation.
That is not the case with the solution you propose. Take example 1.
The user presses RETURN in the described spot (out of curiosity, I can
not see any other reason) and sees that (s)he winds up in
* Advanced Customizations:: Now the user believes that when (s)he
presses RETURN in a footnote (s)he will always go to the last menu
item. True for 2., but with the algorithm you propose, (s)he is in
for some further surprises.
In as far as 3. is concerned, I have not found any example yet where
Kai's algorithm goes obviously wrong. Kai's algorithm obviously
malfunctions for descriptions containing blank lines. But such cases
seem to be more rare than the instances in which the algorithm you
describe malfunctions. (Actually, I have not even found a concrete
example yet, although I am sure there must be some somewhere.)
However, anything we implement should work for all info files. That
includes, for instance, files not originally written in texinfo but
automatically generated from, say, SGML files. I have no experience
whatsoever with these and do not know whether they could have weird
indentation and, hence, lead to major malfunctioning of any
indentation based algorithm.
Of the three above solutions, 1. seems the safest, even though I agree
it is not ideal. But there does quite simply not seem to be an ideal
solution.
Sincerely,
Luc.
next prev parent reply other threads:[~2003-02-01 1:22 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <84smvc2guf.fsf@lucy.is.informatik.uni-duisburg.de>
2003-01-29 14:20 ` info Eli Zaretskii
2003-01-30 15:21 ` info Richard Stallman
2003-01-30 16:21 ` info Luc Teirlinck
2003-01-31 19:20 ` info Richard Stallman
2003-02-01 1:22 ` Luc Teirlinck [this message]
2003-02-01 22:11 ` info Richard Stallman
2003-02-02 4:59 ` info Luc Teirlinck
2003-02-02 5:44 ` info Eli Zaretskii
2003-02-02 6:09 ` info Miles Bader
2003-02-03 14:40 ` info Stefan Monnier
2003-02-03 19:00 ` info Luc Teirlinck
2003-02-03 19:16 ` info Luc Teirlinck
2003-02-03 19:19 ` info Luc Teirlinck
2003-02-04 15:41 ` info Richard Stallman
2003-02-05 6:08 ` info Eli Zaretskii
2003-02-05 20:07 ` info Luc Teirlinck
2003-02-09 4:45 ` info Luc Teirlinck
2003-01-29 1:33 info Luc Teirlinck
2003-01-29 3:53 ` info Luc Teirlinck
2003-01-29 6:29 ` info Eli Zaretskii
2003-01-29 19:57 ` info Luc Teirlinck
2003-01-30 5:46 ` info Eli Zaretskii
2003-01-29 21:17 ` info Richard Stallman
2003-01-29 17:33 ` info Eli Zaretskii
2003-01-29 20:39 ` info Luc Teirlinck
2003-01-29 23:21 ` info Luc Teirlinck
2003-01-30 5:48 ` info Eli Zaretskii
2003-01-30 8:39 ` info Kai Großjohann
2003-01-30 15:11 ` info Luc Teirlinck
2003-01-30 16:30 ` info Luc Teirlinck
2003-01-30 20:02 ` info Eli Zaretskii
2003-01-30 20:51 ` info Kai Großjohann
2003-01-30 22:37 ` info Robert J. Chassell
2003-01-31 1:51 ` info Luc Teirlinck
2003-01-31 13:05 ` info Robert J. Chassell
2003-01-31 20:22 ` info Luc Teirlinck
2003-02-01 1:22 ` info Robert J. Chassell
2003-01-29 21:17 ` info Richard Stallman
2003-01-30 0:31 ` info Luc Teirlinck
2003-01-30 1:43 ` info Luc Teirlinck
2003-01-30 2:03 ` info 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200302010122.TAA12524@eel.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 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.