> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> 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?