unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: martin rudalics <rudalics@gmx.at>, emacs-devel <emacs-devel@gnu.org>
Subject: RE: Fix some tooltip related problems
Date: Fri, 12 Jan 2018 08:43:01 -0800 (PST)	[thread overview]
Message-ID: <8e6647b6-029e-49ea-bbf3-7e1e7ac014bf@default> (raw)
In-Reply-To: <5A587620.8040201@gmx.at>

>  >> The option `x-gtk-use-system-tooltips' decides whether to use system
>  >> or Emacs tooltips.  This is a user option and should never be set by
>  >> Lisp code.
>  >
>  > Then that doesn't satisfy what I requested:
>  >    "being able to choose for any given context which to use"
>  >                          ---------------------
>  >    "Can we let Lisp code (and so users too) decide, here or
>  >     there, which kind of tooltip to use (heavyweight "Emacs"
>  >     or lightweight "system")?"
> 
> Right.  Such decisions must be left to the user.

Users have the right to use Lisp.  Users have the right
to choose whether to define or use this or that command
or this or that Lisp code.

There's no contradiction between allowing Lisp code to
choose whether to use faces etc. in a given tooltip and
allowing users to choose whether to allow that and choose
whether all or none or some tooltips should allow it.

Users choose.  The existence of that user option does
not and should not preclude more choice.

The fact that we have a user option for the global choice
of all or none is a red herring in a discussion of whether
and how to let Lisp code (not just C code) take part here.

Of course it is the user who gets to decide whether any
given Lisp code does its thing, whatever that might be.

>  > And users on gtk-build systems can choose.  Choice should
>  > also be available to Lisp functions, as use cases differ.
>  > It's of course possible to let a user option allow for
>  > Lisp control or override/prevent it, au choix.
>  >
>  > Today, does changing the value of that user option change
>  > the behavior dynamically?  E.g., if you did change the
>  > value using a given Lisp function would the behavior change?
>  >
>  > If so then some specific contexts could, by default, use
>  > "Emacs" tooltips, while other contexts did not.
> 
> I'd rather advise to set `x-gtk-use-system-tooltips' once in the init
> file and never change it during the session.

You are free to give anyone any such advice, of course.
It's the individual user who should be able to choose
what she wants.

A tooltip that shows each key as you type it, in, e.g.,
a large, red face (user-configurable) can be helpful
when doing a demo or recording a demo video, to show
which keys you are pressing, at relevant places on the
screen.

There are a zillion uses for tooltips that can take
advantage of using faces (and other Emacs artifacts).

Letting a user decide when, whether, and where to take
advantage of that is normal for Emacs.  Saying that you
shouldn't be able to do that is not normal for Emacs.



  reply	other threads:[~2018-01-12 16:43 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-08  9:53 Fix some tooltip related problems martin rudalics
2018-01-08 14:41 ` Drew Adams
2018-01-08 18:19   ` martin rudalics
2018-01-08 18:50     ` Drew Adams
2018-01-09  9:42       ` martin rudalics
2018-01-09 15:08         ` Drew Adams
2018-01-10 10:20           ` martin rudalics
2018-01-10 15:55             ` Drew Adams
2018-01-10 19:17               ` Alan Third
2018-01-10 21:02                 ` Drew Adams
2018-01-10 23:04                   ` Alan Third
2018-01-10 23:26                     ` Drew Adams
2018-01-11  3:39                   ` Eli Zaretskii
2018-01-11  7:03                 ` Yuri Khan
2018-01-11 14:32                   ` Drew Adams
2018-01-11 10:56               ` martin rudalics
2018-01-11 14:42                 ` Drew Adams
2018-01-11 17:06                   ` martin rudalics
2018-01-11 17:19                     ` Robert Pluim
2018-01-11 17:59                       ` Eli Zaretskii
2018-01-11 18:20                         ` martin rudalics
2018-01-11 23:33                         ` Daniele Nicolodi
2018-01-12  8:38                           ` Eli Zaretskii
2018-01-12  8:40                         ` Robert Pluim
2018-01-12  9:55                           ` Eli Zaretskii
2018-01-12 13:57                             ` Robert Pluim
2018-01-12 14:15                               ` Philipp Stephani
2018-01-11 19:54                       ` Richard Stallman
2018-01-11 23:26                       ` Stefan Monnier
2018-01-12  8:48                         ` Robert Pluim
2018-01-11 18:09                     ` Drew Adams
2018-01-11 18:54                       ` martin rudalics
2018-01-11 19:50                         ` Drew Adams
2018-01-12  8:47                           ` martin rudalics
2018-01-12 16:43                             ` Drew Adams [this message]
2018-01-08 18:47 ` Eli Zaretskii
2018-01-08 19:06   ` martin rudalics
2018-01-08 19:22     ` Eli Zaretskii
2018-01-09  9:42       ` martin rudalics
2018-01-19 18:54 ` martin rudalics

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=8e6647b6-029e-49ea-bbf3-7e1e7ac014bf@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=rudalics@gmx.at \
    /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).