Re: UI inconveniences with M-.

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Sat, 2 May 2015 15:41:22 +0300
> 
> 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.

Which part of what I said was not entirely true there?

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

If I had a good design suggestion, I'd certainly not withhold it.

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

xref.el uses facilities I never used, so for me it means I'd need to
study those as well.  Please believe me that when I said it's more
than I could invest, I already explored some of the code.

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

I can be that user, at least in some cases.  Although the experience
of this bug report doesn't encourage me to get involved in more.

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

I'm talking about projects that are already deployed, sometimes for
years.