[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH] Replace call in org-columns of org-map-entries with org-scan-tag
From: |
Nick Savage |
Subject: |
[PATCH] Replace call in org-columns of org-map-entries with org-scan-tags |
Date: |
Mon, 3 May 2021 09:03:43 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 |
Hello all,
I was trying to track down the source of a bug encountered when I was
submitting my last patch about org-columns. I'm going to walk you
through my thought process and summarize at the end. As part of my
experimenting, I did the following:
1. emacs -Q
2. open a new buffer at "/tmp/test.org"
3. Add a headline (something like "* test"), and run org-columns only be
greeted by an unexpected error: "Non-existent agenda file
/tmp/test.org. [R]emove from list or [A]bort?"
It's clear that /tmp/test.org is not part of the agenda since it's a
brand new file, but I was surprised that org-columns cares at all.
Pressing "R" to remove it from the list tells the user that it wasn't in
the agenda list (as you'd expect) and then continues to display columns
as expected, which made me wonder why it is doing that at all. This
issue only appears though when /tmp/test.org is not saved to disk, which
looks like expected behaviour as per the following.
I looked into what's going on, and it relates to org-map-entries, which
builds a list of what is in the buffer. org-map-entries calls
org-agenda-prepare-buffers. This checks whether the given files are
actual files or not and opens them up if they are. This makes sense I
believe from an org-agenda perspective since it has to make sure all of
the files are open in order to return a list of the headlines, but for
org-columns it does not. org-columns is an interactive function that is
only run on the current buffer, so the buffer should always be open.
org-map-entries has a lot of different paths in it based on the
parameters, but essentially the call from org-columns does two things:
1) call org-agenda-prepare-buffers and 2) sets "res" to the output of
org-scan-tags. I believe that the former is unnecessary and that the
latter is the only necessary code to run in this instance.
To summarize: I've attached a patch to this that makes a change to this.
It replaces org-map-entries with a call instead to org-scan-tags. This
fixes the bug I noted above, and I believe (if I'm using the profiler
correct), makes org-columns a bit faster since it's not calling a bunch
of functions that doesn't matter to its output. As far as I can tell, my
patch works as expected with no obvious behaviour changes. All of the
tests continue to pass as well. I've tested it on my own files and it is
working as expected as well.
I'd appreciate any feedback on this, or if there are edge cases that the
removed code breaks that I haven't been able to identify.
Nick
0001-org-colview.el-org-columns-Replace-org-map-entries-w.patch
Description: Text Data
- [PATCH] Replace call in org-columns of org-map-entries with org-scan-tags,
Nick Savage <=