Bad moves with xref-find-definitions

Bad moves with xref-find-definitions

[Vitalie Spinu]

Hi All,

There has been a breaking change in UI with respect to find definition
functionality. I am all for generic interface but IMO there is no reason
to break standard Emacs interaction mechanism in favor for some not that
well thought UI borrowed from SLIME.

These are the issues with the new interface:

 1) `find-tag` (previously bound to M-.) was prompting for a symbol
     before jumping to the definition. The symbol at point was the
     default. On the expense of one additional RET this was very
     convenient because it leaves the possibility to jump to a different
     symbol and also saves you from useless navigation to a symbol when
     symbol is not directly under the cursor. The desired symbol might
     not be visible, or even present in current buffer.

     Now, "xref-find-definitions" encourages you to navigate to a symbol
     by disrupting the flow twice. Once, when you navigate to a symbol,
     and often for the second time when you need to go back to the
     editing after you saw the definition. This just fosters a bad habit
     of tracking what you read with a cursor. It just cannot be right.

     Needless to say that most other functionality in Emacs does ask for
     completion before performing an action (documentation, find-file
     etc).

     Having an option to *not* navigate to symbol is very useful and
     Emacs was recognizing this need all this time. Why would you change
     this now?

  2) I haven't investigated the API thoroughly so I might be
     misinterpreting this one.

     Etags is still very useful even with dynamic languages. For example
     the language tool might not load all the files in current
     project/directory, or you might intentionally keep some code in
     non-project directories. You might also define your tags for a
     bunch of other related projects which you want to access from the
     current project.

     Now, when "M-." is gone, if the language re-defines
     `xref-find-function` how do I access tags? Do I need to bind a new
     global key for `find-tag` command?

  3) C-u xref-find-definitions places symbol at point as the initial
     input which forces you to delete it. It's rather annoying.


There has been a lengthy discussion on Cider issue tracker to change the
behavior borrowed from SLIME into standard emacs UI [1][2]. Once that
was changed, emacs itself seems to move into wrong ways.

Vitalie

[1] https://github.com/clojure-emacs/cider/issues/699#start-of-content
[2] https://github.com/clojure-emacs/cider/issues/1014#start-of-content

Re: Bad moves with xref-find-definitions

[Stefan Monnier]

>  1) `find-tag` (previously bound to M-.) was prompting for a symbol
>      before jumping to the definition.

You can still get the prompt, with C-u.

>   3) C-u xref-find-definitions places symbol at point as the initial
>      input which forces you to delete it. It's rather annoying.

Indeed, that looks like a bug.  The convention in Emacs is to use empty
initial inputs (and make the default available as M-n instead).


        Stefan

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/25/2015 05:24 PM, Stefan Monnier wrote:

>>    3) C-u xref-find-definitions places symbol at point as the initial
>>       input which forces you to delete it. It's rather annoying.
>
> Indeed, that looks like a bug.  The convention in Emacs is to use empty
> initial inputs (and make the default available as M-n instead).

Okay, fixed now.

Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Stefan Monnier on Sat, 25 Apr 2015 10:24:29 -0400 wrote:

 >> 1) `find-tag` (previously bound to M-.) was prompting for a symbol
 >> before jumping to the definition.

 > You can still get the prompt, with C-u.

That's a bit besides the point. I want my interface to behave exactly
the same independently of the context at point. I also want consistency
with all other emacs completion. And, most importantly, I don't want to
foster bad habits because my brain always chooses the easy path -
navigate to a symbol instead of C-u.

C-u is an awkward solution. You always have to think before the actual
key press. Is the point on a symbol? Do you need that symbol? Is the
symbol that I need close enough to navigate to it? Shall you press C-u,
or maybe navigate to an empty space? All this pain for a marginal
speed-up in a rather corner case.


On radical UI changes a backward compatible option should be
provided. Especially in this case with so many arguments against the new
interface.

Such changes should be broadly discussed. Somewhat surprisingly the
thread that started the generalization [1] hasn't touched the issues
that I have raised.

So please. Could you please bring the standard Emacs UI back?

Thank you,

  Vitalie

[1] http://comments.gmane.org/gmane.emacs.devel/176235

Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

As to my 2nd original point. I think the exclusive approach of tags *or*
dynamic completion is not the correct one. There should be a way to
merge tag candidates with dynamic candidates. Having C/C++ api interface
to higher order languages is a commonality rather than an exception
nowadays.

So maybe xref-identifier-completion-table-function and
xref-find-function should be better lists of functions to allow for
grouped backends?

  Vitalie

 >>> Vitalie Spinu on Sat, 25 Apr 2015 19:42:34 +0200 wrote:

 >>> Stefan Monnier on Sat, 25 Apr 2015 10:24:29 -0400 wrote:
 >>> 1) `find-tag` (previously bound to M-.) was prompting for a symbol
 >>> before jumping to the definition.

 >> You can still get the prompt, with C-u.

 > That's a bit besides the point. I want my interface to behave exactly
 > the same independently of the context at point. I also want consistency
 > with all other emacs completion. And, most importantly, I don't want to
 > foster bad habits because my brain always chooses the easy path -
 > navigate to a symbol instead of C-u.

 > C-u is an awkward solution. You always have to think before the actual
 > key press. Is the point on a symbol? Do you need that symbol? Is the
 > symbol that I need close enough to navigate to it? Shall you press C-u,
 > or maybe navigate to an empty space? All this pain for a marginal
 > speed-up in a rather corner case.

 > On radical UI changes a backward compatible option should be
 > provided. Especially in this case with so many arguments against the new
 > interface.

 > Such changes should be broadly discussed. Somewhat surprisingly the
 > thread that started the generalization [1] hasn't touched the issues
 > that I have raised.

 > So please. Could you please bring the standard Emacs UI back?

 > Thank you,

 >   Vitalie

 > [1] http://comments.gmane.org/gmane.emacs.devel/176235

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/25/2015 09:49 PM, Vitalie Spinu wrote:
>
> As to my 2nd original point. I think the exclusive approach of tags *or*
> dynamic completion is not the correct one. There should be a way to
> merge tag candidates with dynamic candidates.

xref-find-function defined by the major mode could as well do that.

> Having C/C++ api interface
> to higher order languages is a commonality rather than an exception
> nowadays.

I'm not sure what the above is referring to.

> So maybe xref-identifier-completion-table-function and
> xref-find-function should be better lists of functions to allow for
> grouped backends?

The prevailing thought on that subject is that modes can (or maybe 
should) employ the nadvice package to modify these values.

See http://lists.gnu.org/archive/html/emacs-devel/2014-11/msg00338.html 
and the following messages.

Re: Bad moves with xref-find-definitions

[João Távora]

On Sat, Apr 25, 2015 at 6:42 PM, Vitalie Spinu <spinuvit@gmail.com> wrote:
> C-u is an awkward solution. You always have to think before the actual
> key press. 

You don't have to really. If you make a mistake,press M-, to get back. 

I used to feel like you and then quickly got used to the new behaviour. 
The speed up really is worth it. 

> So please. Could you please bring the standard Emacs UI back?

Please don't. Or at least make it customizable. If you do, I vote
to keep the current behaviour the default.

While we're on the subject, is a patch welcome to set
`xref-find-function' to `elisp-xref-find' more pervasively in the
apropos, debugger and help buffers?

The patch attached does this to a certain degree, but takes some care to
not do this is the major mode's definitions, since in theory these modes
could be used for something other than emacs-lisp.

On the other hand, should we care? Currently, M-. in the *Help* buffer
always prompts to find a tag, which is less useful (if not useless) than
having it try to navigate to an elisp symbol definition.

Thanks,
João

diff --git a/lisp/apropos.el b/lisp/apropos.el
index 023ba4b..b91c77a 100644
--- a/lisp/apropos.el
+++ b/lisp/apropos.el
@@ -1140,8 +1140,9 @@ If non-nil, TEXT is a string that will be printed as a heading."
 	  (apropos-print-doc 6 'apropos-face t)
 	  (apropos-print-doc 5 'apropos-widget t)
 	  (apropos-print-doc 4 'apropos-plist nil))
-        (set (make-local-variable 'truncate-partial-width-windows) t)
-        (set (make-local-variable 'truncate-lines) t))))
+        (setq-local truncate-partial-width-windows t)
+        (setq-local truncate-lines t)
+        (setq-local xref-find-function #'elisp-xref-find))))
   (prog1 apropos-accumulator
     (setq apropos-accumulator ())))	; permit gc
 
diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
index ce5c786..7585215 100644
--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -338,7 +338,8 @@ That buffer should be current already."
 			(with-current-buffer (car tem)
 			  (point))))
 	(pop tem))))
-  (debugger-make-xrefs))
+  (debugger-make-xrefs)
+  (setq-local xref-find-function #'elisp-xref-find))
 
 (defun debugger-make-xrefs (&optional buffer)
   "Attach cross-references to function names in the `*Backtrace*' buffer."
diff --git a/lisp/help.el b/lisp/help.el
index fb1719a..3980f21 100644
--- a/lisp/help.el
+++ b/lisp/help.el
@@ -1346,6 +1346,15 @@ the help window if the current value of the user option
 	(with-output-to-temp-buffer " *Char Help*"
 	  (princ msg)))))
 
