From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#19468: 25.0.50; UI inconveniences with M-. Date: Mon, 27 Apr 2015 22:15:34 +0300 Message-ID: <83lhhdwfft.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1430162192 14812 80.91.229.3 (27 Apr 2015 19:16:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Apr 2015 19:16:32 +0000 (UTC) Cc: dgutov@yandex.ru, 19468@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 27 21:16:17 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1YmoVt-0004zE-2m for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Apr 2015 21:16:17 +0200 Original-Received: from localhost ([::1]:57371 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmoVn-0003rM-BO for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Apr 2015 15:16:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmoVj-0003rH-63 for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 15:16:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmoVf-0001Dn-2O for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 15:16:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51755) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmoVe-0001Dj-Uy for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 15:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YmoVe-0004fZ-N2 for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 15:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 19:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.143016215617936 (code B ref 19468); Mon, 27 Apr 2015 19:16:02 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 19:15:56 +0000 Original-Received: from localhost ([127.0.0.1]:41531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmoVV-0004fC-Su for submit@debbugs.gnu.org; Mon, 27 Apr 2015 15:15:55 -0400 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:35933) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmoVS-0004ew-4l for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 15:15:51 -0400 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NNH00J00C4Z5S00@mtaout26.012.net.il> for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 22:17:19 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNH00ACRC8VB180@mtaout26.012.net.il>; Mon, 27 Apr 2015 22:17:19 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:102104 Archived-At: > From: Stefan Monnier > Cc: dgutov@yandex.ru, 19468@debbugs.gnu.org > Date: Mon, 27 Apr 2015 13:21:07 -0400 > > > I certainly hope that at least the Semantic one materializes soon > > enough, otherwise it sounds like all this move to xref was for the > > benefit of unbundled packages, > > IMO one of the main tasks of the maintainers is to provide > infrastructure that consolidates the features that are duplicated out > there in many different packages, all mutually slightly incompatible. > > So the usefulness does not directly depend on whether that feature is > used by bundled or unbundled packages. Emacs thrives in large part > thanks to all the unbundled packages out there and we shouldn't treat > them as second-rate citizens. We shouldn't treat the Emacs core as second-rate citizen, either. A feature as central to code development and Emacs in general as finding definitions and references of symbols cannot thrive only (or mainly) outside the core, IMO. > > and users of Emacs are just punished by having to learn a new UI for > > no real advantage. > > I like the new UI, FWIW. Where did you see me say I dislike it? I'm just saying that learning a new UI for the sake of a new UI is a waste. I _am_ prepared to learn a new UI if it brings new useful functionality with it. > BTW, w.r.t the use of etags, what do you think of the patch below, which > lets the elisp-xref functionality fallback on etags for functions/vars > that aren't currently bound? What's it supposed to do? Anyway, I once again think that if we will mostly "fall back on etags" every time the new back-ends are somehow imperfect, then what exactly did we gain with this move? I heard more than once in recent discussions that the etags back-end is less than perfect, to put it mildly; after hearing this so much, I wonder how it makes sense to fall back on it all the time. If it's not good, let's replace it with something better, not fall back on it. > > That said, the usual way in Emacs to provide minor variants of a > > command is via special values of the prefix argument, like, for > > example, "C-x C-s" does. > > The different ways to call xref-find-function are to distinguish > jumping to the definition or to "all uses", and currently few backends > support those features Sounds like another feature that was planned, but never implemented. Once again, why did we switch to xref if so much of its promise is yet to come? > I don't think we have a clear idea yet of how they should be > presented to the user There's prior art out there in other IDEs, we could start by learning from them. > and there are too many variants to collapse them all into C-u. "C-x C-s" manages to provide no less than 4 variants with C-u, so I see no problem to use it with this command. That said, ... > So they'd probably be provided via different commands instead of all > being accessed via M-. ... I won't mind this alternative, either, although we don't have too many keys left to use for those other commands.