[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: UI inconveniences with M-.
From: |
Eli Zaretskii |
Subject: |
Re: UI inconveniences with M-. |
Date: |
Sat, 02 May 2015 15:57:43 +0300 |
> 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.
- Re: UI inconveniences with M-., (continued)
- Re: UI inconveniences with M-., Fumitaka Tokumitsu, 2015/05/02
- Re: UI inconveniences with M-., Dmitry Gutov, 2015/05/01
- Re: UI inconveniences with M-., Eli Zaretskii, 2015/05/02
- Re: UI inconveniences with M-., Fumitaka Tokumitsu, 2015/05/02
- Re: UI inconveniences with M-., Dmitry Gutov, 2015/05/02
- Re: UI inconveniences with M-.,
Eli Zaretskii <=
- Re: UI inconveniences with M-., Dmitry Gutov, 2015/05/02
- Re: UI inconveniences with M-., Eli Zaretskii, 2015/05/02
- Re: UI inconveniences with M-., Dmitry Gutov, 2015/05/02
Re: UI inconveniences with M-., Stefan Monnier, 2015/05/02
Re: UI inconveniences with M-., Dmitry Gutov, 2015/05/02