+(defun help--setup-xref-find-function (&rest _args)
+  (with-current-buffer (help-buffer)
+    (setq-local xref-find-function #'elisp-xref-find)))
+
+(advice-add 'describe-mode :after #'help--setup-xref-find-function)
+(advice-add 'describe-function :after #'help--setup-xref-find-function)
+(advice-add 'describe-variable :after #'help--setup-xref-find-function)
+(advice-add 'describe-bindings :after #'help--setup-xref-find-function)
+
 \f
 ;; The following functions used to be in help-fns.el, which is not preloaded.
 ;; But for various reasons, they are more widely needed, so they were

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/25/2015 09:56 PM, joaotavora@gmail.com (João Távora) wrote:

> While we're on the subject, is a patch welcome to set
> `xref-find-function' to `elisp-xref-find' more pervasively in the
> apropos, debugger and help buffers?

I'm fine with that, but the effect will also make it harder for Eli to 
undo that change. :) Dunno how important that is.

See http://debbugs.gnu.org/19466.

> The patch attached does this to a certain degree, but takes some care to
> not do this is the major mode's definitions, since in theory these modes
> could be used for something other than emacs-lisp.

Makes sense.

> On the other hand, should we care? Currently, M-. in the *Help* buffer
> always prompts to find a tag, which is less useful (if not useless) than
> having it try to navigate to an elisp symbol definition.

If you run 'make tags', it'll create lisp/TAGS linked with src/TAGS, the 
former containing the core Lisp definitions. Though not any third-party 
ones.

> diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
> index ce5c786..7585215 100644
> --- a/lisp/emacs-lisp/debug.el
> +++ b/lisp/emacs-lisp/debug.el
> @@ -338,7 +338,8 @@ That buffer should be current already."
>   			(with-current-buffer (car tem)
>   			  (point))))
>   	(pop tem))))
> -  (debugger-make-xrefs))
> +  (debugger-make-xrefs)
> +  (setq-local xref-find-function #'elisp-xref-find))

Both this and the other places should probably set 
xref-identifier-completion-table-function as well. You could extract 
those three lines from emacs-lisp-mode.

> +(advice-add 'describe-mode :after #'help--setup-xref-find-function)
> +(advice-add 'describe-function :after #'help--setup-xref-find-function)
> +(advice-add 'describe-variable :after #'help--setup-xref-find-function)
> +(advice-add 'describe-bindings :after #'help--setup-xref-find-function)

Why not add the call to the command definitions directly?

xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 04/25/2015 09:56 PM, joaotavora@gmail.com (João Távora) wrote:
>
>> While we're on the subject, is a patch welcome to set
>> `xref-find-function' to `elisp-xref-find' more pervasively in the
>> apropos, debugger and help buffers?
>
> I'm fine with that, but the effect will also make it harder for Eli to
> undo that change. :) Dunno how important that is.
>
> See http://debbugs.gnu.org/19466.

I've read/skimmed it. Indeed, it's not acceptable to force users to
customize their xref-finding backend in emacs-lisp-mode, its derived
modes (lisp-interaction-mode), or its related modes (elisp apropos,
help, debugger), if, for some reason, they believe etags is a better
backend for them in certain contexts.

BTW the necessary level of indirection is already present with
`advice-add': we needn't necessarily add more variables. I mean:

   (advice-add 'elisp-xref-find :override #'etags-xref-find)

Should be enough and quite readable. Conversely, I wouldn't be very
annoyed if etags were the default method of finding elisp xrefs. Then I
would use advice-add to set my behaviour, perhaps by doing

   (advice-add 'elisp-xref-find :override
   #'elisp-compiled-identifier-locations) ; better name pending

Additionally, if `add-function' allowed `:append' for its WHERE arg,
like Common Lisp's method combinations, it would be even cleaner to get
the behaviour desired by Eli (and Vitalie, I think), of multiple
backends.

   (advice-add 'elisp-xref-find :append #'etags-xref-find)

>> The patch attached does this to a certain degree, but takes some care to
>> not do this is the major mode's definitions, since in theory these modes
>> could be used for something other than emacs-lisp.
>
> Makes sense.

It does, I know, but it would be a lot simpler, especially for functions
spawning *Help* buffers, to just assume we're in an elisp-related
context. Packages like SLIME or SLY or CIDER that make use of these
major modes should be the ones overriding the backend.

>> +(advice-add 'describe-mode :after #'help--setup-xref-find-function)
>> +(advice-add 'describe-function :after #'help--setup-xref-find-function)
>> +(advice-add 'describe-variable :after #'help--setup-xref-find-function)
>> +(advice-add 'describe-bindings :after #'help--setup-xref-find-function)
>
> Why not add the call to the command definitions directly?

Because there are a lot more "describe-*" functions, and ideally, one
would want to advise them on a predictable pattern, not clutter each
`describe-*''s sometimes intricate design with pin-pointed calls to a
setup function.

Anyway, this problem goes away if we take the simpler approach of just
setting it in the major-mode function. It makes the resulting patch a
lot simpler.

João

PS: here's my latest version

diff --git a/lisp/apropos.el b/lisp/apropos.el
index 023ba4b..492d9d7 100644
--- a/lisp/apropos.el
+++ b/lisp/apropos.el
@@ -475,7 +475,8 @@ This requires at least two keywords (unless only one was given)."
 (define-derived-mode apropos-mode special-mode "Apropos"
   "Major mode for following hyperlinks in output of apropos commands.
 
-\\{apropos-mode-map}")
+\\{apropos-mode-map}"
+  (elisp--setup-xref-backend))
 
 (defvar apropos-multi-type t
   "If non-nil, this apropos query concerns multiple types.
diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
index ce5c786..e4c59f0 100644
--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -708,6 +708,7 @@ Complete list of commands:
 \\{debugger-mode-map}"
   (setq truncate-lines t)
   (set-syntax-table emacs-lisp-mode-syntax-table)
+  (elisp--setup-xref-backend)
   (use-local-map debugger-mode-map))
 \f
 (defcustom debugger-record-buffer "*Debugger-record*"
diff --git a/lisp/help-mode.el b/lisp/help-mode.el
index d6679e9..6fc63ea 100644
--- a/lisp/help-mode.el
+++ b/lisp/help-mode.el
@@ -288,7 +288,8 @@ Commands:
   (set (make-local-variable 'revert-buffer-function)
        'help-mode-revert-buffer)
   (set (make-local-variable 'bookmark-make-record-function)
-       'help-bookmark-make-record))
+       'help-bookmark-make-record)
+  (elisp--setup-xref-backend))
 
 ;;;###autoload
 (defun help-mode-setup ()
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index ad35c48..98a3427 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -218,6 +218,8 @@ Comments in the form will be lost."
   :type 'hook
   :group 'lisp)
 
+(declare-function 'elisp--setup-xref-backend "elisp-mode")
+
 ;;;###autoload
 (define-derived-mode emacs-lisp-mode prog-mode "Emacs-Lisp"
   "Major mode for editing Lisp code to run in Emacs.
@@ -227,8 +229,6 @@ Blank lines separate paragraphs.  Semicolons start comments.
 
 \\{emacs-lisp-mode-map}"
   :group 'lisp
-  (defvar xref-find-function)
-  (defvar xref-identifier-completion-table-function)
   (lisp-mode-variables nil nil 'elisp)
   (add-hook 'after-load-functions #'elisp--font-lock-flush-elisp-buffers)
   (setq-local electric-pair-text-pairs
@@ -236,9 +236,7 @@ Blank lines separate paragraphs.  Semicolons start comments.
   (setq imenu-case-fold-search nil)
   (add-function :before-until (local 'eldoc-documentation-function)
                 #'elisp-eldoc-documentation-function)
-  (setq-local xref-find-function #'elisp-xref-find)
-  (setq-local xref-identifier-completion-table-function
-              #'elisp--xref-identifier-completion-table)
+  (elisp--setup-xref-backend)
   (add-hook 'completion-at-point-functions
             #'elisp-completion-at-point nil 'local))
 
@@ -581,6 +579,11 @@ It can be quoted, or be inside a quoted form."
 (declare-function xref-make-bogus-location "xref" (message))
 (declare-function xref-make "xref" (description location))
 
+(defun elisp--setup-xref-backend ()
+  (setq-local xref-find-function #'elisp-xref-find)
+  (setq-local xref-identifier-completion-table-function
+              #'elisp--xref-identifier-completion-table))
+
 (defun elisp-xref-find (action id)
   (require 'find-func)
   (pcase action

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/26/2015 02:51 PM, joaotavora@gmail.com (João Távora) wrote:

> BTW the necessary level of indirection is already present with
> `advice-add': we needn't necessarily add more variables. I mean:
>
>     (advice-add 'elisp-xref-find :override #'etags-xref-find)

