こなた  やなまかわ   おたかたけ  ま — Sent from Mailbox On Sat, May 2, 2015 at 5:14 PM, Eli Zaretskii wrote: >> 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?