From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Rocky Bernstein Newsgroups: gmane.emacs.devel Subject: Re: A couple of things that I think should be in byte bytecode meta comments Date: Sat, 23 Dec 2017 21:44:34 -0500 Message-ID: References: <83o9mqlin0.fsf@gnu.org> <83h8sildcd.fsf@gnu.org> <83fu81luke.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113e3618b5569205610d07e4" X-Trace: blaine.gmane.org 1514083410 20470 195.159.176.226 (24 Dec 2017 02:43:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 24 Dec 2017 02:43:30 +0000 (UTC) Cc: emacs-devel To: rswgnu@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 24 03:43:26 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eSwG5-0004tB-5F for ged-emacs-devel@m.gmane.org; Sun, 24 Dec 2017 03:43:25 +0100 Original-Received: from localhost ([::1]:48320 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSwI3-0006TN-Hi for ged-emacs-devel@m.gmane.org; Sat, 23 Dec 2017 21:45:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51656) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSwHG-0006SJ-2R for emacs-devel@gnu.org; Sat, 23 Dec 2017 21:44:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eSwHE-0001OH-D5 for emacs-devel@gnu.org; Sat, 23 Dec 2017 21:44:38 -0500 Original-Received: from mail-qt0-x22d.google.com ([2607:f8b0:400d:c0d::22d]:41552) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eSwHE-0001NI-3p for emacs-devel@gnu.org; Sat, 23 Dec 2017 21:44:36 -0500 Original-Received: by mail-qt0-x22d.google.com with SMTP id i40so40321030qti.8 for ; Sat, 23 Dec 2017 18:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6rsk/ScJ1/3Dvrzsd7rRc9d0+lToRWX5DkiOPOY9QvI=; b=aRA7ZYIkguX5DhHCn0PMGjINOpgSoA1zTMxi4KikA6sTlMSm0Cmrk1AtZLPZQW8zUr Ypdd/XWWIqCxJ2D7rB+1xTjDF3T+7tq4AFNGEdDC9zxmOpxfKXsMlmuVaHXrS3iJFSUZ 8AHEaz/WTmKx/HozDECWACl48i7SUqrQu20pRJ9BhPQYWLfy6Ad+XCMZXu7aoZtADB7g tpctQACh7LLOMINUjUNGqRh/en0rLWEnqunUvfiSaVrt444syCAtSYcVxB0jJkUff3a5 yAUmLTN7D3N39norPY+EtNy4gkq5cSL+1ObxGGOIUzGzm6hTtE4+VoKSCnvQmc5f6RvE zN6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6rsk/ScJ1/3Dvrzsd7rRc9d0+lToRWX5DkiOPOY9QvI=; b=oL4sZ9WbPiqbsRmt2YX/Iq4nzEXn8pA4dAWLInGRB8E5PKTba0zc9G02b03aCJqM0o WnWRZ9ltUoyhHjZdF+RGOcb+5DqCMcTHTD+zr47SfLtGLH+1gbRbYuLqRMuHf+1Gy3OK EIkh/WhSWsHWPy2qvstwPzQSf1mAdggWVEp5j44r3CxAI/I93Z/79QeeoQZYCrvh/22G dA2b8sptJCd7N3K4seUEMsToI1TY7dhLsCfJ+UFSPIS5j8r+af7xDziZSl7xIsGYnhMi 4Bm1QEmxcCRxBGyRr2dwUfLw5sBdawnp4ElxZM2WiRKG1XuwqJ/4zOgtxFKUlp+YAMLq YT2Q== X-Gm-Message-State: AKGB3mKqu54sW45xbCV3y9iiOAEHTCGRY4hvuBcpZolaW1458bTBnQe7 xiuRfmWO6uae+8yYer2D8Qb5kk6PnKU0rK+Wf8k= X-Google-Smtp-Source: ACJfBovPZWmprltBnsujDj5FmAwjzy2ZE7K5Y6KWyp5QI/XVSgpY2Z8UV3EYCsG9mlfinYSOTlJ20A8csFw/WfwSULc= X-Received: by 10.237.36.114 with SMTP id s47mr25461949qtc.144.1514083475345; Sat, 23 Dec 2017 18:44:35 -0800 (PST) Original-Received: by 10.12.197.8 with HTTP; Sat, 23 Dec 2017 18:44:34 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: Ckj5Yf_LT0g2pdZJMjJ7Cacs16o X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c0d::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:221396 Archived-At: --001a113e3618b5569205610d07e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 23, 2017 at 1:30 PM, Robert Weiner wrote: > =E2=80=8B... It is a matter of utility, not of havoc. > Reminds me of the discussions I recall having decades ago with colleagues who maintained that undo wasn't necessary, since they always got in the habit of saving the file before making important changes. =E2=80=8B > >> =E2=80=8BOk. this was a just suggestion. That it has caused such negativ= e >> reaction, I've seen before in other venues, and I'm sorry. >> =E2=80=8B=E2=80=8B >> For my part, I know what I can do to handle my concerns when or if I >> decide to improve the error reporting and debugging situation on Emacs. >> Yes, I am sorry I didn't say at the outset that this is were I envision >> this getting used. >> > > =E2=80=8BYes, an easy to follow use case would be helpful. > I've spent too much time in this thread at the expense of working in things that will have a more direct benefit to society. The easy-to-follow stuff will have to be deferred. > I am very much in favor of improving Emacs' error messages, especially > anything that leads to the source of an error when a backtrace is not > produced. > Great - think about it it and discuss it with your colleagues. I am eager to hear what you have to offer. If you can explain how something you envision could make that happen, > then you'll likely see feedback change. > I made an inadvertent mistake when I made the suggestion assuming that others' experience and background here was similar to mine. I'm sure you are right, but as I said, right now I don't think this is an effective use of either my or emacs-devs' limited time. So again, rather than explain, I will defer on this. None of the feedback here so far has been particularly helpful in getting things done. So right now having feedback change through more verbiage isn't important and doesn't feel like it is going to be a winner either. Here is an analogous situation that might explain my position. Rather than explain "undo" to a community where there are some that are more vocally disposed to opine that frequent saves are good enough, a better approach (and more pleasing too) would just to create "undo" and let the feature sell itself - or not. (I know some who are still "I don't need undo" believers) There are some communities where one suggests something and people respond with the default response: is why? And there are other communities where the response is; why not? Because Emacs is critically used, by necessity the overwhelming and more vocal group is in the "why?" the camp. There are other venues that have the luxury to be more in the "why not?" camp for things like this. > BTW, I think there might be a good idea in there about using hash codes t= o > verify valid use of a file, > Glad to have introduced you to this idea. I am eager to see what you do with it. though my personal experience is that incompatible byte codes are well > reported by Emacs and have not caused me any problems to date. > This has nothing to do with incompatible byte codes. I think you are conflating this with another thread. The much bigger problem is tracing an error raised from C code back to the > source function that raised it when running without a C debugger active. > Without that, users can't provide much of a bug report except possibly ho= w > to trigger the problem. > Ok. Think about and discuss. Again, I look forward to hearing what you come up with. > Bob > > > --001a113e3618b5569205610d07e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable




On Sat, Dec 23, 2017 at 1:30 PM, Robert Weiner <rsw@gnu.org><= /span> wrote:
=E2=80=8B... It is a matter of utility, not of havoc.

Reminds me of the di= scussions I recall having decades ago with colleagues who maintained that u= ndo wasn't necessary, since they always got in the habit of saving the = file before making important changes.

=E2=80=8B
=E2=80=8BOk. this was a just suggestion. Th= at it has caused such negative reaction, I've seen before in other venu= es, and I'm sorry.=C2=A0
=E2=80=8B=E2=80=8B
For my part, I k= now what I can do to handle my concerns when or if I decide to improve the = error reporting and debugging situation on Emacs. Yes, I am sorry I didn= 9;t say at the outset that this is were I envision this getting used.

=E2=80=8BYes, an easy to follow use case would= be helpful.=C2=A0

= I've spent too much time in this thread at the expense of working in th= ings that will have a more direct benefit to society.=C2=A0 The easy-to-fol= low stuff will have to be deferred.

=C2=A0
I am very much in favor of improving Emacs' error mess= ages, especially anything that leads to the source of an error when a backt= race is not produced.

Great -=C2=A0 think about it it and discuss it with your colleagues. I a= m eager to hear what you have to offer.

=C2=A0 If you can explain how something you envision could make th= at happen, then you'll likely see feedback change.

I made an inadvertent mistake when I ma= de the suggestion assuming that others' experience and background here = was similar to mine. I'm sure you are right, but as I said, right now I= don't think this is an effective use of either my or emacs-devs' l= imited time. So again, rather than explain, I will defer on this.
=

None of the feedback here so far has been particularly = helpful in getting things done. So right now having feedback change through= more verbiage isn't important and doesn't feel like it is going to= be a winner either.

Here is an analogous situ= ation that might explain my position. Rather than explain "undo" = to a community where there are some that are more vocally disposed to opine= that frequent saves are good enough, a better approach (and more pleasing = too)=C2=A0 would just to create "undo" and let the feature sell i= tself - or not. (I know some who are still "I don't need undo"= ; believers)

There are some communities where = one suggests something and people respond with the default response: is why= ? And there are other communities where the response is; why not?

Because Emacs is critically used, by necessity the ove= rwhelming and more vocal group is in the "why?" the camp. There a= re other venues that have the luxury to be more in the "why not?"= camp for things like this.


BTW, I think there might be= a good idea in there about using hash codes to verify valid use of a file,=

Glad to have intr= oduced you to this idea.=C2=A0 I am eager to see what you do with it.

though my personal experience is that= incompatible byte codes are well reported by Emacs and have not caused me = any problems to date.=C2=A0

<= /div>
This has nothing to do with incompatible byte codes. I think you = are conflating this with another thread.

The much bigger problem is tracing an error raised from C code back to= the source function that raised it when running without a C debugger activ= e.=C2=A0 Without that, users can't provide much of a bug report except = possibly how to trigger the problem.


Ok.=C2=A0 Think about and discuss. Again, = I look forward to hearing what you come up with.

=

Bob



--001a113e3618b5569205610d07e4--