Looks good enough to me. Indeed, maybe xref-etags-mode should be 
replaced by a function that applies these advices.

> Should be enough and quite readable. Conversely, I wouldn't be very
> annoyed if etags were the default method of finding elisp xrefs. Then I
> would use advice-add to set my behaviour, perhaps by doing

I think elisp-xref-find is a better default.

>     (advice-add 'elisp-xref-find :override
>     #'elisp-compiled-identifier-locations) ; better name pending

This cannot be done globally (or it'll affect all buffers).

> Additionally, if `add-function' allowed `:append' for its WHERE arg,
> like Common Lisp's method combinations, it would be even cleaner to get
> the behaviour desired by Eli (and Vitalie, I think), of multiple
> backends.
>
>     (advice-add 'elisp-xref-find :append #'etags-xref-find)

a: If we want it to do appending, that could be implemented in 
`elisp-xref-find'. Or there could be a variant of it doing that.

b: This doesn't deal with duplicates, which I think is the main problem 
if we were to go that way.

> It does, I know, but it would be a lot simpler, especially for functions
> spawning *Help* buffers, to just assume we're in an elisp-related
> context. Packages like SLIME or SLY or CIDER that make use of these
> major modes should be the ones overriding the backend.

Can we be sure that languages using the default backend (etags) and 
expecting it to work in their help buffers, will be a negligible minority?

> +(defun elisp--setup-xref-backend ()
> +  (setq-local xref-find-function #'elisp-xref-find)
> +  (setq-local xref-identifier-completion-table-function
> +              #'elisp--xref-identifier-completion-table))

Shouldn't this also include the dynamic declarations removed from 
`emacs-lisp-mode'?

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Eli Zaretskii]

> From: joaotavora@gmail.com (João Távora)
> Date: Sun, 26 Apr 2015 12:51:00 +0100
> Cc: Vitalie Spinu <spinuvit@gmail.com>,
> 	Stefan Monnier <monnier@IRO.UMontreal.CA>, emacs-devel@gnu.org
> 
> >> The patch attached does this to a certain degree, but takes some care to
> >> not do this is the major mode's definitions, since in theory these modes
> >> could be used for something other than emacs-lisp.
> >
> > Makes sense.
> 
> It does, I know, but it would be a lot simpler, especially for functions
> spawning *Help* buffers, to just assume we're in an elisp-related
> context.

Beware: quite a few commands pop up *Help* buffers whose contents have
nothing to do with Lisp.  Some examples:

  . C-u C-x =
  . C-h C-\
  . M-x describe-current-coding-system RET

etc.

> Anyway, this problem goes away if we take the simpler approach of just
> setting it in the major-mode function. It makes the resulting patch a
> lot simpler.

I don't think it's right to always setup an ELisp xref backend in Help
mode, for the above reasons.

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Eli Zaretskii on Sun, 26 Apr 2015 17:51:18 +0300 wrote:

 > Beware: quite a few commands pop up *Help* buffers whose contents have
 > nothing to do with Lisp.  Some examples:

 >   . C-u C-x =
 >   . C-h C-\
 >   . M-x describe-current-coding-system RET

 > etc.

It's because help-mode is not specialized enough. I think there should
be `elisp-help-mode`,  `describe-help-mode` etc. which are derived from
`help-mode`. Maybe obvious, but this struggle with the choice of the
default backend wouldn't be there if xref was able to merge backends.

(FWIW, I would also like to have elisp xref in info mode.)

  Vitalie

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[João Távora]

Vitalie Spinu <spinuvit@gmail.com> writes:

>  >>> Eli Zaretskii on Sun, 26 Apr 2015 17:51:18 +0300 wrote:
>
>  > Beware: quite a few commands pop up *Help* buffers whose contents have
>  > nothing to do with Lisp.  Some examples:
>
>  >   . C-u C-x =
>  >   . C-h C-\
>  >   . M-x describe-current-coding-system RET
>
>  > etc.
>
> It's because help-mode is not specialized enough. I think there should
> be `elisp-help-mode`,  `describe-help-mode` etc. which are derived from
> `help-mode`.

Maybe yes. But anyway Eli's right, some help contexts have nothing to do
with elisp. I see two options:

1) I like this derived mode approach. To implement it perhaps we could
   make `help-mode-setup' call some `help-mode-setup-function' so that
   `with-help-window' does the right thing. Then we set this var in the
   contexts we want. If this is the chosen approach, what should
   `help-mode-setup-function' default to? Perhaps the mew derived
   `elisp-help-mode' since that minimizes the number of describe-*'s to
   touch.

2) Otherwise, we have to explicitly reset the backend on a per-context
   basis. Now, should the default for help mode be `elisp-xref-find' and
   we reset those three, or the other way around? Is my previous
   (advice-add describe-thingy :after ...) strategy acceptable for this?

(BTW: the fix for apropos-mode and debugger-mode is not controversial
right?)

> Maybe obvious, but this struggle with the choice of the
> default backend wouldn't be there if xref was able to merge backends.

I don't see how. How would we remove elisp-xref-find as a backend in
certain help-mode contexts without touching the code where such
contexts are setup.

> (FWIW, I would also like to have elisp xref in info mode.)

But only for the elisp manual, right?

João

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>>  (João Távora)on Tue, 28 Apr 2015 12:41:19 +0100 wrote:

 >> Maybe obvious, but this struggle with the choice of the
 >> default backend wouldn't be there if xref was able to merge backends.

 > I don't see how. How would we remove elisp-xref-find as a backend in
 > certain help-mode contexts without touching the code where such
 > contexts are setup.

Then xref-etags + xref-elisp grouped backend can be the default
everywhere except when it's explicitly redefined.

 >> (FWIW, I would also like to have elisp xref in info mode.)

 > But only for the elisp manual, right?

For all info actually. There are a lot of emacs packages in info for
which xref-elisp is meaningful. For non-emacs documentation other xref
backends are not that meaningful IMW.

BTW, this is potentially one good user case for the proposed contextual
dispatch in cl-generic. You might want dispatch xref on context more
refined than major-mode, emacs related info pages in this case.

 Vitalie

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Eli Zaretskii]

> From: Vitalie Spinu <spinuvit@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  monnier@IRO.UMontreal.CA,  dgutov@yandex.ru
> Date: Tue, 28 Apr 2015 13:59:03 +0200
> 
> For non-emacs documentation other xref backends are not that meaningful IMW.

??? Please see the list of non-Lisp packages I showed in a previous
message: each one of them features a more or less complex programming
language that very much can benefit from xref-style functionality.

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Eli Zaretskii on Tue, 28 Apr 2015 18:17:31 +0300 wrote:
 >> 

 >> For non-emacs documentation other xref backends are not that
 >> meaningful IMW.

 > ??? Please see the list of non-Lisp packages I showed in a previous
 > message: each one of them features a more or less complex programming
 > language that very much can benefit from xref-style functionality.

This is obviously true. My point was different.

If you need to choose a default backend in info mode, xref-eslips is
more useful than xref-etags which is the current default. If you set a
tag table, it will be for one language (at least one location). How does
it help you reading glibc, Gawk, GDB, Make, Guile ...?

  Vitalie


  

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Eli Zaretskii]

> From: Vitalie Spinu <spinuvit@gmail.com>
> Cc: joaotavora@gmail.com,  emacs-devel@gnu.org,  monnier@IRO.UMontreal.CA,  dgutov@yandex.ru
> Date: Tue, 28 Apr 2015 17:45:00 +0200
> 
>  > ??? Please see the list of non-Lisp packages I showed in a previous
>  > message: each one of them features a more or less complex programming
>  > language that very much can benefit from xref-style functionality.
> 
> This is obviously true. My point was different.
> 
> If you need to choose a default backend in info mode, xref-eslips is
> more useful than xref-etags which is the current default.

Only if most of your manuals are for Lisp-related packages.  If not,
it will be as useless as xref-etags.

IOW, "more useful" does not necessarily mean "useful enough".  We need
to be smarter than either of these two as a single default back-end.

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Stefan Monnier]

>> (FWIW, I would also like to have elisp xref in info mode.)
> But only for the elisp manual, right?

It'd make sense to provide an xref-info backend, which could be taught
about the language used in each Info manual and dispatch to the
corresponding xref backend.


        Stefan

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/28/2015 04:27 PM, Stefan Monnier wrote:

> It'd make sense to provide an xref-info backend, which could be taught
> about the language used in each Info manual and dispatch to the
> corresponding xref backend.

Shouldn't an Info xref backend just use the Info index, and jump to 
references within the manual, not to external files?

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Dmitry Gutov on Wed, 29 Apr 2015 00:28:58 +0300 wrote:

 > On 04/28/2015 04:27 PM, Stefan Monnier wrote:
 >> It'd make sense to provide an xref-info backend, which could be taught
 >> about the language used in each Info manual and dispatch to the
 >> corresponding xref backend.

 > Shouldn't an Info xref backend just use the Info index, and jump to references
 > within the manual, not to external files?

