Re: How to organize tasks about Worg within Worg documents

[Adam Porter]

On 5/12/24 07:18, Ihor Radchenko wrote:


I looked into this further, and found
exporters/taskjuggler/ox-taskjuggler.org

that has whole "TODO" subtrees hidden with :noexport: tag.

Such half-ready subtrees are not really ready for normal viewing and are
mostly a material for WORG hackers to work on. Not sure how they fit
into the discussed todo records and notes concept.


Seems like a reasonable solution in that case.

Re: Better support admonitions blocks

[Adam Porter]

Hi Ihor, JD, et al,

On 4/4/24 12:04, Ihor Radchenko wrote:

JD Smith  writes:


Pandoc recently added read/write support
<https://github.com/jgm/pandoc/issues/9475> for "admonitions",
which are a GFM construct
<https://github.com/orgs/community/discussions/16925> already
supported by other org-exporters, and on GH in markdown.  This
refcard
<https://github.com/fniessen/refcard-org-mode?tab=readme-ov-file#base-admonitions>
references an org #{begin,end}_{note,warning,tip,caution,important}
syntax which pandoc now follows (though it does not support the
extra admonitions like danger/error/etc.).

It would be nice to add org support for these 5 admonition blocks
to the C-c C-, org block structure templates, and perhaps allow
block face styling for these as well (ala org-src-block-faces).


CCing Adam. We recently discussed "highlight" blocks in the context
of WORG publishing.


Thanks.


I do not see much problem adding such blocks, although I am not sure
if we want them by default.


I would tend to agree that they probably shouldn't be part of Org's
default configuration (at least, not yet--if they were to become very
widespread in usage, then maybe we could reconsider).

What we may do is to implement something akin link's :export and 
:active-func parameters to allow custom fontification and export. 
(... and add a new :structure-template parameter to auto-add them to 
structure templates)


Then, we can add optional support for all the proposed blocks that
will define how to insert, export, and fontify them.


That would seem good to me.

As far as Worg goes, I'd be in favor of having them available on Worg by 
default; they should be useful for writing documentation.


Thanks,
Adam

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Adam Porter]

On 4/2/24 06:20, Ihor Radchenko wrote:

I just looked into changing this TODO into inlinetask and that would 
require adding a style for inlinetasks. While looking, I noticed a 
commented section in worg-editing.org:


...

Also, the above macros may we one existing way to provide
highlighting we discussed earlier.

WDYT?


A few thoughts:

1.  Having to use separate BEGIN and END macros is less convenient than 
more Lispy constructs, like a macro call with a string argument.  But I 
guess, to wrap Org elements, like a TODO heading or inline task, it 
would be necessary.  A macro call with the text as an argument wouldn't 
be a task in Org syntax, which would make it less useful outside of 
rendered HTML.


2.  Those macros, or one much like them, could be useful for the use 
case of centering text to stand out, as discussed in the other thread.


3.  For cases that don't potentially involve wrapping Org elements, 
having a simple macro with the text as its argument might be preferable 
to having separate BEGIN and END macros.  I wonder if we could have 
non-begin-end equivalents of the begin-and-end macros listed there.


--Adam

Re: [PATCH] lisp/ox-html.el: Add avif support for html export inline images

[Adam Porter]

Hi Ihor,

I noticed what appears to be a typo in this commit: 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1be2f9693



+*** =.avif= images are not recognized in ~org-html-inline-image-rules~
  ^

Unless I misunderstand something, I guess it's supposed to say "now 
recognized."  :)


--Adam

Re: How to organize tasks about Worg within Worg documents

[Adam Porter]

On 4/1/24 06:34, Ihor Radchenko wrote:


What we may do is the following:
1. Make sure that we stick to the recommended todo keywords, so that
todo keywords have a known-in-advance class in html export.
2. Put notes into LOGBOOK drawers (set `org-log-into-drawer' in WORG
dirlocals)
3. Change `org-html-format-drawer-function' during publishing to mark
the LOGBOOK drawers with a distinct class.
4. Enable org-inlinetask library during publishing.

Then, the CSS switch will involve toggling visibility of (1) todo
keyword classes; (2) inlinetask class; (3) LOGBOOK drawer class.


Sounds good to me!

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Adam Porter]

On 3/30/24 06:08, Ihor Radchenko wrote:


This is actually not true that Emacs repository has a separate copyright
assignment form.

CONTRIBUTE file says

 In most cases, to start the assignment process you should download
 
https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
 and return the completed information to the address at the top.

This is linking to one of the forms at gnulib, the same with what
gnu.org suggests.

In contrast, we, in WORG, link to a _copy_ of the form rather than to
the original form.

I've just pushed some clarifications to org-maintenance page, adding the
correct link, but still leaving our current form - our form has one
answer pre-filled.
https://git.sr.ht/~bzg/worg/commit/e5deaca5


Thanks.


TODO: Get updated version of form from Emacs maintainers that includes
the line asking the secretary to send confirmation to interested
parties (i.e. the Org maintainers).


I am inclined to remove this todo - I already asked gnulib guys and they
contacted FSF about the latest version of the form. Until we get a
reply, there is nothing we can act upon. See
https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00060.html


FWIW, I'd be inclined to leave the task for future action, perhaps 
changing it to a WAITING keyword with a state-change note explaining the 
status (that's what I use in my system, anyway).  But if you disagree, I 
won't argue.


Thanks,
Adam

Re: How to organize tasks about Worg within Worg documents

[Adam Porter]

On 3/30/24 05:47, Ihor Radchenko wrote:

Adam Porter  writes:


Using a normal heading for a task would "commandeer" the structure of
the document, which I think is a real problem.


Not really. If some section is incomplete, marking it "TODO" means that
it should be completed. And the details might be listed in the logbook
notes, for example. The section name itself does not necessarily have to
details what needs to be done.

We have multiple instances of such "TODO" items in WORG, some also
include comments on what should be done.

On the other hand, inlinetasks are more concrete and immediately mark
both where exactly and what needs to be done.


You make a good point: for some cases, an entire section/heading may 
need "to be done," so giving the whole heading a TODO makes sense.  For 
other tasks, an inline one would be more appropriate.



I am not 100% sure if we need to constrain "TODO" items to one or
another style. Global todo list, marking existing sections as TODO, and
inlinetasks all may have their place depending on the situation.

The policy we may want to set is whether "TODO" keywords and notes
should be displayed to all the users. WORG has this set all over the
place - some TODO headings are marked to be not exported, some TODO
keywords are hidden via #+options: todo:nil, some notes are placed into
# comments.

May we have some kind of css-based toggle that will enable "developer
mode", revealing all the todo keywords, inlinetasks, and notes? Then, we
hide the "unfinished" parts from users by default, but let them see what
can be contributed?


I like the idea of a visual toggle very much, so I'm certainly in favor 
of that.


I'm not sure that we must have a constraint on the way TODOs are 
written, but having some limitations on or conventions about it might 
make such a visual toggle easier to implement (as well as other tools 
one might use to collect and visualize tasks across the project).

Re: How to organize tasks about Worg within Worg documents

[Adam Porter]

Hi Tom,

On 3/29/24 18:30, Thomas S. Dye wrote:

Here's another potential solution that I find useful.

d. Keeping tasks under a heading held back from export.
I have a capture template that saves tasks about the document under a * 
Tasks :no-export: heading.  To keep the agenda sane, I don't add the 
file.  Instead, I show buffer local tasks with org-sidebar.


Yes, that's a good solution if we want the tasks hidden from the 
exported HTML on Worg.  I'm not sure if we do want that; that may be 
another minor policy decision to be made.  (Maybe it's not a big deal, 
but a bit of consistency in this regard would make Worg seem more 
serious and polished, which might encourage more contribution.)

How to organize tasks about Worg within Worg documents (was: Re: [Worg] CSS improvements)

[Adam Porter]

On 3/29/24 04:48, Ihor Radchenko wrote:


Also, we may consider re-using inlinetask style for TODO: entries.

Rather than
#+begin_center
TODO: Even better, find a volunteer to maintain this information!
#+end_center

We can do

 TODO Even better, ...


That is a lot of asterisks, and I can't remember if inline tasks are
enabled by default.  :)  But in general, sure, I've no objection.  I
think that we should have some standard way to encode tasks within Worg
documents, regardless of what it is.


Yeah. And... we do.
https://orgmode.org/worg/worg-editing.html#orgce51883

Just a normal heading with TODO keyword.


I'm not sure that page really covers the question of how to present 
tasks about the document within the same document.


Using a normal heading for a task would "commandeer" the structure of 
the document, which I think is a real problem.


ISTM that there are a few potential solutions:

a. Using inline tasks.  Although not enabled by default, they seem to
   solve the problem pretty well.

b. Using commented lines, i.e.

 # TODO: Improve this information.

   Potentially we could even comment Org syntax within the file, like:

 # * TODO Improve this information  :research_needed:

   Which encodes a normal Org heading but as a commented line, so it
   wouldn't affect the structure of the document itself.  Of course,
   that would not appear in the exported content, which is probably not
   what we want; but those headings could still be collected, e.g. by
   something like magit-todos.

c. Keeping tasks in a separate file.  We do already have the /todo.org
   file, so maybe this is what we should standardize on, i.e. never
   putting tasks in the documents themselves but only in this file.

Regardless of the decision, I do think that having this stated as a 
policy somewhere would be helpful.


WDYT?

Re: [Worg] CSS improvements

[Adam Porter]

On 3/28/24 08:18, Ihor Radchenko wrote:

Adam Porter  writes:


I guess we can make this into a poll... (I have no better ideas on
how to resolve the disagreement)


I think that's unnecessary.  Worg isn't a democracy, after all.  If you
are vetoing the idea, then let it be vetoed, and let us move on with the
rest of the proposed changes.  I'll go ahead and push them, without the
background color.


It is not about democracy or veto. We disagree about expectations for
#+begin_center. Expectations are not about me or you, but rather about
what WORG authors will expect. So, asking people makes sense.


If you feel strongly enough about the background color idea (which would 
be an interesting reversal ;), I'll leave that in your hands. 
Otherwise, I don't feel strongly enough about it to pursue a poll.



Also, we may consider re-using inlinetask style for TODO: entries.

Rather than
#+begin_center
TODO: Even better, find a volunteer to maintain this information!
#+end_center

We can do

 TODO Even better, ...


That is a lot of asterisks, and I can't remember if inline tasks are 
enabled by default.  :)  But in general, sure, I've no objection.  I 
think that we should have some standard way to encode tasks within Worg 
documents, regardless of what it is.


Thanks,
Adam

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Adam Porter]

On 3/28/24 07:01, Ihor Radchenko wrote:

Adam Porter  writes:


On 3/26/24 09:59, Ihor Radchenko wrote:


I agree. My concern was not about dropping the previous wording.

What about

The assignment process does not always go quickly; occasionally it may
get stuck or overlooked at the FSF.  If there is no response to the
contributor from FSF, Org mode maintainers can contact the FSF at
   =copyright-clerk AT fsf DOT org=.  Historically, FSF replies to the
   maintainer request within a few days.

 ^^^

Other than changing "request" to, e.g. "arrive," no objection from me.


Actually, what Bastien suggested is slightly different.
See the attached tentative patch.


Sure.  I've pushed that, adding a "co-authored-by" line for Bastien.

Thanks,
Adam

Re: [Worg] CSS improvements

[Adam Porter]

On 3/28/24 06:44, Ihor Radchenko wrote:


So I would still suggest that, on Worg, we use my suggested styling
on #+begin_center blocks.  This would make them useful and fulfill
their natural purpose.


I think that we have a principal disagreement here. For me,
highlighting #+begin_center blocks is extremely unnatural. I would
never expect that, and I would be extremely surprised by that.


It's a mild background color fitting with the theme of the Worg site.

And as I've said, centering has not even had any effect up til now.  So
I don't think it's a big deal.


Since Worg is updated with relatively low frequency, anyway,
perhaps this suggestion could be tried as an experiment.  If
problems are found with it, then the extra styling, beyond merely
centering the text, could be reverted.  Nothing is permanent here;
we've probably spilled more virtual ink on this topic than would be
affected by the change.


I am mostly worried about future effect. We will not have any
problems with it in the near future, because the only user of this
style will be your new WORG page.


I don't know what there is to worry about.  If someone centers some text 
on a Worg page to make it stand out, it would...stand out?  :)



Anyway, if this idea is vetoed, it would still be good to have some
way to make text stand out in a standard way, similar to various
HTML documentation styles in other projects (to avoid resorting to
inline HTML).  It seems like a missing feature on Worg.


Agree.


And the other changes in the patch would be good to have,
regardless.


Yup.



I guess we can make this into a poll... (I have no better ideas on
how to resolve the disagreement)


I think that's unnecessary.  Worg isn't a democracy, after all.  If you
are vetoing the idea, then let it be vetoed, and let us move on with the 
rest of the proposed changes.  I'll go ahead and push them, without the 
background color.


Thanks,
Adam

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Adam Porter]

On 3/26/24 09:59, Ihor Radchenko wrote:


I agree. My concern was not about dropping the previous wording.

What about

The assignment process does not always go quickly; occasionally it may
get stuck or overlooked at the FSF.  If there is no response to the
contributor from FSF, Org mode maintainers can contact the FSF at
  =copyright-clerk AT fsf DOT org=.  Historically, FSF replies to the
  maintainer request within a few days.

   ^^^

Other than changing "request" to, e.g. "arrive," no objection from me.

Thanks,
Adam

Re: [Worg] CSS improvements

[Adam Porter]

On 3/26/24 09:48, Ihor Radchenko wrote:

Adam Porter  writes:


What is the purpose of centering text if not to make it stand out?


To align text. I am not sure why anything more is necessary - it
is certainly counter-intuitive for me that "center" means something more
than just alignment.


Again, what is the purpose of centering text?  The answer, "To align
text," is tautological.


I am very confused. Of course, it is tautological. "center" container is
aiming to align the text. That's why it is named "center".


Yes, but why do we center text?  That's what I'm asking.


Especially, on Worg, where the whole site serves as a kind of extended
user manual, the purpose of centering text is, what, if not to make it
stand out?


To align text... I really do not understand why one would _anticipate_
that #+begin_center is doing anything other than center alignment.


Of course, I'm not suggesting that this be the default for Org's HTML 
export CSS.  I'm suggesting that, on Worg, since the .org-center class 
hasn't even been styled, we might as well use it for this purpose--to 
make text stand out--since that's generally the purpose of centering 
text anyway.



If you need extra highlighting, we may introduce a dedicated style and
apply it via special block.


Why, when we already have #+begin_center?  Currently it's not even used
at all.  This would not change anything that already exists; it would
make something that already exists useful.


