From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#23341: x-show-tip does not respect the value of tooltip-hide-delay, and the default tooltip timeout isn't configurable Date: Sun, 1 May 2022 16:19:28 +0000 Message-ID: References: <571AE240.2090103@live.com> <8735hu1u9o.fsf@gnus.org> <83zgk27fn6.fsf@gnu.org> <87r15ezim2.fsf@gnus.org> <83y1zm7e6q.fsf@gnu.org> <87a6c2zglu.fsf@gnus.org> <87ee1ertza.fsf@yahoo.com> <87k0b5tzqu.fsf@gnus.org> <87o80hr4nb.fsf@yahoo.com> <87zgk1poi2.fsf@gnus.org> <87h769r10l.fsf@yahoo.com> <874k29pme6.fsf@gnus.org> <87a6c1qzzk.fsf@yahoo.com> <875ympo4vy.fsf@gnus.org> <8735htqum4.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14528"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "clement.pitclaudel@live.com" , "23341@debbugs.gnu.org" <23341@debbugs.gnu.org> To: Po Lu , Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 01 18:20:19 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nlCJ0-0003cI-UL for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 May 2022 18:20:19 +0200 Original-Received: from localhost ([::1]:54838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nlCIz-0000XJ-JD for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 May 2022 12:20:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlCIk-0000Qv-HB for bug-gnu-emacs@gnu.org; Sun, 01 May 2022 12:20:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40142) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nlCIk-000349-7H for bug-gnu-emacs@gnu.org; Sun, 01 May 2022 12:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nlCIk-0006lq-2y for bug-gnu-emacs@gnu.org; Sun, 01 May 2022 12:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 May 2022 16:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23341 X-GNU-PR-Package: emacs Original-Received: via spool by 23341-submit@debbugs.gnu.org id=B23341.165142197625973 (code B ref 23341); Sun, 01 May 2022 16:20:02 +0000 Original-Received: (at 23341) by debbugs.gnu.org; 1 May 2022 16:19:36 +0000 Original-Received: from localhost ([127.0.0.1]:34035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlCIJ-0006kr-MS for submit@debbugs.gnu.org; Sun, 01 May 2022 12:19:36 -0400 Original-Received: from mx0b-00069f02.pphosted.com ([205.220.177.32]:51852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlCIG-0006ki-Fo for 23341@debbugs.gnu.org; Sun, 01 May 2022 12:19:34 -0400 Original-Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 2419d18V013484; Sun, 1 May 2022 16:19:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2021-07-09; bh=/LSDkdeb5l+/XTc/T+nu+R++QFas1pyYu1fGbM0VHiE=; b=qLS3xTCZmhozEiD7UztcBPMUMqgiwZEriEYYirxIcUpEf/nmX592/Gq45h/lWwvNTonM mLbndDW3zWHBGTF+6zRnv68JavPOa5tG2yVJ5oRuW07BnPHrPYugPpZs2C+B0UCYtnfK LA7BLWzblBFMfGpute6qLpFVNcjDHXlkXLdfX+z8btyslw2M+1ZxJog3VGjABDI/6KhG iiFOB00tHqQVtJjlh6fuioAzK8j4TnwxyEeZ5q3pyGlFv/vsoMmk2yeJwZFdE6/OfKFi 8/C1zu1HoOC5GtjHetq/MYVhCUhGh4AmMp0NRZnwJ6Dzf4jbYmlQZaCJ7Ysrey3ts5in 6A== Original-Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3frvqs9tgr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 01 May 2022 16:19:31 +0000 Original-Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.16.1.2/8.16.1.2) with SMTP id 241GFgfX007431; Sun, 1 May 2022 16:19:31 GMT Original-Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2100.outbound.protection.outlook.com [104.47.58.100]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com with ESMTP id 3fsvbjs1th-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 01 May 2022 16:19:30 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QtdMMuNXAwPzfRg6QBp+P5V0IQzlpLx9zCIgdnIJtO9rw9/pZjvr3ckAeF7sKavM/wyEuhkmumoIqEsh6/ieT09/GomWN5gY6x5jOy3UyfDApRc+lQUtfeC7z8mX6+6gFdq9kPXVRcQD+PnkOISRq32aaIdf/G7trYF+fdjlp4y2/pv7WhMcs+0YXK8sMCe1WkcTjMSeVYfcQtltqpzQZcO6q/wsAg8vV40yWTFHTl4f/ZHoMxx3V6u4Fln9N8bm5q29rses0KovgVdjQFi7w6JtAMIX0Gsp9ykI1TdSDmXVFQYd4KhB2IJxgaKuY74rvHi/dHaWzAPdEK+4nYK8Pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/LSDkdeb5l+/XTc/T+nu+R++QFas1pyYu1fGbM0VHiE=; b=n64xnax7150FDn/CBmK9jMHd+mNw39pCK+MKiP4v1+krODTivuepvpwMxre3ITC673Cp2RApUfKvWQ7Mk4gjVnB3NUngKF0bo1+tQhLZwm/cypFtsZJJRQwgphE2hbeTbX4B+c0UFW3DjyEQydlfFsbbJBrPjBA/ksa/CbgBEvnN4SlwhKNC5XShTOaGEQkUeism/I7aMXU7voOqMDXiFKsiggzWtbgJ/4o+9IWQVW/LfeheFdQK5UsWcRgUKSSyEwroiclHi/fLIIGxTWP7hSr9mSqFh1V6qWCWtv08MQkRl664DujTOFNrFD9skl/6yZQpEK5leA57lmy1WIbF0A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/LSDkdeb5l+/XTc/T+nu+R++QFas1pyYu1fGbM0VHiE=; b=rDk6qRLMxY1mLhmrM52JwcAFqChNlRuQS2KV7K4LlVvknwtoiwkP7Ls95lh/N2YRzYrw+eqivl1MHPrnE8eebj03bHXjIhutEztpQaenrMW+KXk7pX/PyWyU8s4t6EHgLmwLTjPNIVVm8x9fOZg0aVEPOk5sTy7ja6muB35CHMY= Original-Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by BYAPR10MB2472.namprd10.prod.outlook.com (2603:10b6:a02:aa::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.13; Sun, 1 May 2022 16:19:28 +0000 Original-Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::a0e7:5f38:ab50:5123]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::a0e7:5f38:ab50:5123%9]) with mapi id 15.20.5206.013; Sun, 1 May 2022 16:19:28 +0000 Thread-Topic: [External] : bug#23341: x-show-tip does not respect the value of tooltip-hide-delay, and the default tooltip timeout isn't configurable Thread-Index: AQHYXVr4ToTaVEEXOEO5JBE5HiiRQ60KILYQ In-Reply-To: <8735htqum4.fsf@yahoo.com> Accept-Language: en-US Content-Language: en-US x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 21de5dbf-274d-4126-8be4-08da2b8e5dbc x-ms-traffictypediagnostic: BYAPR10MB2472:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uaAY19+zBo2togNOL9Bx5sCLV0ApHV63zHguYFcHFMQuF0BwRzfynoIxKRPReK3ZSTBr9mgS/sV/TfBgENnGlyRVxM9LskH/2MkWiv5fVktgdV+g7ew4TEBaYA0QlVMYAHlH9B2lcDX0ANA/ZQMC6APX2gfGxWbpz2v9fuKI29RSJaGr73mFZFgcznUx5nReWoq7FQBdxGQzTHPfGWrZE+xTpHrODU+WEtCaqBgywIzpT0yI+W3ORAP/ptoXtqf8uG1b4qE4C1tTWUH+XCprrwLcZuP0akBoW/T6Q092AzoSdCOyu1rg8n6M5dLqaC+/jZGUS7VK+XkMaGbd6UlS9ZxFJscb3YmPoRao5VxprwczUwUHE8AVwW5a9qns5KwiSkdnNyXLUXV2eaJsiNbJB8VUgg1mLlWqluIur7130w9g4zwjF0DsWtfOjD75YvB830K1UkPGM1hoscnM4G250IWCR0fYXTVuvah4EXBF8VjhhvLBXpF5hhDCeHZ7/RDCThIYKBR4N8qIcRwwnK2j8SI2Vf9ZDR1xMTtt0hU7dS4RzpJWMd6Z9hwv0vLVnN2pOfcR1XXVWmmSn3jh0obRczchTJy8AaxB2ht6m0BJenp64YWINyPhzoWLYeDPJjWkc7tXRSVSByoUNAe1VQPX1ITvoDUv16GAYecTY9E2gt78QC3Vhfjlv54sK6UhA14ITviwZPfRskSzZtLst9K06w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(38070700005)(5660300002)(6506007)(2906002)(38100700002)(54906003)(26005)(9686003)(7696005)(8936002)(83380400001)(186003)(44832011)(122000001)(55016003)(33656002)(508600001)(71200400001)(52536014)(86362001)(66946007)(76116006)(316002)(110136005)(4326008)(64756008)(8676002)(66556008)(66446008)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: sWL1xPuOhNWw6Et1/Y3uZc4Ht9eUQb7H/h64/5+xomK+HlChBSNr27VYwvaGQdmey8zP57ZH4fT4Q5bk6nM7ApQIZC8/sO5GKVR+/jF+QxEqnR4fRkUQj8xxisuSUQEjv+RYiTLxz/pMYQmC0IhvqWVmdfLCVXlZYbvFzcaIvkZi1CCUYZddh0XC2YIEeN6qkR7ZTv9nFgYS3dUl0/ytpJQyIVC/DgeVGyUA8eoWYysAH59ZqMvzx/0JU+HrihNFwtjJuoBUx8senxYBB2XMkQ8B29FOTpnKCJb1x9jC1SHG5eihi+zLYiPCPPlz4j5WMpJv5g7/xNC38unebTXh/sXHIch6VzHmotwbFdfuCsimxrPd7HGM07f66p2hG+vzniVMP9lvKOQFdS1KqNURPh7tgmEfbC3uk0E3aI02unylBdpL7Ik2dlweCnCg7pAkT+2GVDzJyt/7OdMMtTQdtCpBOmRLkAX07tvUbrdjhGKnKVLFpjUfYVJwPAZZvectMM9dq8U/VxeK88dsgRi8cSYxC/kUk6Us5nSbdcdD+9WArziC5sJMvdPIcE3cn/ibcjxvqhR9ZAQT+/3a0+9ubMMAOBO7WmCkkHpzW1ZCGnTpLpraNx76VFe3KXS60Qzr1e4nYOOGDEiYJLSOTDwfsZ2sM6JHa22kNSws2lfenooh7jUleAau7UHtfiBbB5KEarhY11tN5aWQD89n+C6FZjwTwJqhVsjOOCqZWDUV6v/YaPXB+k0SXOEXb8 RegCQQ1UFCn/9bY+PWyerFP4WlEx7wMqx41yW2qmDTdgpw08N2+Zs1TDN20ed+e7FXR2x8BUDiTuAmEt/j/BNc4US87U4q97TX X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21de5dbf-274d-4126-8be4-08da2b8e5dbc X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2022 16:19:28.3865 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kjws4t5ebCCMEjMbEj558q4fAidOTOmX0g1yowNlTs4gfmcU/x/g928eA+DX5h27Pg4M0w20DKIiITX11wXQhw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB2472 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486, 18.0.858 definitions=2022-05-01_06:2022-04-28, 2022-05-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 spamscore=0 malwarescore=0 adultscore=0 suspectscore=0 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205010131 X-Proofpoint-GUID: 60Y4DPrNAPVrjNyPiRWlBtL8l13vgthA X-Proofpoint-ORIG-GUID: 60Y4DPrNAPVrjNyPiRWlBtL8l13vgthA X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:231168 Archived-At: > But there are external packages calling that function utilizing the > default meanings of its parameters, and it's also an internal function > used by `read-file-dialog', so the analogy with `x-show-tip' is > complete. FWIW, I don't see why `x-show-tip' is being considered "internal". And I'm one who uses it in external libraries. If `tooltip-show' can use `x-show-tip' then so can "external" code that does something similar. The only even partially good excuse for branding something "internal" is to let users know not to depend too heavily on its behavior, as it might change sometime. (And that's anyway true of everything in Emacs.) `tooltip-show' is not sufficiently general to serve as a replacement for the use cases of `x-show-tip'. Branding the latter "off limits" is misguided, IMO. This, in the `x-show-tip' doc string, is misguided: This is an internal function; Lisp code should call `tooltip-show'. (No reason given, BTW. Nothing that helps users understand. Just a big "VERBOTEN !" sign.) ___ On the other hand, there's nothing wrong with _documenting_, clearly, any caveats that you think users of `x-show-tip' should be aware of. And by "documenting" I don't mean hand-waving about unspoken, unclear "complications". ___ Even the title of this bug should be a clue that something is wrong about it: the tail is wagging the dog. Why should `x-show-tip' respect the value of `tooltip-hide-delay'? It's the other way around: `x-show-tip' does not, and should not, depend on any `tooltip-*'. It's `tooltip-*' that depends on its use of `x-show-tip'. ___ What Martin said in this bug thread is sound: A function that calls 'x-show-tip' directly should generally use 'tooltip-hide-delay' as ^^^^^^^^^ TIMEOUT argument. If it doesn't, it should provide a customizable variable to use as ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TIMEOUT argument instead. That's reasonable. If you can reasonably use `tooltip-show' then do so. If you can't, use `x-show-tip'. And in the latter case, if it makes sense to use `tooltip-hide-delay' as the TIMEOUT arg, then do so. If not, then if you can reasonably provide a user option, to let users specify the TIMEOUT to use, then do so. Different uses of showing a tooltip can call for different behaviors, including different TIMEOUT values. For some uses the general option `tooltip-hide-delay' is appropriate. For others it's not - instead, you want to let users specify another timeout value. Martin also suggested: Any package that optionally provides its own delay for hiding tips should, by default, use the value of 'tooltip-hide-delay' for that option. That too makes sense, _in general_. But "should" should be avoided in such guidance, unless "in general" follows. The devil is in the details, i.e., in what the use case is. None of this is complicated. None of it is a reason to call `x-show-tip' off limits. ___ And what Martin said about `x-show-tip' arg TIMEOUT is also sound for args DX and DY: use options `tooltip-[xy]-offset', or provide library-specific options. ___ The bug filer even admitted the following, in response to Martin's clear advice: this isn't a documented convention AFAICS, That calls out for the _proper_ "fix": Just add what Martin suggested to the doc. Don't make a mountain out of this mole hill. ___ This, I think, is the bottom-line expression of the bug OP's problem: I opened this issue based on the experience that it took me some non-trivial amount of time to figure out that I had to configure flycheck-pos-tip-delay, and not tooltip-delay. flycheck-pos-tip follows the convention that you outlined above, but that convention wasn't obvious to me, and doesn't yield a consistent or very nice experience (any time I install a package that uses tooltips, I need to wonder configure its timeout, unless it uses tooltip - which I can't easily guess). IMO, this just points to a case of either or both (1) something (`flycheck-pos-tip') not being well-enough documented or (2) a user not using `C-m' or otherwise checking what a library provides before using it. If Flycheck provides an option for the hide delay it uses, and if it makes that provision obvious, then I don't see a Flycheck bug (or any other bug). Eli said something similar, I think: Bottom line, I think the bug is in the packages that don't provide customizations for this, and you should take this up with the respective maintainers. (I say "I think", because maybe he meant more than that, about an option. Maybe he too meant to suggest that no library should use `x-show-tip'.) If in fact it makes better sense for Flycheck to _not_ provide its own delay option, and instead to just use `tooltip-hide-delay', then change it to do that. (I have no opinion here.) But there's no requirement that code that uses `x-show-tip' use anything `tooltip-*'. That would be backward: the tail wagging the dog. 3rd-party code, just as much as `tooltip.el', can reasonably make use of `x-show-tip'. The OP's complaint is essentially this: I don't want to have to configure every package that I use independently. It's good to be able to fine-tune independent packages, but consistent defaults are nice in any case, aren't they? And this: As a user, I would like to have a way to globally configure how long tooltips produced by Emacs are displayed. At the moment, Emacs does not provide such a default. tooltip-hide-delay is close, but it does not cover all tooltips. It can't - and it shouldn't necessarily - cover all tooltips, because Emacs cannot know how some particular library (use case) might make use of tooltips. OP's inconvenience is the cost of not being able to predict and reasonably cover every use case. So the answer is yes, consistency is nice when it makes sense. But yes, if it makes sense for a library to provide its own settings, such a options, as opposed to just using a generally/globally "consistent" setting, then it's up to you as a user to recognize that fact and act accordingly. If a library gives you an option to get the behavior you like as a user, then don't complain that it's a bother to specify that. If _you_ think that option should default to the value of a more general option, then tell it to the library maintainer. It's possible that the maintainer has a good reason to have provided you with a separate option. Or not. IOW, it's either a problem with that library or a user problem. It's not a problem with `x-show-tip'. One person's inconvenience for having to customize more than just one option is another person's relief in being able to get behavior, in a particular context, that differs from what that general option provides. As Eli put it: to me, such a global value makes very little sense, because tooltips can be used for many different features that don't necessary display short helpful text. Having a single value for all the possible use cases is IMO not a good customization design, as it can never be a "one fits all" value anyway. And he says this, with which I also agree: tooltip-hide-delay has no relation whatsoever to x-show-tip. It is a user option supported by functions in tooltip.el, as its name says. No relation, although I also agree with Martin's suggestion that it can make sense to use that option in a call to `x-show-tip' when other things are equal (i.e., when there's no good reason not to). ___ There were good things said in this thread. This is not one of them, IMO: Reading this thread, there were some good arguments for why we shouldn't add such a variable -- x-show-tip isn't supposed to be called directly, and tooltip.el already has a way to tweak this. Drop the "x-show-tip isn't supposed to be called directly". That's misguided. The rest is fine. ___ Just one opinion, from one 3rd-party provider, who sometimes uses `x-show-tip' with `tooltip-hide-delay' and sometimes uses it with a delay option designed for use with a specific library that calls `x-show-tip'.=20