That's yet another level of contextual dependence. If one gets used to
the idea of xref jumping to a source location everywhere, doing
something else in info might be rather annoying.

  Vitalie

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Eli Zaretskii]

> Date: Wed, 29 Apr 2015 00:28:58 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: Eli Zaretskii <eliz@gnu.org>, Vitalie Spinu <spinuvit@gmail.com>,
>  emacs-devel@gnu.org
> 
>     It'd make sense to provide an xref-info backend, which could be taught
>     about the language used in each Info manual and dispatch to the
>     corresponding xref backend.
> 
> Shouldn't an Info xref backend just use the Info index, and jump to references within the manual, not to external files?

This could be the default, but I'm not sure it should be the only
source of information.  E.g., what if there's no index, or the symbol
in question is not indexed?

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Eli Zaretskii]

> From: Vitalie Spinu <spinuvit@gmail.com>
> Cc: joaotavora@gmail.com (João Távora),
>   emacs-devel@gnu.org,  monnier@IRO.UMontreal.CA,  dgutov@yandex.ru
> Date: Tue, 28 Apr 2015 13:06:41 +0200
> 
> (FWIW, I would also like to have elisp xref in info mode.)

Do you read Info manuals only about Emacs and Lisp?  I read them about
glibc, Gawk, GDB, Make, Guile, and a few others.  Each one of those
has its own scripting/programming language, so the Elisp xref will
unlikely to be of any value.

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Eli Zaretskii on Tue, 28 Apr 2015 18:15:41 +0300 wrote:

 >> From: Vitalie Spinu <spinuvit@gmail.com>

 > I read them about glibc, Gawk, GDB, Make, Guile, and a few others.

Just out of curiosity. How many times have you setup tags for core
symbols of Gawk, Make, Guile and others when you were reading info
intros on those?

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Eli Zaretskii]

> From: Vitalie Spinu <spinuvit@gmail.com>
> Cc: joaotavora@gmail.com,  emacs-devel@gnu.org,  monnier@IRO.UMontreal.CA,  dgutov@yandex.ru
> Date: Tue, 28 Apr 2015 17:47:51 +0200
> 
>  >>> Eli Zaretskii on Tue, 28 Apr 2015 18:15:41 +0300 wrote:
> 
>  >> From: Vitalie Spinu <spinuvit@gmail.com>
> 
>  > I read them about glibc, Gawk, GDB, Make, Guile, and a few others.
> 
> Just out of curiosity. How many times have you setup tags for core
> symbols of Gawk, Make, Guile and others when you were reading info
> intros on those?

I always run "make TAGS" right after I build some project.

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Helmut Eller]

On Tue, Apr 28 2015, Vitalie Spinu wrote:

> Maybe obvious, but this struggle with the choice of the
> default backend wouldn't be there if xref was able to merge backends.

My original proposal had a xref-location= generic function for exactly
that reason: to give the front end the possibility to remove duplicates.

However, this was removed because a) it complicates the
front-end<->backend-end API b) everybody who can write methods for
xref-location= can just as well write a backend that removes duplicates.

For me those are convincing arguments too delegate duplicate removal to
backends.

Helmut

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Helmut Eller on Wed, 29 Apr 2015 08:55:24 +0200 wrote:

 > On Tue, Apr 28 2015, Vitalie Spinu wrote:
 >> Maybe obvious, but this struggle with the choice of the
 >> default backend wouldn't be there if xref was able to merge backends.

 > My original proposal had a xref-location= generic function for exactly
 > that reason: to give the front end the possibility to remove duplicates.

 > However, this was removed because a) it complicates the
 > front-end<->backend-end API b) everybody who can write methods for
 > xref-location= can just as well write a backend that removes duplicates.

 > For me those are convincing arguments too delegate duplicate removal to
 > backends.

I probably miss something essential but this doesn't make sense to
me. We are talking about merged backends. So, the task of frontend is to
remove duplicates which result from merging multiple candidate lists
coming from backends. How an individual backend can deal with that?

  Vitalie

  

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Helmut Eller]

On Wed, Apr 29 2015, Vitalie Spinu wrote:

>  > For me those are convincing arguments too delegate duplicate removal to
>  > backends.
>
> I probably miss something essential but this doesn't make sense to
> me. We are talking about merged backends. So, the task of frontend is to
> remove duplicates which result from merging multiple candidate lists
> coming from backends. How an individual backend can deal with that?

You have 2 backends.  Create a third backend that calls the other two
and does the merging.  The front-end is doesn't need to know how to
merge.

Helmut

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Helmut Eller on Wed, 29 Apr 2015 15:01:42 +0200 wrote:

 > On Wed, Apr 29 2015, Vitalie Spinu wrote:
 >> > For me those are convincing arguments too delegate duplicate removal to
 >> > backends.
 >> 
 >> I probably miss something essential but this doesn't make sense to
 >> me. We are talking about merged backends. So, the task of frontend is to
 >> remove duplicates which result from merging multiple candidate lists
 >> coming from backends. How an individual backend can deal with that?

 > You have 2 backends.  Create a third backend that calls the other two
 > and does the merging.  The front-end is doesn't need to know how to
 > merge.

Then for any combination of backends that you want to merge you need to
write yet another backend.

  Vitalie

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/29/2015 06:30 PM, Vitalie Spinu wrote:

> Then for any combination of backends that you want to merge you need to
> write yet another backend.

While that may sound like it'll lead to a combinatorial explosion of 
backends, that's not very likely to happen in practice.

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/29/2015 09:55 AM, Helmut Eller wrote:

> However, this was removed because a) it complicates the
> front-end<->backend-end API b) everybody who can write methods for
> xref-location= can just as well write a backend that removes duplicates.

And in the current context, the xref-location= method, by itself, 
wouldn't help with the pretty much insolvable problem of comparing 
"lazy" xrefs coming from different backends.

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Helmut Eller]

On Wed, Apr 29 2015, Dmitry Gutov wrote:

> On 04/29/2015 09:55 AM, Helmut Eller wrote:
>
>> However, this was removed because a) it complicates the
>> front-end<->backend-end API b) everybody who can write methods for
>> xref-location= can just as well write a backend that removes duplicates.
>
> And in the current context, the xref-location= method, by itself,
> wouldn't help with the pretty much insolvable problem of comparing
> "lazy" xrefs coming from different backends.

It's always solvable:

(equal (xref-location-marker L1)
       (xref-location-marker L2))

covers all cases; it's just not very efficient.

Helmut

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/29/2015 04:04 PM, Helmut Eller wrote:

> It's always solvable:
>
> (equal (xref-location-marker L1)
>         (xref-location-marker L2))
>
> covers all cases; it's just not very efficient.

That's true. It may also open 1-2 new buffers in the background. I'm 
really not sure what our policy on those should be.

Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[Stefan Monnier]

> Additionally, if `add-function' allowed `:append' for its WHERE arg,
> like Common Lisp's method combinations, it would be even cleaner to get
> the behaviour desired by Eli (and Vitalie, I think), of multiple
> backends.

>    (advice-add 'elisp-xref-find :append #'etags-xref-find)

