all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Vitalie Spinu <spinuvit@gmail.com>
Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>, emacs-devel@gnu.org
Subject: Re: Bad moves with xref-find-definitions
Date: Sun, 26 Apr 2015 20:51:02 +0300	[thread overview]
Message-ID: <553D2586.6060809@yandex.ru> (raw)
In-Reply-To: <87fv7mn9is.fsf@gmail.com>

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.



  reply	other threads:[~2015-04-26 17:51 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-23 15:07 Bad moves with xref-find-definitions Vitalie Spinu
2015-04-25 14:24 ` Stefan Monnier
2015-04-25 16:25   ` Dmitry Gutov
2015-04-25 17:42   ` Vitalie Spinu
2015-04-25 18:49     ` Vitalie Spinu
2015-04-25 19:07       ` Dmitry Gutov
2015-04-25 18:56     ` João Távora
2015-04-25 23:50       ` Dmitry Gutov
2015-04-26 11:51         ` xref backends for elisp-related modes Was: " João Távora
2015-04-26 13:56           ` Dmitry Gutov
2015-04-26 14:51           ` Eli Zaretskii
2015-04-28 11:06             ` Vitalie Spinu
2015-04-28 11:41               ` João Távora
2015-04-28 11:59                 ` Vitalie Spinu
2015-04-28 15:17                   ` Eli Zaretskii
2015-04-28 15:45                     ` Vitalie Spinu
2015-04-28 16:01                       ` Eli Zaretskii
2015-04-28 13:27                 ` Stefan Monnier
2015-04-28 21:28                   ` Dmitry Gutov
2015-04-29 12:35                     ` Vitalie Spinu
2015-04-29 15:45                     ` Eli Zaretskii
2015-04-28 15:15               ` Eli Zaretskii
2015-04-28 15:47                 ` Vitalie Spinu
2015-04-28 16:03                   ` Eli Zaretskii
2015-04-29  6:55               ` Helmut Eller
2015-04-29 12:40                 ` Vitalie Spinu
2015-04-29 13:01                   ` Helmut Eller
2015-04-29 15:30                     ` Vitalie Spinu
2015-04-29 17:09                       ` Dmitry Gutov
2015-04-29 12:47                 ` Dmitry Gutov
2015-04-29 13:04                   ` Helmut Eller
2015-04-29 13:12                     ` Dmitry Gutov
2015-04-27  2:20           ` Stefan Monnier
2015-04-25 19:11     ` Dmitry Gutov
2015-04-25 20:43       ` Vitalie Spinu
2015-04-26  3:37         ` Dmitry Gutov
2015-04-26  6:38           ` Bozhidar Batsov
2015-04-26 18:41             ` Dmitry Gutov
2015-04-27 19:36               ` Bozhidar Batsov
2015-04-28  1:23                 ` Dmitry Gutov
2015-04-28 11:30               ` Vitalie Spinu
2015-04-26 10:44           ` Vitalie Spinu
2015-04-26 13:14             ` Vitalie Spinu
2015-04-26 15:09             ` Dmitry Gutov
2015-04-26 16:23               ` Vitalie Spinu
2015-04-26 17:51                 ` Dmitry Gutov [this message]
2015-04-26 20:56                   ` Vitalie Spinu
2015-04-27 21:57                     ` Dmitry Gutov
2015-04-26  3:34     ` Stefan Monnier
2015-04-26 11:31       ` Vitalie Spinu
2015-04-26 14:50         ` Eli Zaretskii
2015-04-26 15:12           ` Dmitry Gutov
2015-04-26 15:32             ` Eli Zaretskii
2015-04-26 15:20         ` Dmitry Gutov
2015-04-26 16:01           ` Vitalie Spinu
2015-04-26 17:26             ` Dmitry Gutov
2015-04-27  2:26         ` Stefan Monnier
2015-04-25 19:01 ` Dmitry Gutov
2015-04-25 20:34   ` Vitalie Spinu
2015-04-25 21:44     ` Vitalie Spinu
2015-04-26  0:20     ` Dmitry Gutov
2015-04-26  0:28       ` Dmitry Gutov
2015-04-28 15:31       ` Vitalie Spinu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=553D2586.6060809@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    --cc=spinuvit@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.