all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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?



  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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.