[ANN] org-ql v0.8.7 released

[Adam Porter]

Hi all,

FYI, v0.8.7 of org-ql has been released.  The changelog follows.

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

Thanks,
Adam



*Fixes*
⁃ Timestamps with internal time ranges (e.g. `<2024-06-26
  10:00-11:00>') are matched for simple queries.  (This support is not
  yet comprehensive, e.g. a query that depends on the specific inner
  time range may not behave as expected.  Previously such timestamps
  were not matched at all.  See [#237] and [#371].  Thanks to [Ihor
  Radchenko].)
⁃ Timestamps with day-of-the-week abbreviations are matched more
  flexibly (allowing, e.g. a period in French locales).  (See [#429],
  [#432].  Thanks to [Florian D.] for reporting.)
⁃ Command `org-ql-search' did not narrow properly when called
  interactively.

*Compatibility*
⁃ Dynamic blocks work with Org 9.7.  ([#431].  Thanks to [Jez Cope] for
  reporting.)


[#237] 

[#371] 

[Ihor Radchenko] 

[#429] 

[#432] 

[Florian D.] 

[#431] 

[Jez Cope] 

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
 for "admonitions",
which are a GFM construct
 already
supported by other org-exporters, and on GH in markdown.  This
refcard

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 
.  I found this message 
from January 
 
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: [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: [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: Policy proposal: Do not move existing functions/macros except in major version increments

[Adam Porter]

Hi Bastien,

On 6/1/20, Bastien  wrote:
> Hi Adam,
>
> Adam Porter  writes:
>
>> The relatively recent moving of org-get-outline-path to org-refile.el
>> has caused breakage in Org itself in several places, e.g.
>>
>> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00260.html
>> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00259.html
>> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00261.html
>
> ahem, my bad.  I made this bold (and wrong) move, and I broke code out
> of org-mode.
>
> I understand your proposal, and it's always good to be reminded that
> many people depend on Org's code out there.  It is not easy to spend
> time working on Org *and* tracking all these interesting extensions.

Of course, no one could be expected to keep track of all those things.
Such is the nature of writing software that runs in a Lisp image,
where anyone can use anything, and does.

> I agree with Nicolas that we should not put more constraints on the
> shoulders of Org current developers, especially because their time is
> limited - and obviously not enough to cope with every request.

I mostly agree with you.  My request is simply that, when a change has
the potential to break third-party packages, and it's a change, such
as this one, that mostly moves code around for organizational
purposes, that it be delayed until the next major version.  My goal
for such a policy would be to reduce the frequency of such changes
that third-party package authors have to write compatibility code for.
The (if (version< org-version ...)) workarounds become confusing for
authors and users, and somewhat of a maintenance burden.

> That said, we can make it easier for third-party developers to know
> what changes will be released in the future.
>
> See the "Upcoming changes" in https://updates.orgmode.org
>
> You can subscribe to this RSS feed:
> https://updates.orgmode.org/feed/changes
>
> Or check the data directly:
> https://updates.orgmode.org/data/changes
>
> To announce the change you see, I just used this email header:
>
>   X-Woof-Change: 9092c289 9.4
>
> That is the commit number where the change happens and the version
> in which the change will be released.
>
> The list of upcoming changes is emptied when a new major released is
> done, because the changes are then advertized in this file, as usual:
> https://orgmode.org/Changes.html
>
> I think that's a tiny distributed effort for developers and a easy
> way to track changes for third-party developers.

That's a very clever way to do it!  Thanks for your work on this.  If
it's feasible, you might also consider allowing committers to put such
a header in the git commit log and parsing it out of that, which could
make it even easier.

Thanks,
Adam

Re: org-clip-link should be included in core

[Adam Porter]

On Sat, May 23, 2020 at 10:14 AM Bastien  wrote:

> So IIUC the need is to easily remove the link part of a link.
>
> I pushed a change to make this easier.  Now you can hit `C-c C-l' on
> a link, empty the link part, keep the description and RET to get only
> the description inserted as non-link text.
>
> Let me know if this seems okay for you.
>
> I'm copying Adam as he may comment on that too.

That seems like an elegant solution.  Thanks, Bastien.

Re: Policy proposal: Do not move existing functions/macros except in major version increments

[Adam Porter]

Hi Nicolas,

Nicolas Goaziou  writes:

> Hello,
>
> Adam Porter  writes:
>
>> The relatively recent moving of org-get-outline-path to org-refile.el
>> has caused breakage in Org itself in several places, e.g.
>
> [...]
>
>> Thankfully, Kyle has proposed a patch to revert that change.  I hope
>> it is merged.
>>
>> If it is not, when a new Org version is released with those changes
>
> What makes you think a new Org would be released in this situation,
> without fixing it first?

I don't know what will happen.  I don't know whether the Org maintainers
would consider the problem serious enough to avert (as you said later,
"it happens").  That's why I pointed out what the consequences would be
if the patch isn't merged, to encourage its merging.

>> I think changes like this should not be made without very careful
>> consideration of the wider implications.  These kinds of changes
>> create a not-insubstantial burden on maintainers of Org-related
>> packages to keep up with churn and maintain compatibility with
>> multiple Org versions (which are used in the wild for years--I know
>> of users still using Org 8, as well as Org 9 versions that are
>> included with older Emacs versions (e.g. Emacs 26.3 is still stuck in
>> Debian unstable, not migrating to testing, stable, or backports)).
>
> [...]
>
>> So, I propose that changes like these should not be made except in
>> major version increments, e.g. this change should have been delayed
>> until the release of Org 10.0.  It would be helpful for users and
>> package authors if they knew that changes like these would not be
>> made until the next major version increment.
>
> FWIW, I think this is too strong a requirement.
>
> This breakage is unfortunate, and I can hear the consequences it has
> on the Org ecosystem, but, hey, it happens. Note that moving part of
> Org elsewhere usually introduces less friction. This is a relatively
> exceptional situation.

Of course, I am biased here, but I feel like it's not quite as
exceptional as it ought to be.  The more Org-related packages I make and
maintain, the more version-specific workarounds I have to add due to
changed function names, signatures, etc.  These are sometimes necessary,
of course, but I think they should be made more carefully and
deliberately.

Of course, Org doesn't make any promises to third-party packages.  But
that is the issue, isn't it?  I'm saying that I think it should start
taking this issue a little more seriously.  :)

> Master is an unstable branch, relatively open to experimentation.
> Moreover, that experimentation happens before deciding if the next
> release should be 10.0 or 9.4, so it wouldn't help users or package
> authors.

That is a matter of policy, which is what I'm proposing.  When such a
change is desired (symbol name, function signature, etc), it should be
targeted at the next major version increment.  If the project as a whole
is not ready to make that increment, that change should be delayed until
then--it can be developed in a branch and merged when preparing the
major release.  These kinds of changes could even be documented in
advance, e.g. in a ROADMAP or PLANS file, or whatever you want to call
it, which would be more explicit and referenceable than merely a mailing
list post.

> It doesn't mean we cannot do better here. For example, I think we
> could improve the way Org loads its libraries. Ideally, external
> libraries should only (require 'org), and optionally, (require 'ox-*)
> or (require 'ol-*). Thus, changes like the one discussed here would be
> implementation details. For example, "ox-hugo.el" requires directly
> "ob-core.el", and now "org-refile.el", which is, IMO, a path to
> troubles. It should only require "org.el".
>
> The current situation is tricky though: "org.el" requires some
> libraries (e.g., "org-key.el", "org-table.el", ...), and some
> libraries require "org.el" (e.g., "org-capture.el", "org-element.el",
> ...). I expect "org.el" to be the entry point for the Org package, so
> loading should happen in one-way only.
>
> This would not solve everything, but it would certainly make things
> smoother for external libraries.
>
> WDYT?

That is a good idea, and one that needs addressing.  I'd be glad to give
some feedback on it, but in a separate thread, please, because it seems
like a different matter from the issue I'm raising and the proposal I'm
making.

Thanks,
Adam

Re: [ANN] org-ql 0.4 released

[Adam Porter]

David R  writes:

> On Saturday, January 25, 2020, Adam Porter  wrote:
>
>> I care about stability, not MELPA Stable.  It's your choice to use MELPA
>> Stable, and you're free to upgrade or downgrade individual packages to
>> work around such occasional, temporary breakage caused by it--the pieces
>> are yours to keep.  I'm sorry for any inconvenience, but your config is
>> up to you.
>
> It seems to me that this last statement ("Your config is up to you"),
> or perhaps the point of view that produces it, is not self-evident
> when applied to package versions. I think that in some way it's near
> the heart of the controversy.
>
> Maybe for me personally, my config being up to me (regarding package
> versions) is a disadvantage. I gratefully make use of a number of
> packages that I don't fully understand, and if I was required to study
> all of them until I was confident that I *did* fully understand them
> before installing, I'd just give up using Emacs at all.

That is not what I am suggesting.

I suggest that you:

1.  Keep your Emacs config backed up, preferably with version control,
including all installed packges.

2.  Upgrade packages deliberately, not "upgrade all upgradable
packages."

3.  When you discover a problem caused by an upgrade, roll-back to a
known-good configuration until you have time to debug the problem.

This is what I recommend to all Emacs users.  It does not require
understanding any packages' source code.

Elisp has no inter-package API.  It's just a Lisp machine.  Elisp
packages are just symbols that you load into your image.  There is no
actual separation between packages' symbols.  There are no versioned
APIs, no synchronized transitions.

Each user's configuation, image, set of installed packages, etc. is that
user's responsibility.  In that sense, it's no different from a computer
system as a whole: you choose what software to install on it.  If you
like or need a certain version of certain software, it's up to you to
ensure that you have a copy of it available.  If you upgrade some
software and it doesn't work anymore with some other software version,
it's up to you to deal with it.

One of Emacs's chief strengths is user empowerment.  That doesn't mean
that users need to know how everything works--not even the core Emacs
developers do.  It means that you should know enough to maintain the
operability of the system, like you generally do for the rest of your
computer system.

The Emacs package "ecosystem" is not a "vendored" system.  It's not like
Debian, with thousands of relatively curated packages maintained as a
middleman, expected to work together in a stable release.  In Emacsland,
Each package (outside of Emacs and ELPA, and somewhat within ELPA as
well) is developed independently.

Nor should Emacs be treated like other software systems that are
live-updated whenever the developers hit the "push" button, with users
expecting the latest everything to work together all the time because
one party (ostensibly) takes responsibility for ensuring that.

Emacs gives the user the power.  And with great power...well, you know.

Having said all that, the problems with MELPA Stable are, in a sense,
artificial, and they're orthogonal to these general issues.  I can only
recommend, again, to not use it.  If you're lucky, it will work fine.
When it doesn't, the solution will involve not using it.  So you might
as well just skip it.  If you want less-frequent package upgrades, just
don't upgrade your packages so frequently.  Or use something like Quelpa
or Straight or Borg, where you can easily install the package versions
you want.

Policy proposal: Do not move existing functions/macros except in major version increments

[Adam Porter]

The relatively recent moving of org-get-outline-path to org-refile.el
has caused breakage in Org itself in several places, e.g.

https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00260.html
https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00259.html
https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00261.html

Thankfully, Kyle has proposed a patch to revert that change.  I hope it
is merged.

If it is not, when a new Org version is released with those changes
(actually, sooner, because some users run the master branch), it will
cause further breakage in out-of-tree packages and code in user
configurations.

I think changes like this should not be made without very careful
consideration of the wider implications.  These kinds of changes create
a not-insubstantial burden on maintainers of Org-related packages to
keep up with churn and maintain compatibility with multiple Org versions
(which are used in the wild for years--I know of users still using Org
8, as well as Org 9 versions that are included with older Emacs versions
(e.g. Emacs 26.3 is still stuck in Debian unstable, not migrating to
testing, stable, or backports)).

For my own packsges, I would expect to get multiple bug reports for
several of my packages, which means that for each one, I then have to
deal with the report, make a fix, test it, log it, push it, close the
bug report...and for all that, nothing is gained.  It adds up, and it's
frustrating and demoralizing.

Of course, I am not opposed, in principle, to refactoring and
reorganization of this sort.  Org is a huge project, and it certainly
could benefit from these kinds of changes, in general.

So, I propose that changes like these should not be made except in major
version increments, e.g. this change should have been delayed until the
release of Org 10.0.  It would be helpful for users and package authors
if they knew that changes like these would not be made until the next
major version increment.

If this is agreeable to the Org maintainers, I'd ask that it be
documented in the project and announced in the NEWS file.

Thanks,
Adam

Re: I'm slowly coming back

[Adam Porter]

Hi Bastien,

I've been keeping an eye out for you!  :)  Glad to hear you're well, and
I'm looking forward to your return.

Adam

Re: Assistant to remove unused IDs of org-id

[Adam Porter]

Marc-Oliver Ihm  writes:

> as I use the excellent package org-id in a somewhat non-standard way,
> I tend to produce IDs, that are not referenced from anywhere. Org-id
> handles this great and does not suffer in performance, but eventually
> I want to remove those unreferenced IDs.  Therefore I have written a
> small interactive assistant:
>
> https://github.com/marcIhm/org-working-set/blob/master/org-id-cleanup.el
>
> to help with removing those IDs.  The assistant (interactive function:
> org-id-cleanup) is quite detailed with its instructions and checks, so
> that the risk of doing harm ist reduced to a minimum, although not to
> zero (therefore the first step is to ask for a backup).
>
> In any case I wonder, if this functionality (removing unreferenced
> IDs) could be helpful for anyone else.
>
> So please feel free to have a look.  Finally I would be grateful for
> any comment whatsoever (e.g. regarding the name of org-id-cleanup.el).

Hi Marc,

Thanks, this looks useful.  I posted some feedback as an issue on the
repository.

Adam

Re: virtual org-mode meetup tomorrow 11am EST

[Adam Porter]

Ihor Radchenko  writes:

> FYI:
> I have recently stumbled upon a FOSS service for video conferencing:
> https://meet.jit.si/ (recommended in Tor blog
> https://blog.torproject.org/remote-work-personal-safety) 
>
> Might be another option for future meetings.

Yes, that's what was used for EmacsConf 2019.  It seemed to work well
enough.  See the archived videos.

Re: Automatic formatting of the table as you type

[Adam Porter]

ndame  writes:

> As for org-at-table-p being slow storing the start and end position of
> the table could be a solution, so if point is between them then there
> is no need to check org-at-table-p again.
>
> org-table-align seemed fast enough for me when I tried the posted
> code, but if it's slower for large tables then the code could measure
> the time it takes to perform the alignment for the current table and
> if it's above a certain threshold then it could introduce a bit of
> idle delay for the update, so it doesn't hold back the user from
> typing, and if the alignment is fast then it could perform the update
> without delay.
>
> Anyway, I think if implemented properly then this feature could be a
> worthy addition to org, even as default if it works well, because it's
> a much better user experience and a much better first impression for
> new users, instead of the current default fragile table which falls
> apart during typing and fixed only when TAB is pressed.

I suggest being very careful with this.  While it's a very nice feature,
it's bound to be slow with large tables.  And it is very frustrating for
users when typing becomes laggy.  Most users who encounter it would
probably not know if there's a way to fix the problem, e.g. by disabling
a feature, because they probably wouldn't even know what to look for.
Most would probably think it a bug, and it could harm Org's and Emacs's
reputation, making people think they're inherently slow or laggy when
typing.

Pressing TAB (or any other key that moves to the next field) to realign
a table is not a significant burden.  A feature like this should
probably remain an add-on package, or at least disabled by default.

Re: org-pop-mode

[Adam Porter]

"Mark E. Shoulson"  writes:

> Heh; fair enough.  The filename originally was "org-level-end.el", I
> think; I started using the catchier "org-pop" because... well, it was
> catchier.  It made sense in my mind, in the "push"/"pop" sense used
> with stacks in programming, that you "push" to a deeper level and this
> library would allow you to "pop" back up to a higher one.  I'll see if
> I can think of something better, thanks.

Well, org-heading-push-pop wouldn't be a /great/ name, but the push/pop
paradigm is understandable, so you might consider that.  :)

>
>> 2.  In the code, I saw you comment about cl-flet, and I see you using
>> fset and unwind-protect in the org-pop-with-continuations macro.
>> Instead, use cl-letf with symbol-function, like:
>>
>>(cl-letf* (((symbol-function 'foo)
>>#'my-foo)
>>   ((symbol-function 'bar)
>>(lambda ()
>>  ...)))
>>  BODY)
>>
>> See also Nic Ferrier's package, noflet.
>
> I'll take a look, thanks.  It's questionable whether I really should
> even be messing about with that macro anyway.  I musnt have removed the
> comments, but I had a whole thing there about how I had been trying
> with cl-letf and/or cl-flet and it didn't work. Thing is, cl-flet,
> according to the docs, (info:cl#Function Bindings) is strictly
> *lexical* binding, which is not going to cut it.  cl-letf might be
> different; the docs are different about it, but I am pretty sure I
> tried it and it didn't work, or didn't work "enough of the time."  But
> maybe I had it wrong, and maybe noflet will succeed.

The issue is what the macros expand to.  cl-letf rebinds the function
symbols, just like fset, so it affects all code that runs in Emacs until
the function symbols are set again.  cl-flet expands into lambdas bound
to variables and replaces calls to them with funcall, so it only affects
calls in the macro's body.  Use pp-macroexpand-last-sexp to see the
expansions.

BTW, in the body of your email, the text you write has these two
characters between sentences: "  ".  The second is a plain space, but
the first is a Unicode non-breaking space, or "C-x 8 RET a0".  I noticed
because it's displayed in Emacs as an underline character next to the
plain space.

Re: org-pop-mode

[Adam Porter]

"Mark E. Shoulson"  writes:

> This is something I've wanted for years in org-mode, but which in some
> ways could actually be _offensive_ to its ideals.  If you're an
> outline purist, look away.
>
> ...
>
> So, I present a pre-alpha version,
> https://gist.github.com/clsn/09ac4b098b6ad7366bb5e0bc2d5f of
> org-pop-mode.  To "pop" back up, create a headline at the level you're
> popping back to, and give it a tag of "contd", and the headline text
> should not be something important.  Instructions and explanations are
> in the comments of the file (the part about installing from MELPA is a
> lie, though).
>
> Any feedback?

Hi Mark,

Indeed, this is something that is frequently asked about.  I probably
wouldn't use it myself, but it looks like you've done a good job on it.
Here is some feedback:

1.  I'd suggest a more descriptive name, especially if you plan to
publish it to MELPA.  org-pop doesn't seem to convey anything about what
it does.  :)

2.  In the code, I saw you comment about cl-flet, and I see you using
fset and unwind-protect in the org-pop-with-continuations macro.
Instead, use cl-letf with symbol-function, like:

  (cl-letf* (((symbol-function 'foo)
  #'my-foo)
 ((symbol-function 'bar)
  (lambda ()
...)))
BODY)

See also Nic Ferrier's package, noflet.

Re: ox.html causes w3c xhtml validation

[Adam Porter]

Colin Baxter  writes:

> In my opinion, if it can't be fixed then the changes should be
> removed. Surely, we cannot have an org-mode that knowingly
> exports/publishes something that causes a validation error!

Looking at the error message, the fix might be very simple:

  The most common cause of this error is unencoded ampersands in URLs as
  described by the WDG in "Ampersands in URLs".

Re: virtual org-mode meetup tomorrow 11am EST

[Adam Porter]

Thanks to John for hosting, and to all who "attended" virtually.  It was
great fun.  Looking forward to doing it again.

Re: [PATCH] Add NO-STATS switch to org-get-heading

[Adam Porter]

Please don't add more arguments to org-get-heading.  It used to have 2,
then it had 4, and now you want to add a 5th.  Every time the function's
signature changes, it breaks code in third-party packages and user code
in random places, which requires the addition of messy compatibility
code and intermediate functions that do nothing but wrap org-get-heading
with a certain number of arguments.

It would be much preferable to make a new function that uses keyword
arguments so the addition of more arguments won't affect existing code.
Maybe it could be called org-entry-heading.

Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

[Adam Porter]

Kaushal Modi  writes:

> Failure 1: org-get-outline-path has moved, and not mentioned in ORG-NEWS
>
> Compiling ox-hugo.el now gives:
>
> ox-hugo.el:4284:1: Warning: the function ‘org-get-outline-path’ is not known 
> to be defined.
>
> I see that defun has now moved to org-refile.el. I see that
> org-get-outline-path has nothing to do specific to refiling. Can that
> be moved back to org.el, or may be a separate library? Otherwise,
> ox-hugo.el will have to load org-refile.el too (yes, I don't use
> org-refile (yet), and that's how I discovered this :))

Yes, please move that function back.  This is going to cause breakage in
a variety of packages that use that function but do not load
org-refile.  I can hear the bug reports rumbling already...  ;)

Re: Regarding collapsing blank lines between headlines

[Adam Porter]

Hi Russell,

This is not exactly what you asked for, but here's some code that
ensures blank lines exist between headings and entry content.  You could
modify it to remove excess lines without too much trouble.

https://github.com/alphapapa/unpackaged.el#ensure-blank-lines-between-headings-and-before-contents

Re: Survey: changing a few default settings for Org 9.4

[Adam Porter]

Marco Wahl  writes:

 - org-loop-over-headlines-in-active-region => t
>>>
>>> I vote for => 'start-level.  Loop over headlines with same level as the
>>> first.
>>
>> Yes, good suggestion.
>
> Let's see what others say.

I can see how that could be useful, but I feel like it would be less
intuitive than looping over all headings in the region.  I would be
confused by that behavior if I weren't aware of this discussion and the
option's settings.  So I would vote for t over 'start-level.

My two cents.  :)

Re: Survey: changing a few default settings for Org 9.4

[Adam Porter]

I generally approve of all of these changes.  However, hiding emphasis
and macro markers can make editing text at the boundaries of emphasized
text non-intuitive, which I can imagine might frustrate some new users,
so that should probably be carefully considered.  The other changes seem
like obvious improvements to me.  :)  Thanks for your work on this,
Bastien!

Re: Possible to exclude/include tags for agenda custom commands?

[Adam Porter]

Hi Bastien,

Bastien  writes:

> Hi Adam,
>
> Adam Porter  writes:
>
>> https://alphapapa.github.io/org-almanac/
>
> this is a very nice list of resources!
>
> Do you think we can advertize it somewhere on Worg?
>
> If yes but are unsure *where*, just go ahead with whatever location
> seems fine, we can always rearrange Worg's contents later on.

Yes, I'd be glad for it to be listed on Worg.  Feel free to add it if
you like, or I might add it myself after I add a bit more content.

I was thinking about working on Worg rather than making yet another
resource, but:

1.  I saw you mention that you're planning to reorganize Worg's content
soon, and I wouldn't want to interfere with that.

2.  I sometimes feel hesitant to put a lot of effort into curating and
organizing content on Worg because, like all wikis, that work can easily
be invalidated if others come along later and add content in random
places.

One of my goals for this "org-almanac" is to catalog content in a
somewhat canonical way, to avoid the "wiki effect."  For this project,
I'd rather have less content that's organized more clearly, than have
lots of content scattered about.  Of course, I don't presume to say that
the way I've done it is the best way, and I'm experimenting as I go.

Anyway, do you have any more thoughts about these issues?

Thanks,
Adam

Re: Possible to exclude/include tags for agenda custom commands?

[Adam Porter]

Stig Brautaset  writes:

> Hi Bastien,
>
> Bastien  writes:
>>> I can easily do this in the list of TODOs, with a tag search. However, I
>>> haven't figured out how to do this for the agenda. Is it possible? If
>>> so, how?
>>
>> From what I understand, check `org-agenda-tag-filter' to see how to
>> use it within an agenda custom command.
>
> Thank you! That did indeed do it. 
>
> FWIW my stanza looks like this now:
>
> (setq org-agenda-custom-commands
>  '(("w" "Work Agenda"
> ((agenda "" ((org-agenda-span 'day)))
>  (todo "TODO"
>((org-agenda-max-entries 5)
> (org-agenda-todo-ignore-scheduled 'all)
> (org-agenda-todo-ignore-deadlines 'all)
> (org-agenda-todo-ignore-timestamp 'all
> ((org-agenda-tag-filter '("-@home" "-MAYBE"
>("h" "Home Agenda"
> ((agenda "")
>  (todo "TODO"
>((org-agenda-max-entries 5)
> (org-agenda-todo-ignore-scheduled 'all)
> (org-agenda-todo-ignore-deadlines 'all)
> (org-agenda-todo-ignore-timestamp 'all
> ((org-agenda-tag-filter '("-@work" "-MAYBE"
>("m" "Maybe"
> ((todo "PROJ")
>  (tags-todo "-PROJ/TODO"))
> ((org-agenda-tag-filter '("MAYBE"
>("P" "Projects" tags-todo "-MAYBE/PROJ"
>
> Stig

Hi Stig,

Thanks for sharing that.  I think this is a fairly common question among
Org users, yet not always easy to find the answer to, so I've added your
example here along with a couple of other solutions:

https://alphapapa.github.io/org-almanac/#Exclude%20and%20include%20tags%20in%20custom%20Agenda%20commands

Re: [PATCH] ox.el: Fix extra character deleted in org-export--update-included-link

[Adam Porter]

Dear Nicolas and Bastien,

I feel like a child whose parents are fighting.  :)  If I may speak for
other Org users: you're invaluable to us, and we look up to you.  Please
don't let the deficiencies inherent in online, textual communication
cause deterioration in your fellowship.

With gratitude for all your contributions,
Adam

Re: Provide org-insert-subitem

[Adam Porter]

Bastien  writes:

> First of all, don't be afraid, I don't have a grand plan for "cleaning
> up" things.

Don't worry, I trust you.  :)  Org wouldn't be what it is today without
your work, and I'm grateful for how much time you've been putting into
improving Org lately.

>> I'm not sure what you mean about functions mentioned as usable by the
>> user.  org-insert-subheading is an interactive command, so it's
>> explicitly usable by the user.
>
> Yes, org-insert-subheading is interactive and usable and in Org's core
> but how can a user *discover* this command?
>
> There is no keybinding for it and no mention in the manual.  Even as a
> function, it is not even used in Org codebase.
>
> The ways I can see for a user to discover this command is by trying to
> complete M-x org-insert TAB or by reading Org's code (or other code in
> the wild using it.)

I guess what happened here is that I found that command years ago,
probably from either reading someone else's config online or, as you
say, using completion (I discover so many things using Helm
completion--I'm constantly using "C-h f org-" when working on
Org-related code).  Then I bound it to S-RET in my config, and I've been
using it ever since.  To me it feels like just as much a part of Org as
any other Org command.

> So to me it's a "utility" command: something that Org does not depend
> on, something that provides a useful feature, but not useful enough to
> have a keybinding in Org's core or to be used as a function in Org's
> core.

What if we document it in the manual?  For example, in section 2.5,
"Structure editing", we have:

`M-' (`org-insert-heading')
 Insert a new heading/item with the same level as the one at point.

`C-' (`org-insert-heading-respect-content')
 Insert a new heading at the end of the current subtree.  

`M-S-' (`org-insert-todo-heading')
 Insert new TODO entry with same level as current heading.  See
 also the variable `org-treat-insert-todo-heading-as-state-change'.  

`C-S-' (`org-insert-todo-heading-respect-content')
 Insert new TODO entry with same level as current heading.  Like
 `C-', the new headline will be inserted after the current
 subtree.  

What if we add:

`S-' (`org-insert-subheading')
 Insert a new subheading and demote it.
 Works for outline headings and for plain lists alike.

Note that I also propose binding it to S-.  It seems that, by
default, that key is currently bound in Org buffers to
org-table-copy-down:

Copy the value of the current field one row below.

That's surely a useful function, but I feel like it probably isn't
widely used enough to deserve to be bound to S- in all contexts.
Of course, frequent users of this command, feel free to correct me, lest
I be a hypocrite.  ;)

If that seems agreeable, then I'd also propose renaming the command
(preserving its old name in an alias, of course) to something which
would not imply that it only works in outlines, perhaps
org-insert-subitem or org-insert-demoted.

In the longer term , perhaps we could make a new, contextual command
that would call one command in tables and another command in non-table
contexts.  If there were a clever way we could make similar, roughly
corresponding actions in both tables and tree structures use the same
bindings contextually, that might be useful.  I think it would be
reasonable, because if point is in a table, the user probably won't want
to insert a new outline heading in the middle of it.

What do you think?  Thanks.

Re: Provide org-insert-subitem

[Adam Porter]

Hi Bastien,

Bastien  writes:

> I still find it strange to keep functions that are used nowhere in the
> Org's core--except of course for functions that explicitely mention as
> usable by the user (e.g. `org-clock-persistence-insinuate'.)
>
> I'd rather have these functions stored in a org-utils.el library for
> those who care.

I'm not sure what you mean about functions mentioned as usable by the
user.  org-insert-subheading is an interactive command, so it's
explicitly usable by the user.  And it's in org.el, so it's in Org's
"core", right?  I guess we're thinking in different terms.

Inserting a subheading or subitem is a very common operation in an
outlining and list-making tool, so it would seem like a significant
regression to remove it.

I'm not opposed to reorganizing the code, of course, as long as it
remains loaded as a command when org-mode is activated.

[ANN/RFC] org-ql-view-dispatch command

[Adam Porter]

Hi friends,

I've pushed a new feature to org-ql's master branch: a Magit-like view
dispatcher using Jonas Bernoulli's transient.el library.  It makes for
quick and easy modification of org-ql-view queries, allowing you to
build them interactively rather than requiring you to write Lisp code or
use the Customization system.  Here's a screencast of it:

https://github.com/alphapapa/org-ql/raw/master/images/org-ql-view-dispatch.gif

It seems to work well, but I'd appreciate any feedback.

Thanks,
Adam

Re: How to intersperse commands with their output in RESULTS block?

[Adam Porter]

Diego Zamboni  writes:

> I came up with the following block, which cleans up all the cruft from
> the output of the =script= command and produces a nicely formatted
> session transcript:
>
> #+NAME: cleanup
> #+BEGIN_SRC emacs-lisp :var data="" :results value :exports none
>   (replace-regexp-in-string
>"\\$ exit\\(.\\|\n\\)*$" ""
>(replace-regexp-in-string
> "^bash-.*\\$" "$"
> (replace-regexp-in-string
>  "\\(\\(.\\|\n\\)*?\\)\\$\\(.\\|\n\\)*\\'" ""
>  (replace-regexp-in-string "
> " "" data) nil nil 1)))
> #+END_SRC
>
> (I am not happy with the regexp nesting and repetition above, I am not
> an expert yet in emacs-lisp regex facilities. Suggestions appreciated
> for how to simplify it).

Hi Diego,

A few suggestions:

1.  You can use `rx' to define regexps in a Lispy way, and the ELPA
package `xr' converts existing regexp strings to the rx format, which
can help in learning rx syntax.  For example:

  (xr "^bash-.*\\$" 'brief) ;;=> (seq bol "bash-" (0+ nonl) "$")

So you can use that regexp like:

  (replace-regexp-in-string (rx bol "bash-" (0+ nonl) "$") ...)

This nasty one is much easier with rx:

  (xr "\\(\\(.\\|\n\\)*?\\)\\$\\(.\\|\n\\)*\\'" 'brief)
  ;;=>
  ;; (seq (group (*? (group anything)))
  ;;  "$" (0+ (group anything)) eos)

2.  To avoid the nested calls, you can use a loop, like:

  (cl-loop for (match replace) in
   (list (list (rx foo bar) "replacement"))
   do (setf string
(replace-regexp-in-string match replace
  string)))

Re: org-adapt-indentation default should be nil [legibility 3/6]

[Adam Porter]

Texas Cyberthal  writes:

>> the default settings do not put blank lines between headings and
>> their entry text,
>
> I don't know what this means. Plain Emacs behaves the same way
> Spacemacs does in this regard. Insertion of a blank line after a
> heading is voluntary but standrd.

I don't know what you mean, either, but you keep mentioning Spacemacs,
which isn't very relevant.

>> without any indentation, headings and entry text on varying levels
>> tends to blend together, making for very poor readability.
>
> If the goal is to read the body text of headings, then deeply
> indenting it is contrary to the goal. If the goal is to see the depth
> of headings, then the bodies should be folded. If folded mode doesn't
> convey sufficient information, the solution is to rewrite the heading
> titles to better summarize the body text.

It is not for you to decide what others should do.  Your preferences are
not mine.  It sounds like you should develop your own "Texas Cyberthal
Emacs starter kit" that has all the settings you think are best.

>> No one is "good at" Emacs and Org when they first come to it.
>
> UI difficulty is exponential, not linear.

Come on, we all know that the Emacs learning curve is a spiral.

> The more initially difficult the Emacs UI is acknowledged to be, the
> more important it is to reduce that difficulty with noob-friendly
> defaults, so that they can eventually reach the point of elitist
> unconcern for noobs.

The issue here is not whether Emacs can generally be improved, but
whether your specific proposals are good ideas.

It's unfriendly of you--and incorrect--to imply that we are elitists
without concern for new users.  Much effort is put into improving
documentation, answering questions, writing explanatory articles, giving
demonstrations, etc.  Some of us even publish code to help others
improve their configs, e.g. https://github.com/alphapapa/alpha-org.  I
suggest that you give those avenues a try, rather than insisting that
your preferences are best for others.

> The problem with aiming software at noobs is ruining the expert
> experience.

That is one problem with software that overemphasizes the experience of
new users.  Another, perhaps more serious, problem is that it inhibits
the development of such expertise.  I feel like some of ESR's writings
are relevant here.

> Changing defaults doesn't ruin expert experience because experts have
> configuration management.

A VCS does not obviate the need to compensate for changes in default
behavior.

> Noob friendly defaults increases the likelihood there is a long term
> for them.  Emacs' biggest barrier to adoption is acclimatization.

You're not quite wrong, but you're missing the point about long-term
users.  What makes software attractive in the long-term is not what
makes it appeal to new users.  Emacs is not called "the editor of a
lifetime" for nothing--nor is notepad.exe called that, even though it is
very easy for new users to use.  Emacs is attractive in the long-term
because of its power, flexibility, and potential for mastery.  There is
a balance to be struck between appealing to new users and empowering the
development of expertise; to an extent, the two goals do conflict.

> I just read a GTD thread in which they all agreed Org was too hard to
> be worth learning, including the guy advocating it:
>
> https://forum.gettingthingsdone.com/threads/emacs-org-mode-is-the-perfect-tool-for-gtd.15028/page-2
>
> To be clear, this is the biggest GTD forum, which Org is the best
> implementation of, and it seems most of them are using digital GTD
> tools.

So what?  Emacs and Org do not need to adapt themselves to users who do
not like them.  They are successful because of what they are.

You seem very concerned about new users, thinking that, unless we make
Emacs/Org very easy for new users to understand, there will be no new
users.  This is obviously not the case.  Emacs is one of the oldest
pieces of software still widely used.  It and Org are gaining new users
every day; the community is more vibrant than ever.  Probably more
people use Emacs and Org today than ever before.

Consider an analogy: Years ago, Mozilla Firefox was the fastest, most
powerful, most popular browser that wasn't imposed on its users.  It was
the obvious victor in the "browser wars," having led the way in
unseating IE and freeing the Web from Microsoft's hegemony.  Then Google
Chrome arose as a challenger, with certain inherent advantages due to
Google's position.  Mozilla then chose to stop leading and start
following.  Every new Firefox release became more like Chrome, with
Mozilla thinking that it could win back users.  But why would a user who
was happy with Chrome want to switch to a poor imitation of it?  Mozilla
thought it could succeed by abandoning what had made it successful--it
thought Firefox would be more popular if it stopped being Firefox.  The
result was continued decline in Firefox's market share and, eventually,
Mozilla's 

Re: org-startup-truncated default should be nil [legibility 2/6]

[Adam Porter]

Texas Cyberthal  writes:

>> visual-line-mode and toggle-truncate-lines are basic Emacs commands
>> that all users should learn early.
>
> Visual lines, logical lines etc is a complicated mess that Spacemacs
> avoids entirely. I recall fiddling with it and never being satisfied,
> until adopting Spacemacs solved it. Now I know even less about it than
> I did then, because there's no need to know. A brief investigation
> shows Spacemacs sets (line-move-visual t) in prosey text modes, so
> that C-n next-line operates on visual lines. However commands such as
> C-e operate on logical lines: mwim-end-of-line-or-code. This is a sane
> default that permits fluid navigation of paragraphs, which is all a
> noob wants to do.
>
> Similarly, I almost never use truncate-lines, to the point that I had
> to websearch to recall what it was called within the last week.

If I understand correctly, you're arguing that defaults should be
changed because you don't understand how Emacs works, and since you use
Spacemacs, you don't even care how it works.

May I suggest that you propose your changes on the Spacemacs repo.

Re: Defaults for noobs, dotfiles for vets [legibility 1/6]

[Adam Porter]

Texas Cyberthal  writes:

> Making a vet change a default if he decides he doesn't like a change
> upon upgrading won't drive him away, but Emacs' unfriendly defaults
> are always driving away noobs. Therefore Org's defaults should be
> noob-friendly, not vet-friendly.

There is certainly room to improve some Emacs defaults; there are active
threads on emacs-devel about it now.

However, the question of to what degree Emacs should target certain
types of users is a wider one, and answering it one way or the other
doesn't necessarily support your proposed changes.

> Probably vets should use legible settings as well. I became accustomed
> to less-legible Org settings, and thought they were superior. But when
> I cleaned up my Spacemacs config, I incidentally restored some default
> legibility tweaks I'd disabled. After a brief exposure, I realized the
> tweaks were superior, and that my preferences had been wrong. Changing
> the defaults can overcome vet inertia and improve their UI.

It's neither the spirit nor practice of Emacs to tell users what
settings they should use.  Emacs exists to empower users to meet their
needs according to their preferences.

It is not for you, nor us, to decide whether certain users are suffering
from "inertia" which we ought to overcome on their behalf for the sake
of improving their UI.  That is for them to decide, not us.  This is
Emacs, not Apple, Inc.

>> Terminals can display colors, underlines, italics, and bold text
>
> Proposed legibility changes don't affect those font aspects.

I was responding to this claim of yours:

>>> Concerns about terminal impact appear to be moot, since terminal
>>> ignores most font settings.

So your claim has been clarified from "terminals ignore most font
settings" to "my proposed changes don't affect the font aspects that
terminals display."

Please quote enough of the message you're replying to so that the
conversation can be easily followed (by me, if no one else).

Re: org-mode functional programming library

[Adam Porter]

Nicolas Goaziou  writes:

> Note that, at some point, Org will support "seq.el", i.e., when we
> drop support for Emacs 24.

Just a small FYI about seq.el, for those who may not be aware: while
it's a very useful library, it can be quite slow since it uses generics.
For example, here are some benchmarks comparing seq-intersection with
other functions that intersect lists:

https://gist.github.com/alphapapa/36b117c178dec677258f372c3a01d8b5

Note the last benchmark listed, which shows that cl-intersection is
about 2x as fast as seq-intersection.  As well, dash.el's -intersection
is about 17x faster than seq-intersection.

So while seq.el will undoubtedly be useful in Org, it should be used
carefully with regard to performance.  Type-specific functions will
generally be much faster.  And as long as dash.el can't be used in Org
proper, a custom implementation may be called for at times.

Re: Prose with markup needs more line spacing [legibility 5/6]

[Adam Porter]

Texas Cyberthal  writes:

> Code requires less line spacing. It has more whitespace, fewer capital
> letters, and no markup such as underlining. Code is read differently
> than prose; it requires less sequential scanning.

Code certainly can have markup like underlining.  For example,
flymake/flycheck highlighting, highlight-function-calls-mode, Semantic,
etc.

> Prose has big blocks of text with taller capital letters that must be
> scanned sequentially. The tall bits bump into lines above and below.
> Org prose adds markup. Underlining and all-caps tags are common. This
> requires a bit more line spacing for optimal legibility:
>
> #+begin_src elisp
> ;; prose with markup needs more line spacing
> (defun leo-space-lines ()
>   (setq line-spacing 0.175))
> (add-hook 'org-mode-hook 'leo-space-lines)
> #+end_src

We should definitely not be messing with line spacing in default
settings.  Line spacing is a very personal preference, and it varies
widely by other configuration, such as font.

Please, feel free to make your own prose-specific Org theme or minor
mode, or use or improve one of the several that already exist.  Org
defaults need not be changed to meet your preferences.

Re: Fixed vs variable pitch font [legibility 4/6]

[Adam Porter]

Texas Cyberthal  writes:

> Readable prose requires variable-pitch font. Readable code requires
> fixed-pitch font. Org should make it easy to configure the two
> separately.
>
> mixed-pitch-mode mostly solves this problem, but only advanced users
> know about it.
> https://gitlab.com/jabranham/mixed-pitch

I also prefer proportional fonts for prose in Org buffers, and I
configured my face settings accordingly a long time ago.

However, it is not necessarily so that proportional fonts are required
for prose.  Great works have been written on typewriters for many
years.  As well, Emacs/Org are not necessarily aimed at prose writing
more than other uses, and changing the default would probably be
off-putting to many existing users, so the default probably should not
be changed.

Having said that, if Org could have a simple org-mixed-pitch-mode, or
something like that, that could be very helpful, since it could make
such configuration much easier.  Maybe one could be written to use
face-remapping, which shouldn't take much code.

Re: org-adapt-indentation default should be nil [legibility 3/6]

[Adam Porter]

Texas Cyberthal  writes:

> #+begin_src elisp
> (org-adapt-indentation nil)
> #+end_src
>
> Adaptive indentation makes sense when using Org as a plain-text
> database. It does not make sense when using Org for longform prose.
>
> In the former case, outline depth is important to reflect properties
> such as inheritance. The code elements are primary and the prose
> secondary.
>
> In the latter case, the primary payload is the prose. Gratuitously
> indenting it wastes screen space and requires the user to make layout
> adjustments for legibility. The extra information value of indentation
> reflecting outline depth is negligible; the heading already conveys
> it.
>
> Beginners are bad at making adjustments to keep heavily-indented prose
> legible. Thus the default should be nil.

I think you have a better case for changing this setting.  However, I
think there is another consideration: the default settings do not put
blank lines between headings and their entry text, and without any
indentation, headings and entry text on varying levels tends to blend
together, making for very poor readability.  Disabling this setting
would make this problem worse.

Generally, I don't think "beginners are bad at" is a good argument for
changing defaults.  No one is "good at" Emacs and Org when they first
come to it.  There's probably room for improving the defaults, but we
should not necessarily make changes based on guessing what brand-new
users are most likely to want.  Emacs and Org are, thankfully, generally
free from the trend of aiming software at those who have never used it
before.  Instead, it tends to call users to learn more and aspire to
mastery, which is more useful and empowering in the long run.

Re: org-startup-truncated default should be nil [legibility 2/6]

[Adam Porter]

Texas Cyberthal  writes:

> #+begin_src elisp
> (org-startup-truncated nil)
> #+end_src
>
> Line truncation is necessary for code but anathema for prose. Prose
> lines need visual wrap as windows resize, so that texts can be
> compared easily.
>
> Advanced Org uses such as large tables require line truncation. Tables
> are a code-like fixed-pitch feature.
>
> Users will write a paragraph of prose longer than the screen well
> before they discover a need for line truncation, such as long lines of
> code or wide tables. Users who need line truncation are likely to know
> about it, whereas users who need line truncation off are unlikely to
> know what it's called.
>
> Learning about line truncation is an unnecessary hurdle for beginners.
> Therefore the default should be nil.

visual-line-mode and toggle-truncate-lines are basic Emacs commands that
all users should learn early.  As well, many users prefer to use filled
paragraphs rather than visual wrapping.  And we shouldn't prioritize
prose above other uses. So this default should probably not be changed.

What would be useful would be if Emacs/Org could be configured to wrap
prose lines but not, e.g. tables and code blocks.  I don't think such
functionality exists in Emacs now, but here's a new package that may be
relevant: https://github.com/luisgerhorst/virtual-auto-fill

As well, it might be good to discuss on emacs-devel whether a feature
could be developed to truncate/wrap lines selectively; maybe
font-locking could be used to apply text properties to disable wrapping
dynamically (assuming that a feature could be developed to wrap based on
a certain text property).  Then we could have the best of both worlds,
and solve an existing problem, viz. that tables and code gets wrapped
when visual-line-mode is enabled.

Re: Defaults for noobs, dotfiles for vets [legibility 1/6]

[Adam Porter]

Texas Cyberthal  writes:

> Beginners spend a while learning to use Emacs as a simple text editor
> before they're able to do anything more advanced. Their ability to
> intelligently customize is minimal. Meanwhile experts have automated
> dotfile deployment, so defaults are almost irrelevant to them.
> Therefore defaults should be set for inexperienced users.

Defaults are relevant for all users, because if you change the default
of a setting that an "experienced user" uses the default for, he will
have to change that setting in his config.  New users come to Emacs/Org
a few at a time; changing the defaults would affect all existing users
at once.  Therefore changing the defaults should be very carefully
considered, and they should not reflect one user's beliefs about what
best suits other users.

> Inexperienced users will mostly use Org for longform prose, since they
> haven't learned its database functions yet. Since Org aspires to be a
> personal info manager, it should prioritize prose presentation above
> code conventions.

Org is not intended more for prose writing than for other uses.  We
should not prioritize one such use above others.

> Concerns about terminal impact appear to be moot, since terminal
> ignores most font settings.

Terminals can display colors, underlines, italics, and bold text, and
terminal appearance should not be ignored or de-prioritized.

Re: Make code elements in prose unobtrusive [legibility 6/6]

[Adam Porter]

As Tim said, this is really a matter for theming.  There are several
themes and example configs available that make Org buffers "pretty".
For example:

https://github.com/kunalb/poet
https://github.com/jonnay/org-beautify-theme
https://lepisma.xyz/2017/10/28/ricing-org-mode/

As well, faces are easy to customize using:

  M-x customize-apropos-faces RET org RET

There may be improvements to be made, but the defaults shouldn't be set
to match the preferences of any one user.  Remember that people have
been using Org for years, and theming and faces are very personal.  ;)

Re: Provide org-insert-subitem

[Adam Porter]

Bastien  writes:

> `org-insert-subheading' and `org-insert-todo-subheading' are not used
> anywhere in Org's code.  Do you them?  How?
>
> I'm more inclined to delete these commands since they have no binding
> than to add an `org-insert-subitem'.
>
> Hitting  then  seems swift and handy enough.

Please do not delete org-insert-subheading!  I use it every day and have
for years.  :) It would be much less convenient to have to use two
commands.

BTW, in my version of Org, org-insert-subheading works on both list
items and subheadings, so there's no need for a separate
org-insert-subitem command:

  Insert a new subheading and demote it.
  Works for outline headings and for plain lists alike.

Re: org-superstar-mode: A re-imagining of org-bullets with new features

[Adam Porter]

Hi D,

This looks fantastic!  Great work!  I sent you a quick suggestion on the
issue tracker.  Let's get this on MELPA ASAP!  :)

Re: can't sign in to code.orgmode.org

[Adam Porter]

"Tyler Smith"  writes:

> I am trying to set up an account with code.orgmode.org. I have already
> done this, but when I try to sign in, I get an error about incorrect
> username or password. I have clicked the link to send a password reset
> several times this morning, but no email has shown up in my account,
> or in my spam folder.

I also tried to create an account the other day (I thought I already had
one, but apparently not), and I never received the confirmation email.

Re: New page https://orgmode.org/worg/donate.html

[Adam Porter]

FYI, Jonas Bernoulli also maintains a similar page for Emacs in general:

https://github.com/tarsius/elisp-maintainers

Re: [RFC] C-c C-c in agenda

[Adam Porter]

Marco Wahl  writes:

> For some days now C-c C-c disables column view in Org files.  This helps
> me a bit and never got in my way.  And I thought it would be quite
> natural and consistent to use this binding for the agenda too.
>
> What do you think about all that?

Hi Marco,

I've always had the impression that the "C-c C-c" binding was intended
to do the most obviously useful or natural action in the current
context.  For example, in a capture or log buffer, it completes the
capture.  With point on a #+ line, it resets buffer properties
accordingly.

I don't use column view very often, so I may be biased, but anyway: in
the general context of an Agenda buffer, I don't feel like enabling or
disabling column view is the most obviously useful or natural thing to
do, so "C-c C-c" doesn't seem like an appropriate binding to me.

Re: org-word-count exemptions

[Adam Porter]

There are various solutions floating around.  Here's one way:

(defun ap/org-count-words ()
  "If region is active, count words in it; otherwise count words in current 
subtree."
  (interactive)
  (if (use-region-p)
  (funcall-interactively #'count-words-region (region-beginning) 
(region-end))
(org-with-wide-buffer
 (cl-loop for (lines words characters)
  in (org-map-entries
  (lambda ()
(unpackaged/org-forward-to-entry-content 'unsafe)
(let ((end (org-entry-end-position)))
  (list (count-lines (point) end)
(count-words (point) end)
(- end (point)
  nil 'tree)
  sum lines into total-lines
  sum words into total-words
  sum characters into total-characters
  finally do (message "Subtree \"%s\" has %s lines, %s words, and 
%s characters."
  (org-get-heading t t) total-lines total-words 
total-characters)

(defun unpackaged/org-forward-to-entry-content ( unsafe)
  "Skip headline, planning line, and all drawers in current entry.
If UNSAFE is non-nil, assume point is on headline."
  (unless unsafe
;; To improve performance in loops (e.g. with `org-map-entries')
(org-back-to-heading))
  (cl-loop for element = (org-element-at-point)
   for pos = (pcase element
   (`(headline . ,_)
(org-element-property :contents-begin element))
   (`(,(or 'planning 'property-drawer 'drawer) . ,_)
(org-element-property :end element)))
   while pos
   do (goto-char pos)))