From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Fix some tooltip related problems Date: Fri, 12 Jan 2018 08:43:01 -0800 (PST) Message-ID: <8e6647b6-029e-49ea-bbf3-7e1e7ac014bf@default> References: <5A533FA4.4030507@gmx.at> <9384bae5-cbb9-4b4d-ac5c-1d01f01c8117@default> <5A53B633.5020706@gmx.at> <41d40db5-15d8-4b2c-a058-fb6dabc8bfd3@default> <5A548E7E.2040601@gmx.at> <5A55E8ED.1010602@gmx.at> <475d480b-3885-4779-ae46-09cf7fbbcee7@default> <5A5742E7.3070303@gmx.at> <5A5799A5.1070305@gmx.at> <5A57B302.5090108@gmx.at> <5A587620.8040201@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1515775336 30222 195.159.176.226 (12 Jan 2018 16:42:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 12 Jan 2018 16:42:16 +0000 (UTC) To: martin rudalics , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 12 17:42:12 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ea2PA-0007A5-7N for ged-emacs-devel@m.gmane.org; Fri, 12 Jan 2018 17:42:08 +0100 Original-Received: from localhost ([::1]:51962 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ea2R7-0001XB-Sy for ged-emacs-devel@m.gmane.org; Fri, 12 Jan 2018 11:44:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ea2QJ-0000tl-Rs for emacs-devel@gnu.org; Fri, 12 Jan 2018 11:43:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ea2QE-0003mQ-Vx for emacs-devel@gnu.org; Fri, 12 Jan 2018 11:43:19 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:50634) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ea2QE-0003mC-Oi for emacs-devel@gnu.org; Fri, 12 Jan 2018 11:43:14 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0CGgF3H023598; Fri, 12 Jan 2018 16:43:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=4WFmACV/02CjSgHBNNTG3LYq7vmBIqizSkD423hydv8=; b=f1SD4yuiKbj7nGaM/fp+FWbIOM2pblakS+oY5+n43wSoqUND5IYJ0iznYMBsO2FrEHZ5 6hrWysOXap17pBsHk935MlM8QE4AGluOnbMg5LHiojeDVXNhPEpztzbYPPoLIDd1Dogb UKmmCGdzMH0MXA2DUZD2+KGKVEU1rST+ymau9/JLMiXaYSjLKbNRMjrHlNWzHsIUISiM shBEtIQsTSZVpmCpkEiGfMipai1YtUUg5b65f9QrtZYaMHgG5VaUDz3WgU72+eqN2CgN 3p3BxtVHps4WcROaF9gsici6ezVxLZoB3umG4xhb6r6v8qdhiqw87fQbwtwJHMI+aWSY 3A== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2ff0arr4wt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 12 Jan 2018 16:43:04 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w0CGh35U032131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 12 Jan 2018 16:43:03 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w0CGh2Uk013757; Fri, 12 Jan 2018 16:43:03 GMT In-Reply-To: <5A587620.8040201@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4627.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8772 signatures=668652 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=924 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801120228 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.78 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:221895 Archived-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")?" >=20 > 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. >=20 > 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.