Re: UI inconveniences with M-.

[Dmitry Gutov]

On 05/02/2015 11:12 AM, Eli Zaretskii wrote:

> 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.

That's not entirely true. Think of bug#18285, for example.

> 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.

I'm sure it's useful in the general case. However, in certain situations 
a good design suggestion would be a better argument towards a change 
than only a feature request. You must be aware of that.

> 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.

The amount of code that you'd have to look at is relatively small, in 
the current case. Just the xref-find-function docstring in xref.el, and 
the 70 lines at the end of etags.el.

> 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.

Either way, this analysis doesn't look actionable enough on my side. Sorry.

> 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.

Sure. We can't know for sure if it's valid. We could only find out that 
it's invalid, at some point.

> 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.

Those changes didn't touch of the basics of the design, though. Just on 
implementations (which were initially not much more than proof-of-concept).

> 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.

Thanks, but this is, again, a very general kind of recommendation. It's 
not my first time writing code, too.

> Partly because CEDET is too heavyweight for most of my needs, and
> partly because I simply didn't have enough time to learn it.

Okay. But note that when you're asking for features that it already 
provides for some extent (semantic-symref supports renames; did you know 
that?), for us to create a better user experience we'll need members of 
the target audience to try their best to actually use it and report on 
the pain points.

> 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:

If you can't read it whole, you continue to be in danger of malicious 
behavior tucked somewhere in the codebase. Would it really be better to 
leave it until production deployment, instead of allowing to happen on 
the developer's machine?

> IOW, your methodology would put the cart before the horse, in these
> use cases.

In any case, it's a well-known problem, and people have been known to 
live with that choice.

> 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?

I'm not rejecting. But like you said, one person can only do so much. 
When I don't see a clear path to action that would satisfy both the 
original requirements, as well as the ones you add, the estimated amount 
of work to get to the ideal is unbounded.

There are other features (as well as different projects) I'd like to 
work on.