It would break expectations.
It will also differ from ox-html output with the default css style
`org-html-style-default':


Worg already differs significantly from the ox-html default styles, so 
why not in this way also?



Mostly because it is unexpected, as I described above.
I'd prefer to stick closer to the semantics and just apply alignment to
center blocks.


*shrug*  Worg has existed for years without even doing anything with
#+begin_center blocks--not even centering them.  I propose that we make
it useful and serve its natural purpose, rather than adding a special
new block that most users won't even know about (having to find it in
the voluminous Worg content isn't likely to happen for most users).


I do not see how, without documentation, one would expect that
#+begin_center can be used for highlighting and not for text alignment.
 From my point of view, it is worse than a special block - not only this
ad-hoc convention is not documented; it will also break expectations
about what #+begin_center does.


Again, this is just for Worg, and centering hasn't even had any effect 
for years.  There seem to be no expectations to break.



What about:

1. Introducing a new special block for highlighting
2. Documenting it in https://orgmode.org/worg/worg-editing.html


I think that such a new special block would likely go unused in favor of 
default blocks.  The cognitive load of learning how to contribute to 
Worg is already pretty high.  We see this same pattern in contributions 
to Emacs and Org themselves: code is often unidiomatic because it takes 
a long time to learn all the idioms, and it's often not obvious what the 
idiomatic way to do something is.  The same is true for contributions to 
documentation.  Worg is no different.


So I would still suggest that, on Worg, we use my suggested styling on 
#+begin_center blocks.  This would make them useful and fulfill their 
natural purpose.


I understand your general objection--and I wouldn't suggest it for Org's 
default export CSS--but I think that, for Worg specifically, it needn't 
apply.


Since Worg is updated with relatively low frequency, anyway, perhaps 
this suggestion could be tried as an experiment.  If problems are found 
with it, then the extra styling, beyond merely centering the text, could 
be reverted.  Nothing is permanent here; we've probably spilled more 
virtual ink on this topic than would be affected by the change.


Anyway, if this idea is vetoed, it would still be good to have some way 
to make text stand out in a standard way, similar to various HTML 
documentation styles in other projects (to avoid resorting to inline 
HTML).  It seems like a missing feature on Worg.


And the other changes in the patch would be good to have, regardless.

Thanks,
Adam

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Adam Porter]

On 3/24/24 07:35, Ihor Radchenko wrote:

+New contributors need to submit the 
[[https://orgmode.org/request-assign-future.txt][form]] to the FSF.
+#+begin_center
...
+TODO: Get updated version of form from Emacs maintainers that includes the 
line asking the secretary to send confirmation to interested parties (i.e. the 
Org maintainers).
+#+end_center


I think that we are not very accurate here.
According to
https://www.gnu.org/prep/maintain/maintain.html#Copyright-Papers:

Once the conversation is under way and the contributor is ready for more
details, you should send one of the templates that are found in the
directory /gd/gnuorg/Copyright/; they are also available from the
doc/Copyright/ directory of the gnulib project at
https://savannah.gnu.org/projects/gnulib. This section explains which
templates you should use in which circumstances. Please don’t use any of
the templates except for those listed here, and please don’t change the
wording.

We must use a specific form from a specific URL.


That isn't how the Emacs maintainers handle it.  They send a form by 
email when asked, or direct users to use the one in the Emacs git repo. 
AFAICT, they are equivalent, if not identical.


Regardless, it would be nice to have a canonical answer to this.  The 
gnu.org site says one thing, the emacs.git repo says another, 
org-mode.git says another, the people on the mailing say another, and 
Worg says another--all slightly different for no apparent reason. 
(There's also the Emacs manual, which probably mentions it too.)



Also, about the changes to the FSF form that Stefan mentioned in
https://yhetil.org/emacs-devel/jwvh6hne6nv.fsf-monnier+em...@gnu.org/
It does not look like they are official yet. See
https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00060.html


AFAICT the only change is the line that asks the FSF to send additional 
confirmation to some other interested parties.  Does that need to be 
officially official in order to use it?  The alternative is having the 
contributor ask by writing in the email message, which seems equivalent. 
 IOW, it doesn't change the form, it just adds an extra request.



+The assignment process does not always go quickly; occasionally it may
+get stuck or overlooked at the FSF.  The contact at the FSF for this
+is: =copyright-clerk AT fsf DOT org=.  In rare cases, an inquiry from an
+Org maintainer gets the process moving again.


I may be missing something, but the last sentence now reads like our
(Org maintainer's) inquiry rarely works.

The previous version is very different, IMHO:


-Emails from the paper submitter have been ignored in the past, but an
-email from the maintainers of Org mode has usually fixed such cases
-within a few days.


I would have preferred to omit all the language about the process 
sometimes not going quickly or smoothly; it doesn't seem necessary or 
helpful to publish such words, because they seem accusatory toward the 
FSF volunteers.  But in the spirit of preserving earlier contributors' 
intent rather than erasing it and just putting my own words, I left it.

Re: [Worg] CSS improvements

[Adam Porter]

On 3/24/24 03:56, Ihor Radchenko wrote:

Adam Porter  writes:


I am not sure if centered text should stand out.
AFAIU, you want to add this style for the sole purpose of highlighting


What is the purpose of centering text if not to make it stand out?


To align text. I am not sure why anything more is necessary - it
is certainly counter-intuitive for me that "center" means something more
than just alignment.


Again, what is the purpose of centering text?  The answer, "To align 
text," is tautological.


Especially, on Worg, where the whole site serves as a kind of extended 
user manual, the purpose of centering text is, what, if not to make it 
stand out?



If you need extra highlighting, we may introduce a dedicated style and
apply it via special block.


Why, when we already have #+begin_center?  Currently it's not even used 
at all.  This would not change anything that already exists; it would 
make something that already exists useful.



Mostly because it is unexpected, as I described above.
I'd prefer to stick closer to the semantics and just apply alignment to
center blocks.


*shrug*  Worg has existed for years without even doing anything with 
#+begin_center blocks--not even centering them.  I propose that we make 
it useful and serve its natural purpose, rather than adding a special 
new block that most users won't even know about (having to find it in 
the voluminous Worg content isn't likely to happen for most users).

Re: [Worg] CSS improvements

[Adam Porter]

On 3/23/24 09:49, Ihor Radchenko wrote:

Adam Porter  writes:


(@media all .org-center): Actually style this so that "#+begin_center"
blocks are centered and fit with the rest of the theme, allowing these
blocks to be used to make certain text stand out.


I am not sure if centered text should stand out.
AFAIU, you want to add this style for the sole purpose of highlighting


What is the purpose of centering text if not to make it stand out?


FYI, we usually do

: "Should I use one big Org file or many small ones?"

to make text stand out.


Yes, but that makes it source code, which makes it monospaced, which is 
not appropriate except for source code.


Besides, the .org-center class is not even styled right now, so it isn't 
even given a unique appearance on Worg right now.  So why not use it 
this way?

[Worg] CSS improvements

[Adam Porter]

Hi Bastien, et al,

Please see the attached patch which makes some minor improvements to 
Worg's CSS.  I thought I should get your approval before pushing it.


Thanks,
AdamFrom ab068940b5e63189dae3eddae84aaa2b03d6b6ef Mon Sep 17 00:00:00 2001
From: Adam Porter 
Date: Sat, 23 Mar 2024 09:31:18 -0500
Subject: [PATCH] * style/worg.css: Minor improvements

(@media all body .title): Specify font size in ems.

(@media all h1): Slightly reduce bottom margin so as not to leave a
large space between the title and subtitle.

(@media all .subtitle): Actually style this (apparently few pages use
subtitles yet).

(@media all .org-center): Actually style this so that "#+begin_center"
blocks are centered and fit with the rest of the theme, allowing these
blocks to be used to make certain text stand out.
---
 style/worg.css | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/style/worg.css b/style/worg.css
index 30cadb1b..a675ac5b 100644
--- a/style/worg.css
+++ b/style/worg.css
@@ -61,7 +61,7 @@
 
 body .title {
 	margin-left: 0px;
-	font-size: 22pt;
+	font-size: 2.5em;
 }
 
 #org-div-home-and-up{
@@ -120,7 +120,7 @@
 }
 
 h1 {
-	margin-bottom: 1.5em;
+	margin-bottom: 1em;
 	margin-right: 7%;
 }
 
@@ -315,6 +315,10 @@
 	/* font-lock-string-face */
 	color: #ccc79a;
 }
+.subtitle {
+	font-size: 1.5em;
+	font-style: italic;
+}
 .todo-comment {
 	/* todo-comment-face */
 	color: #ff;
@@ -422,6 +426,14 @@
 	/* calendar-today */
 	text-decoration: underline;
 }
+.org-center {
+	text-align: center;
+	margin-top: 1em;
+	margin-bottom: 1em;
+	background: #587e7226;
+	padding-top: 0.2em;
+	padding-bottom: 0.2em;
+}
 .org-comment {
 	/* font-lock-comment-face */
 	color: #b2;
-- 
2.30.2

[Worg] Keep table of contents visible in wide viewports?

[Adam Porter]

Hi,

Looking at Worg now, it occurred to me that, when my browser window is 
maximized, there's plenty of room for the table of contents to remain 
visible alongside the content.  But it's hidden automatically, and 
remains hidden until the user interacts with it, which seems suboptimal 
for an intra-page table of contents.


Could we modify it to keep the ToC visible when the window is wide 
enough?  I think that would be a big usability improvement.  WDYT?


--Adam

Re: Worg build status?

[Adam Porter]

Hi Bastien,

On 3/22/24 16:13, Bastien Guerry wrote:

Ihor Radchenko  writes:


This is still a problem. Likely on Sourcehut side.


Yes, I haven't received an answer from sr.ht yet, too bad.


For now, only Bastien can trigger the builds.


In the meantime, I've set up a cron job to publish Worg every 12
hours, this is not entirely satisfactory, just a bit better.


Thanks, that's a big improvement.  Happy to see the new page I added 
published so I can link to it on r/orgmode.  :)


--Adam

Worg build status?

[Adam Porter]

Hi,

A couple of days ago I pushed some updates to Worg.git, and then I saw 
that the build seems to be failing 
<https://lists.sr.ht/~bzg/org-build-failures>.  I found this message 
from January 
<https://lists.gnu.org/archive/html/emacs-orgmode/2024-01/msg00311.html> 
explaining that the builds weren't happening automatically anymore, but 
I can't tell if that's still the problem; the last build failure seems 
to have a truncated log.


What's the current status?  I was a little disappointed to see that the 
new page I'd written up isn't getting published, along with any other 
changes.


Thanks,
Adam

Re: [DISCUSSION] "quick-help" popup for org-columns (column view)

[Adam Porter]

Since transient.el is part of Emacs now, these kinds of menus should 
probably be implemented with it.

Re: [DISCUSSION] org-capture.el vs remember.el (was: [ELPA] New package: jami-bot and org-jami-bot)

[Adam Porter]

If this works (big if since given all this is vapourware), we'll
finally have found good use for indirect buffers :-)


FWIW, I use indirect buffers constantly through 
`org-tree-to-indirect-buffer', which is also called from several of my 
tools like org-ql, org-bookmark-heading, etc.  Largely, I treat my ~/org 
directory as a database, and when I open an entry from a search result 
or a bookmark in an indirect buffer, I don't even care what file/buffer 
it's actually in; the indirect buffer offers the illusion that it's in a 
file of its own, without any other content around it.

Re: Provide org-insert-subitem

[Adam Porter]

Hi Bastien, Ihor,

On 12/9/23 11:53, Bastien Guerry wrote:

Hi Adam,

Ihor Radchenko  writes:


Adam Porter  writes:


Well, it's been a few years since I forgot to bump this thread. [0]  :)
I just rediscovered it after wondering why the command
org-insert-subheading still doesn't have a default binding.  May we
revisit this?  I find myself wanting to insert a subheading almost every
day, and I have to "M-x org-insert-subheading RET".

Of course I could bind it myself, and in one of my configs I have, but I
still think it deserves a default binding, even if it were to be a
"smart" command that worked like org-table-copy-down when in a table and
does org-insert-subheading otherwise (because I still think that "S-RET"
is an obviously appropriate binding for this command).

What do you think?  =)


I think that it still makes sense, even after all these years ;)


+1!  Thanks for reviving this thread.

I would suggest a larger set of enhancements here:

- S-RET on a heading copies down the heading.

   For that we would need a new command `org-clone-subtree' bound to
   S-RET that would immediately copy the heading at point. This command
   would accept a universal argument to allow for a number a clones and
   two universal arguments for adding a time shift.

   `org-clone-subtree-with-time-shift' would continue to be bound to
   `C-c C-x c' but would be really a call to `org-clone-subtree'

- S-RET on a list item calls `org-insert-subitem`, a new command.

- C-M-RET on a heading calls `org-insert-subheading', the existing
   command.

- C-M-RET on a list item calls `org-insert-subitem', a new command.

S-RET already "copy down" a table cells, so I'm really suggesting a
generalization of the current keybinding.

I like C-M-RET better than S-RET because inserting a subheading is
like a "subkey" or inserting a heading.

These improvements seem consistent.  WDYT?


