From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: tags-loop-continue Date: Thu, 14 Jan 2016 21:41:55 +0200 Message-ID: <83bn8ogd8c.fsf@gnu.org> References: <83wprimto9.fsf@gnu.org> <56916C10.6050004@yandex.ru> <83oacumqmj.fsf@gnu.org> <56917246.1010800@yandex.ru> <5691795E.9010008@yandex.ru> <83lh7ym725.fsf@gnu.org> <5691D768.3020908@yandex.ru> <83bn8tmnvq.fsf@gnu.org> <56928356.2000609@yandex.ru> <8360z1mkfc.fsf@gnu.org> <5696EE9D.2090708@yandex.ru> <838u3si22k.fsf@gnu.org> <5697C7A8.6060601@yandex.ru> <83wprcgjxk.fsf@gnu.org> <5697DA3B.3070706@yandex.ru> <83io2wggh8.fsf@gnu.org> <5697EC73.6040302@yandex.ru> <83fuy0gf2j.fsf@gnu.org> <5697F3C9.5040702@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1452800515 22185 80.91.229.3 (14 Jan 2016 19:41:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jan 2016 19:41:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 14 20:41:50 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aJnmF-0000Uh-39 for ged-emacs-devel@m.gmane.org; Thu, 14 Jan 2016 20:41:47 +0100 Original-Received: from localhost ([::1]:44355 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJnmE-0004vj-AS for ged-emacs-devel@m.gmane.org; Thu, 14 Jan 2016 14:41:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJnmB-0004vT-BA for emacs-devel@gnu.org; Thu, 14 Jan 2016 14:41:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJnm8-0000et-If for emacs-devel@gnu.org; Thu, 14 Jan 2016 14:41:43 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54135) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJnm8-0000ep-F3; Thu, 14 Jan 2016 14:41:40 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3762 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aJnm7-00088T-O6; Thu, 14 Jan 2016 14:41:40 -0500 In-reply-to: <5697F3C9.5040702@yandex.ru> (message from Dmitry Gutov on Thu, 14 Jan 2016 22:15:21 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:198154 Archived-At: > Cc: emacs-devel@gnu.org > From: Dmitry Gutov > Date: Thu, 14 Jan 2016 22:15:21 +0300 > > On 01/14/2016 10:02 PM, Eli Zaretskii wrote: > > > I just want the people who are used to 'Q' to have something similar > > to what they knew before. It might be okay to show *xref*-style > > buffer with the hits, though. > > Then they can call `next-error' instead. Unfortunately, this facility is > unreliable in the presence of different next-error-function's in target > buffers. But that was before xref came along. > > > Is that what you meant by "press 'r'"? > > I just mean that we don't have to have a separate command outside of > search results buffer. Yes, it's unfamiliar, but the functionality is > covered, and the manual will tell the user needs to do. Could be fine, I think. We did change this in find-definition, so maybe making a similar change in Dired is okay as well. > > Why is it so important to use that particular binding for > > xref-pop-marker-stack? What's wrong with 'M-*'? > > SLIME has shown that it's better. M-* is much farther from M-., and you > can't as quickly navigate back by keeping M pressed, releasing `.' and > pressing `,'. When I use these commands, I don't really go back and forth that way. In fact, I need to use M-* only rarely. > And really, the xref UI doesn't need it. As long as the *xref* buffer is displayed, it doesn't. But once it is buried, there's no easy way to go to the next hit, right? > We should commit to one default paradigm of behavior. I think I agree. > >> - Do we create versions of all new commands that use the traditional > >> interface? > > > > No, not necessarily. They should be functionally equivalent and > > similar enough in principle. They don't have to have the same > > interface. > > What are the requirements, then? I don't know, to present a reasonable UI for an equivalent functionality?