emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Patch] Enable byte-compile-error-on-wran for error-free files in li


From: Eli Zaretskii
Subject: Re: [Patch] Enable byte-compile-error-on-wran for error-free files in lisp/
Date: Thu, 22 Feb 2018 09:18:53 +0200

> From: Stefan Monnier <address@hidden>
> Date: Thu, 22 Feb 2018 00:24:37 -0500
> Cc: address@hidden
> 
> - 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]