* bug#37930: 26.3; Elisp manual: please remove index entry `seq library' @ 2019-10-25 20:53 Drew Adams 2019-10-26 7:18 ` Eli Zaretskii 0 siblings, 1 reply; 6+ messages in thread From: Drew Adams @ 2019-10-25 20:53 UTC (permalink / raw To: 37930 These are all of the index entries with "library" in them: commentary, in a Lisp library dynamic-library-alist find library image-load-path-for-library library library compilation library header comments library search Lisp library load-library locate-library seq library `seq library' does not belong here. (Either that or entries also belong for some or all of the umpteen other libraries provided in an Emacs distribution.) In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32) of 2019-08-29 Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd Windowing system distributor `Microsoft Corp.', version 10.0.17763 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#37930: 26.3; Elisp manual: please remove index entry `seq library' 2019-10-25 20:53 bug#37930: 26.3; Elisp manual: please remove index entry `seq library' Drew Adams @ 2019-10-26 7:18 ` Eli Zaretskii 0 siblings, 0 replies; 6+ messages in thread From: Eli Zaretskii @ 2019-10-26 7:18 UTC (permalink / raw To: Drew Adams; +Cc: 37930 tags 37930 wontfix close 37930 thanks > Date: Fri, 25 Oct 2019 13:53:18 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > > commentary, in a Lisp library > dynamic-library-alist > find library > image-load-path-for-library > library > library compilation > library header comments > library search > Lisp library > load-library > locate-library > seq library > > `seq library' does not belong here. Disagree. You are assessing index entries from a completely wrong angle. > (Either that or entries also belong for some or all of the umpteen > other libraries provided in an Emacs distribution.) May I suggest to re-read the well-known quotation about consistency by Ralph Waldo Emerson? There's no need for consistency here. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <<5034f118-77b6-4f94-8d7b-2be7fd8f5195@default>]
[parent not found: <<834kzwvutf.fsf@gnu.org>]
* bug#37930: 26.3; Elisp manual: please remove index entry `seq library' [not found] ` <<834kzwvutf.fsf@gnu.org> @ 2019-10-26 15:00 ` Drew Adams 2019-10-26 15:12 ` Eli Zaretskii 0 siblings, 1 reply; 6+ messages in thread From: Drew Adams @ 2019-10-26 15:00 UTC (permalink / raw To: Eli Zaretskii, Drew Adams; +Cc: 37930 > tags 37930 wontfix > close 37930 > > > commentary, in a Lisp library > > dynamic-library-alist > > find library > > image-load-path-for-library > > library > > library compilation > > library header comments > > library search > > Lisp library > > load-library > > locate-library > > seq library > > > > `seq library' does not belong here. > > Disagree. You are assessing index entries from > a completely wrong angle. What angle is that? You disagree that `seq library' doesn't belong. Fair enough. Why do you think it belongs? You didn't address the substance of the report: lack of a reason why it should be present. What's a good reason why it, alone among our many libraries, should have an index entry of that form? That's what begs justifying. There's no need to justify some imagined purist consistency. There should be no special need for a reason to remove it, if there's no reason to have it. Maybe there's a good reason for entry `seq library'. It's not obvious to me. If so, please say what it is. I'd like to understand. > > (Either that or entries also belong for > > some or all of the umpteen other libraries > > provided in an Emacs distribution.) > > May I suggest to re-read the well-known > quotation about consistency by Ralph Waldo > Emerson? > > There's no need for consistency here. (Once again, BTW) no one has argued for blind and systematic consistency. That's never a requirement. And I'd be the last person to argue for that. Occam's razor: If there's no good reason to add `seq library', why add it? If there's a reason for it _then_ close the report (after providing the reason, please). ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#37930: 26.3; Elisp manual: please remove index entry `seq library' 2019-10-26 15:00 ` Drew Adams @ 2019-10-26 15:12 ` Eli Zaretskii 0 siblings, 0 replies; 6+ messages in thread From: Eli Zaretskii @ 2019-10-26 15:12 UTC (permalink / raw To: Drew Adams; +Cc: 37930 > Date: Sat, 26 Oct 2019 08:00:09 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: 37930@debbugs.gnu.org > > > > commentary, in a Lisp library > > > dynamic-library-alist > > > find library > > > image-load-path-for-library > > > library > > > library compilation > > > library header comments > > > library search > > > Lisp library > > > load-library > > > locate-library > > > seq library > > > > > > `seq library' does not belong here. > > > > Disagree. You are assessing index entries from > > a completely wrong angle. > > What angle is that? That of consistency. As expressed by "doesn't belong". > You disagree that `seq library' doesn't belong. > Fair enough. Why do you think it belongs? That's a wrong question, when talking about index entries. the important question is "is it useful?" > Maybe there's a good reason for entry `seq > library'. It's not obvious to me. Not obvious to you doesn't mean you should file a bug report, or that we should continue discussing this. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <<<5034f118-77b6-4f94-8d7b-2be7fd8f5195@default>]
[parent not found: <<<834kzwvutf.fsf@gnu.org>]
[parent not found: <<80c877d4-178e-479b-bc12-048aefbb433f@default>]
[parent not found: <<83sgnftuan.fsf@gnu.org>]
* bug#37930: 26.3; Elisp manual: please remove index entry `seq library' [not found] ` <<83sgnftuan.fsf@gnu.org> @ 2019-10-26 15:55 ` Drew Adams 2019-10-26 16:10 ` Eli Zaretskii 0 siblings, 1 reply; 6+ messages in thread From: Drew Adams @ 2019-10-26 15:55 UTC (permalink / raw To: Eli Zaretskii, Drew Adams; +Cc: 37930 > > > > `seq library' does not belong here. > > > > > > Disagree. You are assessing index entries from > > > a completely wrong angle. > > > > What angle is that? > > That of consistency. As expressed by "doesn't belong". > > > You disagree that `seq library' doesn't belong. > > Fair enough. Why do you think it belongs? > > That's a wrong question, when talking about index entries. the > important question is "is it useful?" Fair enough. Read it that way then, if you want to quibble. To me, it doesn't belong - it shouldn't be present, because I don't see it as especially useful. But I'll be glad to learn how it is. You don't say why it's useful. In particular, why is it more useful than an entry that could be added for some other library? What's so useful about this entry for this library? > > Maybe there's a good reason for entry `seq > > library'. It's not obvious to me. > > Not obvious to you doesn't mean you should file a bug report, or that > we should continue discussing this. I should file a bug report when I think it can help improve Emacs. And that's what I do. Please don't tell others when or whether they _should_ file bug reports. You can close any report that you don't think is helpful. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#37930: 26.3; Elisp manual: please remove index entry `seq library' 2019-10-26 15:55 ` Drew Adams @ 2019-10-26 16:10 ` Eli Zaretskii 0 siblings, 0 replies; 6+ messages in thread From: Eli Zaretskii @ 2019-10-26 16:10 UTC (permalink / raw To: Drew Adams; +Cc: 37930 > Date: Sat, 26 Oct 2019 08:55:11 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > Cc: 37930@debbugs.gnu.org > > > > You disagree that `seq library' doesn't belong. > > > Fair enough. Why do you think it belongs? > > > > That's a wrong question, when talking about index entries. the > > important question is "is it useful?" > > Fair enough. Read it that way then, if you > want to quibble. "Quibble", thanks a lot. > To me, it doesn't belong - it shouldn't be > present, because I don't see it as especially > useful. But I'll be glad to learn how it is. How else do you get to functions from that library in the manual? > > Not obvious to you doesn't mean you should file a bug report, or that > > we should continue discussing this. > > I should file a bug report when I think it can > help improve Emacs. And that's what I do. > > Please don't tell others when or whether they > _should_ file bug reports. Your bug report was considered and rejected. Why do you continue arguing instead of accepting the decision? This is a recurring pattern with you, and one that makes it so unnecessarily hard handling your bug reports. People avoid responding to your bug reports because of that. I myself sometimes avoid them. This is unnecessary, and actually harms Emacs. Please consider not arguing about decisions to close your bug reports. > You can close any report that you don't think is helpful. I already did. But it doesn't seem to help, not with bugs filed by you. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-10-26 16:10 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-10-25 20:53 bug#37930: 26.3; Elisp manual: please remove index entry `seq library' Drew Adams 2019-10-26 7:18 ` Eli Zaretskii [not found] <<5034f118-77b6-4f94-8d7b-2be7fd8f5195@default> [not found] ` <<834kzwvutf.fsf@gnu.org> 2019-10-26 15:00 ` Drew Adams 2019-10-26 15:12 ` Eli Zaretskii [not found] <<<5034f118-77b6-4f94-8d7b-2be7fd8f5195@default> [not found] ` <<<834kzwvutf.fsf@gnu.org> [not found] ` <<80c877d4-178e-479b-bc12-048aefbb433f@default> [not found] ` <<83sgnftuan.fsf@gnu.org> 2019-10-26 15:55 ` Drew Adams 2019-10-26 16:10 ` Eli Zaretskii
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.