From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Patch] Enable byte-compile-error-on-wran for error-free files in lisp/ Date: Thu, 22 Feb 2018 09:18:53 +0200 Message-ID: <83lgfl5w6a.fsf@gnu.org> References: <87o9kii4an.fsf@cochranmail.com> <87371tn2qg.fsf@cochranmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1519283807 11951 195.159.176.226 (22 Feb 2018 07:16:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 22 Feb 2018 07:16:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 22 08:16:43 2018 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 1eol7T-0002lT-Bb for ged-emacs-devel@m.gmane.org; Thu, 22 Feb 2018 08:16:43 +0100 Original-Received: from localhost ([::1]:36541 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eol9V-00069F-Ci for ged-emacs-devel@m.gmane.org; Thu, 22 Feb 2018 02:18:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eol9P-00067h-Bm for emacs-devel@gnu.org; Thu, 22 Feb 2018 02:18:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eol9M-0000tc-55 for emacs-devel@gnu.org; Thu, 22 Feb 2018 02:18:43 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33864) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eol9M-0000tS-0f; Thu, 22 Feb 2018 02:18:40 -0500 Original-Received: from [176.228.60.248] (port=1400 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eol9K-0006cj-Ba; Thu, 22 Feb 2018 02:18:39 -0500 In-reply-to: (message from Stefan Monnier on Thu, 22 Feb 2018 00:24:37 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:222982 Archived-At: > From: Stefan Monnier > Date: Thu, 22 Feb 2018 00:24:37 -0500 > Cc: emacs-devel@gnu.org > > - there are various situations where there's no really good replacement. > I guess that means that while they are marked as obsolete we really > won't be getting rid of them any time soon. And we can probably just > silence the remaining warnings with `with-no-warnings` but only after > we clearly document the need to use this function and what it would > need to do otherwise. I think we need a new set of specialized primitives and/or optional arguments to existing primitives, in order to cover the cases where there are no good replacements. We declared those functions obsolete because they were used by Lisp packages without a good understanding of what they do and how to do the same "correctly". Most, if not all, of the remaining warnings in our own sources are of the kind where the proposed alternatives won't do. So I think we want to keep the obsolescence, but we need additional features to solve the problems without using these functions. > > Hmm, sounds like its better to just not do that with files distributed > > in parallel. I don't have a problem with that (most files is better than > > no files after all), but I have no idea which ones are and are not 'core > > only' files. Guidance requested. > > Good question. After contributing to Emacs for almost 20 years > I generally "just know", but it's not 100% and it's not written down > anywhere for those who don't have that 20 year head start. > > I agree it would be useful to document it. Eli, John, any idea what > would be the best way to document those things? Should we just add > a "Unbundled: yes" to the pseudo-headers, or maybe just (ab)use the > typical "URL: ..." pseudo-header for that? A new keyword sounds good.