From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Fumitaka Tokumitsu" Newsgroups: gmane.emacs.devel Subject: Re: UI inconveniences with M-. Date: Sat, 02 May 2015 01:46:34 -0700 (PDT) Message-ID: <1430556393960.5aca91aa@Nodemailer> References: <83zj5npfcp.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1430556394305" X-Trace: ger.gmane.org 1430556426 3289 80.91.229.3 (2 May 2015 08:47:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 May 2015 08:47:06 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, Dmitry Gutov To: "Eli Zaretskii" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 02 10:46:48 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 1YoT4S-000412-6t for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 10:46:48 +0200 Original-Received: from localhost ([::1]:56385 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoT4R-0000JL-4L for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 04:46:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoT4M-0000J6-4l for emacs-devel@gnu.org; Sat, 02 May 2015 04:46:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoT4K-0005VU-0q for emacs-devel@gnu.org; Sat, 02 May 2015 04:46:42 -0400 Original-Received: from mail-qg0-x22c.google.com ([2607:f8b0:400d:c04::22c]:35868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoT4F-0005Th-Bd; Sat, 02 May 2015 04:46:35 -0400 Original-Received: by qgeb100 with SMTP id b100so46597841qge.3; Sat, 02 May 2015 01:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:mime-version:message-id:in-reply-to:references:from:to:cc :subject:content-type; bh=2l5Ksgoy/ONvngaVyBNueQ5zPmHywZJTiyy2Rwbjg4M=; b=ueBRObZfqQnN/U2w4vNIRqh02qn4FEatjPdMqXLaPl/uTkOEd8MicuMUjYTdlTvhuv P4lLyyCZILp6F2fKbilVOdV3ofil2I5j30+kMBXQnBULh8GeGThjUHDb0f738Mq27+0B FanlbnlzRcRpE1t8ds6kaQrA93HJZNXGTDKrbql3/O65uz72stH3qgdOlO2xwvBVnYWO Ry+ZWUAsI23+I3a6T81YHNbmQKAgTSDlFBW02uamDPISZe0wPJJHB8CFQ+eg/iCROoab 3c+1pZveTQnPe3zfPWI6Ey9zri1vlZi71IyMLhlgnIQG2gq4j5LCpFmNLsUL+PtxXkde NBQA== X-Received: by 10.55.53.143 with SMTP id c137mr26895797qka.15.1430556394897; Sat, 02 May 2015 01:46:34 -0700 (PDT) Original-Received: from hedwig-73.prd.orcali.com (ec2-54-85-253-161.compute-1.amazonaws.com. [54.85.253.161]) by mx.google.com with ESMTPSA id 28sm5145570qkw.13.2015.05.02.01.46.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 May 2015 01:46:34 -0700 (PDT) X-Google-Original-Date: Sat, 02 May 2015 08:46:33 GMT X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/) In-Reply-To: <83zj5npfcp.fsf@gnu.org> X-Orchestra-Oid: 9907E276-4B72-434B-B19D-D6065E2758A7 X-Orchestra-Sig: 55964fd6588e0f19a08fb68fee1c0c72fba489cd X-Orchestra-Thrid: TFB12FED1-6944-4BF4-A204-E2CF54CCAD1C_1499752374264323516 X-Orchestra-Thrid-Sig: 45d73e69cb6cb4b513d0fed999557690c24c3449 X-Orchestra-Account: 68af1510f161755f3803e7df4cde6f08b37f7339 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c04::22c 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:186126 Archived-At: ------Nodemailer-0.5.0-?=_1-1430556394305 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =E3=81=93=E3=81=AA=E3=81=9F=C2=A0 =E3=82=84=E3=81=AA=E3=81=BE=E3=81=8B=E3=82=8F =C2=A0 =E3=81=8A=E3=81=9F=E3=81=8B=E3=81=9F=E3=81=91=C2=A0 =E3=81=BE =E2=80=94 Sent from Mailbox On Sat, May 2, 2015 at 5:14 PM, Eli Zaretskii wrote: >> Cc: emacs-devel@gnu.org >> From: Dmitry Gutov >> Date: Sat, 2 May 2015 00:11:28 +0300 >>=20 >> > If I wanted to talk about the code, I'd say something like >> > =22this-and-that function does wrong things because of so-and-so=22. >>=20 >> I think both I and Stefan very much wanted you to look at the actual=20 >> code here. It's much easier to make demands on functionality than to=20 >> propose a clean and modular design. > 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. 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. > 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. I think the job > of making the feature better in response to bug reports is the job of > those who worked on the feature to begin with, and thus have intimate > knowledge of the design and the implementation. >> > Through my naive-user eyes, filtering 140 hits to provide >> > just a few is perfectly within the capabilities of the UI, at least = in >> > principle. >>=20 >> That is, of course, possible. But then we'll need to define some=20 >> universal language-arnostic metadata that the UI would use to operate. > I think this kind of universal metadata is very much clear and mostly > already supported. After all, Emacs has been doing this kind of jobs > for a very long time, which is why we have notions like e.g. = =22symbols=22, > which each language defines differently. >> > It sounds more and more like it could be the fault of the design, and >> > specifically of how functionality is divided between the back-end and >> > the UI. Let me elaborate. >> > >> > <...> >> > To me, this means that separating the back-ends from the UI while >> > leaving the UI =22dumb=22 is basically unworkable, because such a >> > separation does not really separate anything: there will still be a >> > very high degree of coherency and cohesion between the two parts. Or >> > maybe there will only be one usable back-end, and the rest will >> > bit-rot. >>=20 >> Sorry, all I see here is a lot of conjecture. > Of course it is. What else did you expect from a bystander who wasn't > involved in the design and implementation=3F > 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. >> The current implementations took not a lot of code, and they work >> well enough. > 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. At least it =22didn't work well enough=22 for me, which is a = sign > that it isn't perfect. And you already made quite a few changes based > on my experience. 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. I don't know what you will find, if > you do that, but I do know that if you continue to insist that the > design is perfect, you will never see its flaws, if they exist. >> By the way, CEDET has had a similar feature for a while (try `M-x=20 >> semantic-mode', then `C-c , G' on some function, in a C file). Arguably,= =20 >> even with a better interface. >>=20 >> Any reason why you haven't been using it=3F > Partly because CEDET is too heavyweight for most of my needs, and > partly because I simply didn't have enough time to learn it. >> > And I'm not even sure your ideas of how to solve that =22little = detail=22 >> > are workable, because of the potentially adverse consequences of >> > loading code you don't actually need (or want) to execute. What if >> > the code is buggy, or dangerous, or simply does things you don't want >> > to be done in your Emacs session=3F >>=20 >> That's a valid concern, but you'd have to read that kind of project = from=20 >> top to bottom first. Then you can load it and proceed to use the=20 >> navigation functions. > 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: you will never make your > deadline. Using the tools I'm talking about is the only way to find > the =5Frelevant=5F places which you do need to read and understand. > IOW, your methodology would put the cart before the horse, in these > use cases. >> > I don't know what that means, and don't know enough about JDEE to = talk >> > about it. In any case, Java is not a =22classic=22 compiled language,= as >> > a Jave development environment is generally capable of running the >> > code in an interpreter. >>=20 >> There are several ones for C, example:=20 >> http://www.drdobbs.com/cpp/ch-a-cc-interpreter-for-script-computing/1844= 02054 >>=20 >> Not that it has any relevance to the xref backend interface. > Then why bring it up=3F >> > See above: you assume that the division of functionality between the >> > UI and the back-ends is at the right place. I'm not so sure. If I'm >> > right, then when more back-ends come, we will see more problems, not >> > less. >>=20 >> That's conjecture again. > And I have some gray heir to back it up with. I have learned from > long experience that good design is frequently backed up by intuition > and =22conjecture=22. I'm not necessarily saying I'm right in this case,= > but what if I am=3F Shouldn't you at least consider that, instead of > rejecting it flatly as =22conjecture=22 and sticking to the original > design as if it were a scripture=3F ------Nodemailer-0.5.0-?=_1-1430556394305 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=C2=A0=E3=81=93=E3=81=AA=E3=81=9F=C2=A0
=E3=82=84=E3=81=AA=E3=81=BE=E3=81=8B=E3=82=8F
=C2=A0 =E3=81=8A=E3=81=9F=E3=81=8B=E3=81=9F=E3=81=91=C2=A0
=E3=81=BE

=E2=80=94
Sent from Mailbox


On Sat, May 2, 2015 at 5:14 PM,= Eli Zaretskii <eliz@gnu.org> = wrote:

> Cc: = emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 2 May 2015 00:11:28 +0300
>=20
> > If I wanted to talk about the code, I'd say something like
> > =22this-and-that function does wrong things because of = so-and-so=22.
>=20
> I think both I and Stefan very much wanted you to look at the = actual=20
> code here. It's much easier to make demands on functionality than = to=20
> propose a clean and modular design.

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

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. I think the job
of making the feature better in response to bug reports is the job of
those who worked on the feature to begin with, and thus have intimate
knowledge of the design and the implementation.

> > Through my naive-user eyes, filtering 140 hits to = provide
> > just a few is perfectly within the capabilities of the UI, at= least in
> > principle.
>=20
> That is, of course, possible. But then we'll need to define = some=20
> universal language-arnostic metadata that the UI would use to = operate.

I think this kind of universal metadata is very much clear and = mostly
already supported. After all, Emacs has been doing this kind of jobs
for a very long time, which is why we have notions like e.g. = =22symbols=22,
which each language defines differently.

> > It sounds more and more like it could be the fault of the= design, and
> > specifically of how functionality is divided between the = back-end and
> > the UI. Let me elaborate.
> >
> > <...>
> > To me, this means that separating the back-ends from the UI = while
> > leaving the UI =22dumb=22 is basically unworkable, because = such a
> > separation does not really separate anything: there will = still be a
> > very high degree of coherency and cohesion between the two = parts. Or
> > maybe there will only be one usable back-end, and the rest = will
> > bit-rot.
>=20
> Sorry, all I see here is a lot of conjecture.

Of course it is. What else did you expect from a bystander who = wasn't
involved in the design and implementation=3F

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.

> The current implementations took not a lot of code, and they = work
> well enough.

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. At least it =22didn't work well enough=22 for me, which is a = sign
that it isn't perfect. And you already made quite a few changes based
on my experience. 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. I don't know what you will find, if
you do that, but I do know that if you continue to insist that the
design is perfect, you will never see its flaws, if they exist.

> By the way, CEDET has had a similar feature for a while (try = `M-x=20
> semantic-mode', then `C-c , G' on some function, in a C file). = Arguably,=20
> even with a better interface.
>=20
> Any reason why you haven't been using it=3F

Partly because CEDET is too heavyweight for most of my needs, and
partly because I simply didn't have enough time to learn it.

> > And I'm not even sure your ideas of how to solve that = =22little detail=22
> > are workable, because of the potentially adverse consequences= of
> > loading code you don't actually need (or want) to execute. = What if
> > the code is buggy, or dangerous, or simply does things you = don't want
> > to be done in your Emacs session=3F
>=20
> That's a valid concern, but you'd have to read that kind of = project from=20
> top to bottom first. Then you can load it and proceed to use = the=20
> navigation functions.

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: you will never make your
deadline. Using the tools I'm talking about is the only way to find
the =5Frelevant=5F places which you do need to read and understand.

IOW, your methodology would put the cart before the horse, in = these
use cases.

> > I don't know what that means, and don't know enough about= JDEE to talk
> > about it. In any case, Java is not a =22classic=22 compiled = language, as
> > a Jave development environment is generally capable of = running the
> > code in an interpreter.
>=20
> There are several ones for C, example:=20
> http://www.drdobbs.com/cpp/ch-a-cc-interpreter-for-script-computin= g/184402054
>=20
> Not that it has any relevance to the xref backend interface.

Then why bring it up=3F

> > See above: you assume that the division of functionality = between the
> > UI and the back-ends is at the right place. I'm not so sure.= If I'm
> > right, then when more back-ends come, we will see more = problems, not
> > less.
>=20
> That's conjecture again.

And I have some gray heir to back it up with. I have learned from
long experience that good design is frequently backed up by intuition
and =22conjecture=22. I'm not necessarily saying I'm right in this = case,
but what if I am=3F Shouldn't you at least consider that, instead of
rejecting it flatly as =22conjecture=22 and sticking to the original
design as if it were a scripture=3F


------Nodemailer-0.5.0-?=_1-1430556394305--