You can get that with

     (advice-add 'elisp-xref-find :around
       (lambda (orig-fun &rest args))
         (append (apply #'etags-xref-find args)
                 (apply orig-fun args)))

tho it's obviously not as elegant.  We could add a `:append'
alternative.  We just need to add the corresponding bytecode to
advice--bytecodes.  Sadly, these typically need to be handtweaked, since
they need to use a particular layout in their constant vector.


        Stefan

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/25/2015 08:42 PM, Vitalie Spinu wrote:

> Such changes should be broadly discussed. Somewhat surprisingly the
> thread that started the generalization [1] hasn't touched the issues
> that I have raised.

Maybe because they're not as important as you make them out to be?

> So please. Could you please bring the standard Emacs UI back?

Would you like to suggest the name for the new user option?

Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Dmitry Gutov on Sat, 25 Apr 2015 22:11:46 +0300 wrote:

 > Would you like to suggest the name for the new user option?

It probably should be generic such that other "finding" or "jumping"
functionality can reuse it (prompt-before-jump, auto-jump).

The problem is of course that "find-file" is also a "finding" behavior,
for which you unlikely to want this behavior. So it's difficult to draw
a line on what are these commands.

More specific name like xref-auto-jump seems quite suggestive to me.

  Vitalie

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/25/2015 11:43 PM, Vitalie Spinu wrote:

> It probably should be generic such that other "finding" or "jumping"
> functionality can reuse it (prompt-before-jump, auto-jump).

Maybe the rule could be whether the command is almost always related to 
the current buffer's contents.

`describe-function' and friends I would actually consider to be 
counter-examples, because they only work with Elisp.

And similarly how certain other people are attached to etags, I'd always 
want to have access to Elisp documentation and sources, even when 
editing unrelated code in another language.

Hence I think we need a separate, generalizable command and binding that 
would work with different modes and depend on the current language or 
project. That one could work like SLIME's `C-c C-d C-d'.

> The problem is of course that "find-file" is also a "finding" behavior,
> for which you unlikely to want this behavior. So it's difficult to draw
> a line on what are these commands.

Let's stop at xref, for now.

> More specific name like xref-auto-jump seems quite suggestive to me.

How about `xref-prompt-for-identifier', to mirror CIDER's option name?

Re: Bad moves with xref-find-definitions

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 3229 bytes --]

Let me join this discussion. As the maintainer of CIDER, I had to
participate into a much longer debate about the merits of both styles on
the CIDER issue tracker and feel I can share a thought or two.

I believe that the fundamental problem we face is that finding something is
not the same as acting on the thing at point. When you opt to immediately
act on the symbol/file/etc on point you're forcing the users to do one of
two things:

* 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

While I think that for navigating sources acting on the thing at point
probably makes more sense, 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).

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.
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.

Clearly I can roll out any custom solution that suits my needs (we're in
Emacs after all), but I feel we have a deeper usability problem in Emacs in
general and it'd be nice if we could come to some universal solution. Maybe
two sets of matching commands per each such operation or something
(although handy keybindings are always in short supply).

As to whether SLIME's behaviour is preferable to Emacs's - as usual that's
super subjective.

Btw, the idea of having standard behaviour in major modes for finding
definitions, usages & documentation is not bad at all.

On 26 April 2015 at 06:37, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 04/25/2015 11:43 PM, Vitalie Spinu wrote:
>
>  It probably should be generic such that other "finding" or "jumping"
>> functionality can reuse it (prompt-before-jump, auto-jump).
>>
>
> Maybe the rule could be whether the command is almost always related to
> the current buffer's contents.
>
> `describe-function' and friends I would actually consider to be
> counter-examples, because they only work with Elisp.
>
> And similarly how certain other people are attached to etags, I'd always
> want to have access to Elisp documentation and sources, even when editing
> unrelated code in another language.
>
> Hence I think we need a separate, generalizable command and binding that
> would work with different modes and depend on the current language or
> project. That one could work like SLIME's `C-c C-d C-d'.
>
>  The problem is of course that "find-file" is also a "finding" behavior,
>> for which you unlikely to want this behavior. So it's difficult to draw
>> a line on what are these commands.
>>
>
> Let's stop at xref, for now.
>
>  More specific name like xref-auto-jump seems quite suggestive to me.
>>
>
> How about `xref-prompt-for-identifier', to mirror CIDER's option name?
>
>

[-- Attachment #2: Type: text/html, Size: 4329 bytes --]

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

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.

> 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.

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.

> 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.

> 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.

Re: Bad moves with xref-find-definitions

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]

On 26 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 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. :-)

[-- Attachment #2: Type: text/html, Size: 5539 bytes --]

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/27/2015 10:36 PM, Bozhidar Batsov wrote:

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

https://github.com/clojure-emacs/cider/issues/1014? Maybe people just 
missed the suggestion. And note how in 
https://github.com/clojure-emacs/cider/pull/1044 someone wonders why it 
works in a different way.

Anyway, at this point you can add support for xref, and gradually 
deprecate the alternative bindings.

> 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.

I think it's a bit easier than asking a user to change a set of key 
bindings. Should take less code to implement, too.

Having separate bindings for "always prompt" might be a good idea 
anyway, though. Like F12 vs Ctrl-P in Sublime or Ctrl-Click vs Ctrl-N, 
etc, in IDEA.

IDEA also uses a different interface for multiple choices in the 
Ctrl-Click case.

> OK, but this contradicts with the behavior of Emacs's own
> `find-function`, `find-variable`, etc.

It does, but find-func is kind of auxiliary package. None of these 
commands have default bindings.

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

We probably have different standards for user satisfaction. "Everyone is 
equally annoyed" is often quite enough for me. :)

Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Dmitry Gutov on Sun, 26 Apr 2015 21:41:47 +0300 wrote:


 > 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-,'.

I would be reasonably happy with this if I could quickly navigate to
last editing position. I always wanted that C-u C-SPC would allow me to
navigate to the editing position first. Now I am experimenting with
goto-chg mode; will see how it goes.


  Vitalie

Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Dmitry Gutov on Sun, 26 Apr 2015 06:37:25 +0300 wrote:

 > And similarly how certain other people are attached to etags, I'd always want to
 > have access to Elisp documentation and sources, even when editing unrelated code
 > in another language.

Me too.

Ho about having multiple configurable "levels" of xref to be accessed
with numeric prefixes (M-1,M-2 etc). Then one can have M-3 M-. to always
access elisp references, M-4 M-. to access current tags and M-. for
whatever the current mode thinks is the best.

Would be nice to be able to set the "level" dynamically. For example, if
I have a related code which I want to consult only rarely, I build a tag
table for that code and hook it immediately on M-8.

 >> More specific name like xref-auto-jump seems quite suggestive to me.

 > How about `xref-prompt-for-identifier', to mirror CIDER's option name?

Sounds good. 

Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Vitalie Spinu on Sun, 26 Apr 2015 12:44:38 +0200 wrote:

 > Ho about having multiple configurable "levels" of xref to be accessed
 > with numeric prefixes (M-1,M-2 etc). Then one can have M-3 M-. to always
 > access elisp references, M-4 M-. to access current tags and M-. for
 > whatever the current mode thinks is the best.

A couple more alternatives to merging all backends upfront:

  - Start with default backend and then rotate available backends with a
    key (M-r?)
  - Dynamically query all backends after 2-3 keystrokes 

Both strategies make sense only if you prompt first. They also go best
with visual feedback as in IDO or HELM.

  Vitalie

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/26/2015 01:44 PM, Vitalie Spinu wrote:

> Me too.

But you're willing to prepend `M-3' every time you want to look up 
something in Elisp? That's not really ideal either.

> Ho about having multiple configurable "levels" of xref to be accessed
> with numeric prefixes (M-1,M-2 etc). Then one can have M-3 M-. to always
> access elisp references, M-4 M-. to access current tags and M-. for
> whatever the current mode thinks is the best.

That's not bad, but it sounds like too much micromanagement to me. In 
any other editor, it would be accompanied by a dedicated UI, at least. I 
don't know if even Helm would cut it.

So, I'd rather see this as a minor mode. Maybe a package in ELPA?

Personally, I expect "serious" backends to either replace the need for 
etags entirely, or delegate to them and collect the results internally.

> Would be nice to be able to set the "level" dynamically. For example, if
> I have a related code which I want to consult only rarely, I build a tag
> table for that code and hook it immediately on M-8.

That new minor mode could offer a capability to simply switch to a 
different source, temporarily, or just for one command. And keep the 
history of already-configured sources.

A source configuration would not just be limited to the xref- vars, 
though. If you want to consult certain tag tables only sometimes, those 
sources would store the value of tags-table-list, for instance. And 
restore it upon quitting.

>   > How about `xref-prompt-for-identifier', to mirror CIDER's option name?
>
> Sounds good.

Added.

Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Dmitry Gutov on Sun, 26 Apr 2015 18:09:19 +0300 wrote:

 > On 04/26/2015 01:44 PM, Vitalie Spinu wrote:
 >> Me too.

 > But you're willing to prepend `M-3' every time you want to look up something in
 > Elisp? That's not really ideal either.

Not ideal but at least it's context free. And you don't need it that
often from other places anyways.

 > Personally, I expect "serious" backends to either replace the need for etags
 > entirely, or delegate to them and collect the results internally.

It's not really possible. Sometimes you just need to open related
project without "sourcing" it or an old version of the current project
to keep it as a reference. No "serious" backend can accommodate that.

Besides etags it might be potentially handy to have multiple backends
within a mode. In clojure for example you can have one backend for pure
clojure code and another for java code. If xref is able to merge
backends and provide a nice UI to manage those backends then CIDER would
not need to bother with merging or managing those.

As this and other threads suggest managing backends is a non-trivial
task. If you leave this task to major modes everyone will cook his own
soup resulting in a variety of different interfaces.

 >> > How about `xref-prompt-for-identifier', to mirror CIDER's option name?
 >> 
 >> Sounds good.

 > Added.

Thanks!

  Vitalie

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/26/2015 07:23 PM, Vitalie Spinu wrote:

> Not ideal but at least it's context free. And you don't need it that
> often from other places anyways.

I'd rather keep it as C-h f/v/o/m, and add snappier binding(s) for 
context-dependent command(s).

>   > Personally, I expect "serious" backends to either replace the need for etags
>   > entirely, or delegate to them and collect the results internally.
>
> It's not really possible. Sometimes you just need to open related
> project without "sourcing" it or an old version of the current project
> to keep it as a reference. No "serious" backend can accommodate that.

Why not `M-x projectile-switch-project', or something similar?

> Besides etags it might be potentially handy to have multiple backends
> within a mode. In clojure for example you can have one backend for pure
> clojure code and another for java code. If xref is able to merge
> backends and provide a nice UI to manage those backends then CIDER would
> not need to bother with merging or managing those.

I fail to see the benefits of keeping Clojure and Java identifiers 
separate. The commands easily choose one or the other based on the 
context, and if you're typing the identifier manually, the Java ones 
look distinctly different.

Also, while CIDER knows that Java and Clojure identifiers have no 
duplicates between them (and can simply concatenate the lists, or 
something to that effect), the generic code cannot know that.

> As this and other threads suggest managing backends is a non-trivial
> task. If you leave this task to major modes everyone will cook his own
> soup resulting in a variety of different interfaces.

If I have to guess, the built-in major modes will use comparatively 
simpler approaches (like python-mode's delegation to the REPL process to 
fetch completions), but third-party minor modes can provide smarter 
integration.

I definitely don't want to see here micromanagement a la Icicles in the 
default interface.

Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Dmitry Gutov on Sun, 26 Apr 2015 20:51:02 +0300 wrote:
 >> It's not really possible. Sometimes you just need to open related
 >> project without "sourcing" it or an old version of the current project
 >> to keep it as a reference. No "serious" backend can accommodate that.

 > Why not `M-x projectile-switch-project', or something similar?

Because you need an interactive repl running to have dynamic completion
for one, and for multiple language projects you don't have access to
C/Fortran etc definitions from the interactive session anyways. So at
least the etags integration should be done properly in the core.

 > I fail to see the benefits of keeping Clojure and Java identifiers
 > separate.

Generally you don't want to clutter completion or location tables with
java symbols from all the projects that you import. %99.99 of those are
useless. In most cases you need clojure and java symbols in current
project. Next level is all core and imported clojure symbols. Then all
java classes/methods.

There is an open issue in CIDER on interactive doc completion where this
was discussed [1]. Bozhidar can comment on this more, but the general
idea is that you want to offer completion candidates in some sort of
stages in order to avoid impairing the usability. I think the same
concern is valid for references (for the prompt case and apropos at
least).



  Vitalie

[1] https://github.com/clojure-emacs/cider/issues/1059#start-of-content

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/26/2015 11:56 PM, Vitalie Spinu wrote:

> Because you need an interactive repl running to have dynamic completion
> for one, and for multiple language projects you don't have access to
> C/Fortran etc definitions from the interactive session anyways. So at
> least the etags integration should be done properly in the core.

We're talking about using some new tags table, to jump to a file in a 
different project, right? How come it's important to have a running 
repl, then?

> Generally you don't want to clutter completion or location tables with
> java symbols from all the projects that you import. %99.99 of those are
> useless. In most cases you need clojure and java symbols in current
> project. Next level is all core and imported clojure symbols. Then all
> java classes/methods.

Note that these levels are not split along the lines of Clojure/Java.

And while it seems like it could a sensible approach, I don't exactly 
see a solution in terms of new xref features.

> There is an open issue in CIDER on interactive doc completion where this
> was discussed [1]. Bozhidar can comment on this more, but the general
> idea is that you want to offer completion candidates in some sort of
> stages in order to avoid impairing the usability. I think the same
> concern is valid for references (for the prompt case and apropos at
> least).

But the currently suggested approach proposes to use one completion 
table for all stages.

Re: Bad moves with xref-find-definitions

[Stefan Monnier]

> That's a bit besides the point. I want my interface to behave exactly
> the same independently of the context at point.

You're talking here about the fact that M-. will prompt if there's no
"thing at point"?  We could make it signal an error, indeed.

> And, most importantly, I don't want to foster bad habits because my
> brain always chooses the easy path - navigate to a symbol instead of
> C-u.

Thing is: the two are different.  In some languages, figuring out "the
thing at point" may itself not be obvious and even finding
a human-palatable textual representation of "the thing at point" may
turn out to be extra work.

So M-. really means "pass the current buffer position to the backend and
let it figure out what are the possible corresponding definitions".
Whereas C-u M-. asks the user for a textual representation of some
definition, and then tries to find matching definitions.

Of course, we could make the "empty minibuffer" mean "use the current
buffer position", but it seems cleaner to short-circuit the minibuffer
so we don't have to use a special string for it.

> Such changes should be broadly discussed. Somewhat surprisingly the
> thread that started the generalization [1] hasn't touched the issues
> that I have raised.

We did discuss those UI issues.  You're not the first to bring it up.
I personally don't think it's such a major change.

> As to my 2nd original point. I think the exclusive approach of tags *or*
> dynamic completion is not the correct one.  There should be a way to
> merge tag candidates with dynamic candidates.

In theory at least there is (as Dmitry points out) by having the major
modes change the variable via `add-function' using :around or something
like that.  I haven't tried doing so, so I don't know if it turns out to
be easy to do that.  If it's not, then I'd welcome a patch that makes
it easier.
But if you want to override the major mode to use etags, you probably
want to use xref-etags-mode.

> Having C/C++ api interface to higher order languages is a commonality
> rather than an exception nowadays.

I do not understand what you're trying to say here (more specifically,
I can't see how this relates to the discussion).


        Stefan

Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Stefan Monnier on Sat, 25 Apr 2015 23:34:36 -0400 wrote:

 >> That's a bit besides the point. I want my interface to behave exactly
 >> the same independently of the context at point.

 > You're talking here about the fact that M-. will prompt if there's no
 > "thing at point"?  

Yes.

 > We could make it signal an error, indeed.

I would like that. At least it would force people using C-u. Now I
always navigate to empty space, even though I ware that it's a
completely stupid habit.

>> And, most importantly, I don't want to foster bad habits because my
 >> brain always chooses the easy path - navigate to a symbol instead of
 >> C-u.

 > Thing is: the two are different.  In some languages, figuring out "the
 > thing at point" may itself not be obvious and even finding
 > a human-palatable textual representation of "the thing at point" may
 > turn out to be extra work.

 > So M-. really means "pass the current buffer position to the backend and
 > let it figure out what are the possible corresponding definitions".
 > Whereas C-u M-. asks the user for a textual representation of some
 > definition, and then tries to find matching definitions.

 > Of course, we could make the "empty minibuffer" mean "use the current
 > buffer position", but it seems cleaner to short-circuit the minibuffer
 > so we don't have to use a special string for it.

Backend has to figure out the "thing" anyways. From there building
"textual representation" and passing back to xref is a triviality. Also,
you have to provide completions and textual representation of on C-u
anyways.

What do you currently do if there are multiple matching definitions of
the "thing-at-point"? Prompt?

 >> Having C/C++ api interface to higher order languages is a commonality
 >> rather than an exception nowadays.

 > I do not understand what you're trying to say here (more specifically,
 > I can't see how this relates to the discussion).

All I was trying to say is that tags are commonly useful alongside
dynamic backends. Blindly replacing tags with an even very good backend
is not the right direction IMW. Expecting from end users to solve this
problem with add-function :before is unacceptable if there are way to
fix it at Emacs level. 

Different backends can figure different "things-at-point". It would be
wise to try back-ends in turn, just like completion-at-point-functions
does.

As to prompting, if you try to accommodate multiple backends, then
merging completion candidates from multiple backends is a simple task
when you prompt. If you try instead to "bypass the minibuffer" it's
likely to be a much more difficult task.


  Vitalie

Re: Bad moves with xref-find-definitions

[Eli Zaretskii]

> From: Vitalie Spinu <spinuvit@gmail.com>
> Date: Sun, 26 Apr 2015 13:31:36 +0200
> Cc: emacs-devel@gnu.org
> 
> > >  > > 1) `find-tag` (previously bound to M-.) was prompting for a symbol
> > >  > > before jumping to the definition.
> > >  > >
> > >  > You can still get the prompt, with C-u.
> > >  >
> > > That's a bit besides the point. I want my interface to behave exactly
> > > the same independently of the context at point.
> > >
> > You're talking here about the fact that M-. will prompt if there's no
> > "thing at point"?  
> >
> Yes.
> >
> > We could make it signal an error, indeed.
> 
> I would like that.