Not that I necessarily object, but that seems like a lot of new things 
to me.  The immediate, simple benefit I seek is provided by this code in 
my config now, binding it to "S-" in org-mode-map:


  (defun ap/org-shift-return ( arg)
"Call `org-insert-subheading' or `org-table-copy-down'."
(interactive "p")
(cond ((org-at-table-p)
   (org-table-copy-down arg))
  (t
   (org-insert-subheading arg

The "C-M-RET" binding doesn't feel quite right to me.  Using "shift" 
feels like a mnemonic for "sub", whereas "C-M" seems like it should do 
something much less frequently used, since it requires two modifiers.


Ihor also made some good points in his message about the combinations of 
commands to insert before/after, with/without TODO, etc, and that 
"M- " is already a quick way to insert a subheading (I wasn't 
aware of the option `org-cycle-level-after-item/entry-creation').  So 
maybe this idea of mine isn't as important as I thought.  :)


Thanks,
Adam

Re: Provide org-insert-subitem

[Adam Porter]

Hi Bastien,


I think that's a good idea to promote org-insert-subheading either by
binding it to a key or another way.

I already have some drafty code that might touch things in this (very
sensible) area, so if you don't mind, I'll come back to the details of
your suggestions when I can articulate them with the few ideas I have
in mind.  And after 9.4 is out.

But yes, there is room for enhancements here.

Don't hesitate to bump this thread in a few weeks if I don't share my
ideas since then.


Well, it's been a few years since I forgot to bump this thread. [0]  :) 
I just rediscovered it after wondering why the command 
org-insert-subheading still doesn't have a default binding.  May we 
revisit this?  I find myself wanting to insert a subheading almost every 
day, and I have to "M-x org-insert-subheading RET".


Of course I could bind it myself, and in one of my configs I have, but I 
still think it deserves a default binding, even if it were to be a 
"smart" command that worked like org-table-copy-down when in a table and 
does org-insert-subheading otherwise (because I still think that "S-RET" 
is an obviously appropriate binding for this command).


What do you think?  =)

Thanks,
Adam

0: https://yhetil.org/orgmode/875zg9trjo@bzg.fr/

[ANN] org-super-agenda v1.3 released

[Adam Porter]

Hi all,

FYI, I've released v1.3 of org-super-agenda:

https://github.com/alphapapa/org-super-agenda/releases/tag/v1.3

It should be available on MELPA soon.

Thanks,
Adam

Re: [BUG] When calling org-tree-to-indirect-buffer: (wrong-type-argument listp org-fold-outline) in org-fold-core-get-folding-spec-from-alias [9.6.6 (release_9.6.6 @ /gnu/store/c7vqk20kf6zw73klr8bacnh

[Adam Porter]

Hi Ihor,

On 8/28/23 04:24, Ihor Radchenko wrote:

Adam Porter  writes:


This is a very strange backtrace.
When I run that `alist-get' call manually, there is no error. And
`alist-get' does not call `car'.

May you try to re-generate the backtrace again?


It is indeed strange.  I generated the backtrace several times over
several sessions before reporting.  I also can reproduce it in a clean
Emacs configuration like so:


You re-define `alist-get' in one of the callers in a way that cannot
handle normal alists like (key . value), not (key . list-value).

(cl-defun burly-follow-url-org-mode ( buffer query)
   "In BUFFER, jump to heading and position from QUERY, and return a buffer.
If QUERY specifies that the buffer should be indirect, a new,
indirect buffer is returned.  Otherwise BUFFER is returned."
   ;; `pcase's map support uses `alist-get', which does not work with string 
keys
   ;; unless its TESTFN arg is bound to, e.g. `equal', but `map-elt' has 
deprecated
   ;; its TESTFN arg, and there's no way to pass it or bind it when using 
`pcase'
   ;; anyway.  So we rebind `alist-get' to a function that uses `assoc-string'.
   (with-current-buffer buffer
 (cl-letf (((symbol-function 'alist-get)
(lambda (key alist  _default _remove _testfn)
  ;; Only the first value in the list of values is returned, so 
multiple
  ;; values are not supported.  I don't expect this to be a 
problem...
  (cadr (assoc-string key alist)

Handled.
Not an Org bug.


My apologies, I overlooked that when investigating the problem.  Thanks 
for your work.


Adam

Re: [BUG] When calling org-tree-to-indirect-buffer: (wrong-type-argument listp org-fold-outline) in org-fold-core-get-folding-spec-from-alias [9.6.6 (release_9.6.6 @ /gnu/store/c7vqk20kf6zw73klr8bacnh

[Adam Porter]

Hi Ihor,

On 8/25/23 03:19, Ihor Radchenko wrote:


Debugger entered--Lisp error: (wrong-type-argument listp org-fold-outline)
   car(org-fold-outline)
   alist-get(org-fold-outline ((:alias . org-link) (org-link . org-link) 
(:alias . org-link-description) (org-link-description . org-link-description) 
(property-drawer . org-fold-drawer) (drawer . org-fold-drawer) (:alias . 
org-fold-drawer) (org-fold-drawer . org-fold-drawer) (verse-block . 
org-fold-block) (src-block . org-fold-block) (special-block . org-fold-block) 
(quote-block . org-fold-block) (export-block . org-fold-block) (example-block . 
org-fold-block) (dynamic-block . org-fold-block) (comment-block . 
org-fold-block) (center-block . org-fold-block) (block . org-fold-block) 
(:alias . org-fold-block) (org-fold-block . org-fold-block) (plain-list . 
org-fold-outline) (inlinetask . org-fold-outline) (outline . org-fold-outline) 
(heading . org-fold-outline) (headline . org-fold-outline) (:alias . 
org-fold-outline) (org-fold-outline . org-fold-outline)))
   org-fold-core-get-folding-spec-from-alias(org-fold-outline)
   org-fold-core--property-symbol-get-create(org-fold-outline)


This is a very strange backtrace.
When I run that `alist-get' call manually, there is no error. And
`alist-get' does not call `car'.

May you try to re-generate the backtrace again?


It is indeed strange.  I generated the backtrace several times over 
several sessions before reporting.  I also can reproduce it in a clean 
Emacs configuration like so:


Using with-emacs.sh on Emacs 29.1:

1.  Run "with-emacs.sh -i burly"
2.  "C-x C-f /tmp/test.org RET"
3.  Input a file like so:

  * Heading A
  ** Heading A1

4.  With point on Heading A1, "C-c C-x b".
5.  "M-x delete-other-windows RET" to show only the subtree buffer.
6.  "M-x burly-bookmark-windows RET", input name, save bookmark.
7.  Kill the file's buffer and delete-other-windows.
8.  "C-x r b" select bookmark that was created, and open it.
9.  You should get the error, and with debug-on-error, the backtrace.

This bug breaks burly's functionality to bookmark and restore subtree 
buffers, which worked fine before upgrading to Emacs 29.1.


Thanks,
Adam

[BUG] When calling org-tree-to-indirect-buffer: (wrong-type-argument listp org-fold-outline) in org-fold-core-get-folding-spec-from-alias [9.6.6 (release_9.6.6 @ /gnu/store/c7vqk20kf6zw73klr8bacnh0gqa

[Adam Porter]

Hi,

Since upgrading to Emacs 29.1 and Org 9.6.6, I am getting an error when
opening a bookmark to an Org subtree buffer created with burly.el.  When
opening the bookmark, burly calls org-tree-to-indirect-buffer to make a
new indirect buffer showing the subtree in question.  This worked fine
in Emacs 28 and the previous Org version I was using, 9.5.something,
IIRC.  Now I get this error (please see the attached backtrace, which is 
abbreviated, and some functions were re-evaluated so as to be interpreted).


FWIW, I also tried setting org-fold-core-style to overlays and
restarting Emacs, but the error still happens, although with a different
symbol in place of org-fold-outline.

Thanks for your work on Org.

AdamDebugger entered--Lisp error: (wrong-type-argument listp org-fold-outline)
  car(org-fold-outline)
  alist-get(org-fold-outline ((:alias . org-link) (org-link . org-link) (:alias 
. org-link-description) (org-link-description . org-link-description) 
(property-drawer . org-fold-drawer) (drawer . org-fold-drawer) (:alias . 
org-fold-drawer) (org-fold-drawer . org-fold-drawer) (verse-block . 
org-fold-block) (src-block . org-fold-block) (special-block . org-fold-block) 
(quote-block . org-fold-block) (export-block . org-fold-block) (example-block . 
org-fold-block) (dynamic-block . org-fold-block) (comment-block . 
org-fold-block) (center-block . org-fold-block) (block . org-fold-block) 
(:alias . org-fold-block) (org-fold-block . org-fold-block) (plain-list . 
org-fold-outline) (inlinetask . org-fold-outline) (outline . org-fold-outline) 
(heading . org-fold-outline) (headline . org-fold-outline) (:alias . 
org-fold-outline) (org-fold-outline . org-fold-outline)))
  org-fold-core-get-folding-spec-from-alias(org-fold-outline)
  org-fold-core--property-symbol-get-create(org-fold-outline)
  org-fold-core-decouple-indirect-buffer-folds()
  org-get-indirect-buffer(# #("Meetings / Sessions" 0 19 
(fontified nil line-prefix "" wrap-prefix #("* " 0 2 (face org-indent)
  #()
  apply(# nil)
  org-tree-to-indirect-buffer()
  (cond (indirect (org-tree-to-indirect-buffer)) (narrowed (progn 
(org-narrow-to-subtree) (goto-char (org-find-olp (read point-olp) 
'this-buffer)
  (progn (widen) (if heading-pos (goto-char heading-pos) (goto-char 
(string-to-number pos))) (cond (indirect (org-tree-to-indirect-buffer)) 
(narrowed (progn (org-narrow-to-subtree) (goto-char (org-find-olp (read 
point-olp) 'this-buffer) (if (and heading-pos relative-pos) (progn 
(forward-char (string-to-number relative-pos (current-buffer))
  (let* ((heading-pos (if top-olp (progn (org-find-olp (read top-olp) 
'this-buffer) (progn (widen) (if heading-pos (goto-char heading-pos) 
(goto-char (string-to-number pos))) (cond (indirect 
(org-tree-to-indirect-buffer)) (narrowed (progn (org-narrow-to-subtree) 
(goto-char (org-find-olp (read point-olp) 'this-buffer) (if (and 
heading-pos relative-pos) (progn (forward-char (string-to-number 
relative-pos (current-buffer)))
  (let ((pos x2699) (indirect x2700) (narrowed x2701) (top-olp x2702) 
(point-olp x2703) (relative-pos x2704)) (let* ((heading-pos (if top-olp (progn 
(org-find-olp (read top-olp) 'this-buffer) (progn (widen) (if heading-pos 
(goto-char heading-pos) (goto-char (string-to-number pos))) (cond (indirect 
(org-tree-to-indirect-buffer)) (narrowed (progn (org-narrow-to-subtree) 
(goto-char (org-find-olp ... ...) (if (and heading-pos relative-pos) (progn 
(forward-char (string-to-number relative-pos (current-buffer
  (let* ((x2699 (map-elt query "pos")) (x2700 (map-elt query "indirect")) 
(x2701 (map-elt query "narrowed")) (x2702 (map-elt query "top-olp")) (x2703 
(map-elt query "point-olp")) (x2704 (map-elt query "relative-pos"))) (let ((pos 
x2699) (indirect x2700) (narrowed x2701) (top-olp x2702) (point-olp x2703) 
(relative-pos x2704)) (let* ((heading-pos (if top-olp (progn (org-find-olp ... 
...) (progn (widen) (if heading-pos (goto-char heading-pos) (goto-char 
(string-to-number pos))) (cond (indirect (org-tree-to-indirect-buffer)) 
(narrowed (progn (org-narrow-to-subtree) (goto-char ... (if (and 
heading-pos relative-pos) (progn (forward-char (string-to-number 
relative-pos (current-buffer)
  (progn (ignore (mapp query)) (let* ((x2699 (map-elt query "pos")) (x2700 
(map-elt query "indirect")) (x2701 (map-elt query "narrowed")) (x2702 (map-elt 
query "top-olp")) (x2703 (map-elt query "point-olp")) (x2704 (map-elt query 
"relative-pos"))) (let ((pos x2699) (indirect x2700) (narrowed x2701) (top-olp 
x2702) (point-olp x2703) (relative-pos x2704)) (let* ((heading-pos (if top-olp 
(progn ... (progn (widen) (if heading-pos (goto-char heading-pos) 
(goto-char (string-to-number pos))) (cond (indirect 
(org-tree-to-indirect-buffer)) (narrowed (progn ... ...))) (if (and heading-pos 
relative-pos) (progn (forward-char ...))) (current-buffer))
  (progn (fset 'alist-get vnew) (progn (ignore (mapp query)) (let* ((x2699 
(map-elt 

Re: [BUG] org-set-tags-command hangs indefinitely in some indirect buffers [9.7-pre (release_9.6.6-412-g2f7b35 @ /home/adam/.emacs.d/straight/repos/org/lisp/)]

[Adam Beckmeyer]

Here's a backtrace when C-g in the middle of the hanging `org-set-tags-command`:

Debugger entered--Lisp error: (quit)
  org-element-headline-parser(990890 t)
  #f(compiled-function (limit  granularity mode structure) "Parse the 
element starting at point.\n\nReturn value is a list like (TYPE PROPS) where 
TYPE is the type\nof the element and PROPS a plist of properties associated to 
the\nelement.\n\nPossible types are defined in 
`org-element-all-elements'.\n\nLIMIT bounds the search.\n\nOptional argument 
GRANULARITY determines the depth of the\nrecursion.  Allowed values are 
`headline', `greater-element',\n`element', `object' or nil.  When it is broader 
than `object' (or\nnil), secondary values will not be parsed, since they 
only\ncontain objects.\n\nOptional argument MODE, when non-nil, can be 
either\n`first-section', `item', `node-property', 
`planning',\n`property-drawer', `section', `table-row', or 
`top-comment'.\n\n\nIf STRUCTURE isn't provided but MODE is set to `item', it 
will be\ncomputed.\n\nThis function assumes point is always at the beginning of 
the\nelement it has to parse." #)(990890 element 
nil nil)
  org-element--parse-to(990890)
  org-element-at-point(990890)
  org-element-cache-map(#f(compiled-function (el) #))
  org-get-buffer-tags()
  org-set-tags-command(nil)
  funcall-interactively(org-set-tags-command nil)
  command-execute(org-set-tags-command)

[BUG] org-set-tags-command hangs indefinitely in some indirect buffers [9.7-pre (release_9.6.6-412-g2f7b35 @ /home/adam/.emacs.d/straight/repos/org/lisp/)]

[Adam Beckmeyer]

Hi everyone,

In some of my files, org-set-tags-command hangs indefinitely when invoked in an 
indirect buffer. Attached is an example file where you can see the behavior:

1. Open this file in org-mode.
2. Invoke org-tree-to-indirect-buffer in the "Hello World" heading
3. Invoke org-set-tags-command in the new indirect buffer.

I noticed this problem on git master but bisected and found the bug was 
introduced by: 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2f7b35ac89470f17937f5c20524c38db103aaa4c

Emacs  : GNU Emacs 29.1 (build 2, x86_64-unknown-linux-gnu, X toolkit, cairo 
version 1.16.0)
 of 2023-08-02
Package: Org mode version 9.7-pre (release_9.6.6-412-g2f7b35 @ 
/home/adam/.emacs.d/straight/repos/org/lisp/)

Best


Adam Beckmeyer
*** 2021-08 August
 2021-08-23 Monday
*** Hello World   :Foobar:

Re: [BUG] org-set-tags-command hangs indefinitely in some indirect buffers

[Adam Beckmeyer]

> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=561c1d0db

Perfect. Can confirm that bug is no longer present even with my more complex 
org files.

Thanks so much!

--
Adam Beckmeyer

Re: [BUG] org-set-tags-command hangs indefinitely in some indirect buffers

[Adam Beckmeyer]

See attached.*** 2021-08 August
 2021-08-23 Monday
*** Hello World   :Foobar:

[BUG] org-set-tags-command hangs indefinitely in some indirect buffers

[Adam Beckmeyer]

Hi everyone,

In some of my files, org-set-tags-command hangs indefinitely when invoked in an 
indirect buffer. Attached is an example file where you can see the behavior:

1. Open this file in org-mode.
2. Invoke org-tree-to-indirect-buffer in the "Hello World" heading
3. Invoke org-set-tags-command in the new indirect buffer.

I noticed this problem on git master but bisected and found the bug was 
introduced by: 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2f7b35ac89470f17937f5c20524c38db103aaa4c

Here's a backtrace when C-g in the middle of the hanging `org-set-tags-command`:

Debugger entered--Lisp error: (quit)
org-element-headline-parser(990890 t)
#f(compiled-function (limit  granularity mode structure) "Parse the 
element starting at point.\n\nReturn value is a list like (TYPE PROPS) where 
TYPE is the type\nof the element and PROPS a plist of properties associated to 
the\nelement.\n\nPossible types are defined in 
`org-element-all-elements'.\n\nLIMIT bounds the search.\n\nOptional argument 
GRANULARITY determines the depth of the\nrecursion. Allowed values are 
`headline', `greater-element',\n`element', `object' or nil. When it is broader 
than `object' (or\nnil), secondary values will not be parsed, since they 
only\ncontain objects.\n\nOptional argument MODE, when non-nil, can be 
either\n`first-section', `item', `node-property', 
`planning',\n`property-drawer', `section', `table-row', or 
`top-comment'.\n\n\nIf STRUCTURE isn't provided but MODE is set to `item', it 
will be\ncomputed.\n\nThis function assumes point is always at the beginning of 
the\nelement it has to parse." #)(990890 element 
nil nil)
org-element--parse-to(990890)
org-element-at-point(990890)
org-element-cache-map(#f(compiled-function (el) #))
org-get-buffer-tags()
org-set-tags-command(nil)
funcall-interactively(org-set-tags-command nil)
command-execute(org-set-tags-command)


Emacs : GNU Emacs 29.1 (build 2, x86_64-unknown-linux-gnu, X toolkit, cairo 
version 1.16.0)
of 2023-08-02
Package: Org mode version 9.7-pre (release_9.6.6-412-g2f7b35 @ 
/home/adam/.emacs.d/straight/repos/org/lisp/)

Best


Adam Beckmeyer

Re: time-warping - retroactively marking DONE?

[Adam Spiers]

On Sun, 25 Jun 2023 at 17:03, Adam Spiers  wrote:
> Three years later, I finally tried this:

Apologies for the noise; apparently three years is enough time for me
to completely forget that I'd already found a better solution to this:

https://list.orgmode.org/caokdye-dwkh4_kw1q5bzhaig1-eyxnjnt4nw_dhhyhui12u...@mail.gmail.com/T/#me7c7a5f2d750217c47ec27c1a4ed712a62991a9d

Re: time-warping - retroactively marking DONE?

[Adam Spiers]

Three years later, I finally tried this:

On Wed, 8 Jul 2020 at 05:53, Kyle Meyer  wrote:
> Adam Spiers writes:
> > I'm looking for a way to retroactively mark a task as having been done
> > at a previous time/date.  I know that I can just change the keyword to
> > DONE and then edit the timestamp, but this is tedious when it's a
> > repeating event, e.g.:
> [...]
>
> I'm not aware of any built-in support for this.
>
> > If this is not currently possible, would it make sense to write a
> > wrapper around `org-todo', e.g. `org-todo-timewarp' or
> > `org-retroactive-todo', which interactively prompts for a timestamp
> > before invoking `org-todo'?
>
> I think this is the easiest approach, though I'm not sure such a wrapper
> needs to live in Org proper.  Here's a snippet from a recent thread [*]
> that should get you most of the way there:
>
> (defun my-org-todo-time-machine ()
>   (interactive)
>   (cl-letf (((symbol-function 'current-time)
>  (lambda ()
>(apply #'encode-time (org-parse-time-string
>  "2019-11-27 Mi 16:44")
> (call-interactively #'org-todo)))
>
>
> [*] 
> https://orgmode.org/list/875zj42rpx@passepartout.tim-landscheidt.de/T/#u

I made it read a time interactively:

(defun as-org-todo-time-machine (arg)
  (interactive "P")
  (let ((fake-time
 (apply #'encode-time (org-parse-time-string
   (org-read-date)
   
(cl-letf (((symbol-function 'current-time)
   (lambda () fake-time)))
  (call-interactively #'org-todo

It almost works perfectly, although monkey-patching current-time doesn't affect
the code in org-auto-repeat-maybe which sets LAST_REPEAT, since that uses
the built-in format-time-string:

(org-entry-put nil "LAST_REPEAT" (format-time-string
  (org-time-stamp-format t t

I found that adding (current-time) as the optional time parameter fixed it:

(org-entry-put nil "LAST_REPEAT" (format-time-string
  (org-time-stamp-format t t)
  (current-time

since that allows the monkey-patching to apply there too.  Is it worth
submitting
a patch for this?

Persisting the current working directory in an org-babel session

[Adam Sneller]

For some reason, I am unable to make changes to my working directory persist, 
from one emacs-lisp SRC block to the next.

For example, consider the following:

* Literate programming in a single session
:PROPERTIES:
:header-args: :var DIR="/Users/adam/Desktop/test"
:END:

#+BEGIN_SRC emacs-lisp :session *elisp*
(cd DIR)
#+END_SRC

#+RESULTS:
    : /Users/adam/Desktop/test/


#+BEGIN_SRC emacs-lisp :session *elisp*
(cd ".")
#+END_SRC

#+RESULTS:
    : /Users/adam/org/

The :header-args: define a starting directory (DIR="/Users/adam/Desktop/test"). 
The first block establishes the *elisp* session and navigates into DIR, using 
(cd DIR). Confirmation is then seen in the #+RESULTS. 

A second block is then created in the same *elisp* session. This simply echos 
the current working directory with (cd "."). BUT... the #+RESULTS show that the 
working directory has not persisted from our first block and has instead, 
defaulted to the default org-mode directory.

Now, I realise that I could have used :dir in my initial :header-args: to set 
the same working directory for all blocks. But what I am interested in is why 
my changes are not persisting, when (if I am not mistaken) this is the entire 
point of establishing a session?

Thanks!

Adam Sneller

Re: [PATCH] * lisp/org.el: (org-get-indirect-buffer) Allow indirect base buffers

[Adam Porter]

Hi Ihor,

On 11/5/22 03:09, Ihor Radchenko wrote:

Adam Porter  writes:


The attached patch improves the function org-get-indirect-buffer, fixing
a bug, clarifying the code, and adding a docstring.


Thanks! I have some comments.


Thanks for your review.  I've attached a new patch.


+(cl-defun org-get-indirect-buffer ( (buffer (current-buffer)) heading)
+  "Return an indirect buffer based on BUFFER.
+If HEADING, prepend it to the name of the new buffer."


Maybe append to the name?


Yes, thanks.  In the new patch I took the liberty of improving the 
format to make it more distinctive (i.e. it won't resemble a normal 
filename).



+  (let* ((base-buffer (or (buffer-base-buffer buffer) buffer))
+ (suffix-prefix (if heading
+(concat heading "-")
+  ""))


Why not pre-define the whole prefix instead?
(prefix (format "%s-%s" (buffer-name base-buffer)
 (if heading (concat heading "-") "")))

then, can just say (format "%s%s" prefix n) in the loop.


+ (buffer-name (cl-loop for n from 1 to 100


why to 100? It may fail (even though unlikely) and also unnecessary.
Can just say for n from 1.


I chose to limit the index because IME it's better to signal an error 
than to potentially go into an infinite loop.  Although it shouldn't 
happen, it could in the case of unforeseen circumstances, one of which I 
experienced while writing the patch.


But, even better, the new patch uses the built-in function 
generate-new-buffer-name, which handles it for us, and more efficiently.



+  ;; FIXME: Explain why this `condition-case' is necessary.  Why
+  ;; could an error be signaled with the CLONE argument non-nil,
+  ;; and why would trying again without CLONE solve the problem?
+  (error (make-indirect-buffer base-buffer buffer-name)


I did not find why in the git logs. It looks like some ancient code. You
can remove it in a followup patch.


Very well, the new patch omits it.

Thanks,
AdamFrom 22e7091b5d6dd8a84446b303a2706ab3d422b52f Mon Sep 17 00:00:00 2001
From: Adam Porter 
Date: Fri, 4 Nov 2022 14:52:58 -0500
Subject: [PATCH] * lisp/org.el: (org-get-indirect-buffer) Allow indirect base
 buffers

Previously, calling this function on an indirect buffer would fail,
preventing the user from making a new indirect buffer based on an
indirect buffer (e.g. imagine the user makes an indirect buffer for a
large subtree, then wants to make another one for a subtree of that).
Now, the base buffer of the buffer is used, when applicable.

Also, the function is partially rewritten to be clearer, and a
docstring is added.
---
 lisp/org.el | 35 ---
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index d8708f8f2..6c39f351f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6160,25 +6160,22 @@ frame is not changed."
 (run-hook-with-args 'org-cycle-hook 'all)
 (and (window-live-p cwin) (select-window cwin
 
-(defun org-get-indirect-buffer ( buffer heading)
-  (setq buffer (or buffer (current-buffer)))
-  (let ((n 1) (base (buffer-name buffer)) bname)
-(while (buffer-live-p
-	(get-buffer
-	 (setq bname
-		   (concat base "-"
-			   (if heading (concat heading "-" (number-to-string n))
-			 (number-to-string n))
-  (setq n (1+ n)))
-(condition-case nil
-(let ((indirect-buffer (make-indirect-buffer buffer bname 'clone)))
-  ;; Decouple folding state.  We need to do it manually since
-  ;; `make-indirect-buffer' does not run
-  ;; `clone-indirect-buffer-hook'.
-  (org-fold-core-decouple-indirect-buffer-folds)
-  ;; Return the buffer.
-  indirect-buffer)
-  (error (make-indirect-buffer buffer bname)
+(cl-defun org-get-indirect-buffer ( (buffer (current-buffer)) heading)
+  "Return an indirect buffer based on BUFFER.
+If HEADING, append it to the name of the new buffer."
+  (let* ((base-buffer (or (buffer-base-buffer buffer) buffer))
+ (buffer-name (generate-new-buffer-name
+   (format "%s%s"
+   (buffer-name base-buffer)
+   (if heading
+   (concat "::" heading)
+ ""
+ (indirect-buffer (make-indirect-buffer base-buffer buffer-name 'clone)))
+;; Decouple folding state.  We need to do it manually since
+;; `make-indirect-buffer' does not run
+;; `clone-indirect-buffer-hook'.
+(org-fold-core-decouple-indirect-buffer-folds)
+indirect-buffer))
 
 (defun org-set-frame-title (title)
   "Set the title of the current frame to the string TITLE."
-- 
2.34.0

[PATCH] * lisp/org.el: (org-get-indirect-buffer) Allow indirect base buffers

[Adam Porter]

Hi,

The attached patch improves the function org-get-indirect-buffer, fixing 
a bug, clarifying the code, and adding a docstring.


Thanks,
AdamFrom 8e70024cae3f4569d6a0c86a0e4d8079126fe9e5 Mon Sep 17 00:00:00 2001
From: Adam Porter 
Date: Fri, 4 Nov 2022 14:52:58 -0500
Subject: [PATCH] * lisp/org.el: (org-get-indirect-buffer) Allow indirect base
 buffers

Previously, calling this function on an indirect buffer would fail,
preventing the user from making a new indirect buffer based on an
indirect buffer (e.g. imagine the user makes an indirect buffer for a
large subtree, then wants to make another one for a subtree of that).
Now, the base buffer of the buffer is used, when applicable.

Also, the function is partially rewritten to be clearer, and a
docstring and a FIXME are added.
---
 lisp/org.el | 31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index d8708f8f2..3b67040f7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6160,25 +6160,32 @@ frame is not changed."
 (run-hook-with-args 'org-cycle-hook 'all)
 (and (window-live-p cwin) (select-window cwin
 
-(defun org-get-indirect-buffer ( buffer heading)
-  (setq buffer (or buffer (current-buffer)))
-  (let ((n 1) (base (buffer-name buffer)) bname)
-(while (buffer-live-p
-	(get-buffer
-	 (setq bname
-		   (concat base "-"
-			   (if heading (concat heading "-" (number-to-string n))
-			 (number-to-string n))
-  (setq n (1+ n)))
+(cl-defun org-get-indirect-buffer ( (buffer (current-buffer)) heading)
+  "Return an indirect buffer based on BUFFER.
+If HEADING, prepend it to the name of the new buffer."
+  (let* ((base-buffer (or (buffer-base-buffer buffer) buffer))
+ (suffix-prefix (if heading
+(concat heading "-")
+  ""))
+ (buffer-name (cl-loop for n from 1 to 100
+   for suffix = (format "%s%s" suffix-prefix n)
+   for name = (format "%s-%s"
+  (buffer-name base-buffer)
+  suffix)
+   while (buffer-live-p (get-buffer name))
+   finally return name)))
 (condition-case nil
-(let ((indirect-buffer (make-indirect-buffer buffer bname 'clone)))
+(let ((indirect-buffer (make-indirect-buffer base-buffer buffer-name 'clone)))
   ;; Decouple folding state.  We need to do it manually since
   ;; `make-indirect-buffer' does not run
   ;; `clone-indirect-buffer-hook'.
   (org-fold-core-decouple-indirect-buffer-folds)
   ;; Return the buffer.
   indirect-buffer)
-  (error (make-indirect-buffer buffer bname)
+  ;; FIXME: Explain why this `condition-case' is necessary.  Why
+  ;; could an error be signaled with the CLONE argument non-nil,
+  ;; and why would trying again without CLONE solve the problem?
+  (error (make-indirect-buffer base-buffer buffer-name)
 
 (defun org-set-frame-title (title)
   "Set the title of the current frame to the string TITLE."
-- 
2.34.0

[PATCH] org-imenu-get-tree: Allow parent headings to be selected themselves

[Adam Porter]

Hi,

Please see the attached patch that remedies a longstanding, simple 
shortcoming in Org's Imenu support.


Thanks,
AdamFrom 00104b2b9246b19cdb02bbce993d120581dc9f0e Mon Sep 17 00:00:00 2001
From: Adam Porter 
Date: Mon, 30 May 2022 02:59:06 -0500
Subject: [PATCH] org-imenu-get-tree: Allow parent headings to be selected
 themselves

Imenu only allows leaf nodes to be chosen.  In programming language
buffers, non-leaf nodes are "virtual" nodes, i.e. categories like
"functions" or "variables" rather than actual locations in the buffer.
But in Org buffers, non-leaf nodes are headings, which the user may
want to select with Imenu.

So now, for a non-leaf node (i.e. headings that have children), we
push an extra item to the result, without including its children, so
that it can be listed and selected in Imenu as a leaf node.
---
 lisp/org-compat.el | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index 7041976..e9c53cf 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -1053,6 +1053,11 @@ This also applied for speedbar access."
 	   (let* ((m (point-marker))
 		  (item (propertize headline 'org-imenu-marker m 'org-imenu t)))
 	 (push m org-imenu-markers)
+ (when (save-excursion (org-goto-first-child))
+   ;; Entry has children: push an extra item for entry
+   ;; itself so it can be selected (Imenu only allows
+   ;; selection of leaf nodes).
+   (push (cons item m) (aref subs level)))
 	 (if (>= level last-level)
 		 (push (cons item m) (aref subs level))
 	   (push (cons item
-- 
2.7.4

Re: [Worg] New subdirectory not fully built?

[Adam Porter]

Max Nikulin  writes:

> It seems, you have managed to solve the problem, I guess, by fixing
> link targets:
>
> https://git.sr.ht/~bzg/worg/commit/31f4212874e1bc54f335e329f6bcee83801dcf9c

I did that, but see also the following commit where I gave in and set
"broken-links:t".  There were too many internal "id:" links to convert
manually in that very old file that few will ever read, anyway.  :)

(And I thought that "id:" links worked in exported files, but apparently
not?)

Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken

[Adam Porter]

Hi Ihor,

> See the attached fix.  The fix looks reasonable, though I fail to
> understand why org-no-popup was even used in org-goto-location.  We kind
> of want a popup there.  git blame did not reveal anything useful either.
>
> Adam, can you test the fix in different scenarios first? I do not use
> org-goto interface, so I only did a light testing.

A quick test seems to indicate that it works again.  Please note that I
only recently started using org-goto myself, so I can't claim to know
all the ways in which it ought to be tested.  :)

Thanks.

Re: [BUG] Org 9.5: org-goto UI seems broken

[Adam Porter]

Max Nikulin  writes:

>> Running Org 9.5 on Emacs 28.0.60, I noticed that org-goto seems to be
>> broken:
>>
>> 1. When I press "C-c C-j", instead of displaying the indirect buffer in
>> one window and the org-goto menu in another, only the org-goto window
>> (the "*Org Help*" buffer) is displayed.
>
> Confirmed
>
> Regression is caused by

Thanks.  :)

[BUG] Org 9.5: org-goto UI seems broken

[Adam Porter]

Hi,

Running Org 9.5 on Emacs 28.0.60, I noticed that org-goto seems to be
broken:

1. When I press "C-c C-j", instead of displaying the indirect buffer in
one window and the org-goto menu in another, only the org-goto window
(the "*Org Help*" buffer) is displayed.

2. When I type a letter of a heading, instead of going to a heading
matching that character, I see "No variable specified" in the echo area.

3. When I press "C-g" to exit org-goto, the "*Org Help*" buffer doesn't
get buried, and I see "Quit" in the echo area.

4. When I then press "q", the "*Org Help*" buffer is buried and I'm
shown an "*org-goto*" buffer, which appears to be the indirect clone
that should have been shown.

5. Then when I press "C-g" again, I'm returned to the window
configuration that was shown before I called org-goto.

AFAIK, org-goto worked on Org 9.4.6 that I was using before Org 9.5 was
merged into the Emacs 28.0.x branch.

--
Thanks,
Adam

Re: org-element.el change in emacs.git

[Adam Porter]

Hi Amin,

Amin Bandali  writes:

>> By the way, I'm curious, not having always followed the internal details
>> of Org's development over the years: why are changes like that made to
>> emacs.git and merged back into Org, instead of being made in Org and
>> then merged back into Emacs with the next sync?  It seems like it could
>> be a burden, requiring someone like you to track them and merge them,
>> but there's probably a good reason for this workflow.
>>
>
> Speaking from personal experience/observations, as far as I know the
> Emacs developers don't have strict rules about having uni-directional
> changes.  And this is not unique to Org; I've seen similar changes in
> both directions in other projects developed outside emacs.git that are
> periodically merged into emacs.git.  Eliminating the need for keeping
> track of such changes is one potential argument for developing Org --
> and those other similar packages -- inside emacs.git itself. :)

That would be an interesting development, indeed.  :)  Thanks.

Re: [Worg] Proposing a few CSS changes

[Adam Porter]

Hi Timothy,

Timothy  writes:

> Great! I’ve just taken a peek and it’s a clear improvement in my eyes
> .

:)

>> Note that, after I made the other changes, the links scattered around
>> the page clashed very badly with the nice “Org green” and black theme,
>> so I adjusted them as well (as detailed in the commit message).  I tried
>> using “Org green” for the link text, but it seemed too low-contrast, as
>> well as a bit distracting while reading, so I opted to use colorize just
>> the underlines, and to make the link text green when hovering.
>
> I just had a look at this, and I tried a darkened green (#08402e). I think 
> this
> may be the best option.

That may be a good choice, yes.  But I almost feel like, with the
headers also being a very similar green, it's a bit of "green overload"
in some areas.  For example, this screenshot:


But in other places it does look nice, so I won't protest if you want to
make that change.  :)

>> Note as well that I ended up using 48em for the content width due to the
>> unicorn logo in the corner being covered up by wider content than that
>> (in a half-1080p-width browser window, which seems like an important use
>> case to consider).
>
> We should probably update the “angry unicorn” to the logo on the homepage,
> perhaps  or a 
> simplified
> version.

Well, personally, I don't mind having "the original" there.  :)  But I'll
leave that decision to you and others.

Thanks.

[Worg] New subdirectory not fully built?

[Adam Porter]

Hi,

I took the liberty of creating a new "archive" subdirectory in Worg to
preserve some obsolete content (like "Fireforg", an extension which its
Worg entry said hasn't been developed since 2009):

https://orgmode.org/worg/archive/index.html

The archive's index page is exported, but the linked "fireforg.org"
file, in the same directory, appears to not have been generated, as it
returns 404:

https://orgmode.org/worg/archive/fireforg.html

I checked other subdirectories' indexes and files, and I made the link
in the same way, so I don't know if I did something wrong, or if there's
something else going on.

Thanks,
Adam

Re: [orgweb] Making the git repo URL more visible

[Adam Porter]

Timothy  writes:

> I think a “Source Code” header could make sense, with a link to the cgit page,
> git clone line, and maybe a sentence or on Savannah for the unfamiliar. 
> Perhaps
> we could like to the org-contrib and website repos as well there?

Sounds good to me.

Re: [orgweb] Making the git repo URL more visible

[Adam Porter]

Hi Timothy,

On Fri, Oct 1, 2021 at 10:10 AM Timothy  wrote:
>
> Hi Adam,
>
> > Just now I found myself needing to look up the URL of the Org git repo,
> > and it seemed a bit harder than it ought to be.  It’d be nice if there
> > were a prominent “source code” link on the front page, but I remembered
> > that it was somewhere on the “Contribute” page, so I opened that.
>
> > When it loaded, I still overlooked the URL to the git repo.  I was
> > expecting to see some kind of “Source Code” header, or “git repo” link,
> > but instead the link is “The Org Codebase”, and it’s not under a header
> > or near any other text like “source code” or “git repo”, so it seems
> > easy to overlook:
>
> Thanks for bringing this up. I agree that it should be more prominent. My
> instinctual response is to change the text, add an icon, and bump the font 
> size
> up. Perhaps make it a /button link/ like “Tools that work with Org” on the
> homepage. I’d be tempted to put it on the homepage, but I’m also wary of
> clutter, and I’m hoping that the use of the common Git branch icon may clue 
> devs
> into thinking that the repository is linked/given on that page.
>
> Do you have any thoughts on that?

Maybe this is moot, since Bastien already added the link to the home
page, but anyway...

On the Contribute page, I'd be in favor of having some kind of
heading, like "Source Code," and listing the git URL in text for easy
copying (i.e. not hiding the URL behind a descriptive link).  It'd
also be good to have a clickable link to view the repo on Savannah.

Also, on that page, while I'm glad to have Bastien's sponsorship links
there, the "GitHub" link with the GitHub icon might be expected to be
a link to the git source code, because that's a common way to link to
a git repo on other projects' sites.  So it might be good to put them
under a heading, like "Sponsor Development".

Re: [orgweb] Making the git repo URL more visible

[Adam Porter]

Hi Bastien,

On Sat, Oct 2, 2021 at 12:03 AM Bastien  wrote:
>
> Hi Adam,
>
> Adam Porter  writes:
>
> > Other FOSS projects's sites seem to make their source code repo links
> > very prominent; could Org's web site do that too?  :)
>
> Done, let me know if it's good enough.
>
> I was missing this prominent link too!

Thanks, I think it's great having the git repo URL front-and-center on
the home page of FOSS projects.

Re: searching agenda from TRAMP

[Adam Porter]

JARZz  writes:

> Hello all, 
>
> I have a case of a somewhat irregular org mode setup. Here are the givens: 
>
> 1 I have many org files. One for each week of the year, including a
> couple of generic ones, IE journal.org, routines.org, wiki.org,
> etc. All in all it's about 120 files or so, all loaded to my
> org-agenda.

120 files is a lot, but the overhead is generally in setting up each Org
buffer, activating org-mode and calling hooks, etc.  Once a buffer is
open, searching them should be fast enough, depending on size, search
type, etc.

> 3 I need to use agenda searches with specific information, such as
> user names, machines names, program names etc. in my agenda to find
> specific cases.

You might give org-ql a try, as its searching is generally much faster,
although it won't solve any TRAMP-related problems.

> As long as I worked with my files locally, things were OK. TRAMP slows
> me down a lot, though. I know the problem is not the connection
> because scp and ssh session works like a breeze. It seems the issues
> happens with indexing the files.

> I don't know what happens behind the scenes exactly, but it takes a
> good minute or to load my agenda with all the files, and it can take
> 10-15 minutes to search through them for a specific string. This
> problem also happens when I used sshfs, which makes me believe more
> strongly the problem is, again, not with the ssh connection itself,
> but with the indexing.

There is no indexing.  :)  (org-ql does implement a per-buffer, per-query
cache for repeated queries, though.  And org-roam does offer a database
that searches some parts of Org files, although I've no idea if it's
compatible with TRAMP.)

> Is there a way to seep this up? Or perhaps a workaround you think
> might work? I want to use the GUI Emacs. What do you think? Also, what
> causes this?

As you probably know, Emacs and Org are full of configuration and
state.  I have little experience with TRAMP, but from what I do have,
I've seen that state and configuration can cause major performance
issues in unexpected ways.  So I'd suggest that you try to reproduce the
problem in a clean, or as minimal as possible, Emacs configuration.  My
with-emacs.sh script would help with that:

https://github.com/alphapapa/with-emacs.sh

If it still happens in a clean Emacs, then you should try using the
latest version of everything: Emacs, Org, and related packages.  (Again,
with-emacs.sh makes it easy to test in separate configs, and something
like Guix can help with running newer Emacs versions.)  If it doesn't
happen in a clean Emacs, then you could try using the bug-hunter package
to bisect your config.

If none of that helps, you'll probably have to dig in to the problem,
use the profiler, etc, to try to find what exactly is taking so long.
This kind of problem usually isn't easy to troubleshoot.  :(

Good luck!

Adam

Re: org-element.el change in emacs.git

[Adam Porter]

Hi Kyle,

Kyle Meyer  writes:

> Thanks for the heads up.
>
> I monitor Org-related changes to the Emacs repo and port them to Org's.
> Entering into Emacs release periods, I tend to look at least once a day
> so that porting doesn't hold up cutting a bugfix release and syncing.
> Other times, it's not as frequent, but usually not less than once a
> week. 

Well, I guess I need to follow the mailing list more closely; if I did,
I'd probably have already known that.  :)

> None of that is to say that flagging an important commit isn't
> appreciated.  Just setting expectations about what the normal intake
> looks like.

I don't know, for what we're paying you, I think something like a 1-hour
turnaround time would be more appropriate...  ;)

> (Fwiw a log of the considered commits is available at
> .)

I didn't know about that URL.  That's 8 years of faithful, thankless
maintenance.  Thanks for your work on Org.  :)

By the way, I'm curious, not having always followed the internal details
of Org's development over the years: why are changes like that made to
emacs.git and merged back into Org, instead of being made in Org and
then merged back into Emacs with the next sync?  It seems like it could
be a burden, requiring someone like you to track them and merge them,
but there's probably a good reason for this workflow.

org-element.el change in emacs.git

[Adam Porter]

Hi Bastien, et al,

I noticed this recent commit on emacs.git making a change to
org-element.el:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=58102466e32d4dd9c7d816cdc3f4595a2145f332

I don't see that change in org-mode.git, and it seems like it could be
an important one, so I wanted to make sure it doesn't go unnoticed.

-- 
Thanks,
Adam

Re: [Worg] Proposing a few CSS changes

[Adam Porter]

Hi Timothy,

Timothy  writes:

>> I find it frustrating when I’ve configured my browser to […]
>
> I think this is the source of our differences of opinion. I personally haven’t
> touched my browser’s default CSS, and am not a fan of the default styling, but
> clearly you have changed your browser’s default CSS to something that you find
> works well.
>
> This leads me to a slightly conflicted position, because I both like the idea
> that if the user has set up their browser to use a font they like, a text size
> they like etc. that sites would respect that. But I also suspect that very few
> people ever do this, and am not that happy about how things look with 
> unmodified
> browser defaults. Here I lean towards trying to ensure the best average
> experience, and unfortunately I think that means overriding the default CSS.

No, I haven't changed my browser's default CSS, only the font settings
in preferences.  These are standard features, having been present on
browsers for decades, are easily adjusted by any user, and ideally they
should take into account platform defaults as well.  These include both
font family and size.

We should keep in mind that the platforms and systems which view the
site are wide and varied.  Some users may have high-DPI monitors in dim
environments, others may have low-DPI monitors in bright environments;
some users may have perfect eyesight, while others may be legally blind.
Some users may use an OS that uses strong hinting (e.g. MS-Windows),
while others may use one that does little-to-none (e.g. MacOS).  Because
of those factors, there is no good default for us to use; what looks
good on our systems may look very poor or even unreadable to other
users.

So I think it's very important to respect the user's settings,
especially for long texts and documentation (i.e. not the "home page"
parts of Web sites whose purpose is to present projects as a whole).

Re: [BUG] 81c7a2dee8 misaligns time lines in agenda

[Adam Porter]

Hi Bastien,

On Sat, Sep 25, 2021 at 2:46 PM Bastien  wrote:

> > Since Bastien made this change, and it's very simple, I'm guessing he'll
> > know what the proper fix is.  :)
>
> The change I made was superceded by Nicolas series of patches:
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/log/?qt=grep=fix+org-duration-to-minutes+error

Oops, thanks.  I found your commit by searching the log, but I should
have checked blame on the code to see if it had been changed since
then.

> I agree the new alignment looks wrong: the starting time should
> bit right-aligned with other time above/below, and the separating
> dash should not spaces for "HH:MM" time strings on the right, but
> only for " H:MM".
>
> Would you have time to prepare a patch for this?

Unfortunately, I'm unable to reproduce it on my system, even using Org
9.4.6 in a clean Emacs config.  For some reason, it only seems to
happen on the org-super-agenda repo's GitHub Actions CI (which tests
on Emacs 26.3, 27.1, and snapshot versions).  So I'm not sure what's
going on.  :(  Hopefully Nicolas's changes solve the problem for Org
9.5 (if the problem is really one after all).

Re: [Worg] Proposing a few CSS changes

[Adam Porter]

Hi Timothy,

Timothy  writes:

> I’m a big fan of the shift to a fixed em-based max width. However, I’m not 
> quite
> sold on a few of the other changes, for instance the font change. While it 
> does
> vary, I must say than in particular I find the default serifed font of 
> browsers
> somewhat unattractive. Have you considered instead a sans-serif system font
> stack? For example, this is what I used on the homepage:
> ┌
> │ -apple-system, BlinkMacSystemFont, San Francisco, Helvetica Neue, 
> Helvetica, Ubuntu, Roboto, Noto, Segoe UI, Arial, sans-serif;
> └

I think the default serif font varies by platform, e.g. MacOS browsers
will use a much different one than Windows ones.  As well,
platform-based differences in font rendering (especially between MacOS,
Windows, and GNU/Linux) have a significant effect on the end result.

IMHO, I prefer not to "chase" issues like this by trying to account for
them in CSS.  This is why I prefer to remove font specifications for
documentation pages: let the user decide.  I find it frustrating when
I've configured my browser to use a readable font for long documents,
but the site "commandeers" the font to something that may only look nice
and readable on the author's system.

As for serif vs sans-serif, I think serif fonts are much easier to read,
and AFAIK "research" backs this up.  :)  That's not the only
consideration, of course, and I wouldn't suggest changing the main Org
site to use a serif font.  But for wiki/documentation sites, I think
serifs are a better choice.

But if we remove the font specification altogether, users who prefer
sans-serif fonts and use that setting in their browsers will see
sans-serif.  I think that, for long texts and documentation, it's
important to let the user control the appearance of main body text as
much as possible.

> Regarding the header colour, while I’m not much of a fan of the original grey,
> perhaps this would be a chance to introduce some visual ties with the rest of
> the site and the logo, for example by setting the heading colour to `#587e72' 
> (the
> dark gree from the Org logo).

I think that'd be nice, yes.

> I also tend to find the default font size slightly to small on most browsers.
> I’d be in favour of bumping up the base fontsize to `1.2rem' and changing the
> width restriction from `60em' to `60rem' so it remains constant.

I'll push back on this change strongly.  :)  I really hate it when sites
increase the default font size for body text.  I've configured my
browsers to use the font size that's most readable and useful for me.
There seems to be an "epidemic" of sites increasing the default font
size nowadays; sometimes only one or two paragraphs are visible on a
single screen of text.  Again, I think this is an attribute we should
leave entirely to the users to configure.

> Lastly, on padding, I feel you may have been a bit over-zealous in your 
> removal
> of padding from headlines. IMO a bit more space helps visually separate 
> sections
> and let them “breath”, and browsers defaults tend to pack things a bit more
> densely than I would.

I could live with adding a little bit of padding back, but not too
much.  There's already way too much whitespace on the Web.  ;)

If you like, I'll prepare a new "patch" and post screenshots so we can
try to reach consensus.

-- 
Thanks,
Adam

Re: [Worg] Proposing a few CSS changes

[Adam Porter]

Bastien  writes:

> Hi Adam,
>
> Adam Porter  writes:
>
>> If these are agreeable, I can apply them to the Worg repo.
>
> Sure, please go ahead!  Thanks,

Hi Bastien,

Thanks.  Since Timothy has some thoughts on these changes, I'll wait
until we come to a consensus on them.  :)

Re: [ANN] org-ql 0.6 released

[Adam Porter]

Juan Manuel Macías  writes:

> Hi Adam,
>
> Thank you very much for this great package. I could no longer live without
> org-ql/helm-org-ql :-)

Hi Juan,

Thanks for the kind words.  I'm glad it's useful to you.  :)

[ANN] org-ql 0.6 released

[Adam Porter]

Hi friends,

FYI, I just released version 0.6 of org-ql.  Please see the changelog
here:

https://github.com/alphapapa/org-ql#06

-- 
Thanks,
Adam

Re: Heading toward Org 9.5

[Adam Porter]

Bastien  writes:

> I'll work on integrating small bug fixes and feature improvements
> listed on https://updates.orgmode.org during this week, aiming at
> releasing Org 9.5 over the next week-end.
>
> If your patch does not appear on updates.orgmode.org and didn't 
> receive an answer on the list, please send me an email pointing at
> the reference on orgmode.org/list.

Hi Bastien,

Back in July I mentioned a bug I found:

https://lists.gnu.org/archive/html/emacs-orgmode/2021-07/msg00603.html

If this could be addressed for Org 9.5, I would be grateful.  As it is,
it makes it difficult to keep my org-super-agenda tests working cleanly
on Org versions both before and after 9.4.6.

--
Thanks,
Adam

[BUG] 81c7a2dee8 misaligns time lines in agenda

[Adam Porter]

Hi,

In the course of working on a PR for org-super-agenda [0], we found that
a recent change to Org, commit 81c7a2dee8 [1], causes a misalignment in
the way time lines in the agenda are displayed.  The org-super-agenda
test suite shows this change when results from Org 9.4 and 9.4.6 are
compared.  For example, in this diff of an agenda buffer:

#+BEGIN_EXAMPLE diff
 @@ -2,8 +2,8 @@
 Wednesday   5 July 2017
 
  Today
-  test:7:02.. Sunrise (12:04 of daylight)
-   8:00.. 
+  test:   7:02..  Sunrise (12:04 of daylight)
+  8:00..  
   10:00.. 
   12:00.. now - - - - - - - - - - - - - - - - - - - - - - - - -
   12:00.. 
#+END_EXAMPLE

The old lines, with single-digit hours, were properly aligned with the
lines with multi-digit hours, but the new lines are one character too
far to the left.

Since Bastien made this change, and it's very simple, I'm guessing he'll
know what the proper fix is.  :)

Thanks,
Adam

0: https://github.com/alphapapa/org-super-agenda/pull/167
1: 
https://code.orgmode.org/bzg/org-mode/commit/81c7a2dee8e6d0c5e58d0cb4ca97cfc9477ff660

Re: [PATCH] org-agenda.el: Add a M-, binding for org-priority-show

[Adam Spiers]

On Sat, 1 May 2021 at 11:45, Bastien  wrote:
> Kyle Meyer  writes:
> > With a C-u, org-agenda-priority calls org-priority-show.  So perhaps
> > instead of adding a new binding, the documentation should be improved.
>
> I pushed a small enhancement for org-agenda-priority's docstring
> with commit e080eb759.
>
> I am reluctant adding another keybinding to the agenda especially
> since there is no keybinding for `org-priority-show'.

Thanks, that sounds like a better approach.

Re: Can no longer org-set-link-parameters with "fuzzy" link types

[Adam Sneller]

Thank you both for the replies!

Nicholas - can you recommend how to best implement this with 
font-lock-add-keywords?

Best regards,

-Adam

> On 6 Apr 2021, at 13:06, Nicolas Goaziou  wrote:
>
> Hello,
>
> Kyle Meyer  writes:
>
>> [ Sorry for the slow response. ]
>>
>> Adam Sneller writes:
>>
>>> I have a function that searches for broken fuzzy links in org-mode and
>>> applies org-warning face to anything it finds:
>>>
>>> (org-link-set-parameters
>>> "fuzzy"
>>> :face (lambda (path)
>>> (let ((org-link-search-inhibit-query t))
>>> (if (condition-case nil
>>> (save-excursion
>>> (save-match-data
>>> (org-link-search path (point) t)))
>>> (error nil))
>>> 'org-link 'org-warning
>>>
>>> In 9.4.4 this patch breaks this:
>>>
>>> https://code.orgmode.org/bzg/org-mode/commit/8c4e270df280a08b7e61295712c86246088146ba
>>>
>>> Is there some other recommended way to get this done as of 9.4.4?
>>
>> I don't know enough about the change to say whether this is recommended,
>> but it looks like you could get the behavior you're after with something
>> like
>>
>>  (add-to-list 'org-link-parameters
>>   '("fuzzy" :face (lambda (path) ...)))
>
> Link parameters are meant to be used with "scheme:path" links. However,
> we forbid internal link types, as writing [[fuzzy:whatever]] would be
> confusing for Org. As a consequence, link parameters are not meant to
> control internal links.
>
> We might need a different variable specific to internal links, but in
> the current case, using `font-lock-add-keywords' should be sufficient.
>
> Regards,
> --
> Nicolas Goaziou

Re: overloading of internal priority calculations in agenda

[Adam Spiers]

Thanks Jack for the helpful response and support of my assessment.

I do intend to fix this as part of my ongoing (but currently delayed)
work on improving agenda sorting and adding an option to manually sort.

On Tue, 9 Mar 2021 at 07:07, Jack Kamm  wrote:
>
> Hi Adam,
>
> > I further noticed that this overloading of the internal priority by
> > including timestamp and habit data causes disruption to the behaviour
> > I imagine most users would expect from `org-agenda-sorting-strategy'.
> > For example, if you have `priority-down' as the first entry in the
> > `agenda' section and `category-keep' as the second, then differences
> > in the SCHEDULED timestamp are included in the priority calculation
> > and can therefore prevent sorting of two adjacent [#B] items by
> > category.  This seems like a bug to me, or at least breaks the
> > Principle of Least Surprise.
>
> I just ran into this issue you highlight here.
>
> In particular, I was trying to set the org-agenda-sorting-strategy to
>
> (priority-down scheduled-down)
>
> i.e., sorting by priority (highest first), and then within priority,
> sorting by scheduled (most recent first).
>
> However, the fact that the priority includes the scheduled timestamp
> makes this sorting strategy impossible.
>
> I agree this seems like a bug, in that it contradicts the written
> documentation as far as I can tell (for example, the *Help* for
> org-agenda-sorting-strategy mentions nothing of the fact that the
> priority includes the scheduled timestamp, and I don't see anything
> about it in the *Info* either).
>
> I imagine that many have gotten used to the default behavior of sort by
> highest priority, then by earliest scheduled timestamp, but we could
> keep this default behavior by adding "scheduled-up" after
> "priority-down" in org-agenda-sorting-strategy, as you allude.
>
> Jack

Can no longer org-set-link-parameters with "fuzzy" link types

[Adam Sneller]

I have a function that searches for broken fuzzy links in org-mode and applies 
org-warning face to anything it finds:

(org-link-set-parameters
"fuzzy"
:face (lambda (path)
(let ((org-link-search-inhibit-query t))
(if (condition-case nil
(save-excursion
(save-match-data
(org-link-search path (point) t)))
(error nil))
'org-link 'org-warning

In 9.4.4 this patch breaks this:

https://code.orgmode.org/bzg/org-mode/commit/8c4e270df280a08b7e61295712c86246088146ba

Is there some other recommended way to get this done as of 9.4.4?

Thanks,

Adam Sneller – CCO
MS2 Digital
20 Old Bailey, St Paul's, ​London EC4M 7AN
​adam.sneller@ms2.digital
office: 020 3988 6800
direct: 020 3988 6809
The information in this e-mail and any documents and files transmitted with it 
are confidential and for the use of the intended recipient only. If you are not 
the intended recipient, please delete the message and any attachments 
immediately and notify the sender. Although MS2 Group Limited believes this 
e-mail and any attachments are free of any virus or other defect which may 
affect a computer, it is the responsibility of the recipient to ensure that it 
is virus free and MS2 Group Limited does not accept any responsibility for any 
loss or damage arising from its use. MS2 Group Limited is registered in England 
and Wales, company number 10410414. Registered office: 27 Old Gloucester 
Street, London WC1N 3AX. 'MS2 Digital' is the trading name of MS2 Group Limited.
​
​© 2020 MS2 Group Limited

Re: Citations with page numbers using helm-bibtex and org-ref

[Adam Sneller]

Thanks John!

I think you have just given me my next homework assignment for "Adam's list of 
things to noodle around with in eLisp" :)

Adam

> On 21 Feb 2021, at 17:40, John Kitchin  wrote:
>
> It seems like some ideas are getting mixed up in your description. A cite 
> link in org-ref is related to a bibtex entry in a bibtex file, not to an org 
> heading in an org-file. In other words in your example, I would expecta 
> bibtex entry with the key bradley1973es to exist in one of the default 
> bibliography files you use (or in the one you define in a bibliography link). 
> The notes are just for your purposes.
>
> the headings/links in your notes file will not show up in any completion 
> backend in org-ref for citation selection, as only the bibtex entries are 
> used to construct those.
>
>  If you are looking for a way to select one of those headings from your 
> notes, and then insert the appropriate link, you would have to use something 
> different than org-ref. there is not presently a way to map an annotated cite 
> link to the specific note. I am not even sure you can write a function that 
> does that, as the functions only take a key for looking up the note file, and 
> not the description too. It certainly is possible to write a new function 
> that would work on the link at point to do that, and to call it 
> interactively, or add it as an action though. You would still get the key to 
> open the note file, and then use the link description if it exists to somehow 
> search forward for the relevant heading or text, failing gracefully if you, 
> for example, make a cite to a page you did not make a note on.
>
> When it comes time to authoring a paper, I think the workflow is you would 
> have to open the notes you made, find the section you want to use in your 
> paper, and copy the link you put in your notes to your new document. There 
> are some variations you might consider, but none of them would really be 
> integrated into the org-ref completion mechanisms that are generated from the 
> bibtex entries.
>
> For example you  might store the link or parts in a property like this:
>
> * The Accelerator-Multiplier Model
>   :PROPERTIES:
>   :key:  bradley1973es
>   :page: p200
>   :cite: [[cite:bradley1973es][p200]]
>   :END:
>
>
> and then write a small function you use interactively to copy it, e.g.
>
> #+BEGIN_SRC emacs-lisp
> (defun get-link ()
>   (interactive)
>   (kill-new (org-entry-get (point) "cite")))
> #+END_SRC
>
> and you might bind that to a key if you use it a lot. Alternatively you might 
> put the key in file-level property, and only store the page, and use property 
> inheritance, to build the link. There are a lot of options to choose from. 
> But, simply copying and pasting a link might also be the simplest.
>
> It might be possible to use the org-store/insert-link machinery for this too, 
> but I have found that to be trickier than I thought it should be in the past.
>
> John
>
> ---
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu <http://kitchingroup.cheme.cmu.edu/>
>
>
>
> On Sun, Feb 21, 2021 at 12:13 PM Adam Sneller  <mailto:a...@earth2adam.com>> wrote:
> Hi Bruce/John,
>
> Thanks for getting back to me. So I guess your notes file would look 
> something like this?
>
>
> #+TITLE: Bradley, J. (1973): Essential Mathematics For Economists
>
> * Dynamic models: the consumption function
> [[cite:bradley1973es][p164]]
>
> * Changes in Capital Stock
> [[cite:bradley1973es][p188]]
>
> * The Accelerator-Multiplier Model
> [[cite:bradley1973es][p200]]
>
>
> So when when it comes time to author your paper, if you run org-store-link on 
> any of these, the description gets stripped off the link, so that only 
> cite:bradley1973es is stored (which obviously defeats the purpose). And if 
> you copy the link over by hand, it maps back to the document bradley197es.org 
> <http://bradley197es.org/> (not the actual note).
>
> Am I missing anything?
>
> Adam
>
>> On 21 Feb 2021, at 12:21, Bruce D'Arcus > <mailto:bdar...@gmail.com>> wrote:
>>
>> On Sat, Feb 20, 2021 at 10:31 PM Adam Sneller > <mailto:adam.sneller@ms2.digital>> wrote:
>>
>>> I currently use org-ref and helm-bibtex to manage my database of academic 
>>> sources, with one notes file per source. A lot of my sources are books. So 
>>> note typically grow over time, as I add multiple headers (each pertaining 
>

Re: Citations with page numbers using helm-bibtex and org-ref

[Adam Sneller]

Hi Bruce/John,

Thanks for getting back to me. So I guess your notes file would look something 
like this?


#+TITLE: Bradley, J. (1973): Essential Mathematics For Economists

* Dynamic models: the consumption function
[[cite:bradley1973es][p164]]

* Changes in Capital Stock
[[cite:bradley1973es][p188]]

* The Accelerator-Multiplier Model
[[cite:bradley1973es][p200]]


So when when it comes time to author your paper, if you run org-store-link on 
any of these, the description gets stripped off the link, so that only 
cite:bradley1973es is stored (which obviously defeats the purpose). And if you 
copy the link over by hand, it maps back to the document bradley197es.org 
<http://bradley197es.org/> (not the actual note).

Am I missing anything?

Adam

> On 21 Feb 2021, at 12:21, Bruce D'Arcus  wrote:
>
> On Sat, Feb 20, 2021 at 10:31 PM Adam Sneller  
> wrote:
>
>> I currently use org-ref and helm-bibtex to manage my database of academic 
>> sources, with one notes file per source. A lot of my sources are books. So 
>> note typically grow over time, as I add multiple headers (each pertaining to 
>> a chapter or topic/note taken from that source).
>>
>> But now I want to produce a citation that references the page numbers where 
>> I captured that note...
>>
>> What is the recommended way to handle this? Are you breaking notes into 
>> individual files, each with their own @inbook citation?
>
> Generally speaking, referencing page numbers and sections of a cited
> source is not handled by dedicated citations, but rather by
> annotations on the containing citation (book etc.).
>
> So in the pandoc syntax, for example, [@book, p23].
>
> I do the same with notes, and just included the specific citation with
> the note if I need to maintain the specific source page.
>
> Bruce
>

Citations with page numbers using helm-bibtex and org-ref

[Adam Sneller]

I currently use org-ref and helm-bibtex to manage my database of academic 
sources, with one notes file per source. A lot of my sources are books. So note 
typically grow over time, as I add multiple headers (each pertaining to a 
chapter or topic/note taken from that source).

But now I want to produce a citation that references the page numbers where I 
captured that note...

What is the recommended way to handle this? Are you breaking notes into 
individual files, each with their own @inbook citation? And suppose you are 
capturing a section (not necessarily a chapter title). Are you still using 
@inbook?

Thanks!

Adam Sneller – CCO
MS2 Digital
20 Old Bailey, St Paul's, ​London EC4M 7AN
​adam.sneller@ms2.digital
office: 020 3988 6800
direct: 020 3988 6809
The information in this e-mail and any documents and files transmitted with it 
are confidential and for the use of the intended recipient only. If you are not 
the intended recipient, please delete the message and any attachments 
immediately and notify the sender. Although MS2 Group Limited believes this 
e-mail and any attachments are free of any virus or other defect which may 
affect a computer, it is the responsibility of the recipient to ensure that it 
is virus free and MS2 Group Limited does not accept any responsibility for any 
loss or damage arising from its use. MS2 Group Limited is registered in England 
and Wales, company number 10410414. Registered office: 27 Old Gloucester 
Street, London WC1N 3AX. 'MS2 Digital' is the trading name of MS2 Group Limited.
​
​© 2020 MS2 Group Limited

Re: Auto-activate new <<>>

[Adam Sneller]

Thanks John! It looks like there is also an org-activate-target-links which may 
narrow the field a bit. Here is what I have so far:

(defadvice org-activate-target-links (after ad-update-target-links ())
  "Activate radio target links as soon as a new target is created."
  (lambda ()
(interactive)
(when (and (org-in-regexp org-target-regexp)
   (not (org-in-regexp org-target-regexp nil t)))
  (org-update-radio-target-regexp
(ad-activate 'org-activate-target-links)

Unfortunately, this is not working for me...

Any ideas?

> On 8 Feb 2021, at 13:44, John Kitchin  wrote:
>
> I guess the place to do it is with an advice on org-activate-links. Maybe a 
> simple after advice would do.
>
> John
>
> ---
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu <http://kitchingroup.cheme.cmu.edu/>
>
>
>
> On Sun, Feb 7, 2021 at 8:48 PM Kyle Meyer  <mailto:k...@kyleam.com>> wrote:
> Adam Sneller writes:
>
> > I want to call org-update-radio-target-regexp as soon as org-mode
> > recognises a new <<>> has been created (which seems to
> > happen as soon as the third ">" is typed).
> >
> > What hook can I use to get this done?
>
> I'm not spotting any hook that could be used for this.  The <<>>
> fontification happens through a simple 'regular expression => face'
> mapping in org-font-lock-keywords.
>
> You're probably aware of this and it's just not as automatic as you'd
> like, but just in case: pressing `C-c C-c' with point on <<>
> will call org-update-radio-target-regexp.
>

Auto-activate new <<>>

[Adam Sneller]

I want to call org-update-radio-target-regexp as soon as org-mode recognises a 
new <<>> has been created (which seems to happen as soon as the 
third ">" is typed).

What hook can I use to get this done?

Adam Sneller – CCO
MS2 Digital
20 Old Bailey, St Paul's, ​London EC4M 7AN
​adam.sneller@ms2.digital
office: 020 3988 6800
direct: 020 3988 6809
The information in this e-mail and any documents and files transmitted with it 
are confidential and for the use of the intended recipient only. If you are not 
the intended recipient, please delete the message and any attachments 
immediately and notify the sender. Although MS2 Group Limited believes this 
e-mail and any attachments are free of any virus or other defect which may 
affect a computer, it is the responsibility of the recipient to ensure that it 
is virus free and MS2 Group Limited does not accept any responsibility for any 
loss or damage arising from its use. MS2 Group Limited is registered in England 
and Wales, company number 10410414. Registered office: 27 Old Gloucester 
Street, London WC1N 3AX. 'MS2 Digital' is the trading name of MS2 Group Limited.
​
​© 2020 MS2 Group Limited

Re: overloading of internal priority calculations in agenda

[Adam Spiers]

Thanks a lot - appreciate the feedback!

On Tue, 22 Dec 2020 at 23:38, Samuel Wales  wrote:

> if my opinion is worth anything [perhaps not much here :]], i like
> your proposals and the idea of being able to re-sort an existing
> agenda assuming that is your goal.
>
> i don't use any priority sorting except in user-customizable but it
> makes sense to decouple them for those who do.  and i frequently want
> to differently sort an existing agenda view.
>
>
> On 12/22/20, Adam Spiers  wrote:
> > Hi again,
> >
> > On Wed, Dec 02, 2020 at 02:20:53PM +, Adam Spiers wrote:
> >>Hi all,
> >>
> >>I'm currently working on adding a feature to org-agenda which allows
> >>manual ordering of entries in combination with the existing automatic
> >>ordering (as dictated by `org-agenda-sorting-strategy').
> >>
> >>During my investigations I noticed that while `org-get-priority' converts
> >>[#B] style cookies into a numeric priority which is a multiple of
> >>1000, further adjustments are made in functions like
> >>`org-agenda-get-scheduled' before adding this numeric priority as a
> >>text property on the entry:
> >>
> >>'priority (if habitp (org-habit-get-priority habitp)
> >>(+ 99 diff (org-get-priority item)))
> >>
> >>In this case `diff' refers to the number of days between now and when
> >>the item was scheduled.  A slightly different calculation is made in
> >>`org-agenda-get-timestamps':
> >>
> >>(org-add-props item props
> >>  'priority (if habit?
> >>(org-habit-get-priority (org-habit-parse-todo))
> >>  (org-get-priority item))
> >>
> >>I further noticed that this overloading of the internal priority by
> >>including timestamp and habit data causes disruption to the behaviour
> >>I imagine most users would expect from `org-agenda-sorting-strategy'.
> >>For example, if you have `priority-down' as the first entry in the
> >>`agenda' section and `category-keep' as the second, then differences
> >>in the SCHEDULED timestamp are included in the priority calculation
> >>and can therefore prevent sorting of two adjacent [#B] items by
> >>category.  This seems like a bug to me, or at least breaks the
> >>Principle of Least Surprise.
> >
> > [snipped]
> >
> >>Given that `org-agenda-sorting-strategy' now supports all manner of
> >>sorting criteria, many of which are time-sensitive, I would like to
> >>know if there is any reason not to remove this overloading of the
> >>priority calculation, i.e. decoupling it to depend purely on the
> >>result of `org-get-priority' and `org-habit-get-priority'?
> >>
> >>If fact, perhaps we could go one step further and add support for new
> >>habit-priority-{up,down} sorters to `org-agenda-sorting-strategy', so
> >>that the priority-{up,down} sorters sort purely by the priority cookie
> >>and nothing else?
> >
> > Gently bumping this as I didn't get any replies yet.  I would like to
> > continue working on a solution, but obviously don't want to waste time
> > on something which would be rejected.
> >
> > If it is considered important to preserve the exact behaviour
> > currently offered by `org-agenda-sorting-strategy' then I would
> > propose the following:
> >
> > - Keep the existing priority-{up,down} which combine priority cookies
> >with timestamp data and the result from `org-habit-get-priority',
> >but probably also deprecate it and remove it from the default value.
> >
> > - Introduce new priority-cookie-{up,down} sorters which operate purely
> >on [#A] and [#1] style priority cookies and nothing else.
> >
> > This would facilitate decoupling of the sortable criteria whilst
> > remaining backwards compatible.
> >
> > Does this sound reasonable?  I am keen to proceed very soon (ideally
> > over the Xmas break).  I have already written some new ert tests for
> > `org-agenda-sorting-strategy' which would be included in any submitted
> > patches.
> >
> > Thanks!
> > Adam
> >
> >
>
>
> --
> The Kafka Pandemic
>
> Please learn what misopathy is.
>
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>

Re: overloading of internal priority calculations in agenda

[Adam Spiers]

Hi again,

On Wed, Dec 02, 2020 at 02:20:53PM +, Adam Spiers wrote: 

Hi all,

I'm currently working on adding a feature to org-agenda which allows 
manual ordering of entries in combination with the existing automatic 
ordering (as dictated by `org-agenda-sorting-strategy'). 

During my investigations I noticed that while `org-get-priority' converts 
[#B] style cookies into a numeric priority which is a multiple of 
1000, further adjustments are made in functions like 
`org-agenda-get-scheduled' before adding this numeric priority as a 
text property on the entry: 


   'priority (if habitp (org-habit-get-priority habitp)
   (+ 99 diff (org-get-priority item)))

In this case `diff' refers to the number of days between now and when 
the item was scheduled.  A slightly different calculation is made in 
`org-agenda-get-timestamps': 


   (org-add-props item props
 'priority (if habit?
   (org-habit-get-priority (org-habit-parse-todo))
 (org-get-priority item))

I further noticed that this overloading of the internal priority by 
including timestamp and habit data causes disruption to the behaviour 
I imagine most users would expect from `org-agenda-sorting-strategy'. 
For example, if you have `priority-down' as the first entry in the 
`agenda' section and `category-keep' as the second, then differences 
in the SCHEDULED timestamp are included in the priority calculation 
and can therefore prevent sorting of two adjacent [#B] items by 
category.  This seems like a bug to me, or at least breaks the 
Principle of Least Surprise. 


[snipped]

Given that `org-agenda-sorting-strategy' now supports all manner of 
sorting criteria, many of which are time-sensitive, I would like to 
know if there is any reason not to remove this overloading of the 
priority calculation, i.e. decoupling it to depend purely on the 
result of `org-get-priority' and `org-habit-get-priority'? 

If fact, perhaps we could go one step further and add support for new 
habit-priority-{up,down} sorters to `org-agenda-sorting-strategy', so 
that the priority-{up,down} sorters sort purely by the priority cookie 
and nothing else? 


Gently bumping this as I didn't get any replies yet.  I would like to 
continue working on a solution, but obviously don't want to waste time 
on something which would be rejected. 

If it is considered important to preserve the exact behaviour 
currently offered by `org-agenda-sorting-strategy' then I would 
propose the following: 


- Keep the existing priority-{up,down} which combine priority cookies
  with timestamp data and the result from `org-habit-get-priority',
  but probably also deprecate it and remove it from the default value.

- Introduce new priority-cookie-{up,down} sorters which operate purely
  on [#A] and [#1] style priority cookies and nothing else.

This would facilitate decoupling of the sortable criteria whilst 
remaining backwards compatible. 

Does this sound reasonable?  I am keen to proceed very soon (ideally 
over the Xmas break).  I have already written some new ert tests for 
`org-agenda-sorting-strategy' which would be included in any submitted 
patches. 


Thanks!
Adam

overloading of internal priority calculations in agenda

[Adam Spiers]

Hi all,

I'm currently working on adding a feature to org-agenda which allows
manual ordering of entries in combination with the existing automatic
ordering (as dictated by `org-agenda-sorting-strategy').

During my investigations I noticed that while `org-get-priority' converts
[#B] style cookies into a numeric priority which is a multiple of
1000, further adjustments are made in functions like
`org-agenda-get-scheduled' before adding this numeric priority as a
text property on the entry:

'priority (if habitp (org-habit-get-priority habitp)
(+ 99 diff (org-get-priority item)))

In this case `diff' refers to the number of days between now and when
the item was scheduled.  A slightly different calculation is made in
`org-agenda-get-timestamps':

(org-add-props item props
  'priority (if habit?
(org-habit-get-priority (org-habit-parse-todo))
  (org-get-priority item))

I further noticed that this overloading of the internal priority by
including timestamp and habit data causes disruption to the behaviour
I imagine most users would expect from `org-agenda-sorting-strategy'.
For example, if you have `priority-down' as the first entry in the
`agenda' section and `category-keep' as the second, then differences
in the SCHEDULED timestamp are included in the priority calculation
and can therefore prevent sorting of two adjacent [#B] items by
category.  This seems like a bug to me, or at least breaks the
Principle of Least Surprise.

I did some git archaelogy and found that the first ever git commit
4be4c562 (for release 4.12a) already includes
`org-agenda-sorting-strategy', but at that point, time-{up,down} were
the only time-related sorting criteria available.

I was also wondering where the magic 99 number above came from, and I
found that the same (first ever) commit introduced the following
priority calculation:

(+ (- 5 diff) (org-get-priority txt))

Subsequently, commit 70b6cc5d (for release 5.10a) changes this to:

(+ 94 (- 5 diff) (org-get-priority txt))

and then commit 69ec6258 (on 2016-11-25) changes it to

(+ 99 diff (org-get-priority item))

Given that `org-agenda-sorting-strategy' now supports all manner of
sorting criteria, many of which are time-sensitive, I would like to
know if there is any reason not to remove this overloading of the
priority calculation, i.e. decoupling it to depend purely on the
result of `org-get-priority' and `org-habit-get-priority'?

If fact, perhaps we could go one step further and add support for new
habit-priority-{up,down} sorters to `org-agenda-sorting-strategy', so
that the priority-{up,down} sorters sort purely by the priority cookie
and nothing else?

Thanks!
Adam

[PATCH] org-agenda.el: Add a M-, binding for org-priority-show

[Adam Spiers]

This offers an easy way to check the internal numeric priority
used for sorting within the agenda.
---
 doc/org-manual.org | 8 
 lisp/org-agenda.el | 1 +
 2 files changed, 9 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 5a84a6de6..e914af42d 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -9891,6 +9891,14 @@ the other commands, point needs to be in the desired 
line.
   Set tags for the current headline.  If there is an active region in
   the agenda, change a tag for all headings in the region.
 
+- {{{kbd(M-\,)}}} (~org-priority-show~) ::
+
+  #+kindex: M-,
+  #+findex: org-priority-show
+  Show the numeric priority for the current item.  This priority is
+  composed of the main priority given with the =[#A]= cookies, and by
+  additional input from the age of a schedules or deadline entry.
+
 - {{{kbd(\,)}}} (~org-agenda-priority~) ::
 
   #+kindex: ,
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index a482b3db4..40ea31fdc 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -2399,6 +2399,7 @@ (defun org-agenda-mode ()
 (org-defkey org-agenda-mode-map "\C-c\C-p" #'org-agenda-previous-date-line)
 (org-defkey org-agenda-mode-map "\C-c," #'org-agenda-priority)
 (org-defkey org-agenda-mode-map "," #'org-agenda-priority)
+(org-defkey org-agenda-mode-map [(meta ?,)] #'org-priority-show)
 (org-defkey org-agenda-mode-map "i" #'org-agenda-diary-entry)
 (org-defkey org-agenda-mode-map "c" #'org-agenda-goto-calendar)
 (org-defkey org-agenda-mode-map "C" #'org-agenda-convert-date)
-- 
2.28.0

Re: [ANN] org-ql 0.5 released

[Adam Porter]

Hi Jean Louis,

Thanks for your feedback.

>As the more complexities are created then even org-ql becomes complex
>to work with just as SQL becomes more and more complex with more
>relational tables and pieces of information.

The idea of Org QL is to make such things simple.  For example, you
don't need to know Elisp to run "M-x org-ql-search RET" and type this
query:

  todo: priority:A deadline:to=3

Which would display all to-do items with priority A due within the next
3 days.

> For org-ql I hope that your system can be used as underlying layer or
> low level language for functionality that may help user to think their
> stuff without thinking on underlying functionality. You have offered
> examples and those are in my opinion too abstract for Org users. They
> are fine for programmers or more skilled users.

The org-ql-search and org-ql-view UIs are built on the underlying org-ql
library.

> High level functions would be something like a wizard with code
> generation, that creates hyperlink for the user without user having to
> think about org-ql

> It could be something like `ql-meta' or `ql-summary' that is created
> on the fly and that collects information for agenda like view, and
> creates Org file with hyperlink that invokes the agenda like view.

This is already implemented.  Search views can be built incrementally
using the Transient UI.  See the screencast GIFs in the readme.

> Entries from the past week could be something on the fly. Additional
> hyperlink in the ql-summary could have the user to customize sorting
> without thinking of the underlying code.

See "M-x org-ql-view-recent-items RET".

> Find entries matching a certain CUSTOM_ID could be automatically
> generated heading:
>
> *** Entries by CUSTOM_ID
>
> ONE TWO THREE MORE HYPERLINKED AND SORTED CUSTOM_IDS
>
> when user clicks on any of those this would invoke the org-ql and show
> those entries. By click and by thinking, not necessarily by
> constructing the org-ql.
>
> Similar could be for deadlines.

This is already implemented.  See the sections "Links" and "Dynamic
Blocks" in the readme.

> Music could be sorted by author in the summary Org file that has many
> hyperlinks which in turn use the org-ql to activate music, or annotate
> it.

Those are interesting ideas for future work, thanks.

> Your file `examples.org' has some hyperlinks under the heading
> Contents and none of hyperlinks work. Why is it so?

I went to https://github.com/alphapapa/org-ql/blob/master/examples.org
and clicked the links in "Contents" and they work for me.

> In the end I could not test examples as it asks for org-ql-search that
> in turn asks for super-agenda that I do not have.
>
> I wonder how could I install the package that requires
> org-super-agenda and that it starts working. Maybe you missed one
> (require 'org-super-agenda) as when I wish to install it, it does not.

If you install org-ql from MELPA or with Quelpa, org-super-agenda will
be installed automatically.  The `require' function does not install
packages.

Thanks,
Adam

[ANN] Org QL Custom Predicates Tutorial

[Adam Porter]

Hi again friends,

Following the release of org-ql 0.5, I've pushed a new feature to the
0.6-pre branch: custom predicates.  You can now easily define custom
predicates to make searching easier.  For example, you could define a
custom (person) predicate like so:

#+BEGIN_SRC elisp
(org-ql-defpred person (name)
  "Search for entries with the \"person\" property being NAME."
  :body (property "person" name))
#+END_SRC

Then you could do a search for entries in your agenda files having the
property "person" with the value "Bob" like this:

#+BEGIN_SRC elisp
(org-ql-search (org-agenda-files) "person:Bob")
#+END_SRC

Please see the tutorial for a walkthrough of the process of building a
custom predicate incrementally:

https://github.com/alphapapa/org-ql/blob/master/examples/defpred.org

Thanks,
Adam

[ANN] org-ql 0.5 released

[Adam Porter]

Hi friends,

FYI, I've released org-ql 0.5.  It includes many improvements since the
last release, including some unique features, such as linking to and
bookmarking agenda-like views for easy access, and designing agenda-like
views incrementally with a Magit-like UI.

Changelog: https://github.com/alphapapa/org-ql#05

Please let me know if you have any feedback.

Thanks,
Adam

[ANN] org-super-agenda 1.2 released

[Adam Porter]

Hi friends,

FYI, I've released version 1.2 of org-super-agenda, which includes
several improvements since the last stable release.

https://github.com/alphapapa/org-super-agenda#changelog

Please let me know if you have any feedback.

Thanks,
Adam

[ANN] org-ql: Bookmarks, dynamic blocks, and links

[Adam Porter]

Hi all,

FYI, I've recently added some new features to org-ql[0]:

1.  Dynamic Blocks[1] allow you to insert a block that lists headings in
a document which match a query, formatting them into certain columns.
For example (please excuse the wrapped header line for this message):

#+BEGIN: org-ql :query "todo: priority:A,B" \
:columns (todo (priority "P") deadline heading) \
:sort (deadline priority) :take 7 :ts-format "%Y-%m-%d %H:%M"
| Todo | P | Deadline | Heading   |
|--+---+--+---|
| TODO | A | 2017-07-07 00:00 | Take over the world   |
| TODO | B | 2017-07-10 00:00 | Renew membership in supervillain club |
| TODO | A | 2017-07-15 00:00 | Take over the universe|
| TODO | B | 2017-07-21 00:00 | Internet  |
| TODO | A | 2017-08-01 00:00 | Spaceship lease   |
| TODO | A |  | Skype with president of Antarctica|
| TODO | B |  | Take over Mars|
#+END:

2. Links[2] allow you to access an Org QL View by clicking on a link,
like:

[[org-ql-search:todo:NEXT priority:A]]

It integrates with the Org link storing and inserting commands (`C-c l`
and `C-c C-l`), so you can easily create a custom search view and insert
a link to it into an Org file.  Then you can click the link to run the
search.

3.  Bookmarks allow Org QL View buffers to be bookmarked with Emacs
bookmark commands, like "C-x r m".  This also integrates with my new
buffer/window/frame/workspace-restoration package, Burly.[3]

Together, these features allow agenda-like views and searches to be
easily and quickly designed, saved, and accessed.

Please let me know if you have any feedback.

Thanks,
Adam

0: https://github.com/alphapapa/org-ql
1: https://github.com/alphapapa/org-ql#dynamic-block
2: https://github.com/alphapapa/org-ql#links
3: https://github.com/alphapapa/burly.el

Re: [PATCH] org-refile.el: Add org-refile-reverse which toggles org-reverse-note-order

[Adam Spiers]

On Sun, Sep 06, 2020 at 02:10:09AM -0400, Amin Bandali wrote:

Bastien writes:


Hi Adam,

Adam Spiers  writes:


This is useful for prepending to the start of the target headline
instead of appending to the end, or vice-versa depending on
org-reverse-note-order.


I think this would be useful.  What others think?


[...]

+1; sounds quite useful to me as well.

Thank you both.


Is it time to revisit this yet?

Thanks!

[PATCH] x11idle: Make installation a little smoother

[Adam Spiers]

Fix a -Wimplicit-int compiler warning, and make it more obvious how to
obtain scrnsaver.h on three of the most popular Linux distros.

Signed-off-by: Adam Spiers 
---
 contrib/scripts/x11idle.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/contrib/scripts/x11idle.c b/contrib/scripts/x11idle.c
index 22cefe1e6..b8db27560 100644
--- a/contrib/scripts/x11idle.c
+++ b/contrib/scripts/x11idle.c
@@ -1,4 +1,9 @@
+/* This header file is provided by the libxss-dev package on Debian,
+ * by the libXss-devel rpm on openSUSE, and the libXScrnSaver-devel
+ * rpm on Fedora.
+ */
 #include 
+
 #include 
 
 /* Based on code from
@@ -7,7 +12,7 @@
  * compile with 'gcc -l Xss x11idle.c -o x11idle' and copy x11idle into your
  * path
  */
-main() {
+int main() {
 XScreenSaverInfo *info = XScreenSaverAllocInfo();
 //open the display specified by the DISPLAY environment variable
 Display *display = XOpenDisplay(0);
-- 
2.28.0

Re: [PATCH] [WIP] org-agenda.el: Make org-entries-lessp more efficient

[Adam Spiers]

On Sat, Oct 24, 2020 at 01:36:05PM +0200, Bastien wrote: 
Hi Adam, 

this looks good to me, thanks a lot. 


Thanks for the review :-) 

Does "WIP" means that you want to wait for other patches to complete 
this one or shall I apply this one already? 


The intention is for it to be a standalone patch, so I don't think 
there's any need to wait for other patches.  The "WIP" was coming more 
from the fact that I haven't done extensive testing to make sure I 
didn't break a single one of the many sorting criteria - especially 
this one:


+('category-keep   (if (org-cmp-category a b) +1 nil)) ;; FIXME: check this

Ideally there would already be unit and/or functional tests covering 
agenda sorting, but I can't see any and I imagine they would be 
non-trivial to add (although perhaps not too difficult either). 

Also, the previous behaviour was to silently ignore 
user-defined-{up,down} if org-agenda-cmp-user-defined was not defined, 
but that intuitively felt wrong to me (IMHO it kind of violates the 
Principle of Least Surprise) so I didn't bother to preserve that 
behaviour.  However I admit that is a pretty subjective choice, so if 
you think the existing behaviour should be preserved, I can tweak the 
code to do that.  In fact, even if you agree with me that it would be 
better to generate an error when user-defined-{up,down} is used with 
org-agenda-cmp-user-defined being nil, I just noticed that it currently 
generates the very unhelpful error: 


org-entries-cmp-1: Symbol’s function definition is void: nil

so we would want to explicitly catch that case and generate a more 
helpful error message, e.g. "org-agenda-sorting-strategy contains 
user-defined sorting but org-agenda-cmp-user-defined is nil". 

BTW, as you can partially see from the below link, I did some 
performance profiling relating to this change and it did indeed seem 
to shave a few milliseconds off org-entries-lessp, although in the 
grand scheme of things, that didn't make as much of a dent in 
org-agenda's running time as I'd hoped for ;-) 



https://gist.github.com/trishume/40bf7045a23412d4c016f5e8533437db#gistcomment-3494087

[PATCH] [WIP] org-agenda.el: Make org-entries-lessp more efficient

[Adam Spiers]

[This is only lightly tested and therefore probably not quite ready
for merging yet; however I'm submitting now to get feedback.]

org-entries-lessp was not as efficient a multi-criteria comparator as
it could have been, since it evaluated all criteria and then combined
them via (eval (cons 'or ...)), thereby missing a chance for lazy
evaluation via short-circuiting: if one of the earlier criteria in
org-agenda-sorting-strategy-selected evaluates to non-nil, giving a
definitive comparison result, there is no need to evaluate any of the
later criteria.

So instead iterate over the criteria one by one, and return as soon as
we have a definitive result.

Also remove code duplication by adopting a unified approach to
ascending/descending sorting.

Note that the way org-entries-lessp is invoked by
org-agenda-finalize-entries is still inefficient, because the same
values (e.g. timestamps, priorities, etc.) are extracted from every
pair of entries in each comparison within the sort.  In the future,
introducing a Schwartzian transform can probably address this.

However the refactoring in this commit is a step in the right
direction, and it also allows other code to determine which comparison
is decisive in ordering any two elements.

Signed-off-by: Adam Spiers 
---
 lisp/org-agenda.el | 103 -
 1 file changed, 46 insertions(+), 57 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 88bb3f90d..eadc7fedd 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -7187,65 +7187,54 @@ (defsubst org-cmp-habit-p (a b)
 (cond ((and ha (not hb)) -1)
  ((and (not ha) hb) +1
 
+(defun org-entries-cmp (a b)
+  "Iterate through the sorting criteria in
+`org-agenda-sorting-strategy-selected' until a sorter returns a
+definitive comparison, then return a cons cell (RESULT . SORTER)."
+  (let (sorted-by
+   sort-result
+   (ss org-agenda-sorting-strategy-selected))
+(while (and ss (not sorted-by))
+  (let* ((sorter (car ss))
+(sorter-name (symbol-name sorter))
+;; If sorter symbol ends in "-down" then pass the -up version
+;; to org-entries-cmp-1 and then negate the result.
+(sorter-down-p (string-match "-down\\'" sorter-name))
+(up-sorter
+ (if sorter-down-p
+ (replace-regexp-in-string "-down\\'" "-up" sorter-name)
+   sorter-name)))
+   (setq sort-result (org-entries-cmp-1 a b (intern up-sorter)))
+   (setq ss (cdr ss))
+   (when sort-result
+ (setq sort-result (if sorter-down-p (- sort-result) sort-result))
+ (setq sorted-by sorter
+(cons sort-result sorted-by)))
+
+(defun org-entries-cmp-1 (a b sorter)
+  "Compare two entries via the given sorter."
+  (pcase sorter
+('timestamp-up(org-cmp-ts a b ""))
+('scheduled-up(org-cmp-ts a b "scheduled"))
+('deadline-up (org-cmp-ts a b "deadline"))
+('tsia-up (org-cmp-ts a b "timestamp_ia"))
+('ts-up   (org-cmp-ts a b "timestamp"))
+('time-up (org-cmp-time a b))
+('stats-up(org-cmp-values a b 'org-stats))
+('priority-up (org-cmp-values a b 'priority))
+('effort-up   (org-cmp-effort a b))
+('category-up (org-cmp-category a b))
+('category-keep   (if (org-cmp-category a b) +1 nil)) ;; FIXME: check this
+('tag-up  (org-cmp-tag a b))
+('todo-state-up   (org-cmp-todo-state a b))
+('habit-up(org-cmp-habit-p a b))
+('alpha-up(org-cmp-alpha a b))
+('user-defined-up (funcall org-agenda-cmp-user-defined a b
+
 (defun org-entries-lessp (a b)
   "Predicate for sorting agenda entries."
-  ;; The following variables will be used when the form is evaluated.
-  ;; So even though the compiler complains, keep them.
-  (let* ((ss org-agenda-sorting-strategy-selected)
-(timestamp-up(and (org-em 'timestamp-up 'timestamp-down ss)
-  (org-cmp-ts a b "")))
-(timestamp-down  (if timestamp-up (- timestamp-up) nil))
-(scheduled-up(and (org-em 'scheduled-up 'scheduled-down ss)
-  (org-cmp-ts a b "scheduled")))
-(scheduled-down  (if scheduled-up (- scheduled-up) nil))
-(deadline-up (and (org-em 'deadline-up 'deadline-down ss)
-  (org-cmp-ts a b "deadline")))
-(deadline-down   (if deadline-up (- deadline-up) nil))
-(tsia-up (and (org-em 'tsia-up 'tsia-down ss)
-  (org-cmp-ts a b "timestamp_ia")))
-(tsia-down   (if tsia-up (- tsia-up) nil))
-(ts-up   (and (org-em 'ts-up 'ts-down ss)
-  (org-cmp-ts a b "timestamp")))
-(ts-dow

[PATCH] org-agenda.el: Fix 'Maker' typo

[Adam Spiers]

TINYCHANGE

Signed-off-by: Adam Spiers 
---
 lisp/org-agenda.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index a1b20649d..88bb3f90d 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4127,7 +4127,7 @@ (defvar org-agenda-last-marker-time (float-time)
 
 (defun org-agenda-new-marker ( pos)
   "Return a new agenda marker.
-Maker is at point, or at POS if non-nil.  Org mode keeps a list of
+Marker is at point, or at POS if non-nil.  Org mode keeps a list of
 these markers and resets them when they are no longer in use."
   (let ((m (copy-marker (or pos (point)) t)))
 (setq org-agenda-last-marker-time (float-time))
-- 
2.28.0

Re: variable-pitch-mode misaligns org-mode heading tags

[Adam Spiers]

On Wed, Sep 16, 2020 at 11:55:53PM +0100, Adam Spiers wrote: 
I've actually managed it get it working now!  See the attached patch. 
However unfortunately it is not ready to be merged yet.  Firstly, it 
breaks `test-org/tag-align'.  Secondly, since this changes the method 
of alignment from simply using raw spaces to using a single space with 
a display text property, when the file is saved and reloaded, it just 
displays a single space and the alignment is lost.  Another 
unfortunate side-effect is that if the file is simultaneously 
displayed in a graphical window and a text window via the same emacs 
server (e.g. via emacsclient -t), then one of the two windows will 
have incorrect alignment. 

So I think the correct fix will be to keep the original number of 
spaces, but use a display text property to redisplay those spaces as a 
single space with the given width.  I'm guessing that the display text 
property will be ignored on text-only (tty) windows, fixing both 
problems in one go. 

So I'll take another stab at this soon, if Bastien or some other Org 
guru can confirm I'm on the right track. 


Hrm, no this isn't good enough.  For graphical windows we still need 
to set the display text properties to align all tags when the buffer 
initially loads.  AFAICS there's currently no code to trigger this, so 
it would need to be added, and for large files this might actually 
cause problems with file loading time unless it was done in the 
background (a bit like fontification can be done). 

Advice on how to handle this best is very welcome. 

Re: Help administer code.orgmode.org: moderate user access and manage the gogs instance

[Adam Spiers]

On Wed, 16 Sep 2020 at 08:21, Bastien  wrote:
> Hi Timothy,
>
> TEC  writes:
>
> >> Is anyone willing to help with (1) and/or (2)?
> >
> > I'm willing to give (2), and potentially (1) a shot :)
>
> Thanks a lot!  I wrote you offlist about this.

It's not nearly as generous an offer, but as I don't have a gogs
account yet, I volunteer to be a guinea pig if TEC wants to practice
giving (1) a shot ;-)

I think I used to have push access to Worg many years ago, and I've
noticed one or two issues which I'd be happy to fix if I regained
that.  Or is Worg also subject to a peer review process these days?

Cheers,
Adam

Re: variable-pitch-mode misaligns org-mode heading tags

[Adam Spiers]

On Wed, Sep 16, 2020 at 03:03:02PM -0400, Jeff Filipovits wrote: 
It looks like (window-text-pixel-size) could be used to calculate the 
pixel length of the tags list? 


Ahah!  This indeed did the trick!  I have no idea how I missed this 
handy function previously when I was scouring the manual... 

I am having trouble deciphering the 
manual (https://www.gnu.org/software/emacs/manual/html_node/elisp/Pixel-Specification.html#Pixel-Specification) 
for pixel specification for spaces, though. The right alignment 
specification for some reason sends the tags to the next line, as do 
most other solutions that I would expect to align the text to the 
right side of the window. 

I can experiment more in a couple days, but in the meantime maybe 
someone smarter than me give some hints on how to use the pixel 
specification properties. 


I've actually managed it get it working now!  See the attached patch. 
However unfortunately it is not ready to be merged yet.  Firstly, it 
breaks `test-org/tag-align'.  Secondly, since this changes the method 
of alignment from simply using raw spaces to using a single space with 
a display text property, when the file is saved and reloaded, it just 
displays a single space and the alignment is lost.  Another unfortunate 
side-effect is that if the file is simultaneously displayed in a graphical 
window and a text window via the same emacs server (e.g. via emacsclient -t), 
then one of the two windows will have incorrect alignment. 

So I think the correct fix will be to keep the original number of 
spaces, but use a display text property to redisplay those spaces as a 
single space with the given width.  I'm guessing that the display text 
property will be ignored on text-only (tty) windows, fixing both 
problems in one go. 

So I'll take another stab at this soon, if Bastien or some other Org 
guru can confirm I'm on the right track. 

BTW I tried your code and for some reason it didn't insert any space 
for me, but I didn't look into that yet. 


The way it’s written it would only reduce the gap between the headline 
and tags to a space, and it assumes there are multiple spaces there 
already. If there’s no space between the two, I don’t think it’ll 
insert one. Probably not the best way as it was thrown together to 
test the text property fix. 


I figured out that it wasn't working because my `org-tags-column' is a 
negative value in order to align flush-right, and your code didn't 
support that. 

I accepted long ago that the solution to using a variable pitch font 
for org headings was that the tags would not be aligned to the right 
and never looked back, so maybe this is not worth the price of fixing 
it if it is messy. And diving down to calculating the pixel width of 
text seems like it’s getting pretty messy. 


Actually I think it ended up fairly clean.  Huge thanks to you for 
giving me the hint I needed!  I just adapted your code a bit.  I've 
marked you as a co-author in the commit message.  For now your 
contribution probably still falls into the category of "Tiny changes": 


https://orgmode.org/worg/org-contribute.html#org9fbb342

However you might want to preemptively sign the copyright assignment 
papers: 


https://orgmode.org/worg/org-contribute.html#copyrighted-contributors
>From 7655c32847d7abd9da7603b1a1a314b7d1b87ba5 Mon Sep 17 00:00:00 2001
From: Adam Spiers 
Date: Wed, 16 Sep 2020 23:12:04 +0100
Subject: [PATCH] [WIP] org.el: Align tags using specified space display property
To: emacs-orgmode@gnu.org

Previously tags on heading lines were aligned using spaces, which
assumed a fixed width font.  However variable pitch fonts are becoming
increasingly popular, so ensure there is always a single space in
between the heading text and the (colon-delimited) list of tags, and
then if necessary use a display text property to specify the exact
width required by that space to align it in accordance with the value
of `org-tags-column' which the user has chosen:

  https://www.gnu.org/software/emacs/manual/html_node/elisp/Pixel-Specification.html#Pixel-Specification

If the value is positive, align flush-left; if negative, align
flush-right; and if zero, just leave a normal width space.

See the following links for the discussion threads leading to this
patch:

- https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/msg00415.html
- https://gitlab.com/protesilaos/modus-themes/-/issues/85

Signed-off-by: Adam Spiers 
Co-authored-by: Jeff Filipovits 
---
 lisp/org.el | 68 ++---
 1 file changed, 39 insertions(+), 29 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 053635c85..e800eb642 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11831,35 +11831,45 @@ (defun org-toggle-tag (tag  onoff)
   res)))
 
 (defun org--align-tags-here (to-col)
-  "Align tags on the current headline to TO-COL.
-Assume point is on a headline.  Preserve point when aligning
-tags."
-  (when (org-mat

Re: variable-pitch-mode misaligns org-mode heading tags

[Adam Spiers]

Hi Jeff,

Firstly thanks a lot for looking into this! 


On Tue, Sep 15, 2020 at 01:41:04PM -0400, Jeff Filipovits wrote:
Following the call for help to fix bugs, and with building guilt, I’ve 
taken a stab at fixing aligning tags when using a variable-pitch font. 
I haven’t tested this much because I do not know if it is misguided, 
but it seems to work. 

Seems the only way to do it is to use the ‘display text property and 
expand a single space between the headline and tags. Here is a drop-in 
replacement of org--align-tags-here which ensures there is one space 
between the tags and headline, and then expands that space by setting 
a text property. 


Yes, this is the same conclusion I reached a little while ago: 


   https://gitlab.com/protesilaos/modus-themes/-/issues/85#note_407147422

However as mentioned there, AFAICS this approach only manages to 
*left*-align the tags, not *right*-align them.  When there are several 
tags, this can be problematic as the colon-delimited list of tags will 
either spill over the buffer's right margin, or avoid that by 
requiring an alignment column which is further to the left and ends up 
interfering with the main text of the buffer.  Given that the 
colon-delimited lists have variable numbers of characters, I think 
it's clear that right alignment is the only decent space-efficient 
layout.


BTW I tried your code and for some reason it didn't insert any space for 
me, but I didn't look into that yet. 

I’ve removed the point-preserving code because it does not seem to be 
needed using this method. This would also allow removing 
org-fix-tags-on-the-fly from org-self-insert-command since there is 
only a single space between the headline and the tags and it is 
adjusted automatically. 


Makes sense. 

If this looks promising I can throw some more time at it. If not, I 
will happily abandon it. 


I think it's promising for sure.  But I think there is still a 
remaining problem regarding how to implement the right alignment of 
the colon-delimited list of tags.  If this list uses a fixed-width 
font then it is relatively easy, because then the value to provide to 
:align-to can be calculated as `org-tags-column' minus the column 
width of the tag list.  And indeed this seems to be how the original 
version of `org--align-tags-here' achieves right alignment: 


   (new (max (if (>= to-col 0) to-col
   (- (abs to-col) (string-width (match-string 1

But the whole point of this exercise is to support variable-width 
fonts.  In this case, the correct position for the end of the single 
space is most likely not even a multiple of the fixed column width, so 
it would probably need to be measured in pixels rather than columns. 
And in order to calculate it, it is first necessary to calculate the 
exact width in pixels of the colon-delimited list of tags. 

As I mentioned in the comment linked above, I searched for a way of 
calculating the pixel width of the tag list, and the best I could find 
was `pos-visible-in-window-p' which has some issues which I mentioned 
there.  If you have thoughts on whether I'm right about those, and if 
so how to solve them, I'd love to hear! 


Cheers,
Adam

Re: [feature request] org-at-timestamp-p should accept multiple parameters

[Adam Faryna]

Thanks. I understand now.

I think to generate a patch in this case it's too much hustle, for a minor
benefit.

--
Adam

On Wed, 9 Sep 2020 at 09:13, Bastien  wrote:

> Hi Adam,
>
> Adam Faryna  writes:
>
> > Ok, maybe I misunderstood the purpose of this function. I wanted to
> > use it to check if the timestamp is active or inactive and I tried to
> > get it by using (org-at-timestamp-p 'inactive) while pointing at the
> > timestamp. But actually when I call it on any timestamp like
> > [2020-09-04 Fri], <2020-09-04 Fri> I always get nil. So either it's a
> > bug, or I miss something.
>
> (org-at-timestamp-p) returns t on an active timestamp.
>
> (org-at-timestamp-p 'inactive) returns t on any timestamp, including
> inactive ones.
>
> If you think the docstring could be enhanced, can you share a patch?
>
> See https://orgmode.org/worg/org-contribute.html on how to contribute.
>
> Thanks,
>
> --
>  Bastien
>

Re: [feature request] org-at-timestamp-p should accept multiple parameters

[Adam Faryna]

Ok, maybe I misunderstood the purpose of this function. I wanted to use it
to check if the timestamp is active or inactive and I tried to get it by
using (org-at-timestamp-p 'inactive) while pointing at the timestamp. But
actually when I call it on any timestamp like [2020-09-04 Fri], <2020-09-04
Fri> I always get nil. So either it's a bug, or I miss something.

Thanks,

Adam

On Tue, 8 Sep 2020 at 15:26, Bastien  wrote:

> Hi Adam,
>
> thanks, but I still need to understand the exact change you suggest
> and what general fix/improvement it will provide.  Probably a patch
> will be easier to understand for this.
>
> Thanks,
>
> --
>  Bastien
>

Re: [feature request] org-at-timestamp-p should accept multiple parameters

[Adam Faryna]

I think the problem is general. If you work with any timestamp that is
agenda like, you can't check using this function if it's active or
inactive. The one solution would be to remove parameter "agenda" and
consider every timestamp as a agenda like (the "timestamp" in "
org-at-timestamp-p" suggest that there is time information in it anyway) by
default, or keep it as it is but extend parameter list with support of
named parameters where agenda-like can be activated with :agenda t,
inactive timestamp with :inactive t, with default values nil.

Thanks,
Adam

On Sat, 5 Sep 2020 at 13:59, Bastien  wrote:

> Hi Adam,
>
> you forgot to copy the emacs-orgmode list - can you repost your email
> there?
>
> Thanks,
>
> --
>  Bastien
>

Re: make org-refile auto-recache when needed?

[Adam Spiers]

Hi Bastien,

On Fri, Sep 04, 2020 at 04:12:08PM +0200, Bastien wrote:

Adam Spiers  writes:

I note that when org-refile-use-cache is enabled and the cache becomes
stale, attempting to refile results in this error message (originating
from `org-refile-check-position'):

Invalid refile position, please clear the cache with `C-0 C-c C-w' before 
refiling

Is there any reason why it couldn't just automatically rebuild the
cache when needed?


If we can rebuild the cache for refile target in a reliable way, sure,
we should do this.  I had a quick look and this isn't straightforward,
so help is welcome.  I note the idea for after 9.4.


Thanks for the reply!

I don't see why we need to be able to rebuild it reliably.  Can't we
just try, then if it succeeds, refile as normal, and if it fails, then
output an error saying that the cache rebuild failed and making a
helpful suggestion of what to try next?  Maybe I'm missing something.

Re: [PATCH] doc: Document C-. for jumping to today when choosing a timestamp

[Adam Spiers]

On Fri, Sep 04, 2020 at 03:47:08PM +0200, Bastien wrote:

Hi Adam,

Adam Spiers  writes:


This useful key binding was previously missing from the manual.


Thanks for spotting this.  I added it (as 2df7a8fa) together with
the `.'  keybinding, which achieves the same.


Thanks Bastien.  There's actually a subtle but important difference
between the two: when editing a timestamp with a time of day in, e.g.

<2020-08-27 Thu 17:00>

then the prompt in the minibuffer will be:

SCHEDULED Date+time [2020-08-27]: 17:00

While the point is after the "17:00", pressing '.' does not cause a
jump to today's date; instead it just appends the '.' character after
the "17:00".  In contrast, C-. successfully jumps to today without
altering the prompt input.  So in this context, C-. is far more useful
than just '.'.

Funnily enough I found that if I first jump to the beginning of
"17:00" via C-a, then they do indeed behave identically.

Re: time-warping - retroactively marking DONE?

[Adam Spiers]

On Wed, 8 Jul 2020 at 23:09, No Wayman  wrote:
> I emailed Adam directly with an experimental package I wrote to
> solve the problem of changing the todo-state of an entry at an
> arbitrary time.
> He suggested I posted here as well:
>
> https://github.com/progfolio/epoch/
>
> The package advises current-time to return `epoch-current-time' if
> is set (falling back to the usual current-time if not).
> A macro, `epoch-with-time' is provided which allows a body to be
> executed with current-time set to an arbitrary time.
> Two commands (which I may separate into their own package),
> `epoch-todo' and `epoch-agenda-todo' call their respective
> org-mode commands.
> `org-read-date' is called with the tasks's SCHEDULED or DEADLINE
> time pre-populated so one can easily edit relative to that time.
>
> Still very much a work in progress, but the two commands are
> useful for me so far.
>
> Any ideas, suggestions, criticisms are appreciated.

Many thanks again for this.  It's working great for me!

In case anyone's interested, here's my use-package config (which uses
the awesome straight.el package manager to install it):

https://github.com/aspiers/emacs/blob/aa62bd84b51a02cb0fc980862a63514349d253bf/.emacs.d/init.d/as-org-mode.el#L111-L116

I agree with your observation that it might be nicer to separate out
the org-specific stuff into a separate package, because the epoch
stuff seems useful in its own right outside org-mode.

[PATCH] org-refile.el: Add org-refile-reverse which toggles org-reverse-note-order

[Adam Spiers]

This is useful for prepending to the start of the target headline
instead of appending to the end, or vice-versa depending on
org-reverse-note-order.
---
 doc/org-manual.org | 10 ++
 etc/ORG-NEWS   |  9 +
 lisp/org-keys.el   |  1 +
 lisp/org-refile.el | 11 +++
 4 files changed, 31 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 3eb745b5d..e499367b7 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -7190,6 +7190,16 @@ special command:
   Copying works like refiling, except that the original note is not
   deleted.
 
+- {{{kbd(C-c C-M-w)}}} (~org-refile-reverse~) ::
+
+  #+kindex: C-c C-M-w
+  #+findex: org-refile-reverse
+  Works like refiling, except that it temporarily toggles how the
+  value of ~org-reverse-note-order~ applies to the current buffer.  So
+  if ~org-refile~ would append the entry as the last entry under the
+  target header, ~org-refile-reverse~ will prepend it as the first
+  entry, and vice-versa.
+
 ** Archiving
 :PROPERTIES:
 :DESCRIPTION: What to do with finished products.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 10658a970..a3c8397fc 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -267,6 +267,15 @@ Source code block header argument =:file-mode= can set file
 permissions if =:file= argument is provided.
 
 ** New commands
+*** ~org-refile-reverse~
+
+Use default keybinding == to run command
+~org-refile-reverse~.  It is almost identical to ~org-refile~, except
+that it temporarily toggles how ~org-reverse-note-order~ applies to
+the current buffer.  So if ~org-refile~ would append the entry as the
+last entry under the target heading, ~org-refile-reverse~ will prepend
+it as the first entry, and vice-versa.
+
 *** ~org-table-header-line-mode~
 
 Turn on a minor mode to display the first data row of the table at
diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 37df29983..902651175 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -582,6 +582,7 @@ (define-key org-mode-map (kbd "") #'org-shifttab)
 (org-defkey org-mode-map (kbd "C-c ;") #'org-toggle-comment)
 (org-defkey org-mode-map (kbd "C-c C-w") #'org-refile)
 (org-defkey org-mode-map (kbd "C-c M-w") #'org-refile-copy)
+(org-defkey org-mode-map (kbd "C-c C-M-w") #'org-refile-reverse)
 (org-defkey org-mode-map (kbd "C-c /") #'org-sparse-tree) ;minor-mode reserved
 (org-defkey org-mode-map (kbd "C-c \\") #'org-match-sparse-tree) ;minor-mode r.
 (org-defkey org-mode-map (kbd "C-c RET") #'org-ctrl-c-ret)
diff --git a/lisp/org-refile.el b/lisp/org-refile.el
index 7eb0a9643..c6ff35535 100644
--- a/lisp/org-refile.el
+++ b/lisp/org-refile.el
@@ -384,6 +384,17 @@ (defun org-refile-copy ()
 
 (defvar org-capture-last-stored-marker)
 
+;;;###autoload
+(defun org-refile-reverse ( arg default-buffer rfloc msg)
+  "Invoke `org-refile', but temporarily toggling how
+~org-reverse-note-order~ applies to the current buffer.  So if
+`org-refile' would append the entry as the last entry under the
+target heading, ~org-refile-reverse~ will prepend it as the first
+entry, and vice-versa."
+  (interactive "P")
+  (let ((org-reverse-note-order (not (org-notes-order-reversed-p
+(org-refile arg default-buffer rfloc msg)))
+
 ;;;###autoload
 (defun org-refile ( arg default-buffer rfloc msg)
   "Move the entry or entries at point to another heading.
-- 
2.27.0

[PATCH] doc: Document C-. for jumping to today when choosing a timestamp

[Adam Spiers]

This useful key binding was previously missing from the manual.

Signed-off-by: Adam Spiers 
---
 doc/org-manual.org | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 3eb745b5d..7c291c3a7 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -6028,6 +6028,7 @@ calendar, or by pressing {{{kbd(RET)}}}, the date 
selected in the
 calendar is combined with the information entered at the prompt.  You
 can control the calendar fully from the minibuffer:
 
+#+kindex: C-.
 #+kindex: <
 #+kindex: >
 #+kindex: M-v
@@ -6041,6 +6042,7 @@ can control the calendar fully from the minibuffer:
 #+kindex: M-S-LEFT
 #+kindex: RET
 #+attr_texinfo: :columns 0.25 0.55
+| {{{kbd(C-.)}}}   | Jump to today. |
 | {{{kbd(RET)}}}   | Choose date at point in calendar.  |
 | {{{kbd(mouse-1)}}}   | Select date by clicking on it. |
 | {{{kbd(S-RIGHT)}}}   | One day forward.   |
-- 
2.27.0

Bug: org-agenda-sorting-strategy priority has no effect [9.3.7 (9.3.7-16-g521d7f-elpaplus @ /Users/devil/.emacs.d/elpa/org-plus-contrib-20200803/)]

[Adam Faryna]

09) (:endgroup))
 org-modules '(ol-w3m ol-bbdb ol-bibtex ol-docview ol-gnus ol-info ol-irc 
ol-mhe ol-rmail ol-eww
   org-habit org-drill org-collector org-depend org-eww 
org-checklist)
 org-shiftup-final-hook '(windmove-up)
 org-ascii-headline-spacing '(1 . 1)
 org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent 
org-depend-block-todo)
 org-export-creator-string "Adam Faryna (appdy.net)"
 org-odt-preferred-output-format "doc"
 org-mode-hook '(#[0 "\301\211\207" [imenu-create-index-function 
org-imenu-get-tree] 2]
 (closure
  (org-agenda-skip-regexp org-table1-hline-regexp
   org-table-tab-recognizes-table\.el org-table-dataline-regexp
   org-table-any-border-regexp 
org-agenda-restriction-lock-overlay
   org-agenda-overriding-restriction org-agenda-diary-file
   org-complex-heading-regexp calendar-mode-map t)
  nil (setq imenu-create-index-function (quote 
org-imenu-get-tree)))
 org-clock-load
 (lambda nil (set (make-local-variable (quote paragraph-start)) 
"[:graph:]+$")
  (set (make-local-variable (quote paragraph-separate)) 
"[:space:]*$"))
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-all append local] 
5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all 
append local] 5]
 (closure
  (org--rds reftex-docstruct-symbol org-element-greater-elements
   org-clock-history org-agenda-current-date org-with-time 
org-defdecode org-def
   org-read-date-inactive org-ans2 org-ans1 
org-columns-current-fmt-compiled
   org-clock-current-task org-clock-effort 
org-agenda-skip-function
   org-agenda-skip-comment-trees org-agenda-archives-mode 
org-end-time-was-given
   org-time-was-given org-log-note-extra org-log-note-purpose
   org-log-post-message org-last-inserted-timestamp 
org-last-changed-timestamp
   org-entry-property-inherited-from org-blocked-by-checkboxes 
org-state
   org-agenda-headline-snapshot-before-repeat 
org-capture-last-stored-marker
   org-agenda-start-on-weekday org-agenda-buffer-tmp-name 
org-priority-regexp
   org-mode-abbrev-table org-mode-syntax-table 
buffer-face-mode-face org-tbl-menu
   org-org-menu org-struct-menu org-entities org-last-state 
org-id-track-globally
   org-clock-start-time texmathp-why remember-data-file
   org-agenda-tags-todo-honor-ignore-options 
iswitchb-temp-buflist
   calc-embedded-open-mode calc-embedded-open-formula 
calc-embedded-close-formula
   align-mode-rules-list org-emphasis-alist 
org-emphasis-regexp-components
   org-export-registered-backends org-modules 
org-babel-load-languages
   org-id-overriding-file-name org-indent-indentation-per-level
   org-element-paragraph-separate ffap-url-regexp 
org-inlinetask-min-level t)
  nil
  (add-hook (quote change-major-mode-hook) (quote org-show-all) 
(quote append)
   (quote local))
  )
 (closure
  (org-src-window-setup *this* 
org-babel-confirm-evaluate-answer-no
   org-babel-tangle-uncomment-comments 
org-src-preserve-indentation
   org-src-lang-modes org-link-file-path-type 
org-edit-src-content-indentation
   org-babel-library-of-babel t)
  nil
  (add-hook (quote change-major-mode-hook) (quote 
org-babel-show-result-all)
   (quote append) (quote local))
  )
 org-babel-result-hide-spec org-babel-hide-all-hashes 
org-eldoc-load)
 org-clock-persist t
 org-export-with-smart-quotes t
 org-odt-format-drawer-function '(closure
  (hfy-user-sheet-assoc hfy-html-quote-regex 
hfy-html-quote-map
   hfy-face-to-css hfy-begin-span-handler 
hfy-end-span-handler
   archive-zip-extract 
nxml-auto-insert-xml-declaration-flag t)
  (_name contents) contents)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-mime-src-mode-hook '(org-mime-src-mode-configure-edit-buffer)
 org-reverse-note-order t
 org-priority-start-cycle-with-default nil
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-hide-block-startup t
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-bibtex-headline-format-function #[257 "\300\2

[feature request] org-at-timestamp-p should accept multiple parameters

[Adam Faryna]

Hi,

recently I was doing some customization and I needed to check if timestamp
at a point is active or inactive. That timestamp also contains an agenda
like information about reoccurring.

So I tried to use org-at-timestamp-p function for this purpose.

The problem is I needed to check if the timestamp is agenda like and
inactive or ignore the context at the same time. But org-at-timestamp-p
takes only one parameter, and I needed to give it multiple parameters,
which is not possible in the current version.

Can you amend the implementation of org-at-timestamp-p to make it accept a
list of parameters or named parameters instead of just one parameter?

Thanks,
Adam

make org-refile auto-recache when needed?

[Adam Spiers]

Hi all,

I note that when org-refile-use-cache is enabled and the cache becomes
stale, attempting to refile results in this error message (originating
from `org-refile-check-position'):

Invalid refile position, please clear the cache with `C-0 C-c C-w' before 
refiling

Is there any reason why it couldn't just automatically rebuild the
cache when needed?  If it did that then I struggle to imagine why
anyone would ever *not* want the cache enabled, because in the worst
case org-refile would just behave the same as when the cache is
disabled, and in the best case it would perform a lot faster.

Cheers,
Adam

Re: :STYLE: habit causes position in agenda view to change

[Adam Spiers]

On Tue, Jul 14, 2020 at 11:33:03PM -0400, Kyle Meyer wrote:

Adam Spiers writes:


I've noticed that adding the :STYLE: habit property to a TODO causes
its position in the agenda view to change; it jumps to the bottom of
the day.  Is there any way to prevent that?


Try customizing org-agenda-sorting-strategy (in particular, dropping
habit-down from agenda's values).


Perfect, thanks so much Kyle!