unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: monnier+gnu/emacs@cs.yale.edu, emacs-devel@gnu.org
Subject: Re: Reducing mouse-dependency In Emacs.
Date: Mon, 11 Aug 2003 21:30:21 -0500 (CDT)	[thread overview]
Message-ID: <200308120230.h7C2ULg21458@raven.dms.auburn.edu> (raw)
In-Reply-To: <200308111454.h7BEsTti008562@rum.cs.yale.edu> (monnier+gnu/emacs@cs.yale.edu)

Stefan Monnier wrote:

   Reminds me of the suggestion I had a while ago to make such help
   partly automatic (at least when a `local-map' or `keymap' property
   is present, but maybe also when a `mouse-face' is present).

   Having it automatic saves work from the coder, but also allows the help
   text to be different in the `point-over' than in the `mouse-over' case.

I was not a part of that discussion and hence am unfamiliar with the
arguments pro and con.

Eli Zaretskii wrote:

   I think there should be another binding for the same command that
   doesn't use the mouse, and the help echo should print that binding
   when this option is set (since it's obvious the mouse is not used).

There are two problems here.

1. In the dired case, which is rather typical, the problem with
"mouse-2: visit this file in other window" is not just that it
mentions mouse-2 instead of `o', but also that it singles out this
particular command for documentation.  The reason for that is that it
is bound to a mouse command and that the user has the mouse in hand
and hence the author knows that he wants to use a mouse command.
Plenty of help-echo's are in this category.  There is no need to
access these from the keyboard.
2. It seems that your suggestion would require plenty of work
rewriting `help-echo' properties.

If we are going to provide automatic display, I believe we should be
conservative in what we show.  It should really be relevant, since,
especially in spoken version, it is distracting.

I would propose to only show `short-help' on point-over, or at least
provide an option to only show that one.  Maybe `short-help' for
`keymap' and `local-map' properties could be generated automatically
(but overridden by an explicit `short-help' property).  If not, we
could show `help-echo' on point-over, *if* one of those properties is
present, because in that case `help-echo' is very likely to be
relevant.  We could use the convention that a value of t for
`short-help' would mean to show `help-echo' on point-over.  So we
would have three types of `short-help': automatically generated, `t'
to indicate that the `help-echo' property is really relevant to the
keyboard user and explicitly provided strings.

In the beginning most `short-help' properties might be of the first
type, but that could change quickly.  In the meantime, `help-echo' is
available when explicitly asked for, or maybe as an option for
automatic display, for users who do not mind about irrelevant info
showing up in the echo area.

Sincerely,

Luc.

  reply	other threads:[~2003-08-12  2:30 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-10  3:42 Reducing mouse-dependency In Emacs Luc Teirlinck
2003-08-10  6:08 ` Eli Zaretskii
2003-08-10 14:53   ` Luc Teirlinck
2003-08-11 12:53   ` Richard Stallman
2003-08-10 16:50 ` Stefan Monnier
2003-08-10 23:09   ` Luc Teirlinck
2003-08-11  4:05     ` Luc Teirlinck
2003-08-11 23:16       ` Richard Stallman
2003-08-11  6:04     ` Eli Zaretskii
2003-08-11 15:52       ` Luc Teirlinck
2003-08-11 17:52         ` Eli Zaretskii
2003-08-11 14:54     ` Stefan Monnier
2003-08-12  2:30       ` Luc Teirlinck [this message]
2003-08-12  6:28         ` Eli Zaretskii
2003-08-12 16:08           ` Luc Teirlinck
  -- strict thread matches above, loose matches on Subject: below --
2003-08-12  1:29 Luc Teirlinck
2003-08-12  1:43 ` Luc Teirlinck
2003-08-12  2:49 Luc Teirlinck
2003-08-13  5:36 Luc Teirlinck
2003-08-13  7:47 ` Miles Bader
2003-08-13 12:59   ` Luc Teirlinck
2003-08-13 22:56     ` Nick Roberts
2003-08-14  0:35       ` Luc Teirlinck
2003-08-14  1:42         ` Miles Bader
2003-08-14  1:04       ` Luc Teirlinck
2003-08-13 14:32   ` 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=200308120230.h7C2ULg21458@raven.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=emacs-devel@gnu.org \
    --cc=monnier+gnu/emacs@cs.yale.edu \
    /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).