[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UI inconveniences with M-.

From: Dmitry Gutov
Subject: Re: UI inconveniences with M-.
Date: Sat, 2 May 2015 15:41:22 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]