* bug#29598: 26.0; doc of `load-history' @ 2017-12-07 5:55 Drew Adams 2017-12-09 10:48 ` Eli Zaretskii 0 siblings, 1 reply; 6+ messages in thread From: Drew Adams @ 2017-12-07 5:55 UTC (permalink / raw) To: 29598 Shouldn't the doc say something about the order of the elements of the alist? It's a history, but neither the Elisp manual nor the doc string mentions whether the beginning or the end of the list is the oldest part of the history of loads. In GNU Emacs 26.0.90 (build 3, x86_64-w64-mingw32) of 2017-10-13 Repository revision: 906224eba147bdfc0514090064e8e8f53160f1d4 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --without-dbus --host=x86_64-w64-mingw32 --without-compress-install 'CFLAGS=-O2 -static -g3'' ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#29598: 26.0; doc of `load-history' 2017-12-07 5:55 bug#29598: 26.0; doc of `load-history' Drew Adams @ 2017-12-09 10:48 ` Eli Zaretskii 0 siblings, 0 replies; 6+ messages in thread From: Eli Zaretskii @ 2017-12-09 10:48 UTC (permalink / raw) To: Drew Adams; +Cc: 29598 > Date: Wed, 6 Dec 2017 21:55:22 -0800 (PST) > From: Drew Adams <drew.adams@oracle.com> > > Shouldn't the doc say something about the order of the elements of the > alist? It's a history, but neither the Elisp manual nor the doc string > mentions whether the beginning or the end of the list is the oldest part > of the history of loads. Since it's an alist, and every element should be there only once, why does the order matter? ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <<abd8ea3d-1224-4364-b9e2-73b8c63b90bc@default>]
[parent not found: <<837etwuqgx.fsf@gnu.org>]
* bug#29598: 26.0; doc of `load-history' [not found] ` <<837etwuqgx.fsf@gnu.org> @ 2017-12-09 16:27 ` Drew Adams [not found] ` <CADwFkmn0A3EMx_yX9emy8Wvcw5R7Byk7eFUNPYYT1-kxP1_ykA@mail.gmail.com> 2020-10-27 2:31 ` Stefan Kangas 0 siblings, 2 replies; 6+ messages in thread From: Drew Adams @ 2017-12-09 16:27 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams; +Cc: 29598 > > Shouldn't the doc say something about the order of the elements of the > > alist? It's a history, but neither the Elisp manual nor the doc string > > mentions whether the beginning or the end of the list is the oldest > > part of the history of loads. > > Since it's an alist, and every element should be there only once, why > does the order matter? Because it's a history? We already tell users, by using that name, that it is chronological. What we don't tell them is which chronological order is used. If someone is looking for something, it helps to know whether the list order is old-to-new or new-to-old. And if someone locates something of interest in the list it helps to know whether it is the stuff that comes before or after it that was loaded when it got loaded. Is there some reason not to mention the order? We do, after all, bother to call it `*-history'. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <CADwFkmn0A3EMx_yX9emy8Wvcw5R7Byk7eFUNPYYT1-kxP1_ykA@mail.gmail.com>]
* bug#29598: 26.0; doc of `load-history' [not found] ` <CADwFkmn0A3EMx_yX9emy8Wvcw5R7Byk7eFUNPYYT1-kxP1_ykA@mail.gmail.com> @ 2020-08-19 12:53 ` Drew Adams 0 siblings, 0 replies; 6+ messages in thread From: Drew Adams @ 2020-08-19 12:53 UTC (permalink / raw) To: Stefan Kangas, 29598 > >> > Shouldn't the doc say something about the order of the elements of the > >> > alist? It's a history, but neither the Elisp manual nor the doc string > >> > mentions whether the beginning or the end of the list is the oldest > >> > part of the history of loads. > >> > >> Since it's an alist, and every element should be there only once, why > >> does the order matter? > > > > Because it's a history? We already tell users, by using > > that name, that it is chronological. What we don't tell > > them is which chronological order is used. > > > > If someone is looking for something, it helps to know whether > > the list order is old-to-new or new-to-old. And if someone > > locates something of interest in the list it helps to know > > whether it is the stuff that comes before or after it that > > was loaded when it got loaded. > > > > Is there some reason not to mention the order? We do, after > > all, bother to call it `*-history'. > > Do you have a use-case in mind here? If we mention the order, we would > need to follow that in the future, whereas if we don't we could > potentially change it. So unless there is a concrete need to document > it, isn't it better to just avoid it? I really don't understand this hesitation. The use case is described above. Users have a chronological list. Why would we _not_ want to tell them which direction the list goes? That's not obvious. If at some future point Emacs changes the behavior (it never has), then we would, hopefully, document the new order. This is a very minor doc request, asking for a word or two. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#29598: 26.0; doc of `load-history' 2017-12-09 16:27 ` Drew Adams [not found] ` <CADwFkmn0A3EMx_yX9emy8Wvcw5R7Byk7eFUNPYYT1-kxP1_ykA@mail.gmail.com> @ 2020-10-27 2:31 ` Stefan Kangas 2020-10-27 8:53 ` bug#29598: (no subject) Lars Ingebrigtsen 1 sibling, 1 reply; 6+ messages in thread From: Stefan Kangas @ 2020-10-27 2:31 UTC (permalink / raw) To: Drew Adams; +Cc: 29598 Drew Adams <drew.adams@oracle.com> writes: >> > Shouldn't the doc say something about the order of the elements of the >> > alist? It's a history, but neither the Elisp manual nor the doc string >> > mentions whether the beginning or the end of the list is the oldest >> > part of the history of loads. >> >> Since it's an alist, and every element should be there only once, why >> does the order matter? > > Because it's a history? We already tell users, by using > that name, that it is chronological. What we don't tell > them is which chronological order is used. > > If someone is looking for something, it helps to know whether > the list order is old-to-new or new-to-old. And if someone > locates something of interest in the list it helps to know > whether it is the stuff that comes before or after it that > was loaded when it got loaded. > > Is there some reason not to mention the order? We do, after > all, bother to call it `*-history'. I agree that this doesn't sound useful to document the order, in general. It's as likely to confuse as to help, especially if there is we can't even think of a concrete use case for this. Also, if we document it, we sort of make a promise to our users that it won't change. And there doesn't seem to exist any good reason to do that. So I think this should better be closed as wontfix. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#29598: (no subject) 2020-10-27 2:31 ` Stefan Kangas @ 2020-10-27 8:53 ` Lars Ingebrigtsen 0 siblings, 0 replies; 6+ messages in thread From: Lars Ingebrigtsen @ 2020-10-27 8:53 UTC (permalink / raw) To: Stefan Kangas; +Cc: 29598 Stefan Kangas <stefan@marxist.se> writes: > So I think this should better be closed as wontfix. I agree, so I'm closing it now. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-10-27 8:53 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-12-07 5:55 bug#29598: 26.0; doc of `load-history' Drew Adams 2017-12-09 10:48 ` Eli Zaretskii [not found] <<abd8ea3d-1224-4364-b9e2-73b8c63b90bc@default> [not found] ` <<837etwuqgx.fsf@gnu.org> 2017-12-09 16:27 ` Drew Adams [not found] ` <CADwFkmn0A3EMx_yX9emy8Wvcw5R7Byk7eFUNPYYT1-kxP1_ykA@mail.gmail.com> 2020-08-19 12:53 ` Drew Adams 2020-10-27 2:31 ` Stefan Kangas 2020-10-27 8:53 ` bug#29598: (no subject) Lars Ingebrigtsen
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).