Re: UI inconveniences with M-.

["Fumitaka Tokumitsu" <toku345@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6401 bytes --]

こなた 

やなまかわ

  おたかたけ 

ま



—
Sent from Mailbox

On Sat, May 2, 2015 at 5:14 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> Cc: emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> 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?

[-- Attachment #2: Type: text/html, Size: 7417 bytes --]