From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#9054: 24.0.50; show source in other window Date: Tue, 21 Sep 2021 21:05:28 +0300 Organization: LINKOV.NET Message-ID: <87k0j9ixov.fsf@mail.linkov.net> References: <87k4bovfd0.fsf@sophokles.streitblatt.de> <87eea09rwg.fsf@gnus.org> <878s05wxx8.fsf@mail.linkov.net> <87tuisras8.fsf@gnus.org> <87ee9wh4kh.fsf@mail.linkov.net> <82a9592e-b05a-399c-419e-fcbb3e829b35@gmx.at> <87czpfymhj.fsf@mail.linkov.net> <44514af3-09b8-8b6b-c436-cfc5f899142a@gmx.at> <87fsu8pdcp.fsf@mail.linkov.net> <87lf40nwol.fsf@mail.linkov.net> <875122a9-0ff9-4479-97dc-3860466a2b11@gmx.at> <871r5px383.fsf@mail.linkov.net> <87y27vk6pd.fsf@mail.linkov.net> <878rzv8obc.fsf@mail.linkov.net> <76b6ea1e-1256-2205-b6df-cde10330da53@gmx.at> <87czp4lg3p.fsf@mail.linkov.net> <23460cdb-c773-4e60-2770-8aa75e0d5693@gmx.at> <874kaftrgk.fsf@mail.linkov.net> <8bb2944d-29f7-d01b-cd6f-d2a8b1721b46@gmx.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3871"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: Lars Ingebrigtsen , 9054@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 21 20:38:12 2021 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 1mSkeh-0000qp-T7 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Sep 2021 20:38:11 +0200 Original-Received: from localhost ([::1]:54898 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSkef-0000UP-3E for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Sep 2021 14:38:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52172) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSkeX-0000UG-SU for bug-gnu-emacs@gnu.org; Tue, 21 Sep 2021 14:38:01 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36422) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mSkeX-00029T-Kl for bug-gnu-emacs@gnu.org; Tue, 21 Sep 2021 14:38:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mSkeX-0007GA-Jm for bug-gnu-emacs@gnu.org; Tue, 21 Sep 2021 14:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Sep 2021 18:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9054 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 9054-submit@debbugs.gnu.org id=B9054.163224946327873 (code B ref 9054); Tue, 21 Sep 2021 18:38:01 +0000 Original-Received: (at 9054) by debbugs.gnu.org; 21 Sep 2021 18:37:43 +0000 Original-Received: from localhost ([127.0.0.1]:47968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mSkeE-0007FV-Mv for submit@debbugs.gnu.org; Tue, 21 Sep 2021 14:37:42 -0400 Original-Received: from relay2-d.mail.gandi.net ([217.70.183.194]:33613) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mSkeC-0007FC-5n for 9054@debbugs.gnu.org; Tue, 21 Sep 2021 14:37:41 -0400 Original-Received: (Authenticated sender: juri@linkov.net) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id E369940008; Tue, 21 Sep 2021 18:37:31 +0000 (UTC) In-Reply-To: <8bb2944d-29f7-d01b-cd6f-d2a8b1721b46@gmx.at> (martin rudalics's message of "Tue, 21 Sep 2021 10:34:04 +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:215021 Archived-At: >>> We could abbreviate such monsters in the menu entry and show the full >>> identifier in the tooltip of the menu entry. >> >> I'm not sure if this would be more useful: >> >> Describe `display-...' >> Lookup `display-...' in Manuals >> Show Definition of `display-...' >> Show References for `display-...' > > We could try to abbreviate them in some clever way that could be also > used here on emacs-devel when discussing such variables (rather than the > d-f-c-i-c some people use instead). But I think that your 'function' > and 'variable' are already good enough (the term "symbol" has gone for > good) and maybe we could write out the identifier in the tooltips as, > for example, instead of > > "Find definition of identifier" > > we would write > > "Find definition of 'setq'" Good idea. >> Generally, I agree, but the problem is that "Describe Character" >> is not specific to the currently discussed emacs-lisp-mode. > > Neither Paste nor Undo are so we can place that "Describe Character" > just at the end. It should be just intuitively evident for the user > that the properties of the character described at the position of the > mouse are different from the properties of the same character at a > different position. As I claimed before, 'describe-char' tells so many > interesting things which could prompt a user to dig further, as to not > put it into the context menu. The question is whether to show it by default. The default menu that the user will see after clicking somewhere in a new buffer will contain just 2 items: - Select All - Describe Character `x' I think the second item will confuse the users. But it can be added to an optional menu for advanced users. >> Should the context menu always contain "Describe Character" >> in all buffers? > > Definitively. It even does tell the user something useful about > whitespace and control characters. I can't imagine that a novice user would need to describe a character and inspect the output of describe-char. >> The "Select" sub-menu is a good idea. For example, LibreOffice has >> a sub-menu "Selection Mode" with "Standard" and "Rectangle Selection". >> Gimp even has the top-level menu "Select", etc. But this means that >> region-related part of the context menu doesn't need to be the same >> as region-related part of the Edit sub-menu of the menu-bar? > > A "Select" context submenu should propose something reasonable when > there is no active region. When there is an active region around the > mouse position it should say _what_ "Undo" undoes and what "Clear" > clears. And the Edit sub-menu should say the same. I don't understand what it could say. Do you mean it should change to "Undo in Region"? >> Maybe not in Show/Hide sub-menu that is related only to visible parts >> of the screen. > > Tooltips are not visible either until they are shown. Then "Context Menus" could be placed below from "Menu Bar".