From: Eli Zaretskii <eliz@gnu.org>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: nicolas@petton.fr, emacs-devel@gnu.org, tino.calancha@gmail.com
Subject: Re: Add autoload cookies in seq.el
Date: Thu, 21 Jul 2016 17:33:48 +0300 [thread overview]
Message-ID: <834m7jysab.fsf@gnu.org> (raw)
In-Reply-To: <m3shv35knq.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 21 Jul 2016 12:51:21 +0200)
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: tino.calancha@gmail.com, nicolas@petton.fr, emacs-devel@gnu.org
> Date: Thu, 21 Jul 2016 12:51:21 +0200
>
> > Are we mis-communicating? If somefile.el needs a function that is in
> > subr-x.el, all it has to do is (require subr-x). How's that a
> > problem?
>
> We seem to be. That paragraph was about seq.el.
Was it? Here's what I saw and responded to:
> > Lars, why did you put read-multiple-choice in subr.el? Its only user
> > currently is message.el, which is not preloaded, so I think preloading
> > seq.el as result of this is not justified.
>
> Perhaps subr-x.el would be a better place for it...
>
> But I find it rather odd that we can't use the best and most modern
> libraries in the most central parts of Emacs. That's kinda backwards.
> The most central parts of Emacs gets the most obfuscated code?
IOW, from my POV some code which was only used by message.el (which is
not preloaded, and was never supposed to be) was added to subr.el,
which then required to preload seq.el. How is that related to the
following complaint of yours:
> Every time somebody introduces seq-based code into the dumped files,
> it's rewritten since we can't use seq, since it's not dumped. seq was
> written as a library meant to regularise all the different inconsistent
> libraries and functions we use for that stuff.
Since message.el is not a preloaded file, you are free to use
seq-based code in it, which will cause seq.el to be loaded when
message.el is. What I'm objected to is to put the code which uses
seq.el in a preloaded file, when its _only_ user is not preloaded. I
think such a policy makes sense; don't you?
> Until seq stops being persona non grata in the most important Emacs Lisp
> files, it'll probably not see much uptake in the rest of Emacs, either.
> Who wants to go around remembering two different interfaces for lists,
> one that's OK in subr.el and one that's not?
Maybe I'm misremembering, but I only saw discussions about preloading
seq once or twice, including this discussion. So I'm not sure where
does "persona non grata" thing come from. Can you point me to those
incidents which led you to this conclusion?
next prev parent reply other threads:[~2016-07-21 14:33 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-20 6:06 Add autoload cookies in seq.el Tino Calancha
2016-05-20 8:26 ` Nicolas Petton
2016-05-20 8:54 ` Tino Calancha
2016-05-20 9:42 ` Eli Zaretskii
2016-05-21 0:07 ` Tino Calancha
2016-05-21 6:50 ` Eli Zaretskii
2016-07-20 13:24 ` Lars Ingebrigtsen
2016-07-20 15:13 ` Eli Zaretskii
2016-07-21 10:51 ` Lars Ingebrigtsen
2016-07-21 13:27 ` Ted Zlatanov
2016-07-21 14:38 ` Eli Zaretskii
2016-07-21 14:33 ` Eli Zaretskii [this message]
2016-07-21 15:01 ` Lars Ingebrigtsen
2016-07-21 16:09 ` Eli Zaretskii
2016-07-22 9:04 ` Lars Ingebrigtsen
2016-07-22 10:50 ` Ted Zlatanov
2016-07-21 14:36 ` Michael Heerdegen
2016-07-21 15:45 ` Stefan Monnier
2016-07-22 14:26 ` Stefan Monnier
2016-07-22 15:07 ` Nicolas Petton
2016-07-22 15:18 ` Stefan Monnier
2016-07-22 15:28 ` Eli Zaretskii
2016-07-22 17:48 ` Nicolas Petton
2016-05-22 12:17 ` Tino Calancha
2016-05-22 19:54 ` Nicolas Petton
2016-05-23 1:49 ` Tino Calancha
2016-05-23 8:33 ` Nicolas Petton
2016-05-23 15:13 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=834m7jysab.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
--cc=nicolas@petton.fr \
--cc=tino.calancha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).