This is backwards, sorry.  M-. should be intelligent enough not to
signal errors in this situation, and neither should it require users
to navigate needlessly.  No other feature that is sensitive to "the
thing at point" behaves like that, AFAIR.

Do we really want users to hate xref starting from day one?

If this issue is controversial among users, let's have a user option
to control the default behavior -- either always prompt and use the
symbol at point, if any, for the default value, or prompt only when
there's no usable symbol at point.  Then everyone can have what they
like without unduly punishing the rest.

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/26/2015 05:50 PM, Eli Zaretskii wrote:

> This is backwards, sorry.  M-. should be intelligent enough not to
> signal errors in this situation, and neither should it require users
> to navigate needlessly.  No other feature that is sensitive to "the
> thing at point" behaves like that, AFAIR.

Yes, this does not make sense to me either.

> If this issue is controversial among users, let's have a user option
> to control the default behavior -- either always prompt and use the
> symbol at point, if any, for the default value, or prompt only when
> there's no usable symbol at point.

The option has been added.

Re: Bad moves with xref-find-definitions

[Eli Zaretskii]

> Date: Sun, 26 Apr 2015 18:12:32 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> 
> > If this issue is controversial among users, let's have a user option
> > to control the default behavior -- either always prompt and use the
> > symbol at point, if any, for the default value, or prompt only when
> > there's no usable symbol at point.
> 
> The option has been added.

