From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: UI inconveniences with M-. Date: Sat, 2 May 2015 15:41:22 +0300 Message-ID: <5544C5F2.4090905@yandex.ru> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1430570524 12455 80.91.229.3 (2 May 2015 12:42:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 May 2015 12:42:04 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 02 14:42:04 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 1YoWk7-0007bn-AA for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 14:42:03 +0200 Original-Received: from localhost ([::1]:56898 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoWk6-00009f-J0 for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 08:42:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37124) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoWjt-00005U-OB for emacs-devel@gnu.org; Sat, 02 May 2015 08:41:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoWjo-000405-Nz for emacs-devel@gnu.org; Sat, 02 May 2015 08:41:49 -0400 Original-Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:33130) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoWjo-0003ee-Cr; Sat, 02 May 2015 08:41:44 -0400 Original-Received: by wief7 with SMTP id f7so46970571wie.0; Sat, 02 May 2015 05:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Y9dJk+vnv3SfBxHQcuN/+798Y82DK5L4a9WbrJKu5Xs=; b=sa3YjXSoYOwYNNwnbiliWpAmh6FfmNYLnHZ54Kj/0lXSDzrC//7kg/xXYoTpjH3dJl 85m+anezu0KDrb2c8FVTQmvAjZVhSiji9HE/jXZdrl//M12vaKE6ByWlZLxV/U2+WbF6 zQ1FKndT95sjX92bVyJKVJb+upp0rvHLfJpk585kQNmnRz6jbjN4In8veCUMqZAfIUTz BsyyUMFCcgZ+Yn6fBRboC5Yie9D7wCN58x77a7L45RRwpcxZhbIhp2x0Nsrt/ycUTV4n CFlNiYJxvN63ECXul+PgyLjLnYTBHHm3iwT8LN6KX8O3r4jkB4nQrfaoWFkjpeIyf76E /1WA== X-Received: by 10.194.23.197 with SMTP id o5mr26396576wjf.75.1430570485216; Sat, 02 May 2015 05:41:25 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id di7sm2220252wib.23.2015.05.02.05.41.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 05:41:25 -0700 (PDT) user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 in-reply-to: <83zj5npfcp.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22d 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:186134 Archived-At: 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.