From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: UI inconveniences with M-. Date: Sat, 02 May 2015 11:12:54 +0300 Message-ID: <83zj5npfcp.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> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <83fv7kwbow.fsf@gnu.org> <837fsvuefq.fsf@gnu.org> <837fstu3zh.fsf@gnu.org> <5543EC00.8010707@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1430554465 8261 80.91.229.3 (2 May 2015 08:14:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 May 2015 08:14:25 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 02 10:14:15 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 1YoSYw-0005Bx-5i for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 10:14:14 +0200 Original-Received: from localhost ([::1]:56335 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoSYv-0006jj-2T for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 04:14:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53443) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoSYj-0006jT-0F for emacs-devel@gnu.org; Sat, 02 May 2015 04:14:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoSYe-0004ng-UV for emacs-devel@gnu.org; Sat, 02 May 2015 04:14:00 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:58930) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoSYe-0004n5-Gp for emacs-devel@gnu.org; Sat, 02 May 2015 04:13:56 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NNP00I00QOTXE00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 02 May 2015 11:13:11 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNP00ILWQTYV340@a-mtaout22.012.net.il>; Sat, 02 May 2015 11:13:11 +0300 (IDT) In-reply-to: <5543EC00.8010707@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:186120 Archived-At: > Cc: emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sat, 2 May 2015 00:11:28 +0300 > > > If I wanted to talk about the code, I'd say something like > > "this-and-that function does wrong things because of so-and-so". > > I think both I and Stefan very much wanted you to look at the actual > code here. It's much easier to make demands on functionality than to > propose a clean and modular design. One person can only do so much, given her free time, and can only be an expert in so many fields. When you or Stefan report a problem with the display engine, or in some other area where I know enough, I don't ask for a design before I start working on it. In this case, all I have to offer is user experience, some requirements for what I consider to be a good solution, and some general guidelines for such a solution (which I only provided in response to repeated demands to do so). If that is not useful, perhaps we should revise our instructions for bug reporting. IOW, I was reporting problems in an area where I know very little. I don't think it's fair to demand that I provide, let alone code, a solution, as a prerequisite for acting on my report. I think the job of making the feature better in response to bug reports is the job of those who worked on the feature to begin with, and thus have intimate knowledge of the design and the implementation. > > Through my naive-user eyes, filtering 140 hits to provide > > just a few is perfectly within the capabilities of the UI, at least in > > principle. > > That is, of course, possible. But then we'll need to define some > universal language-arnostic metadata that the UI would use to operate. I think this kind of universal metadata is very much clear and mostly already supported. After all, Emacs has been doing this kind of jobs for a very long time, which is why we have notions like e.g. "symbols", which each language defines differently. > > It sounds more and more like it could be the fault of the design, and > > specifically of how functionality is divided between the back-end and > > the UI. Let me elaborate. > > > > <...> > > To me, this means that separating the back-ends from the UI while > > leaving the UI "dumb" is basically unworkable, because such a > > separation does not really separate anything: there will still be a > > very high degree of coherency and cohesion between the two parts. Or > > maybe there will only be one usable back-end, and the rest will > > bit-rot. > > Sorry, all I see here is a lot of conjecture. Of course it is. What else did you expect from a bystander who wasn't involved in the design and implementation? It is up to you to do whatever you want with this conjecture. Some people pay a lot of money to get my conjectures in this and similar fields. You get it for free. > The current implementations took not a lot of code, and they work > well enough. That's not an evidence of the design validity, not IME. This feature is with us for too short time to be able to draw conclusions about its design. At least it "didn't work well enough" for me, which is a sign that it isn't perfect. And you already made quite a few changes based on my experience. I think it might be a good time to step back and review those changes, looking for some more fundamental issues that might benefit from some redesign. I don't know what you will find, if you do that, but I do know that if you continue to insist that the design is perfect, you will never see its flaws, if they exist. > By the way, CEDET has had a similar feature for a while (try `M-x > semantic-mode', then `C-c , G' on some function, in a C file). Arguably, > even with a better interface. > > Any reason why you haven't been using it? Partly because CEDET is too heavyweight for most of my needs, and partly because I simply didn't have enough time to learn it. > > And I'm not even sure your ideas of how to solve that "little detail" > > are workable, because of the potentially adverse consequences of > > loading code you don't actually need (or want) to execute. What if > > the code is buggy, or dangerous, or simply does things you don't want > > to be done in your Emacs session? > > That's a valid concern, but you'd have to read that kind of project from > top to bottom first. Then you can load it and proceed to use the > navigation functions. That's impossible. I'm talking about projects whose line counts are in hundreds of thousands, sometimes millions. You cannot read such project from top to bottom, when all you need to do is fix some bug or find the reason for some particular behavior: you will never make your deadline. Using the tools I'm talking about is the only way to find the _relevant_ places which you do need to read and understand. IOW, your methodology would put the cart before the horse, in these use cases. > > I don't know what that means, and don't know enough about JDEE to talk > > about it. In any case, Java is not a "classic" compiled language, as > > a Jave development environment is generally capable of running the > > code in an interpreter. > > There are several ones for C, example: > http://www.drdobbs.com/cpp/ch-a-cc-interpreter-for-script-computing/184402054 > > Not that it has any relevance to the xref backend interface. Then why bring it up? > > See above: you assume that the division of functionality between the > > UI and the back-ends is at the right place. I'm not so sure. If I'm > > right, then when more back-ends come, we will see more problems, not > > less. > > That's conjecture again. And I have some gray heir to back it up with. I have learned from long experience that good design is frequently backed up by intuition and "conjecture". I'm not necessarily saying I'm right in this case, but what if I am? Shouldn't you at least consider that, instead of rejecting it flatly as "conjecture" and sticking to the original design as if it were a scripture?