Thanks.

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/26/2015 02:31 PM, Vitalie Spinu wrote:

> What do you currently do if there are multiple matching definitions of
> the "thing-at-point"? Prompt?

Show them all in the xref buffer. But if the backend is smart enough, it 
will include the disambiguating context information as text properties 
on the "thing-at-point" string.

That kind of string (probably) can't be present in the completion table, 
though.

> All I was trying to say is that tags are commonly useful alongside
> dynamic backends. Blindly replacing tags with an even very good backend
> is not the right direction IMW. Expecting from end users to solve this
> problem with add-function :before is unacceptable if there are way to
> fix it at Emacs level.

It doesn't have to come down to users. Completion packages could take 
care of it as well.

> As to prompting, if you try to accommodate multiple backends, then
> merging completion candidates from multiple backends is a simple task
> when you prompt.

Not if you want to avoid duplicates. Currently, file opening and 
nagivation to the exact positions is being done lazily (which improves 
overall performance quite a bit). So you can simply call `delete-dups' 
on the xref elements when they come from different backends.

> If you try instead to "bypass the minibuffer" it's
> likely to be a much more difficult task.

How does it make any difference?

Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Dmitry Gutov on Sun, 26 Apr 2015 18:20:13 +0300 wrote:

 > On 04/26/2015 02:31 PM, Vitalie Spinu wrote:
 >> What do you currently do if there are multiple matching definitions of
 >> the "thing-at-point"? Prompt?

 > Show them all in the xref buffer. But if the backend is smart enough, it will
 > include the disambiguating context information as text properties on the
 > "thing-at-point" string.

Aha! I see. Would be nice to be able to flush those into some familiar
interface - IDO, HELM or at least grep-like buffers (compilation
buffers) so that one can use M-g n, M-g p without visiting the buffer.


 >> As to prompting, if you try to accommodate multiple backends, then
 >> merging completion candidates from multiple backends is a simple task
 >> when you prompt.

 > Not if you want to avoid duplicates. ...

 > So you can simply call `delete-dups' on ...
          ^^^ cannot?  

What's the exact problem except abandoning lazynes? Naively I think
about it like this. Gather all candidates. Delete-dups. Then take
backends in turn and see which one contain the reference. If unique, use
that backend, else use *xref* buffer.

I personally never had problems with too many candidates, so "being
lazy" is completely useless feature to me. I am also not convinced you
are gaining much speed here. Each backend has to operate with its own
list of candidates anyways.

  Vitalie

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/26/2015 07:01 PM, Vitalie Spinu wrote:

> Aha! I see. Would be nice to be able to flush those into some familiar
> interface - IDO, HELM or at least grep-like buffers (compilation
> buffers) so that one can use M-g n, M-g p without visiting the buffer.

If you don't like xref--xref-buffer-mode, you're welcome to assign a 
different xref-show-xrefs-function.

>   > Not if you want to avoid duplicates. ...
>
>   > So you can simply call `delete-dups' on ...
>            ^^^ cannot?

Right, sorry.

> What's the exact problem except abandoning lazynes? Naively I think
> about it like this. Gather all candidates. Delete-dups. Then take
> backends in turn and see which one contain the reference. If unique, use
> that backend, else use *xref* buffer.

When there are more than one, we show all matches in the xref buffer. I 
believe showing duplicates in there would be confusing.

Or similarly, if one adapts a tags-loop-continue-like interface for 
this, this command would visit certain locations multiple times.

> I personally never had problems with too many candidates, so "being
> lazy" is completely useless feature to me. I am also not convinced you
> are gaining much speed here. Each backend has to operate with its own
> list of candidates anyways.

Admittedly, the place where the speed improvement is the most glaring is 
the xref-find-apropos command.

Before laziness, it was much slower than `M-x apropos'.

The other problem is what to do with all the files we have to open in 
the process. Do we leave the buffers open? Or do we kill them after 
generating the list, to open again when the user navigates to a 
reference? Or if they abort and repeat the same command with the same 
(or a similar) argument.

Re: Bad moves with xref-find-definitions

[Stefan Monnier]

> Backend has to figure out the "thing" anyways. From there building
> "textual representation" and passing back to xref is a triviality.

Apparently not, because the part of the backend which "figures it out"
might be in an external tool which simply doesn't offer the option to
build a textual representation for it.

> Also, you have to provide completions and textual representation of on
> C-u anyways.

In case the backend is as described above, the C-u path will lead to
suboptimal results, indeed, because it'll have to fallback on
other techniques.

> What do you currently do if there are multiple matching definitions of
> the "thing-at-point"? Prompt?

Yes, in the *xref* buffer.

> All I was trying to say is that tags are commonly useful alongside
> dynamic backends. Blindly replacing tags with an even very good
> backend is not the right direction IMW. Expecting from end users to
> solve this problem with add-function :before is unacceptable if there
> are way to fix it at Emacs level. 

I'm not talking about the end-user using add-function, but about the
major mode's xref's backend doing so.

> Different backends can figure different "things-at-point". It would be
> wise to try back-ends in turn, just like completion-at-point-functions
> does.

If the major mode adds the backends via (add-function :before-until ...)
that's exactly what will happen.


        Stefan

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

Hi there,

On 04/23/2015 06:07 PM, Vitalie Spinu wrote:

> There has been a breaking change in UI with respect to find definition
> functionality. I am all for generic interface but IMO there is no reason
> to break standard Emacs interaction mechanism in favor for some not that
> well thought UI borrowed from SLIME.

SLIME has plenty of users who find the approach convenient. You should 
notice that in both CIDER discussions you've referenced that opinion has 
also been expressed.

When discussing the options for the new UI to replace `find-tag', both 
initial proposals also opted not to prompt by default [1][2]. And this 
is the first complaint we've received about that aspect, in the four 
months since xref had been introduced.

>   1) `find-tag` (previously bound to M-.) was prompting for a symbol
>       before jumping to the definition. The symbol at point was the
>       default. On the expense of one additional RET this was very
>       convenient because it leaves the possibility to jump to a different
>       symbol and also saves you from useless navigation to a symbol when
>       symbol is not directly under the cursor. The desired symbol might
>       not be visible, or even present in current buffer.

Since you're usually intent on typing out the symbol name, pressing 
`C-u' before that shouldn't make a lot of difference. On the other hand, 
when "jump to the symbol at point" is a frequent operation, it makes 
sense to optimize it.

>       Now, "xref-find-definitions" encourages you to navigate to a symbol
>       by disrupting the flow twice. Once, when you navigate to a symbol,
>       and often for the second time when you need to go back to the
>       editing after you saw the definition. This just fosters a bad habit
>       of tracking what you read with a cursor. It just cannot be right.

I don't know if it's a bad habit. Apparently, it's a common one.

>       Needless to say that most other functionality in Emacs does ask for
>       completion before performing an action (documentation, find-file
>       etc).

In my view, "jump to the thing at point" is a different kind of 
operation (and it can work with symbols, file paths, etc).

It also has correspondence in other editors: Ctrl-] in Vim, or 
Ctrl+Click in IDEs.

>       Having an option to *not* navigate to symbol is very useful and
>       Emacs was recognizing this need all this time. Why would you change
>       this now?

The question could as well be, why wasn't it changed sooner. Anyway, 
this behavior can be customizable, like suggested by Michael Griffiths 
in the second CIDER discussion.

But while you're only person requesting it, you can modify the current 
behavior trivially with `advice-add'.

>       Etags is still very useful even with dynamic languages. For example
>       the language tool might not load all the files in current
>       project/directory, or you might intentionally keep some code in
>       non-project directories. You might also define your tags for a
>       bunch of other related projects which you want to access from the
>       current project.

`completion-at-point-functions' defaults to 
`'(tags-completion-at-point-function)'. Are you also worried about a 
major mode overriding it? That's the whole point of adding this kind of 
variable.

And if by any chance the major mode does a poor job, you can use 
xxx-mode-hook to override it back. In this case, there already exists 
`xref-etags-mode', because of a prior request.

>       Now, when "M-." is gone, if the language re-defines
>       `xref-find-function` how do I access tags? Do I need to bind a new
>       global key for `find-tag` command?

You can also add a separate binding for it. And if/when `find-tag' goes 
away, you can use that binding for a new command wrapping 
`xref-find-definitions'.

By the way, it seems I've forgot to declare `find-tag' obsolete.

> There has been a lengthy discussion on Cider issue tracker to change the
> behavior borrowed from SLIME into standard emacs UI [1][2]. Once that
> was changed, emacs itself seems to move into wrong ways.

Maybe the fact that Emacs currently behaves in a certain some way is not 
always a bullet-proof argument in its favor.

