From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#52973: Adding a few context-menu-mode commands Date: Wed, 12 Jan 2022 19:36:03 +0200 Message-ID: <838rvk6em4.fsf@gnu.org> References: <87o84tp69h.fsf@posteo.net> <868rvwsezi.fsf@mail.linkov.net> <87czl75lyz.fsf@posteo.net> <86czl6au29.fsf@mail.linkov.net> <874k6idjod.fsf@posteo.net> <86o84pthgp.fsf@mail.linkov.net> <87pmp4lmfz.fsf@posteo.net> <86pmp41vby.fsf@mail.linkov.net> <83czl47ghd.fsf@gnu.org> <86ee5kzjo2.fsf@mail.linkov.net> <83bl0o6oei.fsf@gnu.org> <87iluwkkyn.fsf@posteo.net> <83k0fc54bd.fsf@gnu.org> <86bl0m13o1.fsf@mail.linkov.net> <87czkxbhsb.fsf@gnus.org> <83sftt5c99.fsf@gnu.org> <86ilupt0d1.fsf@mail.linkov.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22056"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 52973@debbugs.gnu.org, philipk@posteo.net To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 12 18:40:41 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 1n7hc1-0005XU-CO for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 Jan 2022 18:40:41 +0100 Original-Received: from localhost ([::1]:40770 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n7hby-0001xr-Pl for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 Jan 2022 12:40:38 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57220) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7hYT-0007kQ-Vd for bug-gnu-emacs@gnu.org; Wed, 12 Jan 2022 12:37:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37819) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n7hYT-0001L4-KD for bug-gnu-emacs@gnu.org; Wed, 12 Jan 2022 12:37:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n7hYT-0002M4-IM for bug-gnu-emacs@gnu.org; Wed, 12 Jan 2022 12:37:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Jan 2022 17:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52973 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 52973-submit@debbugs.gnu.org id=B52973.16420089778977 (code B ref 52973); Wed, 12 Jan 2022 17:37:01 +0000 Original-Received: (at 52973) by debbugs.gnu.org; 12 Jan 2022 17:36:17 +0000 Original-Received: from localhost ([127.0.0.1]:58955 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n7hXl-0002Kj-24 for submit@debbugs.gnu.org; Wed, 12 Jan 2022 12:36:17 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n7hXj-0002KW-KL for 52973@debbugs.gnu.org; Wed, 12 Jan 2022 12:36:16 -0500 Original-Received: from [2001:470:142:3::e] (port=52528 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7hXd-0001FA-S6; Wed, 12 Jan 2022 12:36:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=v2MhcxXRdTTKKRRN6kgqekoc0V8D8Hceuz1QEbx3knk=; b=AptjkxU4OscW DxlbGTBToNQc5p5/giTcGR3Dg4wGge+eoTi4A765kXSsOf7uT9wItlhOA7eQAV5cx+s+AovVEB+E6 y12shXvGWpZcX3GsMi1GsFkZdwdv/u/XCkt8XMExsFjV1FHjelVmYUW8i/r8/mXfQcsStnKq16Q76 EXCZ8SHQhvzNy8VYtMbU1p+H00QK3qEl+/4DITmyyfqAqFSyVIGsj/OQaCI8tcxhwLmRLuc6pdwec rINCncCuPPHfI1ozTPd5GKlxi6pOMn9t5y5yl31WrthL1G+6BnN4Z7WhJHqZHNHmYguO2qKfFn6DO JCmRRLwFSvpdI4b8PwgNJQ==; Original-Received: from [87.69.77.57] (port=3566 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7hXd-0004DX-Tn; Wed, 12 Jan 2022 12:36:10 -0500 In-Reply-To: <86ilupt0d1.fsf@mail.linkov.net> (message from Juri Linkov on Wed, 12 Jan 2022 19:16:22 +0200) 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:224012 Archived-At: > From: Juri Linkov > Cc: Lars Ingebrigtsen , philipk@posteo.net, > 52973@debbugs.gnu.org > Date: Wed, 12 Jan 2022 19:16:22 +0200 > > > How do we make sure stuff like "foo(1)" doesn't cause a lot of false > > positives when applied in modes whose idea of what that means is very > > different from Man-mode? I don't think you answered my question above. > For example, today while editing a shell script I needed to consult the > man page about the arguments of the command `zenity` used in the script. > It takes too many keystrokes to type `M-x man RET zenity RET' > or first to move point to this command, then to type `M-x man RET RET'. > > With the context menu, it's just one click: press the right mouse button > on the command name, select the item "Open man page", and release the > mouse button. > > As you can see, there is no special syntax "foo(1)" used in the script. > The context menu item "Open man page" might be useful on any word > that can show a man page for any command or function. > > This means that the item "Open man page" can't be added to the > context menu by default, because it makes no sense most of the time. I don't get it: is the "Open man page" item in the context menu useful or is it useless? The beginning of your description sounds like saying that it's useful, and I almost wanted to ask: so you assume that the user will decide when this item makes sense or not, and therefore we shouldn't be bothered by potential false positives?" But then you say that this item is mostly useless and shouldn't be in the context menu by default? That sounds like a contradiction of the success story with which you started, where the existence of the menu item is a win, isn't it? And then this conclusion: > But when a user can tolerate this mostly useless menu item, > then the user could customize the context-menu-functions > and add the item that is used occasionally. How would the user decide whether he can tolerate this mostly useless menu item? And why should this burden be on the user's shoulders?