From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification Date: Mon, 29 Feb 2016 16:57:09 -0500 Message-ID: References: <20160222175244.30186.2617@vcs.savannah.gnu.org> <87k2lwv5ob.fsf@gmx.de> <87egc4v4hs.fsf@gmx.de> <8bd4ec21-1306-41bf-aca7-5571a3014337@default> <87r3g4js64.fsf@gmail.com> <2b98a5dd-7f46-4e92-9398-ede070c261de@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1456783061 13814 80.91.229.3 (29 Feb 2016 21:57:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Feb 2016 21:57:41 +0000 (UTC) Cc: Emacs developers , John Wiegley , Michael Albinus , Oleh Krehel , Kaushal Modi To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 29 22:57:31 2016 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 1aaVoo-0004cB-0l for ged-emacs-devel@m.gmane.org; Mon, 29 Feb 2016 22:57:30 +0100 Original-Received: from localhost ([::1]:39342 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaVon-0005HK-1f for ged-emacs-devel@m.gmane.org; Mon, 29 Feb 2016 16:57:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaVoa-0005H4-Dg for emacs-devel@gnu.org; Mon, 29 Feb 2016 16:57:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaVoU-00014T-Nc for emacs-devel@gnu.org; Mon, 29 Feb 2016 16:57:16 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:32467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaVoU-00014J-J4; Mon, 29 Feb 2016 16:57:10 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CdDQA731xV/96hCkxcgxBUXoJQwRWBUoV5BAICgTw6EwEBAQEBAQGBCkEFg10BAQECAVYhAgULCzQSFBgNJIg3CM8jAQEBAQYBAQEBHos6hQUHhC0FjDCKcZwegUUjgWYkHIFwIDGCRwEBAQ X-IPAS-Result: A0CdDQA731xV/96hCkxcgxBUXoJQwRWBUoV5BAICgTw6EwEBAQEBAQGBCkEFg10BAQECAVYhAgULCzQSFBgNJIg3CM8jAQEBAQYBAQEBHos6hQUHhC0FjDCKcZwegUUjgWYkHIFwIDGCRwEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="194743872" Original-Received: from 76-10-161-222.dsl.teksavvy.com (HELO pastel.home) ([76.10.161.222]) by ironport2-out.teksavvy.com with ESMTP; 29 Feb 2016 16:57:09 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 860A86224A; Mon, 29 Feb 2016 16:57:09 -0500 (EST) In-Reply-To: (Drew Adams's message of "Mon, 29 Feb 2016 13:19:21 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:200827 Archived-At: >> I don't have a strong opinion on this. The issue is the following: >> cl-struct-define is "used internally by cl-defstruct", but it can't >> be changed at will, because it will basically have to be preserved >> for as long as Emacs-NN.MM wants to be able to run .elc files >> generated with Emacs-24.5. > At the rate things have been changing in the byte-compiler, that > won't be long. ;-) Have you had trouble running Emacs-22's .elc files recently? This said, I'd indeed like to move to an execution model where the .elc files are "not sufficient" so we can (and do) always fallback on the .el file in case the .elc is "too old" (or "too new"). This would probably go along with a move towards an execution model where we automatically compile .el files. > To me, `cl' is so obviously an abbreviation for Common Lisp that > I would automatically expect any function (macro, etc.) prefixed > with `cl-' to be a Common-Lisp emulation function. The fact that > some of them aren't is quite confusing and makes me wonder by what > criterion a function or macro is included in (or excluded from) > cl-lib. In theory the criterion is something along the lies of "either it's part of CommonLisp, or its implementation makes it belong to cl-lib". But usually the real criterion is simple: the one who writes and installs the patch gets to decide. [ So for example Drew typically doesn't get to decide. ] Stefan