[1] http://lists.gnu.org/archive/html/emacs-devel/2014-11/msg01302.html
[2] http://lists.gnu.org/archive/html/emacs-devel/2014-11/msg01684.html

Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Dmitry Gutov on Sat, 25 Apr 2015 22:01:47 +0300 wrote:

 > SLIME has plenty of users who find the approach convenient.

Because they just got used to it. I got used to it myself with CIDER,
but at least I recognize the annoyance of flow disruption and C-u
inconvenience. One RET speedup is really not worth it IMO.

 > And this is the first complaint we've received about that aspect, in
 > the four months since xref had been introduced.

Most of people don't track emacs devel. I tend to upgrade every 3 months
or so. So here I am, complaining first time I saw it.

 > Since you're usually intent on typing out the symbol name, pressing
 > `C-u' before that shouldn't make a lot of difference.

That's not exactly correct. With IDO takes 2-3 keys to select a
candidate. Navigating to a symbol and then back to the editing location
takes commonly more. C-u is very difficult to get used to because it's
an "afore" action and it's inconsistent with other completions in Emacs.

 >> Now, "xref-find-definitions" encourages you to navigate to a symbol
 >> by disrupting the flow twice. Once, when you navigate to a symbol,
 >> and often for the second time when you need to go back to the
 >> editing after you saw the definition. This just fosters a bad habit
 >> of tracking what you read with a cursor. It just cannot be right.

 > I don't know if it's a bad habit. Apparently, it's a common one.

Human brain is tricky. Mine always chooses the cognitively easier path
even if it's less efficient in terms of time or muscular effort. I
couldn't get used to Cider's C-u in half a year of intensive
use. Instead, I got used to tracking symbols with the cursor pretty
easily.

 >> Needless to say that most other functionality in Emacs does ask for
 >> completion before performing an action (documentation, find-file
 >> etc).

 > In my view, "jump to the thing at point" is a different kind of operation (and
 > it can work with symbols, file paths, etc).

I fail to see this difference. Instant opening of the doc on symbol
under point makes as much sense to me as jumping to its definition.

 > But while you're only person requesting it, you can modify the
 > current behavior trivially with `advice-add'.

Well. Cider switched to standard Emacs ways because most of other people
(including the lead developer) recognized the need for the change.

Good defaults are very hard, mainly because you have to abstract from
you own habits and think about future generations of users. Most people
get used to whatever the default is. In this respect the current default
is rather unfortunate as it will make new folks use navigation commands
more often than they need to.

 > `completion-at-point-functions' defaults to
 > `'(tags-completion-at-point-function)'. Are you also worried about a
 > major mode overriding it? That's the whole point of adding this kind
 > of variable.

I don't quite follow. Does xref rely on completion-at-point-functions? I
don't see this in the code.

 > And if by any chance the major mode does a poor job, you can use xxx-mode-hook
 > to override it back. In this case, there already exists `xref-etags-mode',
 > because of a prior request.

 > You can also add a separate binding for it. And if/when `find-tag' goes away,
 > you can use that binding for a new command wrapping `xref-find-definitions'.

One can do a lot of things in emacs. A lot of emacs users don't even
know the basics of elisp.

The point is that tags became more difficult to use. In some modes they
work, in others they don't. True that loads of modes rebind M-. In this
respect xref.el is only a marginal improvement. Whether they bind
M-. directly or set xref-find-definition it's the same cake to the
mortals.

If you somehow could merge multiple backends into one navigation system,
that would be a truly big deal. Till then `xref-etags-mode` and alike
feel like clumsy workarounds.


  Vitalie

Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Vitalie Spinu on Sat, 25 Apr 2015 22:34:06 +0200 wrote:

 >> Since you're usually intent on typing out the symbol name, pressing
 >> `C-u' before that shouldn't make a lot of difference.

 > That's not exactly correct. With IDO takes 2-3 keys to select a
 > candidate. 

Ideally IDO-like interfaces should be semantically aware of constructs
around point or at least sniff around the point and place close-by
symbols in front. That would eliminate the need to move the point almost
entirely.


  Vitalie

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/25/2015 11:34 PM, Vitalie Spinu wrote:

> Because they just got used to it.

That's a bad explanation. It directly assumes that SLIME developers 
don't know what's good for them.

I think we can settle on the assumption that both approaches are viable.

> Most of people don't track emacs devel.

Still, many do.

> That's not exactly correct. With IDO takes 2-3 keys to select a
> candidate. Navigating to a symbol and then back to the editing location
> takes commonly more. C-u is very difficult to get used to because it's
> an "afore" action and it's inconsistent with other completions in Emacs.

We can really assume usage of Ido in `xref-find-definitions'. Not only 
it's off by default, without `ido-ubiquitous' (a third-party package) 
you simply can't use it with xref-find-definitions.

But 2-3 keypresses sounds like a serious under-estimate to me either 
way. For instance, when I'm on some unrelated symbol, making `C-h f' 
pick `emacs-lisp-mode' forces me to type out at least half of the 
characters in that function's name. I'd probably type it in full until 
it's the first completion, which ends at `emacs-lisp-m' here.

> Human brain is tricky. Mine always chooses the cognitively easier path
> even if it's less efficient in terms of time or muscular effort. I
> couldn't get used to Cider's C-u in half a year of intensive
> use. Instead, I got used to tracking symbols with the cursor pretty
> easily.

Cognitively easier paths are nothing to sneeze at. Who's to say that 
less muscular effort at the expense of more cognitive one is always better?

Further, `C-s emacs-li' in the current buffer followed by M-. might turn 
out to be the same amount of keypresses, even if cursor is currently far 
from that symbol.

>   > In my view, "jump to the thing at point" is a different kind of operation (and
>   > it can work with symbols, file paths, etc).
>
> I fail to see this difference. Instant opening of the doc on symbol
> under point makes as much sense to me as jumping to its definition.

And indeed, SLIME has a set of commands that do just that. 
elisp-slime-nav copies it in its `C-c C-d C-d'.

It's quite nice, even if I've stopped using it around those same 4 
months ago.

Maybe I should say that the `C-h ???' are a special set, and changing 
how they all behave would be harder. Those keybindings aren't as snappy 
as `M-.' or `C-c C-d' anyway.

And find-file is inherently an operation that doesn't usually use the 
content at point.

>   > But while you're only person requesting it, you can modify the
>   > current behavior trivially with `advice-add'.
>
> Well. Cider switched to standard Emacs ways because most of other people
> (including the lead developer) recognized the need for the change.

Did you have a vote?

 From the first thread, I recall Bozhidar stating that both ways have 
merits.

> Good defaults are very hard, mainly because you have to abstract from
> you own habits and think about future generations of users. Most people
> get used to whatever the default is. In this respect the current default
> is rather unfortunate as it will make new folks use navigation commands
> more often than they need to.

Moving point has its own benefits. For instance, when you press `M-,', 
you instantly see which function call the previous jump was related to.

That makes following the control flow of unfamiliar code much easier.

> I don't quite follow. Does xref rely on completion-at-point-functions? I
> don't see this in the code.

No, it's a separate feature, but the principle is the same: by default, 
completion uses the tags table. Major modes (and some minor modes) add 
elements at the beginning of that hook, effectively blocking 
tags-completion-at-point-function from being used in corresponding 
buffers. Is that a problem? Not so much.

> One can do a lot of things in emacs. A lot of emacs users don't even
> know the basics of elisp.

We hope that those users will feel satisfied with the default behavior.

> The point is that tags became more difficult to use. In some modes they
> work, in others they don't. True that loads of modes rebind M-. In this
> respect xref.el is only a marginal improvement. Whether they bind
> M-. directly or set xref-find-definition it's the same cake to the
> mortals.

Some modes use tags, other ones use facilities they consider better than 
tags. If you think a certain mode should use tags in more situations, 
that's as good cause for a bug report as any.

> If you somehow could merge multiple backends into one navigation system,
> that would be a truly big deal. Till then `xref-etags-mode` and alike
> feel like clumsy workarounds.

This request is too vague, sorry. Feel free to outline a specific design 
in a new bug report.

Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

On 04/26/2015 03:20 AM, Dmitry Gutov wrote:

> We can really assume usage of Ido in `xref-find-definitions'. Not only
      ^^^
      can't

Re: Bad moves with xref-find-definitions

[Vitalie Spinu]

 >>> Dmitry Gutov on Sun, 26 Apr 2015 03:20:01 +0300 wrote:

 > But 2-3 keypresses sounds like a serious under-estimate to me either way. For
 > instance, when I'm on some unrelated symbol, making `C-h f' pick

You have a very emacs-lisp-biased-view. In languages with namespaces and
good taste for names (clojure as example) filtering candidates is very
efficient.

It's even more so for languages with narrower scope, like those for
technical computing (R, julia, matlab). I can assure you that in R, with
ido, candidate selection is a breeze and 2-3 keys are often enough to
get what you want. It really beats navigation-to-the-symbol to the
ground AFAIC.

  Vitalie