From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: UI inconveniences with M-. Date: Sat, 02 May 2015 02:59:28 -0400 Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <553EBBBF.6070509@yandex.ru> <838udcwbdc.fsf@gnu.org> <553FFC99.5080701@yandex.ru> <834mnzuedd.fsf@gnu.org> <554161A8.30202@yandex.ru> <83618du3q3.fsf@gnu.org> <5542E486.2010107@yandex.ru> <83k2wsssm8.fsf@gnu.org> <5543632C.6000306@yandex.ru> <834mnwsbfb.fsf@gnu.org> <554392E2.7080109@yandex.ru> <83oam4qh2u.fsf@gnu.org> <5543C97C.6050000@yandex.ru> <83h9rwqf10.fsf@gnu.org> <5543E3CF.5010402@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430549988 11172 80.91.229.3 (2 May 2015 06:59:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 May 2015 06:59:48 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 02 08:59:39 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YoROk-0007KJ-T7 for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 08:59:39 +0200 Original-Received: from localhost ([::1]:56236 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoROk-0002hp-8U for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 02:59:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoROg-0002hh-KA for emacs-devel@gnu.org; Sat, 02 May 2015 02:59:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoROf-00018T-MU for emacs-devel@gnu.org; Sat, 02 May 2015 02:59:34 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:59488) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoROc-00017r-4M; Sat, 02 May 2015 02:59:30 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVS4rw4V/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCwsOJhIUGA0kLodlohGLdSYIBD0MA4M+A4NwBKNjhFg X-IPAS-Result: AgUFAGvvdVS4rw4V/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCwsOJhIUGA0kLodlohGLdSYIBD0MA4M+A4NwBKNjhFg X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="118060216" Original-Received: from 184-175-14-21.dsl.teksavvy.com (HELO pastel.home) ([184.175.14.21]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 May 2015 02:59:29 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 05A3FA97; Sat, 2 May 2015 02:59:28 -0400 (EDT) In-Reply-To: <5543E3CF.5010402@yandex.ru> (Dmitry Gutov's message of "Fri, 1 May 2015 23:36:31 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:186114 Archived-At: [ Moving this to emacs-devel. ] > Maybe the solution is to define the ability for a backend to return groups, > probably nested ones. I don't see much need for nesting. I think the issue is mostly one of sorting in *xref* (or in the cycling, if we were to use a hypothetical other UI that provides functionality like the old etags.el). So, let's focus on this. My suggestion would be either: - make xref-find-function return not just a list of locations, but also an indication whether they're pre-sorted or not. - make xref-find-function return not a list of locations, but a list of lists of locations (i.e. every location inside a sub-list is considered to have the same "level/quality/likelihood", but the lists are sorted by their "level/quality/likelihood"). - let the backend provide its own sorting function to override the current "group by file" sorting. Basically, I think the focus should be on making sure that we can re-implement the old behavior on top of the new API when using the xref/etags backend. Another thing that we should consider is how to let the user choose which backend to use. Currently we only have xref-etags-mode, but I think it would make sense to make it possible for the user to dynamically choose among the potentially many more backends (e.g. we could add an xref/grep backend, and there will hopefulyl be more using things like id-utils, gtags, ...) and maybe also to use several backends at the same time (merging the results). I don't have any suggestions for what this could/should look like, OTOH. But maybe one way to do that would be to let each backend expose via the API a set of knobs (one of which would be an "enable/disable" knob), and then provide an xref command that can manage these knobs conveniently. Stefan