From: Ihor Radchenko <yantar92@posteo.net> To: Eli Zaretskii <eliz@gnu.org> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, dsmasterson@gmail.com, emacs-orgmode@gnu.org, michel@schi.nz, 59882@debbugs.gnu.org Subject: Re: bug#59882: Multiple versions of Org in load-path problem Date: Wed, 14 Dec 2022 13:37:07 +0000 [thread overview] Message-ID: <87pmcmt8cc.fsf@localhost> (raw) In-Reply-To: <83359innsp.fsf@gnu.org> Eli Zaretskii <eliz@gnu.org> writes: >> I am asking because org-mouse.el advises some functions and its loading >> may cause unexpected consequences. See >> https://orgmode.org/list/87r0x6sju1.fsf@fastmail.fm > > I think org-mouse.el should be fixed not to cause such effects just by > loading it. It should do that only when it is actually used. Yes, we plan to do exactly this https://orgmode.org/list/87zgbqqukg.fsf@localhost However, it will be a breaking backward-incompatible change. And we have similar issues with several important Org components (ol-* and ob-*). In particular, ob-*.el packages affect Org simply by defining function symbols with specific name patters (by ob-core.el design). Achieving no side effects is difficult in practice. Also, note that side effects are not uncommon in Elisp packages. Including, built-ins, like rect.el. dired+ comes to mind among popular third-party packages. >> At the same time, we have users complaining about some defcustoms not >> being available without loading. >> https://orgmode.org/list/25496.19258.682537.503614@gargle.gargle.HOWL > > That's too vague: it talks about "whether a variable exists", which is > ambiguous. That a variable is not boundp until its definition is > loaded is perfectly expected, and I don't think defcustom changes that > in any way (unless you autoload the defcustom, which is considered not > the best style around here). > > So I guess some clarification is in order: what exactly was the > problem with that variable being "nonexistent"? Agree. See the quote below: https://list.orgmode.org/orgmode/25497.41832.663858.836948@gargle.gargle.HOWL/ Like I said in another message that I sent just before receiving yours my conclusion came from the fact that hitting 'C-h v' with the cursor on 'org-goto-interface' provided nothing. It was the first time this ever happened to me. I did try to explicitly enter the variable's name by entering 'org-goto<TAB>', which (like 'org-go<TAB>') is not enough: it is completed to 'org--goto'. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
WARNING: multiple messages have this Message-ID (diff)
From: Ihor Radchenko <yantar92@posteo.net> To: Eli Zaretskii <eliz@gnu.org> Cc: dsmasterson@gmail.com, 59882@debbugs.gnu.org, emacs-orgmode@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>, michel@schi.nz Subject: bug#59882: Multiple versions of Org in load-path problem Date: Wed, 14 Dec 2022 13:37:07 +0000 [thread overview] Message-ID: <87pmcmt8cc.fsf@localhost> (raw) In-Reply-To: <83359innsp.fsf@gnu.org> Eli Zaretskii <eliz@gnu.org> writes: >> I am asking because org-mouse.el advises some functions and its loading >> may cause unexpected consequences. See >> https://orgmode.org/list/87r0x6sju1.fsf@fastmail.fm > > I think org-mouse.el should be fixed not to cause such effects just by > loading it. It should do that only when it is actually used. Yes, we plan to do exactly this https://orgmode.org/list/87zgbqqukg.fsf@localhost However, it will be a breaking backward-incompatible change. And we have similar issues with several important Org components (ol-* and ob-*). In particular, ob-*.el packages affect Org simply by defining function symbols with specific name patters (by ob-core.el design). Achieving no side effects is difficult in practice. Also, note that side effects are not uncommon in Elisp packages. Including, built-ins, like rect.el. dired+ comes to mind among popular third-party packages. >> At the same time, we have users complaining about some defcustoms not >> being available without loading. >> https://orgmode.org/list/25496.19258.682537.503614@gargle.gargle.HOWL > > That's too vague: it talks about "whether a variable exists", which is > ambiguous. That a variable is not boundp until its definition is > loaded is perfectly expected, and I don't think defcustom changes that > in any way (unless you autoload the defcustom, which is considered not > the best style around here). > > So I guess some clarification is in order: what exactly was the > problem with that variable being "nonexistent"? Agree. See the quote below: https://list.orgmode.org/orgmode/25497.41832.663858.836948@gargle.gargle.HOWL/ Like I said in another message that I sent just before receiving yours my conclusion came from the fact that hitting 'C-h v' with the cursor on 'org-goto-interface' provided nothing. It was the first time this ever happened to me. I did try to explicitly enter the variable's name by entering 'org-goto<TAB>', which (like 'org-go<TAB>') is not enough: it is completed to 'org--goto'. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2022-12-14 13:38 UTC|newest] Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-06 2:50 Multiple versions of Org in load-path problem David Masterson 2022-12-06 5:36 ` tomas 2022-12-06 7:04 ` David Masterson 2022-12-07 13:30 ` Ihor Radchenko 2022-12-08 3:27 ` David Masterson 2022-12-08 7:16 ` David Masterson 2022-12-08 7:26 ` Ihor Radchenko 2022-12-08 18:24 ` David Masterson 2022-12-08 19:31 ` Michel Schinz 2022-12-08 21:56 ` bug#59882: " David Masterson 2022-12-08 21:56 ` David Masterson 2022-12-08 22:56 ` Tim Cross 2022-12-09 5:00 ` David Masterson 2022-12-09 6:56 ` Tim Cross 2022-12-09 15:49 ` Sharon Kimble 2022-12-10 20:38 ` Tom Gillespie 2022-12-09 7:17 ` bug#59882: " Eli Zaretskii 2022-12-09 7:17 ` Eli Zaretskii 2022-12-09 7:43 ` David Masterson 2022-12-09 7:43 ` David Masterson 2022-12-09 11:57 ` Eli Zaretskii 2022-12-09 11:57 ` Eli Zaretskii 2022-12-09 19:40 ` Cook, Malcolm 2022-12-09 19:51 ` David Masterson 2022-12-09 20:27 ` Eli Zaretskii 2022-12-09 20:27 ` Eli Zaretskii 2022-12-09 19:51 ` David Masterson 2022-12-09 19:40 ` Cook, Malcolm 2022-12-10 14:01 ` Ihor Radchenko 2022-12-10 14:01 ` Ihor Radchenko 2022-12-14 9:51 ` Ihor Radchenko 2022-12-14 9:51 ` Ihor Radchenko 2022-12-14 12:59 ` Eli Zaretskii 2022-12-14 13:37 ` Ihor Radchenko [this message] 2022-12-14 13:37 ` Ihor Radchenko 2022-12-14 14:35 ` Stefan Monnier 2022-12-14 16:02 ` Max Nikulin 2022-12-15 4:17 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-12-15 4:17 ` Stefan Monnier 2022-12-15 4:56 ` Ihor Radchenko 2022-12-15 4:56 ` Ihor Radchenko 2022-12-16 12:36 ` Max Nikulin 2022-12-16 12:36 ` Max Nikulin 2022-12-16 14:47 ` Ihor Radchenko 2022-12-16 14:47 ` Ihor Radchenko 2022-12-18 15:24 ` Max Nikulin 2022-12-18 15:24 ` Max Nikulin 2022-12-18 15:40 ` Stefan Monnier 2022-12-18 15:40 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-04-06 16:09 ` Max Nikulin 2023-04-06 21:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-04-06 21:25 ` Stefan Monnier 2023-04-19 4:20 ` Tom Gillespie 2023-04-19 4:20 ` Tom Gillespie 2023-04-06 16:09 ` Max Nikulin 2022-12-25 9:48 ` Ihor Radchenko 2022-12-25 11:46 ` Max Nikulin 2022-12-25 11:46 ` Max Nikulin 2022-12-26 8:44 ` Ihor Radchenko 2022-12-26 11:01 ` Ihor Radchenko 2022-12-26 11:01 ` Ihor Radchenko 2022-12-26 12:25 ` Max Nikulin 2022-12-27 9:47 ` Ihor Radchenko 2022-12-27 9:47 ` Ihor Radchenko 2022-12-27 9:56 ` Max Nikulin 2022-12-27 9:56 ` Max Nikulin 2023-02-03 11:02 ` Ihor Radchenko 2023-02-03 11:02 ` Ihor Radchenko 2023-02-03 12:15 ` Eli Zaretskii 2023-02-03 12:15 ` Eli Zaretskii 2023-02-03 20:01 ` Tim Cross 2023-02-14 22:53 ` Gregor Zattler 2023-02-14 22:53 ` Gregor Zattler 2023-02-16 12:14 ` Max Nikulin 2023-02-16 12:14 ` Max Nikulin 2023-02-21 5:22 ` Richard Stallman 2023-02-21 5:22 ` Richard Stallman 2023-02-21 12:32 ` Eli Zaretskii 2023-02-21 12:32 ` Eli Zaretskii 2023-02-21 17:26 ` Bhavin Gandhi 2023-02-21 17:26 ` Bhavin Gandhi 2023-02-22 10:48 ` Ihor Radchenko 2023-02-22 10:48 ` Ihor Radchenko 2023-02-22 16:58 ` Bhavin Gandhi 2023-02-22 16:58 ` Bhavin Gandhi 2023-02-23 9:35 ` Ihor Radchenko 2023-02-23 9:35 ` Ihor Radchenko 2023-04-06 15:02 ` Max Nikulin 2023-04-06 15:02 ` Max Nikulin 2023-04-07 11:39 ` Max Nikulin 2022-12-26 12:25 ` Max Nikulin 2022-12-26 8:44 ` Ihor Radchenko 2022-12-25 9:48 ` Ihor Radchenko 2022-12-14 16:02 ` Max Nikulin 2022-12-14 14:35 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-12-14 14:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-12-14 14:25 ` Stefan Monnier 2022-12-14 12:59 ` Eli Zaretskii 2022-12-14 21:49 ` Cook, Malcolm 2022-12-14 21:49 ` Cook, Malcolm 2022-12-09 19:47 ` Cook, Malcolm 2022-12-09 19:47 ` bug#59882: " Cook, Malcolm 2022-12-08 21:50 ` Cook, Malcolm [not found] ` <87o7se74bf.fsf@penguin> 2022-12-08 7:19 ` David Masterson 2022-12-08 9:10 ` Ihor Radchenko
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=87pmcmt8cc.fsf@localhost \ --to=yantar92@posteo.net \ --cc=59882@debbugs.gnu.org \ --cc=dsmasterson@gmail.com \ --cc=eliz@gnu.org \ --cc=emacs-orgmode@gnu.org \ --cc=michel@schi.nz \ --cc=monnier@iro.umontreal.ca \ /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: linkBe 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.