From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed, original window-switching intent is lost ) Date: Wed, 25 Oct 2017 17:49:09 +0300 Message-ID: <99a495f7-0d27-27b1-e540-603900d7b614@yandex.ru> References: <87infjm3p3.fsf@gmail.com> <871slyi3lk.fsf_-_@gmail.com> <87lgk22ryu.fsf@gmail.com> <87fua91vis.fsf@gmail.com> <13af136e-12fb-4e8d-81ff-63424b1e1943@yandex.ru> <87y3nzu0xu.fsf@gmail.com> <4b46c989-f94e-a5ce-9264-069c34096419@yandex.ru> <87o9ovs6d2.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1508943024 31308 195.159.176.226 (25 Oct 2017 14:50:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Oct 2017 14:50:24 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 Cc: 28814@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 25 16:50:16 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1e7N0Z-0007C9-0w for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Oct 2017 16:50:15 +0200 Original-Received: from localhost ([::1]:48640 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7N0g-0005vV-6i for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Oct 2017 10:50:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7N0R-0005tf-2h for bug-gnu-emacs@gnu.org; Wed, 25 Oct 2017 10:50:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e7N0N-0004yn-1d for bug-gnu-emacs@gnu.org; Wed, 25 Oct 2017 10:50:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53008) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e7N0M-0004yM-Sx for bug-gnu-emacs@gnu.org; Wed, 25 Oct 2017 10:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e7N0M-000279-Ky for bug-gnu-emacs@gnu.org; Wed, 25 Oct 2017 10:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Oct 2017 14:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28814 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 28814-submit@debbugs.gnu.org id=B28814.15089429608066 (code B ref 28814); Wed, 25 Oct 2017 14:50:02 +0000 Original-Received: (at 28814) by debbugs.gnu.org; 25 Oct 2017 14:49:20 +0000 Original-Received: from localhost ([127.0.0.1]:33456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Mzg-000261-HQ for submit@debbugs.gnu.org; Wed, 25 Oct 2017 10:49:20 -0400 Original-Received: from mail-wm0-f47.google.com ([74.125.82.47]:53126) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7Mzf-00025n-DC for 28814@debbugs.gnu.org; Wed, 25 Oct 2017 10:49:19 -0400 Original-Received: by mail-wm0-f47.google.com with SMTP id t139so2492937wmt.1 for <28814@debbugs.gnu.org>; Wed, 25 Oct 2017 07:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Y/FDrFKLdG1k+jYjlOZGCIaMc2gLZtfnYmZ0lH7zWA4=; b=MlMalzgn6/g1qntcGVhy0fWGfG6qqSJHBPIY+1XhUi3WX1Yuumvacr9mUFnsuCQpa1 Ph67uL7eURotD8gC3KJHdGLwoxqaTEIEp8KVgAJaHxA3cuK7u0jNFt8DEfRIreQkifPC b67YP9MCnKlCk6dwvnmxUvvVfAdrJ4aoOZnyoLrFZRpUlzLj9iJh+JWO+bXTrAdDqD+Q xNLRuWY1XczZKcmYozSAobueOqWFFUi4nU4HXqRF5kYKYCB4a59Gps5XuVMxub+aJ+iz Tcw5O46EcOCW1KA8rFkcgqL3Y4fP4zrMjQrOce4K7CRyjPYT9dU4/A7zwUJH66nBOA8G b9OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Y/FDrFKLdG1k+jYjlOZGCIaMc2gLZtfnYmZ0lH7zWA4=; b=X7rtlOKdS6GKpsTweV3elsElE75yZvwZCny0TQDv79fB/kSDN6KxHWMYOoysTjDar3 saQt1q63WuqTzaYwD+Al1o34Pkt9uTjPLUhGZC02JKNyk6vP2FKc8mJ/EQX+8Vy/q0OG lj1Lt7xg86jRhvv112I3Sl0DZwokyB/BNyG6rSIoimxDoS3KAeIEpOI0DoEdx/mChGVP yCaxWwiMDCHnho+cCwTnqWN2QRo9399iazBYTco6vU08KpMTUltoO50F+Tqsk76rTXnL 1iXDi12sLu0QHhyEf0oIRqPMJMd8TH4abSBa/wRqS7cuucwf7HfXYQow+KNW+gtrq971 8z3Q== X-Gm-Message-State: AMCzsaVgtm9oSpOUZ7yL2F3EdeN6XOYr6EBmNRntfLss2LL75xomh4k7 upcn0zeetz+Da2Tghu8ITrRJKJHd X-Google-Smtp-Source: ABhQp+SB7/JXgLmrARX4Jiv6C4QoojmNQXu02Ru/UKECYEWX6ERwTQOJi2dXJnNwEIl5S0GlWBbP3w== X-Received: by 10.80.194.146 with SMTP id o18mr23736622edf.19.1508942953042; Wed, 25 Oct 2017 07:49:13 -0700 (PDT) Original-Received: from [192.168.0.133] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by smtp.googlemail.com with ESMTPSA id w51sm1963907edd.60.2017.10.25.07.49.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Oct 2017 07:49:11 -0700 (PDT) In-Reply-To: <87o9ovs6d2.fsf@gmail.com> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:138963 Archived-At: On 10/25/17 4:29 PM, João Távora wrote: > It seems you’re talking, in part, of the expectations of users coming > from more "modern" UI’s, like Sublime’s. Naturally, I want all kinds of users to be happy with Emacs. And the "modern" editors have the right idea in some of their design decisions. > I can understand that argument, > but I also argue that not drifting too much from the (twitchy, I’ll > admit) window popping behavior of Emacs is useful in its own right. I'm arguing that what in the cases we want to quit the xref buffer right after, we actually want some sort of richly-decorated *completion* UI where the user picks one destination (or we could call it a selection UI; something other editors often use popups for). And once they pick it, Emacs can pop the destination in some window or other to its heart content. > For example, I’d argue that Emacs users are almost universally used to > ’C-h f/c/m’ stuff bringing up obtrusive windows that they can quit by > typing ’q’ and get back to their original configuration (provided, yes, > that they don’t mess with the window configuration in the > meantime). But the window configuration changes that happen while the user selects the destination in the xref buffer, can't be undone with 'quit', with out without your patches. > If that UI can be improved, it certainly should. (I have some very old > ideas about a single window dedicated frame for help windows that could > be discussed and developed). But whatever is done it should be done to > Emacs as a whole, to preserve consistency. If you're talking about window management in general, that seems orthogonal to me. > In the meantime, my xref patches try to stay close to the current > paradigm. Additionally, they should benefit automatically from any > future improvements. Let's wait for Eli's opinion. >> But 'a' (correct me if I'm wrong) normally replaces a buffer in the >> *current* window. And kill the previous buffer. > > I can’t correct you because I had no idea of that convention either. I > just mentioned ’a’ because I read it somewhere in the discussion. The binding I have in mind is in dired-mode. There, 'a' replaces the current buffer with another. I don't recall any other 'a' bindings, off the top of my head. > I’ll > be fine with any key that means "yes I’ve really decided I want to go > here now take me there and bury this buffer". As a last resort, an > unbound command that I can remap RET to, or a decent interface that > allows me to write such a command. I'd also be fine with any of those. :) 2 or 3 sound best, though. >>> Of course my priority goes towards RET doing xref-quit-and-goto-xref and >>> something else doing xref-goto-xref. If that default isn’t changed, I’ll >>> probably to that remap in my init file.. >> >> So you'd always use "something else" to navigate to >> project-find-regexp search results? > > No, I’d use "n" or "SPC". These work fine as always. SPC is not bound by default. And you'll probably use 'n' in xref-find-definitions output as well. > When I find the one > I want to edit, I press "RET". I’m a big boy, I can find the *xref* > buffer again :-) Would you prefer similar behavior in *Grep* buffers as well? If you still use those.