From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: UI inconveniences with M-. Date: Sat, 02 May 2015 15:57:43 +0300 Message-ID: <83fv7fp260.fsf@gnu.org> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <83fv7kwbow.fsf@gnu.org> <837fsvuefq.fsf@gnu.org> <837fstu3zh.fsf@gnu.org> <5543EC00.8010707@yandex.ru> <83zj5npfcp.fsf@gnu.org> <5544C5F2.4090905@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1430571518 27524 80.91.229.3 (2 May 2015 12:58:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 May 2015 12:58:38 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 02 14:58:30 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YoX00-0003Cy-CJ for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 14:58:28 +0200 Original-Received: from localhost ([::1]:56925 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoWzz-00014l-LO for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 08:58:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoWzv-00014V-6S for emacs-devel@gnu.org; Sat, 02 May 2015 08:58:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoWzr-0001dk-VR for emacs-devel@gnu.org; Sat, 02 May 2015 08:58:23 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:37407) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoWzr-0001de-NC for emacs-devel@gnu.org; Sat, 02 May 2015 08:58:19 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NNQ00K003B1UQ00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 02 May 2015 15:57:59 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNQ00KB540MJ790@a-mtaout22.012.net.il>; Sat, 02 May 2015 15:57:59 +0300 (IDT) In-reply-to: <5544C5F2.4090905@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:186135 Archived-At: > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Dmitry Gutov > 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.