From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bozhidar Batsov Newsgroups: gmane.emacs.devel Subject: Re: Bad moves with xref-find-definitions Date: Mon, 27 Apr 2015 22:36:57 +0300 Message-ID: References: <87h9s6c27z.fsf@gmail.com> <87zj5wnlyt.fsf@gmail.com> <553BE6F2.4030604@yandex.ru> <87fv7ondlr.fsf@gmail.com> <553C5D75.9060706@yandex.ru> <553D316B.5050802@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e013c6b927956180514b9ded4 X-Trace: ger.gmane.org 1430163429 3920 80.91.229.3 (27 Apr 2015 19:37:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Apr 2015 19:37:09 +0000 (UTC) Cc: Vitalie Spinu , Stefan Monnier , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 27 21:37:08 2015 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 1Ymoq2-00082C-Na for ged-emacs-devel@m.gmane.org; Mon, 27 Apr 2015 21:37:06 +0200 Original-Received: from localhost ([::1]:57433 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ymoq2-0006xr-1Q for ged-emacs-devel@m.gmane.org; Mon, 27 Apr 2015 15:37:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ymopx-0006tO-3F for emacs-devel@gnu.org; Mon, 27 Apr 2015 15:37:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ymopv-0007jr-FR for emacs-devel@gnu.org; Mon, 27 Apr 2015 15:37:01 -0400 Original-Received: from mail-la0-x236.google.com ([2a00:1450:4010:c03::236]:34728) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ymopv-0007jj-2L for emacs-devel@gnu.org; Mon, 27 Apr 2015 15:36:59 -0400 Original-Received: by laat2 with SMTP id t2so88042182laa.1 for ; Mon, 27 Apr 2015 12:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qFD63znA0AvvPt8XK9l97Ixk7uHBv2vv/OpKA6hcKjU=; b=X5c91n1/fEnJR3rkD1dCYW+LXsarGECUNPD20x2D9368UaX8Pgq+5gbzLgzhvKkbln e0aWrA5pf3SCwAXPrwad2LgYtmUsFnoOX8iQBtWg1viNehbnU7lCAPN7axV8HGXyzgq/ i69NW89GVG7XQdFs28xR2oUlBGZ0+wpyiXZHSYMmsE59YfbhtGj6ikdBmB354ocXMk7c HT+CRba60g2fOdxjBMgVfH3JD9dara03fAWCiGzHwx/1c91CrkXugDKE/ebU1FUh935e Hq6hut1ZLQkThi5MHWcz3Ls837EtYVQoFaskWr1ZoHaI70uA8nGP/uYqGa6RwIF7IsH4 8Mkg== X-Received: by 10.152.2.38 with SMTP id 6mr11597663lar.80.1430163417550; Mon, 27 Apr 2015 12:36:57 -0700 (PDT) Original-Received: by 10.112.25.7 with HTTP; Mon, 27 Apr 2015 12:36:57 -0700 (PDT) In-Reply-To: <553D316B.5050802@yandex.ru> X-Google-Sender-Auth: IX2gf_QAPtBfUy1MLZD7S12NP0E X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::236 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:185942 Archived-At: --089e013c6b927956180514b9ded4 Content-Type: text/plain; charset=UTF-8 On 26 April 2015 at 21:41, Dmitry Gutov wrote: > On 04/26/2015 09:38 AM, Bozhidar Batsov wrote: > > * find some suitable place to invoke a command (e.g. move their cursor >> to a symbol or to an empty place in the buffer) >> * start wondering what prefix to prepend to the command to alter its >> behaviour >> > > "Press C-u to explicitly enter something" is a pretty common Emacs > pattern. If all modes use the xref interface, it'll become even less of a > problem. > > But on the subject of "what prefix", I think you've made a mistake using > `C-u' for "show in the other window". Emacs normally uses `C-x 4' for that, > which is only one keypress longer. The users who prefer the "other window" > behavior can simply switch the bindings. This was not my doing. I suggested C-x 4, but there was strong opposition for it. > > > While I think that for navigating sources acting on the thing at point >> probably makes more sense, >> > > It can also be beneficial in other ways. Like I've described in another > thread, if you're reading a function, say, for the first time and are > trying to trace its control flow, moving point to the symbol before `M-.' > means you'll immediately know where you "came from" after pressing `M-,'. > > when writing code (meaning you'll need to do >> some doc lookups) you're often wondering "What was the behavior of this >> function?" or "What were I supposed to use here?" and it's unlikely that >> the thing at point will help you much (unless you're simply reading code). >> > > Which function? Where's the set of functions you're choosing from? If the > function name is not at point, I'm guessing it's just not typed out fully. > In that case, you'll probably delegate to the "find doc" or the "find > sources" function of the completion interface you're using. > Yep. This makes perfect sense, btw. > > In `completion-at-point''s case, you'll probably first complete the name > fully and then jump to it. However, using xref-find-apropos is not out of > the question either. > > The global config, as implemented now in CIDER ,has the disadvantage of >> insufficient granularity - e.g. I'd like to always jump to the source of >> thing at point, but I wouldn't like for other commands to behave like >> this. >> > > The settings granularity shouldn't be that much a problem: introduce > another possible value for cider-prompt-for-symbol, which will be a list of > commands for which to always prompt. Sure, that's clearly a possibility. I just didn't want to go overboard with this. Such a config has pretty much the same complexity as adding a second set of commands that simply do the different thing. > > > But as the config option controls all similar commands, all of >> them behave in the same way - either acting on the thing at point or >> always prompting for confirmation. >> > > The key question is which set of commands the variable can affect at all. > For me, "jump to", "show references" and "show doc", all should use the > contents at point by default. OK, but this contradicts with the behavior of Emacs's own `find-function`, `find-variable`, etc. > > > Maybe two sets of matching commands per each such operation or something >> (although handy keybindings are always in short supply). >> > > Probably not: being able to press `C-u' together with a per-command user > option should be enough for everyone. > Life has told me that's it's pretty hard to please everyone. :-) --089e013c6b927956180514b9ded4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 6 April 2015 at 21:41, Dmitry Gutov <dgutov@yandex.ru> wrote:=
On 04/26/2015 09:38 AM,= Bozhidar Batsov wrote:

* find some suitable place to invoke a command (e.g. move their cursor
to a symbol or to an empty place in the buffer)
* start wondering what prefix to prepend to the command to alter its
behaviour

"Press C-u to explicitly enter something" is a pretty common Emac= s pattern. If all modes use the xref interface, it'll become even less = of a problem.

But on the subject of "what prefix", I think you've made a mi= stake using `C-u' for "show in the other window". Emacs norma= lly uses `C-x 4' for that, which is only one keypress longer. The users= who prefer the "other window" behavior can simply switch the bin= dings.

This was not my doing. I suggested C= -x 4, but there was strong opposition for it.
=C2=A0


While I think that for navigating sources acting on the thing at point
probably makes more sense,

It can also be beneficial in other ways. Like I've described in another= thread, if you're reading a function, say, for the first time and are = trying to trace its control flow, moving point to the symbol before `M-.= 9; means you'll immediately know where you "came from" after = pressing `M-,'.

when writing code (meaning you'll need to do
some doc lookups) you're often wondering "What was the behavior of= this
function?" or "What were I supposed to use here?" and it'= ;s unlikely that
the thing at point will help you much (unless you're simply reading cod= e).

Which function? Where's the set of functions you're choosing from? = If the function name is not at point, I'm guessing it's just not ty= ped out fully. In that case, you'll probably delegate to the "find= doc" or the "find sources" function of the completion inter= face you're using.

Yep. This makes = perfect sense, btw.
=C2=A0

In `completion-at-point''s case, you'll probably first complete= the name fully and then jump to it. However, using xref-find-apropos is no= t out of the question either.

The global config, as implemented now in CIDER ,has the disadvantage of
insufficient granularity - e.g. I'd like to always jump to the source o= f
thing at point, but I wouldn't like for other commands to behave like this.

The settings granularity shouldn't be that much a problem: introduce an= other possible value for cider-prompt-for-symbol, which will be a list of c= ommands for which to always prompt.

Sure, t= hat's clearly a possibility. I just didn't want to go overboard wit= h this. Such a config has pretty much the same complexity as adding a secon= d set of commands that simply do the different thing.=C2=A0
=C2= =A0


But as the config option controls all similar commands, all of
them behave in the same way - either acting on the thing at point or
always prompting for confirmation.

The key question is which set of commands the variable can affect at all. F= or me, "jump to", "show references" and "show doc&= quot;, all should use the contents at point by default.
OK, but this contradicts with the behavior of Emacs's own = `find-function`, `find-variable`, etc.
=C2=A0


Maybe two sets of matching commands per each such operation or something (although handy keybindings are always in short supply).

Probably not: being able to press `C-u' together with a per-command use= r option should be enough for everyone.

Life has told me that's it's pretty hard to please everyone. :-)= =C2=A0

--089e013c6b927956180514b9ded4--