From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Better startup error handling Date: Sat, 28 Apr 2012 08:55:26 -0700 Message-ID: <9D6D1899732043718AD797F833C1439A@us.oracle.com> References: <83d36wfcf1.fsf@gnu.org> <834ns7g9r8.fsf@gnu.org> <87ty06nnxp.fsf@catnip.gol.com><87vckmm2z7.fsf@catnip.gol.com><87ehr9vp0r.fsf@destructor.i-did-not-set--mail-host-address--so-tickle-me><87ehr9n8nh.fsf@catnip.gol.com><87y5phu8o3.fsf@destructor.i-did-not-set--mail-host-address--so-tickle-me><878vhhn6oq.fsf@catnip.gol.com><87wr50uko3.fsf@spindle.srvr.nix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1335628569 21300 80.91.229.3 (28 Apr 2012 15:56:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 28 Apr 2012 15:56:09 +0000 (UTC) Cc: 'Miles Bader' , 'Jeremiah Dodds' , emacs-devel@gnu.org To: "'Stefan Monnier'" , "'Nix'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 28 17:56:06 2012 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 1SOA06-0001by-1v for ged-emacs-devel@m.gmane.org; Sat, 28 Apr 2012 17:55:58 +0200 Original-Received: from localhost ([::1]:55712 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SOA05-0004W7-Gw for ged-emacs-devel@m.gmane.org; Sat, 28 Apr 2012 11:55:57 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SOA01-0004N6-IR for emacs-devel@gnu.org; Sat, 28 Apr 2012 11:55:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SO9zz-0002BY-9D for emacs-devel@gnu.org; Sat, 28 Apr 2012 11:55:53 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:41786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SO9zv-0002A8-Qy; Sat, 28 Apr 2012 11:55:47 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3SFtZIf025754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 Apr 2012 15:55:35 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q3SFtY51009280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Apr 2012 15:55:34 GMT Original-Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3SFtXYo029999; Sat, 28 Apr 2012 10:55:34 -0500 Original-Received: from dradamslap1 (/10.159.164.157) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 28 Apr 2012 08:55:33 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac0lUdnIXywk0NW4QAW0b47tr1okJwAAfgDA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 148.87.113.117 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:150119 Archived-At: > > Downsides: loads the byte-compiler even in sessions that > > don't need it, and notably inefficient. > > Exactly: in theory it's straightforward, but doing it well > will require more work. IIRC there are some other issues such as > the fact that .emacs code tends to be very different from typical > code in Elisp packages, and the kinds of things we want to flag > aren't all the same (some things are acceptable/normal/unavoidable > in one but not in the other). No flames please, but I have a different objection to this idea. Perhaps you hinted at in in your last sentence - not sure. Anyhooo... .emacs is something that many non-Lisper users use. Sometimes they load 3rd-party libraries from it. Sometimes they include 3rd-party snippets directly in it. Whether that makes sense in general or for any given library or snippet is beside the point here. It is done, and rather often, I believe. Some such libraries or snippets are designed to work with more than one Emacs version. As such, it can be the case that some of the byte-compiler warnings, e.g. function calls with the wrong number of args or functions not known to be defined, are not relevant in the end. The byte compiler is just not smart enough to get everything right, and understandably so. That is, some such warnings might be relevant and helpful to some users and are probably so to developers of the libraries or snippets included, but they are not necessarily relevant to some other users. And those are the users whom we are most worried about wrt the thread Subject line. They are the users who are least likely to know what to do when they run into a startup problem etc. And - and this is important in my experience - some users do not understand, or misunderstand, when then see such warnings. Warnings can even frighten people when they are not understood. I've gotten more than one question or bug report which I replied to by reassuring the user that some such warning is not really relevant in the current situation etc. I'm probably not alone in that. In sum, my objection is that we will be throwing warnings at users who will not necessarily understand them and will not necessarily need to see them anyway. And yes, I do think this is potentially a big problem, for both users and the developers of code they use. Throwing byte-compiler warnings at users to handle or prevent startup problems is the wrong cure, IMHO - really wrong. The byte compiler for any given Emacs version is what it is. It can be helpful but it is certainly not perfect. And in particular it is not always on target when it comes to code that has to work with different Emacs versions. This problem tends to get worse as the byte compiler gets more helpful (almost put that word in quotes ;-)), more verbose, more finnicky. Systematically applying the byte compiler to user .emacs files sounds like a colossally misguided idea, to me.