all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@posteo.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: Please document the caching and its user options
Date: Sat, 15 Jun 2024 12:47:29 +0000	[thread overview]
Message-ID: <87y176gyou.fsf@localhost> (raw)
In-Reply-To: <861q4zy0va.fsf@gnu.org>

Eli Zaretskii <eliz@gnu.org> writes:

>> I am not convinced that we have to do it.
>
> That's too bad.  When a user finds out about this caching, how do you
> propose that he/she looks for the information about it?  I wanted to
> know what is being cached, why, and in what file/directory.  It took
> me quite some time to find the answers, since Org is a very large
> package, and there's no org-cache.el file or similar to serve as the
> immediate suspect.  Surely, such a basic functionality should be at
> least hinted in the documentation, so that users new which options to
> look at and where?

Maybe. Although it is not clear where to document such things.
Ideally, it would be nice if caches were managed by Emacs itself, with
all the cache storage locations customizeable across various packages.
Then, documenting cache locations in the Emacs manual would suffice.

Would it be possible for Emacs to define a framework for cache/var/data
locations? Such framework would not only be useful in the context of
this discussion, but also to tackle the issue with packages sprinkling
things randomly into .emacs.d or ~/ (see
https://github.com/emacscollective/no-littering/)

>> Emacs user manual does not document `multisession-directory' - something
>> very close to how we implement Org caches.  So, apparently, customizing
>> `multisession-directory' and even the very multisession feature
>> existence is not deemed necessary inside Emacs manual. Why would it be
>> different for Org mode manual?
>
> multisession is an optional package, it is neither preloaded nor
> turned on by default in Emacs.

It is used by default in emoji.el (C-x 8 e r)

> ... And even if Emacs makes a mistake of
> not documenting anything it is not a valid argument to make the same
> mistake elsewhere.

I 100% agree. But my default assumption is that things added to Emacs
are usually documented in the manual, if necessary. I assumed that the
judgment was that documenting multisession was not necessary and worked
out of that assumption.

Of course, if you say that multisession and similar things should be
documented, I will follow. Let's discuss the details.

(Also, should we open some kind of bug report to track documenting
multisession in the manual?)

> The emacs-internal encoding is not binary.  In almost all the cases it
> is indistinguishable from utf-8-unix.  It differs where a buffer
> includes characters outside of the Unicode codespace.  The usual
> practice in Emacs is that files holding internal data use
> emacs-internal to make sure all the characters are saved correctly and
> can be later restored correctly.

Then, I agree that using emacs-internal for cached data makes sense.

Note, however, that I see no indication about such convention in the
manual. The only relevant bit is

       The coding system ‘utf-8-emacs’ specifies that the data is
    represented in the internal Emacs encoding (*note Text
    Representations::).  This is like ‘raw-text’ in that no code conversion
    happens, but different in that the result is multibyte data.  The name
    ‘emacs-internal’ is an alias for ‘utf-8-emacs-unix’ (so it forces no
    conversion of end-of-line, unlike ‘utf-8-emacs’, which can decode all 3
    kinds of end-of-line conventions).

However, I cannot come to the conclusion you pointed from reading that
paragraph.

Would it make sense to add the tip about storing Elisp data somewhere in
the Elisp manual?

-- 
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>


  reply	other threads:[~2024-06-15 13:26 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-12  9:38 Please document the caching and its user options Eli Zaretskii
2024-06-14 13:12 ` Ihor Radchenko
2024-06-14 13:41   ` Eli Zaretskii
2024-06-14 15:31     ` Ihor Radchenko
2024-06-14 15:56       ` Eli Zaretskii
2024-06-15 12:47         ` Ihor Radchenko [this message]
2024-06-15 13:01           ` Eli Zaretskii
2024-06-15 14:13             ` Ihor Radchenko
2024-06-15 14:37               ` Eli Zaretskii
2024-06-16  9:05                 ` Ihor Radchenko
2024-06-16 10:41                   ` Eli Zaretskii
2024-06-23  9:12                     ` Björn Bidar
2024-06-15 13:47           ` Ihor Radchenko
2024-06-14 13:56   ` Jens Lechtenboerger
2024-06-14 14:31     ` Publishing cache (was: Please document the caching and its user options) Ihor Radchenko
2024-08-12  7:55       ` Proposal: Change publication timestamps (was: Publishing cache) Jens Lechtenboerger
2024-08-15 18:29         ` Ihor Radchenko
2024-08-25 17:00           ` Proposal: Change publication timestamps Jens Lechtenboerger
2024-09-15 12:02             ` Jens Lechtenboerger
2024-09-17 18:33               ` Ihor Radchenko
2024-06-16  5:40   ` Please document the caching and its user options Daniel Clemente
2024-06-16 12:36     ` Ihor Radchenko
2024-06-17 12:41       ` Daniel Clemente
2024-06-18 15:53         ` Ihor Radchenko
2024-06-18 16:15           ` Eli Zaretskii
2024-06-18 16:25             ` Ihor Radchenko
2024-06-18 16:33               ` Eli Zaretskii
2024-06-18 16:55                 ` Ihor Radchenko
2024-06-19  9:27                   ` Colin Baxter
2024-06-19 10:35                     ` Ihor Radchenko
2024-06-19 13:04                       ` Eli Zaretskii
2024-06-19 13:30                         ` Ihor Radchenko
2024-06-19 16:07                           ` Colin Baxter
2024-06-19 16:15                             ` Ihor Radchenko
2024-06-18 22:06               ` Rudolf Adamkovič
2024-06-19  4:29                 ` tomas
2024-06-23 11:45           ` Daniel Clemente
2024-06-24 10:36             ` Ihor Radchenko
2024-06-26 12:59               ` Daniel Clemente
2024-06-26 13:21                 ` org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options) Ihor Radchenko
2024-06-27  8:55                   ` Daniel Clemente
2024-06-27 10:15                     ` org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options)) Ihor Radchenko
2024-07-02 16:54                       ` Daniel Clemente
2024-07-02 19:16                         ` Ihor Radchenko
2024-07-04 10:36                           ` Daniel Clemente
2024-07-06 13:02                             ` Ihor Radchenko
2024-07-10 13:09                               ` Daniel Clemente
2024-07-11 10:40                                 ` Ihor Radchenko
2024-07-15 17:00                                   ` Daniel Clemente
2024-07-20 14:14                                     ` Ihor Radchenko
2024-07-24 13:47                                       ` Daniel Clemente
2024-07-25  7:31                                         ` Ihor Radchenko
2024-07-25 14:08                                           ` Daniel Clemente
2024-07-25 14:15                                             ` Ihor Radchenko
2024-10-05 18:56                           ` Daniel Clemente
2024-10-20 12:57                             ` Ihor Radchenko
2024-06-27 10:34                     ` org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options) Ihor Radchenko
2024-07-02 16:53                       ` Daniel Clemente
2024-06-27  9:27                 ` Please document the caching and its user options Eli Zaretskii
2024-06-27 10:11                   ` Ihor Radchenko
2024-06-27 10:30                     ` Eli Zaretskii
2024-06-28 12:54                     ` Rudolf Adamkovič
2024-06-28 15:31                       ` 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=87y176gyou.fsf@localhost \
    --to=yantar92@posteo.net \
    --cc=eliz@gnu.org \
    --cc=emacs-orgmode@gnu.org \
    /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.