emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: lra@phdk.org
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Karthik Chikmagalur <karthikchikmagalur@gmail.com>,
	Emacs Orgmode <emacs-orgmode@gnu.org>
Subject: Re: [PATCH] Fixing a regression in org-persists ability to handle non-list container arguments.
Date: Thu, 3 Oct 2024 20:00:40 +0200 (CEST)	[thread overview]
Message-ID: <O8IU9xk--B-9@phdk.org> (raw)
In-Reply-To: <87ikuaqugu.fsf@localhost>


Hi Ihor and Karthik,

> Thanks!
> Applied, onto main.

> LRA, thanks for the fix.

Glad to be of assistance!

> P.S. We really need tests for org-persist.

Yeah I did note a couple of pretty straight-forward opportunities for
clean-up wrt. redundancies and readability, but without
regression-tests and lacking confidence that I understood everything I
thought it was best to keep the patch as simple as possible. I
would've felt pretty stupid if I accidentally introduced a new
regression in my regression-fix haha. I'll include some of the stuff
from my notes below in case it's of interest to anybody working on
org-persist.

I hope it isn't just noise and that it can be of use :)

Regards,
LRA

-----

(These are all relative to the org-latex-preview dev-branch and not
main, but I think all the code in question applies to both, just the
linenums might be off.)

1.
   I noticed when testing on upstream that there are a ton of
   redundant calls to `o-p--normalize-container' throughout the
   package. I saw that you've already dealt with the redundancy in
   your branch Karthik, so maybe it's unimportant but I think the
   redundant calls also just hurt readability somewhat. A couple
   cases of
#+begin_example elisp
(defun somefun (container ... )
  (let ((container (org-persist--normalize-container container))
    ... )))

;; And then every call will have
  ...
  (somefun (org-persist--normalize-container container))
  ...
#+end_example
   
2.
   The bits handling the shape of container in `o-p--add-to-index'
   and `o-p--remove-from-index' are both redundant, as all calls
   to these functions use containers read from the index or from
   `o-p--get-collection', in both cases there's already logic ensuring
   it's a list of lists. This change worked fine in my limited testing:

Replacing =lisp/org-persist.el:L576-9= and =L592-5=
#+begin_example elisp
        (dolist (cont (cons container container))
#+end_example

3.
   Maybe I'm just an idiot, but the use (or maybe just the name) of
   `o-p--get-collection' was a bit confusing to me, as it's used both
   to find and /create/ indices. E.g. this bit of logic in
   `o-p-register' was particularly confusing where it's used in a let
   /before/ a conditional that determines whether the assignment is
   actually used for anything.
   
=lisp/org-persist.el:L1006-8=
#+begin_example elisp
    (let ((collection (org-persist--get-collection container associated misc)))
      (when (and expiry (not inherit))
        (when expiry (plist-put collection :expiry expiry))))
#+end_example

   With the redundant inner `when', it reads a bit like the let was
   supposed to be between the two, which I think makes sense if the
   first condition is an `or' instead of `and'? Although I'm not sure
   I actually figured out how this function or the inherit keyword
   works.

4. 
> Ihor, `org-persist--find-index' is singularly confusing.  I've been over
> it with edebug a few times and still can't figure out what it's doing,
> because `container' means different things at different points in the
> function because of the macro `org-persist-collection-let'.  Could it be
> simplified in some way?

   I had the exact same confusion motivating my attempt at rewording
   the comment. On my machine and in my limited testing, dropping the
   second use of the macro completely  worked fine:

   Replacing =lisp/org-persist.el:L552-4=
#+begin_example elisp
                         (lambda (cont)
                             (member cont (plist-get r :container)))
#+end_example

5.
   Another way to simplify `o-p--find-index' (and I think also get
   pretty close to achieving full consistency on the container shape),
   would be to put this bit from the start of `o-p--get-collection' at
   the start of `-read', `-write-all' and `-unregister' (or maybe in a
   (if (not inner) .. ) at the end of `o-p--normalize-container'?):

#+begin_example elisp
(unless (and (listp container) (listp (car container)))
    (setq container (list container)))
#+end_example

   This would cover all calls to`o-p--find-index' and allow you to
   revert the changes in both my patch and 7fd80991c3 I think. This is
   sort-of what I was thinking of wrt. rewriting
   `o-p--normalize-container' in my original e-mail.

-----


  reply	other threads:[~2024-10-03 18:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-18  0:24 [PATCH] Fixing a regression in org-persists ability to handle non-list container arguments lra
     [not found] ` <O71W8io--B-9@phdk.org-O71WWax----9>
2024-09-18  0:29   ` lra
2024-09-22  9:11     ` Ihor Radchenko
2024-09-22 23:04       ` Karthik Chikmagalur
2024-10-02 17:34         ` Ihor Radchenko
2024-10-03 18:00           ` lra [this message]
2024-10-06 12:35             ` 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

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=O8IU9xk--B-9@phdk.org \
    --to=lra@phdk.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=karthikchikmagalur@gmail.com \
    --cc=yantar92@posteo.net \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.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).