Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

[Bastien]

No Wayman  writes:

> Bastien  writes:
>
>> Applied in maint as c7abcd514, thanks.
>
> Thanks, Bastien. I noticed org-end-time-was-given is bound similarly.
> This binding doesn't affect my usage, but I wonder if it is necessary.
> If you think it isn't, I'd be happy to submit another patch removing
> it.

Actually, "optimistic merging" was too optimistic and your change
breaks a test, as Kyle reported here:

https://orgmode.org/list/87tuwb35wh@kyleam.com/

If you see what's going on, can you report?

-- 
 Bastien

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

[Bastien]

Hi Adam,

Adam Spiers  writes:

> There's actually a subtle but important difference
> between the two: when editing a timestamp with a time of day in, e.g.
>
> <2020-08-27 Thu 17:00>
>
> then the prompt in the minibuffer will be:
>
> SCHEDULED Date+time [2020-08-27]: 17:00
>
> While the point is after the "17:00", pressing '.' does not cause a
> jump to today's date; instead it just appends the '.' character after
> the "17:00".  In contrast, C-. successfully jumps to today without
> altering the prompt input.  So in this context, C-. is far more useful
> than just '.'.

Indeed!  I slightly updated the manual with 0b9080421 in maint.

Thanks,

-- 
 Bastien

Re: WIP: Org-plot work

[TEC]

Bastien  writes:

> Sure, please go ahead.

Will do! :)

> Great -- because I know Mario shared a lot of proposals, many of which
> where probably ignored or dismissed because the patches did not follow
> our conventions closely enough (despite his notable efforts).
>
> It is of foremost importance that we stick to these conventions: they
> help reduce the burden of Org maintainance.  But it is a pity that we
> lose contributions because contributors cannot follow them and find it
> difficult to do so.
>
> So, be free to both cooperate on making org-plot.el more useful!

Thanks. I suspect my work will need reworking to fit, but as long as
people are willing to point out what needs changing, I'm willing to take
a look at it :D

> Also, org-plot.el would do better with a maintainer - would you like
> to step in?

Simply on the basis that I'm actively interested in the functionality -
I'd be happy to sign up for this. As long as you don't mind someone a
bit green being assigned (I'm yet to use Emacs for a whole year, but I
don't see myself stopping any time soon!).

All the best,

Timothy.

Re: WIP: Org-plot work

[Bastien]

Hi Timothy,

TEC  writes:

> Bastien  writes:
>
>> Please share it on the list if you feel it's ready for a review.
>
> Well, I'm pretty sure it needs further tweaks, but I think that the bulk
> of the work would benefit from review at this point --- should I send it
> in?

Sure, please go ahead.

>> Also, Mario has been working on org-plot.el too
>
> Ah yes, well if Mario is interested I'm certainly open to such an idea :)

Great -- because I know Mario shared a lot of proposals, many of which
where probably ignored or dismissed because the patches did not follow
our conventions closely enough (despite his notable efforts).

It is of foremost importance that we stick to these conventions: they
help reduce the burden of Org maintainance.  But it is a pity that we
lose contributions because contributors cannot follow them and find it
difficult to do so.

So, be free to both cooperate on making org-plot.el more useful!

>> I'm not an org-plot.el user so I cannot comment on the usefulness and
>> correctness of the code, but perhaps you need to coordinate your work?
>
> On the usefulness front, I'm quite confident that the exposes some handy
> functionality. One notable result of my patches it that they allow users
> to define plot types they use frequently as 1st-class types (i.e. used
> just as #+PLOT: type:grid, just type:custom instead). This allows the
> GNUPlot boilerplate to be dissociated from the data being plotted, which
> I view as quite beneficial. This generalises the existing types into
> a default set of custom types.

Also, org-plot.el would do better with a maintainer - would you like
to step in?

Thanks,

-- 
 Bastien

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

[Bastien]

Hi Adam,

Adam Spiers  writes:

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

Maybe.  Please provide a patch so that we better know what we discuss.

Thanks,

-- 
 Bastien

tags-todo agenda shoud not ignore DONE items (was: tags-todo org-agenda-custom-command weirdness)

[Bastien]

Kyle Meyer  writes:

>> This behaviour of `tags-todo` seems inconsistent to me. If `todo` can
>> find DONE items, why shouldn't `tags-todo` do the same?
>
> Perhaps it should.  The behavior has been that way for a long time, and
> the code makes it look very deliberate.  That of course is not an
> argument that it should be that way, just one basis for expectations
> (and a reason to be wary of breaking workflows).
>
> And it looks like it was actually supposed to change to your preference
> in 2017.  There was a report [0] that essentially boils down to what
> you're saying, I think.  In response, 942b6267a (org-agenda: `tags-todo'
> command type includes DONE keywords, 2017-04-18) was applied, but then
> reverted for reasons not related to the intended change in behavior [1].
>
> There was then a follow-up in 2fb129b5c (`org-scan-tags' retrieve all
> TODO keywords, not only not-done ones, 2017-08-17).  As far as I can
> tell, that was supposed to achieve the behavior you're after but didn't.
> I don't have time to dig much at the moment, but quickly stepping
> through org-scan-tags, I think the issue is that the MATCHER argument
> still filters out done states.
>
>
> [0] 
> https://orgmode.org/list/caf96xx0xxhpkjaxy0dqmoiy3rnt+duok4p1y71f1awyjanl...@mail.gmail.com/
> [1] https://orgmode.org/list/874lt89fi2@free.fr/

Confirming this as an issue, if someone wants to fix it.

-- 
 Bastien

Re: tags-todo org-agenda-custom-command weirdness

[Bastien]

Stig Brautaset  writes:

> I didn't manage to make the time, no. I still may, but if someone else
> beats me to it I would certainly welcome it! I'm finding it hard to set
> aside time to dig into it given I have a functioning workaround.

Quite understandable, no problem.

-- 
 Bastien

Re: [PATCH] Add support for trace and error output streams in Common Lisp

[Bastien]

Hi Tom,

Tom Gillespie  writes:

> I also wanted to chime in here with a note that this seems to fall
> into a larger set of questions about standardization and
> regularization of the org babel api that have appeared on the list
> over the past couple of months.

Indeed.  This is something we collectively need to focus on for the
next releases.

One problem is that we lack maintainers for Babel languages, so if
readers of this list want to volunteer and take over maintainance
for individual ob-*.el file, please go ahead.

Thanks,

-- 
 Bastien

Re: babel default header args as functions

[Bastien]

Thanks for weighing in into this discussion.

Tom Gillespie  writes:

> I have a number of use
> cases that I can imagine would benefit greatly from being able to
> define a :header-args: :header (lambda () "yay!") property as a
> closure

Can you give some examples? I would love to get a better sense of
the usefulness of this feature.

-- 
 Bastien

Re: [PATCH] Omit file description when :file-desc has nil value

[Kyle Meyer]

Hi Matt,

It looks like this message got detached from the original thread [*] and
ended up a bit misformatted (at least for plain-text readers).  This
seems to be the message you accidentally sent to me off-list, so I will
copy my reply here as well.

  [*] https://orgmode.org/list/87tuwef76g@kyleam.com

Matt Huszagh writes:

> Thanks for the reply, Kyle, and thanks for pointing me to that thread. I
> understand that this would break existing functionality, but I think my
> solution makes more sense. For one, I think that the current
> implementation is a bit confusing. More importantly though, it makes it
> impossible to both provide a default value for :file-desc and omit it in
> some cases. The benefit (as mentioned in that thread) is that in those
> select cases, the same argument would not need to be provided twice. I
> think the cost of the current functionality outweighs the benefit. What
> are your thoughts?

I also don't find the current behavior particularly intuitive.  (I'm
also not really a babel user, so my opinion probably shouldn't count for
much.)  If we were adding it today, I think what you describe would be
better, but, as you mention, breakage also now also weighs against
making a change here.

In any case, I'd suggest raising the discussion on the list after the
9.4 release.

>> Right, to reflect the current behavior established as a result of the
>> above thread, I think that should be reworded to distinguish between an
>> absent :file-desc header and one with no argument.  Sorry for not
>> catching that when reviewing your initial patch.
>
> No worries, and I agree the documentation should be updated. I'm happy
> to provide the patch myself, but I'd like to talk through whether the
> current implementation is the correct one before I do.

Thanks.  To avoid any confusion coming from this description making it
into the 9.4 release, I've updated it in 4b2123fb7.

two test failures on maint branch

[Kyle Meyer]

Just a heads up: with recent changes on maint, I'm seeing two test
failures:

2 unexpected results:
   FAILED  test-org-inlinetask/folding-directly-consecutive-tasks/1
   FAILED  test-org/org-read-date

It looks like the first one came with ee3c3b554 (org.el: Allow empty
subtrees to be folded back, 2020-09-05) and the second with c7abcd514
(org.el (org-add-planning-info): Use caller's `org-time-was-given'
value, 2020-09-05).

Note that, for the second, directly running the test with
BTEST_RE='test-org/org-read-date' doesn't seem to trigger it, while
BTEST_RE='test-org/' does, so there's probably an interaction between
tests.

I haven't yet taken a closer look at those commits or the failures.

Re: [PATCH] lisp/ob-core.el: pass expanded body to org-confirm-babel-evaluate

[Kyle Meyer]

Tom Gillespie writes:

> Hi Kyle,
> Following up in this thread having investigated the impact of coderefs.
> My conclusion is that coderefs need to be stripped out before they are
> passed to org-confirm-babel-evaluate. They are not present in the
> executed code and removing them is not something that a definition
> of org-confirm-babel-evaluate should have to know anything about.
> Right now I work around them by suggesting that users comment
> out their coderefs. This works because my use case is restricted to
> elisp code and I strip the comments using read, but other languages
> would not have such an easy solution.

Thanks for revisiting this.  This change (df5a83637) hasn't made it into
a release yet, so it'd be good to make this move now.

> I have included a patch against maint that reuses the let block
> from org-babel-execute-src-block to accomplish this.

> diff --git a/lisp/ob-core.el b/lisp/ob-core.el
> index cd876da0f..44b02feb9 100644
> --- a/lisp/ob-core.el
> +++ b/lisp/ob-core.el
> @@ -240,9 +240,14 @@ should be asked whether to allow evaluation."
>   (funcall org-confirm-babel-evaluate
>;; Language, code block body.
>(nth 0 info)
> -  (if (org-babel-noweb-p headers :eval)
> -  (org-babel-expand-noweb-references info)
> -(nth 1 info)))
> +  (let ((coderef (nth 6 info))
> +(expand
> + (if (org-babel-noweb-p params :eval)

params is undefined here.  I've s/params/headers/ when applying.

> + (org-babel-expand-noweb-references 
> info)
> +   (nth 1 info
> +(if (not coderef) expand
> +  (replace-regexp-in-string
> +   (org-src-coderef-regexp coderef) "" 
> expand nil nil 1
> org-confirm-babel-evaluate
>  (cond
>   (noeval nil)

Okay, so this is equivalent to your original patch, though your initial
approach avoided duplicating the logic, which I think is worth doing.
I'd like to make sure this gets in before a release, so I've applied
this message's patch (3e1c0b0f4) and then followed it up with a patch
that adds a test, and another that extracts the duplicated logic out to
a helper (as in your original patch).

Re: [feature request] A new cookie type [!] showing the last note taken

[Ihor Radchenko]

> Everyone has their own workflows, but I think the way you are approaching
> this problem is "wrong". 

I think I need to elaborate on the use-cases more then.

I am well aware about the concept of NEXT actions, GTD, projects, and
using categories to bring task context in agenda. However, the problem I
am trying to solve is more subtle.

Sometimes, subdividing a task into NEXT sub-tasks is simply overkill
leading to redundancy. Consider the following example of reading a book,
when the task of reading is also part of bigger project:

* PROJECT Combine GTD approach with Zettelkasten in org-mode
:PROPERTIES:
:CATEGORY: ZettelOrg
:END:

Zettelkasten method looks promising to combine many pieces of
information from various research papers together. However, most of
papers I read are initially captured as TODO - within framework of GTD.

The original GTD approach recommends separating reference materials and
the todo-lists. I need to explore the reasons why it is so in more
details and decide if I need to separate paper notes from their "read"
tasks and how to manage the separation if I decide to do it.

** Literature review

*** NEXT re-read Getting Things Done by David Allen

[[attachment:GTD.pdf]]



That's indeed a fairly big task - reading the whole book. Splitting the
task sounds reasonable:

*** NEXT re-read Getting Things Done by David Allen

[[attachment:GTD.pdf]]

 NEXT Read Chapter 1
 TODO Read Chapter 2
 TODO Read Chapter 3
<...>



There is a problem with this approach though - individual tasks will
appear without context in agenda:

* today NEXT Read Chapter 1

As you mentioned, we can bring some context to the task simply by
showing category:

* today ZettelOrg: NEXT Read Chapter 1

You can see the problem - we already have high-level category for the
project.

Of course, we can define separate category just for the "re-read" task.
But then, we will lose the information about higher-level project. If
you look at the project description I put in the example, you can see
that the higher-level context is, in fact, important - I do not intend to
read the GTD book in generic way, but I intend to explore the possible
combination of Zettelkasten and GTD. This context is general for the
whole project and will apply to other books/articles that may appear in
the project "to-read" list.

There is also another approach to bring context to the individual "Read
Chapter" tasks - we can mention the book title in all of them:

*** NEXT re-read Getting Things Done by David Allen

[[attachment:GTD.pdf]]

 NEXT Read Chapter 1. Getting Things Done by David Allen
 TODO Read Chapter 2. Getting Things Done by David Allen
 TODO Read Chapter 3. Getting Things Done by David Allen
<...>

This works fine, but it is redundant - we have to carry over the first
headline to every sub-task.

So, I suggest to add a short note to the main task instead:

*** NEXT chapter 1 | re-read Getting Things Done by David Allen

[[attachment:GTD.pdf]]

This is much shorter and does not require creating a bunch of similar
tasks. I just need to look at the main task in the morning and decide
what I am going to do with it that day (like read first chapter).

One can argue that the fact that I want to read a chapter of the book is
so trivial that there is no need to bother writing it down. However, it
actually helps tremendously. Look at the following two tasks:

* today NEXT re-read Getting Things Done by David Allen
* today NEXT chapter 1 | re-read Getting Things Done by David Allen

According to my experience using GTD + agenda, I tend to feel a little
depressed by looking at the first task - "OMG, I need to read the whole
book! Better go ahead and clock-in an easier task - I can finish it
quickly." Thinking that I can just read a single chapter is not
something coming to my mind immediately - I need extra effort to realise
it. And things become worse when we have a task, which is less trivial
than reading a book (but also requires simple repetitive [but less
obvious] actions). 

Finally, note that I have an attachment link to the book in the task
description: 

*** NEXT re-read Getting Things Done by David Allen

[[attachment:GTD.pdf]]

This is handy, because I can open this link directly from agenda view
via C-c C-o. If I had to create individual tasks for each chapter, I
would need to carry over the link as well - another bit of redundancy.

> Under the GTD methodology, there is the concept
> of a project (some higher goal to be achieved) and next actions (the
> concrete tasks to do next to achieve the project).  You would only track
> the next action in your regular toto list. In Org mode, this would look
> like:
>
> * PROJECT make babel support org file links in header args (:file or :dir)
> ** TODO Finish the text prop org-mode
>
> My anecdotal impression is that many people using Org do this (see
> https://orgmode.org/worg/org-gtd-etc.html), so they have 

Re: Bug: [patch] Fix org-babel-result-to-file never expanding links when babel is evaluated in indirect buffer [9.3.7 (release_9.3.7-728-g1efc4e @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Thanks!

Bastien  writes:

> Hi Ihor,
>
> I applied an updated version of your patch as f45591630,
> just adding a changelog.
>
> Thanks,
>
> -- 
>  Bastien

Re: [feature request] A new cookie type [!] showing the last note taken

[Allen Li]

On Sat, Aug 29, 2020 at 6:42 AM Ihor Radchenko  wrote:

>
> Over the years of using Org I often have a need to add a short note
> about how to proceed with some task:
>
> * REVIEW check again, subscribe | sindresorhus/awesome:  Awesome
> lists about all kinds of interesting topics :BOOKMARK:
> :PROPERTIES:
> :CREATED: [2020-03-15 Sun 18:59]
> :Source: https://github.com/sindresorhus/awesome
> :END:
> :LOGBOOK:
> CLOCK: [2020-03-17 Tue 16:18]--[2020-03-17 Tue 17:46] =>  1:28
> CLOCK: [2020-03-17 Tue 16:03]--[2020-03-17 Tue 16:18] =>  0:15
> - Refiled on [2020-03-16 Mon 23:59]
> :END:
>
> In the above example, the short note is "check again, subscribe".
> The note is not fixed, but changes as I progress with completing the
> task.
>

Everyone has their own workflows, but I think the way you are approaching
this problem is "wrong".  Under the GTD methodology, there is the concept
of a project (some higher goal to be achieved) and next actions (the
concrete tasks to do next to achieve the project).  You would only track
the next action in your regular toto list. In Org mode, this would look
like:

* PROJECT make babel support org file links in header args (:file or :dir)
** TODO Finish the text prop org-mode

My anecdotal impression is that many people using Org do this (see
https://orgmode.org/worg/org-gtd-etc.html), so they have no need for a
"last note taken embedded in headline" feature.  As a practical matter, I
would find it inconvenient to have both the "last note take"/"next action"
and the overall project headline appear in the agenta view because it makes
the text too wide.  If I need to associate the next action with the overall
project, I take advantage of the CATEGORY property:

* PROJECT make babel support org file links in header args (:file or :dir)
:PROPERTIES:
:CATEGORY: BabelLinks
:END:
** TODO Finish the text prop org-mode

Which would show in the agenda as:

BabelLinks: TODO Finish the text prop org-mode

I have only been partially paying attention to this discussion thread, but
this sounds like both a feature with limited appeal and significant
complexity to implement, so I would suggest implementing it yourself for
your own use case, and then bringing it to the mailing list to share.  Once
you have a dozen people using it, it will likely have developed into a
mature enough form to include in Org mode.

Just my 2 cents.


> This is even more useful for delegated or HOLD tasks where I often need
> to add a short note why the task is delegated or put on hold:
>
> ** HOLD Finish the text prop org-mode | make babel support org file links
> in header args (:file or :dir)
> [[id:468e0645-68aa-4e14-86de-e5ce153538e3][[2017-09-22 Fri]
> CuNbARBshearstrength]] :HOLD:
> :PROPERTIES:
> :CREATED: [2020-07-20 Mon 16:53]
> :SHOWFROMDATE: 2020-08-15
> :END:
> :LOGBOOK:
> - State "HOLD"   from "NEXT"  [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> Seeing this note directly in the headline without a need to dig into the
> task body / LOGBOOK drawer is really handy.
>
> In this last example, I had to duplicate the note taken using built-in
> note mechanism into headline, which was inconvenient. It would be handy
> if I could simply add a [!] cookie (similar to [/] or [%] cookies) to
> the headline to show the last note taken for this task. Then, I could
> easily see the reason why the task is blocked or what I am supposed to
> do with the task right in agenda view or in the folded headline.
> Something like the following
>
> ** HOLD [!] make babel support org... :HOLD:
> :LOGBOOK:
> - State "HOLD"   from "NEXT"  [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> The cookie would be replaced by the last note text, according to
> user-defined format (say, "[%s] |"):
>
> ** HOLD [Finish the text prop org-mode] | make babel support org... :HOLD:
> :LOGBOOK:
> - State "HOLD"   from "NEXT"  [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> What do you think?
>
> Best,
> Ihor
>
>

Re: Adaptive Org faces in headings?

[Diego Zamboni]

Hi Protesilaos,

I had seen the same in my setup. I recently started using Doom Emacs (
https://github.com/hlissner/doom-emacs/) and was pleasantly surprised to
discover that todo and tag faces scale according to the headline in which
they are. I don't know precisely how this is done, but there are some hints
here, you might use it as a starting point:
https://github.com/hlissner/doom-emacs/blob/develop/modules/lang/org/config.el#L146-L175

(tangentially: I am very happy with Doom Emacs. After 30+ years of
handcrafting my Emacs config, I decided to give it a try and I can highly
recommend it).

--Diego


On Sun, Apr 26, 2020 at 9:01 AM Protesilaos Stavrou 
wrote:

> Dear all,
>
> I have noticed that Org faces that combine with headings do not adapt to
> their context.  This applies to keywords, priority cookies, links, and
> possibly other elements as well.
>
> For example, a "todo" keyword (`org-todo' face) will not scale in size
> to match that of the heading level (`org-level-N' face) if the latter
> uses a `:height' property.  Same principle for keywords not inheriting
> the heading's background, overline, etc.
>
> My expectation is to allow `org-level-N' to pass its attributes to any
> element on the same line, unless that element has conflicting face
> attributes of its own.  So, in my example, the heading could pass its
> height to the "todo" keyword when the `org-todo' face does not define a
> `:height' of its own.  Otherwise it would refrain from overriding that
> attribute.
>
> Does the community know of a solution to this issue?
>
> I am running:
>
> * Org mode version 9.3.
>
> * GNU Emacs 27.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.17,
>   cairo version 1.17.3) of 2020-04-20.
>
> Best regards,
> Protesilaos
>
>
> --
> Protesilaos Stavrou
> protesilaos.com
>
>

Re: [PATCH] Add support for trace and error output streams in Common Lisp

[Tom Gillespie]

Hi,

One comment on this patch right now is that =errors= should probably
be changed to =error= for consistency with the slime nomenclature and
with the fact that all the rest of the options for the :results header
are singular nouns.

I also wanted to chime in here with a note that this seems to fall
into a larger set of questions about standardization and
regularization of the org babel api that have appeared on the list
over the past couple of months.

I think that error has a clear and useful meaning for many languages
and it would be great to be able to capture it without resorting to
hackery like 2>&1 which
can't actually separate out the errors from the outputs when working in a shell.

I think this also points to a larger potential feature which is the ability to
capture and insert the output of multiple different streams at the same time
(more on that in a forthcoming mail on org-babel, which I might hold off on
until after the 9.4 release).

Best!
Tom

On Fri, Sep 4, 2020 at 8:37 AM Bastien  wrote:
> Let's continue to discuss this for after 9.4.

Re: tags-todo org-agenda-custom-command weirdness

[Stig Brautaset]

Bastien  writes:
> Stig Brautaset  writes:
>> Thank you for looking into this. I'm going to try to come up with some
>> tests for the behaviour, and with the help of your references see if I
>> can get those tests to pass.
>
> did you manage to find the time to look into this?

I didn't manage to make the time, no. I still may, but if someone else
beats me to it I would certainly welcome it! I'm finding it hard to set
aside time to dig into it given I have a functioning workaround.

Stig

[PATCH] Omit file description when :file-desc has nil value

[Huszaghmatt]

 
 

 
 
 
 
 

 
 Kyle Meyer  mailto:k...@kyleam.com)>  writes:  >  A use case 
was given in the initial patch:  >   
.  >  The 
test for this behavior mentioned there is  >  
test-ob/file-desc-header-argument.  >   >  That thread links to another thread 
by gmane ID. That's this one:  >   
https://orgmode.org/list/87limm4eo2@med.uni-goettingen.de/T/#u  Thanks for 
the reply, Kyle, and thanks for pointing me to that thread. I understand that 
this would break existing functionality, but I think my solution makes more 
sense. For one, I think that the current implementation is a bit confusing. 
More importantly though, it makes it impossible to both provide a default value 
for :file-desc and omit it in some cases. The benefit (as mentioned in that 
thread) is that in those select cases, the same argument would not need to be 
provided twice. I think the cost of the current functionality outweighs the 
benefit. What are your t
houghts? I've got a pending patch 
(https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/msg00041.html) that 
allows a user to provide lambdas as default header arguments (evaluated during 
source block execution or export). This makes the use of defaults much more 
attractive in my mind because they can provide context aware values. Similarly, 
it increases the cost of the current implementation because then this facility 
cannot be used for :file-desc. I guess there are other solutions we could 
explore, such as an empty string (is an empty file descriptor ever a valid use 
case?) taking the place of the current functionality, or fully eliminating the 
file descriptor. However, this is starting to feel like a lot of hacks and 
would be very confusing to new users. Moreover, it really just pushes the 
problem down the road rather than fixing it outright.  >  Right, to reflect the 
current behavior established as a result of the  >  above thread, I think that 
should be reworded to distinguis
h between an  >  absent :file-desc header and one with no argument. Sorry for 
not  >  catching that when reviewing your initial patch. No worries, and I 
agree the documentation should be updated. I'm happy to provide the patch 
myself, but I'd like to talk through whether the current implementation is the 
correct one before I do. Best Matt 

 
 
 
 

 
 

Re: babel default header args as functions

[Huszaghmatt]

  
  

  
  
  
  mailto:tgb...@gmail.com)>  writes:
  
  
  
  >  If the default header closures are being evaluated before checking
  
  >  whether they have been superseded by the headers on a block then that
  
  >  is incorrect and they should not be evaluated until it is clear that
  
  >  they are the value of the header for that block and have not been
  
  >  superseded.   
>   
>   
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
  
  
 Good point, Tom. I’m back from vacation on Wednesday and can   
  
 take a detailed look at this behavior then.
  
  
  
 Matt
  
 

Re: babel default header args as functions

[Tom Gillespie]

I think making the behavior of default arguments consistent with
regular arguments is probably a good thing. I have a number of use
cases that I can imagine would benefit greatly from being able to
define a :header-args: :header (lambda () "yay!") property as a
closure (and actually I assumed that it would just work that way if I
tried to do it, clearly not though). I can't tell for sure if the
patch enables this behavior though or whether I would still get a
Wrong type argument error. I don't see any additional security
implications beyond those already present (or not present) from
allowing closures as arguments to header arguments generally. Looking
at the patch it seems that it preserves the behavior of performing the
evaluation of the closures at the source block, but I'm not 100% sure.
If the default header closures are being evaluated before checking
whether they have been superseded by the headers on a block then that
is incorrect and they should not be evaluated until it is clear that
they are the value of the header for that block and have not been
superseded.
Best!
Tom

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

[Adam Spiers]

Hi Bastien,

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

Adam Spiers  writes:

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

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

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


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


Thanks for the reply!

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

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

[Adam Spiers]

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

Hi Adam,

Adam Spiers  writes:


This useful key binding was previously missing from the manual.


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


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

<2020-08-27 Thu 17:00>

then the prompt in the minibuffer will be:

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

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

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

Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

Bastien  writes:


Applied in maint as c7abcd514, thanks.


Thanks, Bastien. I noticed org-end-time-was-given is bound 
similarly.
This binding doesn't affect my usage, but I wonder if it is 
necessary.
If you think it isn't, I'd be happy to submit another patch 
removing it.

Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

[Bastien]

Hi,

No Wayman  writes:

> The current behavior of `org-add-planning-info' does not include the
> time of day when
> it is passed the TIME argument. This is because `org-time-was-given'
> is initially let-bound to nil
> during the scope of the function.
>
> The attached patch removes that binding and allows the caller to pass
> the time of day in the above case.

Applied in maint as c7abcd514, thanks.

-- 
 Bastien

Re: babel default header args as functions

[Bastien]

Hi Matt,

Matt Huszagh  writes:

> Matt Huszagh  writes:
>
>> I've generated a patch for this. Please let me know your thoughts. I
>> believe this adds valuable flexibility to default header
>> arguments.
>
> I've added an additional fix that makes this work during export too.

I would like to hear what other think about this feature.

Anyone?

Also, if we integrate the change, `eval-default-headers' would be
better named `org-babel-eval-default-headers'.

-- 
 Bastien

Re: Bug: A tag of a subject doesn't get archived if org-archive-subtree-add-inherited-tags t [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]

[Bastien]

Hi,

hpgislero...@bluewin.ch writes:

> a)
> if:   org-archive-subtree-add-inherited-tags nil
> then: Archiving a subject with its tag (C-c $) works as expected,
>   i.e. the subject together with it's tag is archived
> b)
> if:   org-archive-subtree-add-inherited-tags t
> then  Archiving a subject with its tag (C-c $)
>   archives the subject with only its inherited tag
>   but NOT its original tag
>
> Example:
>
> * parent subject :parent:
> ** child subject :child:
>
> Archiving result:
> a) * child subject :child:  <-- ok
> b) * child subject :parent: <-- nok
>
> What I would expect:
> b) * child subject :parent:child: 

I cannot reproduce this error, but you use an old version of Org, 
if you can upgrade (to 9.3.7 at least) and test again, that'd be
great.  

Thanks,

-- 
 Bastien

Re: Setting org-todo-keywords through directory-local variables

[Bastien]

Hi Kévin,

Kévin Le Gouguec  writes:

> I would like to re-submit this idea, now that I am reasonably sure that
> my implementation will not impact users who do not use the feature.

FWIW it looks fine to me, thanks for hacking this together.

We are in feature freeze for 9.4 so let's wait until you can commit
this to master.

Best,

-- 
 Bastien

Re: WIP: Org-plot work

[TEC]

Bastien  writes:

> Please share it on the list if you feel it's ready for a review.

Well, I'm pretty sure it needs further tweaks, but I think that the bulk
of the work would benefit from review at this point --- should I send it
in?

> Also, Mario has been working on org-plot.el too

Ah yes, well if Mario is interested I'm certainly open to such an idea :)

> I'm not an org-plot.el user so I cannot comment on the usefulness and
> correctness of the code, but perhaps you need to coordinate your work?

On the usefulness front, I'm quite confident that the exposes some handy
functionality. One notable result of my patches it that they allow users
to define plot types they use frequently as 1st-class types (i.e. used
just as #+PLOT: type:grid, just type:custom instead). This allows the
GNUPlot boilerplate to be dissociated from the data being plotted, which
I view as quite beneficial. This generalises the existing types into
a default set of custom types.

> That would be for after 9.4.

Of course.

Thanks for getting back to me on this,

Timothy.

Re: org-read-date-display-live has no effect when org-read-date-popup-calendar is nil

[Bastien]

Hi Edmund,

Edmund Christian Herenz  writes:

> I discovered that when disabling the calendar popup during insertion
> of time-stamps (by setting org-read-date-popup-calendar to nil) then
> the current intepretation of the date-prompt is not shown live
> anymore.  The absence or presence of the live preview is controlled
> via the variable org-read-date-display-live.  However, when
> org-read-date-popup-calendar is nil, then setting or unsetting
> org-read-date-display-live has no effect -- the live preview remains
> disabled.  Therfore it currently appears not possible to have a live
> preview of how org-read-date input interpretation when the calendar
> pop-up is disabled.

Thanks, I documented this in c09518b5f in master.

Best,

-- 
 Bastien

Re: tags-todo org-agenda-custom-command weirdness

[Bastien]

Hi Stig,

Stig Brautaset  writes:

> Thank you for looking into this. I'm going to try to come up with some
> tests for the behaviour, and with the help of your references see if I
> can get those tests to pass.

did you manage to find the time to look into this?

This fix will potentially change the behavior of many agenda views, so
we'd better advertize it in a major release.  If not 9.4, a later one,
there really no hurry.

Thanks,

-- 
 Bastien

Re: [BUG] org-agenda-filter and hyphens in category names

[Bastien]

Hi Samuel,

regarding hyphens in categories and agenda filtering, you should be
good to go from maint and master.  Please test it and let us know.

All best,

-- 
 Bastien

Re: [BUG] incorrect (and slow) indentation of logbook entries

[Bastien]

Hi Matt,

Matt Lundin  writes:

> Commit e3b79ad2bf7ab7b91c0ad2b8383d639bfe154ce7 from Feb. 9, 2020 (Allow
> a new value for `org-adapt-indentation') introduced a bug that causes
> logbooks to be incorrectly indented when promoting an entry. 

FWIW, I can confirm this bug, I'll look at it before 9.4.

Thanks for the detailed exploration!

-- 
 Bastien

Re: Bug: [PATCH] org-datetree-insert-line doesn't honor headline spacing customization [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]

[Bastien]

Hi Vasilij,

Vasilij Schneidermann  writes:

> When doing org captures using the datetree format, newly added headlines
> do not follow the value of `org-blank-before-new-entry'.  This seems to
> be the fault of `org-datetree-insert-line' using `insert' as opposed to
> `org-insert-heading' to do its work.  See the attachment for a proposed
> fix.

Thanks for the patch.  I tried it and these two tests fail:

   FAILED  test-org-datetree/find-date-create
   FAILED  test-org-datetree/find-iso-week-create

Perhaps you can check the value of `org-blank-before-new-entry' and
insert a blank line only if needed?

-- 
 Bastien

Re: [PATCH] ob-python.el: Fix issue with sessions on remote machines

[Bastien]

Hi Jack,

Jack Kamm  writes:

> I agree with this policy, and am more or less following it already,
> though it's good to be explicit.

Yep, for future references as well.

I think it would be good to have more maintainers, not just for files
but for bigger areas of the code (Babel, Agenda, Export engine, Table,
Spreadsheet, etc.)

> I'm keeping an eye out for Python-related mail, but if it looks like
> I've missed one, add me to the TO or CC field to ensure it lands in my
> inbox.
>
> I appreciate the freedom to make changes to ob-python, but of course
> defer to you, Nicolas, and Kyle, and seek out guidance when unsure.

Thanks for your time and help again!

-- 
 Bastien

Re: Adaptive Org faces in headings?

[Bastien]

Dear Protesilaos,

thank you very much for your feedback.  Could you insert a small
picture showing where faces customization don't interact nicely,
e.g. when using different heights for org-todo org-level-1?

It would help deciding whether this is an issue for Org or for
Emacs in general regarding faces interaction.

Thanks in advance!

-- 
 Bastien

Re: Bug: [patch] Fix org-babel-result-to-file never expanding links when babel is evaluated in indirect buffer [9.3.7 (release_9.3.7-728-g1efc4e @ /home/yantar92/.emacs.d/straight/build/org/)]

[Bastien]

Hi Ihor,

I applied an updated version of your patch as f45591630,
just adding a changelog.

Thanks,

-- 
 Bastien

Re: [PATCH] ob-python.el: Fix issue with sessions on remote machines

[Jack Kamm]

Hi Bastien,

> - A local maintainer is expected to reply to requests and bug reports
>   regarding the local functionalities he oversees.
>
> - A local maintainer can commit changes directly to the file(s) he
>   maintains (either submitted changes or his own).
>
> - Core maintainers have the final word on any change in any file (so
>   in case of a disagreement with a local maintainer, core maintainers
>   have priority.)
>
> In general, I would like to encourage "optimistic merging" from more
> "local" maintainers.
>
> Does that sound right?  When in doubt, always discuss changes first.

I agree with this policy, and am more or less following it already,
though it's good to be explicit.

I'm keeping an eye out for Python-related mail, but if it looks like
I've missed one, add me to the TO or CC field to ensure it lands in my
inbox.

I appreciate the freedom to make changes to ob-python, but of course
defer to you, Nicolas, and Kyle, and seek out guidance when unsure.

Cheers,
Jack

Re: Bug: inserting capture template [9.3.7 (release_9.3.7-705-gea9463 @ /home/nick/elisp/org-mode/lisp/)]

[Bastien]

Hi Nick,

thanks for the detailed recipe.  

FWIW, I was able to reproduce this bug.

-- 
 Bastien

Re: vertical spacing between lines in a list at odt-export

[Bastien]

Dear Heinz,

Heinz Tuechler  writes:

> thank you - I know that. The problem seems to be that in the odt-file
> all lists, as well as all "normal" text share the same format. In my
> German version of LibreOffice it is called "Textkörper".
> So, if I modify that format in a ODT_STYLES_FILE it changes all the
> "normal" text, not only the lists.
> If I were able to assign a different format to lists, then your proposal
> would be the optimal solution. Until now I did not find out, how to
> assign such a different format to lists.

Perhaps you can send a feature request to the LibreOffice team?

> Why do I use lists at all? It is, because they offer a hierarchical way
> of description, but, contrary to headings and subheadings, after the end
> of a list, you jump to the same level as before the list. Instead with
> headings and subheadings I think, I can go back to the level at the
> beginning only by inserting a new (sub)heading of the desired level.
> Maybe I am missing some alternative.

Perhaps try M-RET in a heading or explore `org-adapt-indentation' (I'm
not sure I completely grok your need, hence the suggestions.)

Best,

-- 
 Bastien

Re: Markup border outdated in spec?

[Bastien]

Hi Kim,

kim.lindber...@gmail.com writes:

> I believe Nicolas Goaziou fixed this in the spec already. 

I should have thought of this :)  Thanks for confirming!

> The use-case where I ran into this issue, if you're curious, is the
> README.org file here https://github.com/talyz/fromElisp. As you can
> see, some of the function names under the `Other functions` are
> rendered incorrectly by the GitHub renderer, but renders and exports
> just fine in Org.

Thanks for this additional information, always useful for the
casual reader of the list (hello casual reader!)

-- 
 Bastien

Re: ob-java and ob-haxe

[Bastien]

Hi Ian,

ian martins  writes:

> It primarily adds features.

Okay, thanks for the feedback, let's wait a bit then.

> It fixes the problem reported here [1] but that's probably not a
> common problem and the person who reported it probably already
> migrated.

Indeed.

Best,

-- 
 Bastien

Re: Emacs brings itself to the foreground when preparing agenda with org-agenda-include-diary t

[Bastien]

Hi Friedrich,

Friedrich Delgado  writes:

> I'd like to be able to use org-agenda-include-diary but disable the
> behaviour that emacs raises itself.

My guess is that the Emacs window pops up becaus of diary, not 
because of Org.

> Please CC me in replies, as I'm not subscribed to this list.
>
> For completeness, I've been asked to file an issue against qtile,
> because they want to be able to prevent such behaviour from clients
> on the window manager side, and they're also dealing with focus
> problems recently. https://github.com/qtile/qtile/issues/1756

I think this kind of configuration should happen on the window-manager
side indeed.

Best,

-- 
 Bastien

Re: Question about org agenda views

[Bastien]

Hi Fredrik,

Fredrik Salomonsson  writes:

> 1: Is there a way to add settings to `org-agenda-list` similar to
> `org-agenda-custom-commands`?

Nope.

> 2: Is there a setting to remove the priority?

Not right now -- and in general, syntactically-wise, priorities
are considered part of the headline "text".

Best,

-- 
 Bastien

Re: Bug: ob-shell cannot forward empty blocks to stdin [9.3.1 (release_9.3.1-101-gc9ee3d @ /home/lockywolf/OfficialRepos/org-mode/lisp/)]

[Bastien]

Hi Vladimir,

Vladimir Nikishkin  writes:

> The MWE would be the following:
>
> #+name: empty
> #+begin_quote
>
> #+end_quote
>
> #+begin_src shell :stdin empty
> #+end_src
>
> Now if you try to execute the second block, you will get a lisp error.
> "Wrong argument integer-or-marker-p"

It probably has been fixed a long time ago because I cannot reproduce
it here.  Sorry if I lost part of the discussion about this bug.  If
you can confirm the fix, that'd be good.

Thanks,

-- 
 Bastien

Re: ob-java and ob-haxe

[ian martins]

It primarily adds features.

It fixes the problem reported here [1] but that's probably not a common
problem and the person who reported it probably already migrated.

[1] https://orgmode.org/list/87d05nidu1@iki.fi/

On Sat, Sep 5, 2020 at 9:04 AM Bastien  wrote:

> Hi Ian,
>
> ian martins  writes:
>
> > Sure, I'd be happy to maintain ob-java.
>
> Thanks!  Does your work on ob-java.el fix bugs or does it foremost
> add new features?  If the former, we can add it now to master, then
> add you as a maintainer immediately.
>
> > The drawback with keeping ob-haxe in an external repo is that the
> > tests won't run when org-mode is changed, but in practice its tests
> > are very similar to ob-java's so the actual risk of it being broken
> > by a change will be small if ob-java is in core.
> >
> > I'll submit ob-haxe to GNU ELPA after ob-java has been accepted. That
> > way I can take out the common parts of ob-haxe which will have been
> > incorporated into ob-core.
>
> Yes -- for now (< 9.4) we cannot accept changes in ob-core.el.
>
> Thanks,
>
> --
>  Bastien
>

Re: Markup border outdated in spec?

[kim . lindberger]

Hi Bastien!

I believe Nicolas Goaziou fixed this in the spec already. I sent this
in two times because my first message got stuck, but eventually both
were sent to the list; I'm sorry for the confusion.

The use-case where I ran into this issue, if you're curious, is the
README.org file here https://github.com/talyz/fromElisp. As you can
see, some of the function names under the `Other functions` are
rendered incorrectly by the GitHub renderer, but renders and exports
just fine in Org.

Best regards,
Kim

On Fri, 2020-09-04 at 11:43 +0200, Bastien wrote:
> Hi Kim,
> 
> thanks for reporting this.
> 
> kim.lindber...@gmail.com writes:
> 
> > There seems to be an inconsistency between the Org syntax spec and
> > the
> > actual behavior regarding text markup: the spec forbids `,`, `'`
> > and
> > `"` in the border, yet it seems to work just fine to use them there
> > in
> > the current version of Org. I think it's great that Org mode
> > supports
> > this, but since the spec hasn't been updated to reflect this
> > change,
> > external Org parsers which follow it don't. An example is org-ruby,
> > which is used by both GitLab and GitHub to render README files: 
> > https://github.com/wallyqs/org-ruby/issues/36
> 
> Can you provide an example configuration that we can test for this?
> 
> Also, can you send a patch against the documentation if we need to
> fix
> it?  See https://orgmode.org/worg/org-contribute.html
> 
> Thanks!
> 

Re: table formula, empty field, duration

[Bastien]

Hi Kristof,

Kristof Ralovich  writes:

> it appears to me that the concept of "empty field" is not defined for
> time durations, or it is quite different to how it is defined for
> numbers (using org-mode 9.1.9).
>
> In the first table, the empty row @6 produces an empty field for the sum
> ($5, first formula), that vmean is able to "skip" (second formula) and
> gives the expected result 8.25 (=33/4).
>
> #+TBLNAME: works_with_numbers
> | h | start | end | h | sum |h | h |
>
> |---+---+-+---+-+--+---|
> |   |08 |  18 |   |  10 |  |   |
> |   |11 |  15 |   |   4 |  |   |
> |   |09 |  20 |   |  11 |  |   |
> |   |10 |  18 |   |   8 |  |   |
> |   |   | |   | |  |   |
> |---+---+-+---+-+--+---|
> |   |   | |   |  33 | 8.25 |   |
>
> #+TBLFM: $5=if(typeof($3-$2)==12, string(""), $3-$2);E::@>$5=vsum(@2..@-1);
> #+TBLFM: @>$6=vmean(@2$5..@-1$5);

Can you provide a more minimal example?

The following table works correctly here (maint and master):

| mean1 | mean2 |
|---+---|
| 08:00 | 08:00 |
| 09:00 | 09:00 |
| 00:00 |   |
|---+---|
| 05:40 | 08:30 |
#+TBLFM: @5$1=vmean(@2..@-1);U
#+TBLFM: @5$2=vmean(@2..@-1);U

So I suspect this is something wrong with your first formula:

> #+TBLFM: $5=if(typeof($3-$2)==12, string(""), $3-$2);E

Let me know if you manage to nail down something more precise.

Thanks,

-- 
 Bastien

Re: Bug: error in org-table-justify-field-maybe - in conjunction with org-sbe [9.3.6 (9.3.6-elpa @ ~/.emacs.d/elpa/org-9.3.6/)]

[Bastien]

Hi Lester,

Lester Longley  writes:

> I am encountering an error when using this .org code:

Thanks a lot for the detailed report.

I prevented the error from occurring in maint (114d50982).

Best,

-- 
 Bastien

Re: Bug: Exporting internal link to special latex block [9.3.7 (9.3.7-14-gb2b587-elpa @ /home/lobo/.emacs.d/elpa/org-20200720/)]

[Bastien]

Hi Marco,

thanks for the feedback, I'm glad you found a workaround.

Marco Falconi  writes:

> However, it would be very nice if it was solved in org. 

Yes, me too.

> Also, my preference would be for the exported id to be the one given
> in the NAME attribute (as it is now), because I use it in the html
> file to name the theorem environment. Of course this is just my
> preference, and I would understand if the solution would work in
> another manner.

I think that's the natural expectation.

Best,

-- 
 Bastien

Re: ob-java and ob-haxe

[Bastien]

Hi Ian,

ian martins  writes:

> Sure, I'd be happy to maintain ob-java.

Thanks!  Does your work on ob-java.el fix bugs or does it foremost
add new features?  If the former, we can add it now to master, then 
add you as a maintainer immediately.

> The drawback with keeping ob-haxe in an external repo is that the
> tests won't run when org-mode is changed, but in practice its tests
> are very similar to ob-java's so the actual risk of it being broken
> by a change will be small if ob-java is in core.
>
> I'll submit ob-haxe to GNU ELPA after ob-java has been accepted. That
> way I can take out the common parts of ob-haxe which will have been
> incorporated into ob-core.

Yes -- for now (< 9.4) we cannot accept changes in ob-core.el.

Thanks,

-- 
 Bastien

Re: org-babel support for haxe

[ian martins]

That makes sense.

It's probably enough to keep the languages page [1] complete and up to
date. External repos should already have docs with the code.

[1] https://orgmode.org/worg/org-contrib/babel/languages.html


On Sat, Sep 5, 2020 at 3:24 AM Bastien  wrote:

> Hi Ian,
>
> ian martins  writes:
>
> > Hello. The included patch adds org-babel support for haxe (https://
> > haxe.org/). It allows main class and function definitions to be
> > optional, accepts variables and supports babel functional mode.
> > Please review.
>
> I'm not an Haxe user, so I cannot review the functionnalities, but
> from a cursory look, it seems fine.
>
> After 9.4, we will probably remove some Babel libraries from Org's
> core: we still need to decide on what criterium, but one candidate
> is to remove a Babel library if the corresponding language is not
> supported within Emacs core itself.
>
> If we go that route, we also need to do a better job at promoting
> external Babel libraries: perhaps a page on https://orgmode.org/worg
> would help.
>
> 2 cents,
>
> --
>  Bastien
>

Re: ob-java and ob-haxe

[ian martins]

Hi Bastien,

Sure, I'd be happy to maintain ob-java.

The drawback with keeping ob-haxe in an external repo is that the tests
won't run when org-mode is changed, but in practice its tests are very
similar to ob-java's so the actual risk of it being broken by a change will
be small if ob-java is in core.

I'll submit ob-haxe to GNU ELPA after ob-java has been accepted. That way I
can take out the common parts of ob-haxe which will have been incorporated
into ob-core.


On Fri, Sep 4, 2020 at 5:50 AM Bastien  wrote:

> Hi Ian,
>
> thanks for your work on this.  Changes for ob-java.el should go in
> core after the 9.4 release.  By the way, if you want to be ob-java.el
> maintainer, that'd be appreciated too!
>
> For ob-haxe.el, as Kyle suggests, let's prefer GNU ELPA (or upcoming
> Non-GNU ELPA): Elisp files in contrib/ will be exfiltrated after 9.4.
>
> Thanks,
>
> --
>  Bastien
>

Re: Bug: Exporting internal link to special latex block [9.3.7 (9.3.7-14-gb2b587-elpa @ /home/lobo/.emacs.d/elpa/org-20200720/)]

[Marco Falconi]

Dear Bastien,

Thanks for the update. For the moment I have worked around the bug by putting an
html-export block in the org file with the correct href when I have to put a 
link to it.

However, it would be very nice if it was solved in org. Also, my preference 
would be for
the exported id to be the one given in the NAME attribute (as it is now), 
because I use it
in the html file to name the theorem environment. Of course this is just my 
preference,
and I would understand if the solution would work in another manner.

Best regards,
_
Marco


Bastien  writes:

> Hi Marco,
>
> Marco Falconi  writes:
>
>> I am trying to export to html a labeled latex special block (a theorem
>> environment, defined by #+begin_theorem [...] #+end_theorem ). I have named 
>> the theorem with
>>
>> #+NAME: thm:mv (I also tried with #+LABEL: and the behavior described below 
>> does not change).
>>
>> I have a link to such block later in the body, in the form [[thm:mv]]. The 
>> link works
>> perfectly in the org file, however it is exported incorrectly to html.
>>
>> In fact, while the theorem environment gets exported in the html as
>>
>>
>>
>>[...]
>>
>>
>>
>> ,
>>
>> the link does not href to "#thm:mv" as expected, but to an auto-generated 
>> label:
>>
>> 
>> 1
>> 
>>
>> I have tried to play around a bit with export options, but to no avail.
>>
>> Is this a known bug?
>
> I also confirm this bug.  I've had a quick look.  It looks like
> `org-export-get-reference' get fooled by trying to provide with a "new
> reference".  I hope Nicolas can have a look because this area of the
> code is quite complexe.
>
> Thanks,

Re: vertical spacing between lines in a list at odt-export

[Heinz Tuechler]

Dear Bastien,

thank you - I know that. The problem seems to be that in the odt-file
all lists, as well as all "normal" text share the same format. In my
German version of LibreOffice it is called "Textkörper".
So, if I modify that format in a ODT_STYLES_FILE it changes all the
"normal" text, not only the lists.
If I were able to assign a different format to lists, then your proposal
would be the optimal solution. Until now I did not find out, how to
assign such a different format to lists.

Why do I use lists at all? It is, because they offer a hierarchical way
of description, but, contrary to headings and subheadings, after the end
of a list, you jump to the same level as before the list. Instead with
headings and subheadings I think, I can go back to the level at the
beginning only by inserting a new (sub)heading of the desired level.
Maybe I am missing some alternative.

best regards,

Heinz

Bastien wrote/hat geschrieben on/am 05.09.2020 10:25:

Hi Heinz,

Heinz Tuechler  writes:


Modifying it from within LibreOffice would mean to change every list by
hand.


You can also create a dedicated ODT style and use it from within your
Org file -- see "Applying custom styles: the easy way" in the manual:

https://orgmode.org/manual/Applying-custom-styles.html

 To apply an ODT style to a particular file, use the
 ‘ODT_STYLES_FILE’ keyword as shown in the example below:

  #+ODT_STYLES_FILE: "/path/to/example.ott"

 or

  #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))

HTH,

Re: Bug: Moving org-inline-tasks produces error message [9.3.6 (9.3.6-elpa @ /home/c.hemminghaus/.emacs.d/elpa/org-9.3.6/)]

[Bastien]

Hi Christian,

Christian Hemminghaus  writes:

> I ran into an error message while composing structured text with
> org-mode using org-inline-tasks. The error appears when moving around
> inline tasks in my document.

yes, I confirm this bug.

The wrong behavior is here, whether you loaded org-inlinetask or not,
but the error ("Invalid...") is only triggered when org-inlinetask is
loaded.

I guess this is due to `org-element-at-point' considering inline tasks
as headlines, thus trying to move only one line.

Nicolas, would you know how to solve this (if it does not get us into
hard syntactic decisions)?

-- 
 Bastien

Re: Bug: Exporting internal link to special latex block [9.3.7 (9.3.7-14-gb2b587-elpa @ /home/lobo/.emacs.d/elpa/org-20200720/)]

[Bastien]

Hi Marco,

Marco Falconi  writes:

> I am trying to export to html a labeled latex special block (a theorem
> environment, defined by #+begin_theorem [...] #+end_theorem ). I have named 
> the theorem with
>
> #+NAME: thm:mv (I also tried with #+LABEL: and the behavior described below 
> does not change).
>
> I have a link to such block later in the body, in the form [[thm:mv]]. The 
> link works
> perfectly in the org file, however it is exported incorrectly to html.
>
> In fact, while the theorem environment gets exported in the html as
>
>
>
>[...]
>
>
>
> ,
>
> the link does not href to "#thm:mv" as expected, but to an auto-generated 
> label:
>
> 
> 1
> 
>
> I have tried to play around a bit with export options, but to no avail.
>
> Is this a known bug?

I also confirm this bug.  I've had a quick look.  It looks like
`org-export-get-reference' get fooled by trying to provide with a "new
reference".  I hope Nicolas can have a look because this area of the
code is quite complexe.

Thanks,

-- 
 Bastien

Re: Website revamp?

[Colin Baxter]

Dear Timothy,

> TEC   writes:

> Hello everyone :)

> The end is now in sight! Other than the somewhat bare index page,
> I feel that we're nearing complete coverage of the current site
> (at least all the 'main' pages).

> If you haven't already please give my revamp project a look:
> http://orgmode.tecosaur.com, and let me know if you've got any
> feedback or suggestions.

This look really nice - simple but comprehensive and very readable.

There is a slight issue with your link "javascript:show_org_source()" in
that it wont load of course in non-js browsers such as eww and emacs-w3m. 

Best wishes,

Colin.


Colin Baxter
URL: http://www.Colin-Baxter.com
-
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
-

Re: Bug: ODT exporter does not honour +LANGUAGE line [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.1/lisp/org/)]

[Bastien]

Hi Marvin,

‘quintus’ Gülker  writes:

> the ODT exporter always exports as English, even if a document is not
> written in English and contains a corresponding +LANGUAGE line. 

thanks for reporting this.

AFAIK, the language of an ODT document is set through the document
style.  When exporting from Org, that would be OrgOdtStyles.xml :

https://code.orgmode.org/bzg/org-mode/src/master/etc/styles/OrgOdtStyles.xml#L20

You can use your own style (see the manual) but you are right that
this is independent from setting the langage through #+LANGUAGE.

HTH,

-- 
 Bastien

Re: Where to customize the generated ID of html export? i.e outline-container-org

[TEC]

Bastien  writes:

> When you upgrade Org, please report whether your code still works so
> that we can discussing its integration as a feature in Org, if that's
> useful to others as well.

For what it's worth, I'm just a few commits behind head and this:
https://tecosaur.github.io/emacs-config/config.html#nicer-generated-heading,code--2
is currently working quite nicely for me.

This was the subject of an earlier email to this list:
https://orgmode.org/list/e1jxajq-0004dk...@lists.gnu.org/ but there
didn't seem to be much interest.

Timothy.

Re: [ISSUE] org-agenda with clocktable infinite on logbook which has text-propertize links

[Bastien]

Hi,

stardiviner  writes:

> When org-agenda have option ~org-agenda-start-with-clockreport-mode~ enabled.
> Generate Org Agenda with clocktable. Here is an Org content which has logbook
> contains link which is text-propertized using Emacs extension
> https://github.com/stardiviner/org-link-beautify (It's written by myself).
>
> #+begin_src org
> ,** PROJECT google-translate [11/22]
>SCHEDULED: <2020-06-09 Tue>
>:LOGBOOK:
>CLOCK: [2020-06-10 Wed 09:19]--[2020-06-10 Wed 10:34] =>  1:15
>- create PR https://github.com/atykhonov/google-translate/pull/118
>CLOCK: [2020-06-10 Wed 09:09]--[2020-06-10 Wed 09:14] =>  0:05
>- finished bump version process, tag v0.12.0, draft GitHub release.
>
> #+end_src
>
> When I remove that text-propertized link, org-agenda generate fine. When have
> that text-propertized link, org-agenda is infinitely un-finished.

I cannot reproduce this with latest Org and GNU Emacs 28.0.50. Can you?

-- 
 Bastien

Re: Documentation for org html head scripts

[Bastien]

Hi Paramjit,

Paramjit Singh  writes:

> I was trying to have a clean html-head while exporting using `ox-html`, and 
> even
> while setting
>
> (setq org-html-head-include-default-style nil)
> (setq org-html-mathjax-template "")
>
> I would get some code in the header, as shown in the following reddit post:
> https://old.reddit.com/r/emacs/comments/humgny/getting_rid_of_excess_header_in_org_html_export/
>
> I tried following the org manual, but a solution was not mentioned in
> it. The person who
> solved the issue for me in the reddit post recommended letting the devs know
> to add it in the documentation. Namely, something like:
> "Customizing the variable org-html-head-include-scripts to nil,
> disables any scripts
> being added to the html-head" (the variable is indeed mentioned,
> however, a small
> paragraph regarding how to get a clean html-head could be added).

Thanks for the suggestion, I added a small section explaining how to
export to bare HTML (see ed8369aff in master).

Best,

-- 
 Bastien

Re: Emacs-orgmode Digest, Vol 172, Issue 21

[Bastien]

Hi Ian,

Ian Garmaise  writes:

> In this version of the org-mode manual in the current repo, there are
> three capture template properties (shown in the source) which are not
> documented:
>
> :jump-to-captured
> :empty-lines-before
> :empty-lines-after
>
> I hope that these can be added in time for v. 9.4

thanks for reporting this, I fixed it in 2af977016 in the master
branch, this will be in 9.4.

Best,

-- 
 Bastien

Re: Org Spreadsheet Documentation Suggestion

[Bastien]

Hi Michael,

Michael Partridge  writes:

> At the moment I do not have time. I haven't used the tool in a while
> since then so I also don't have the vision.

No problem, thanks for replying.  Perhaps someone else can amend the
documentation, if he sees your point.

-- 
 Bastien

Re: [PATCH] org-capture: Update plist before finalizing

[Bastien]

Hi Leo,

applied as 3008fb45d on maint, thanks a lot!

Best,

-- 
 Bastien

Re: [PATCH] org-capture: Update plist before finalizing

[Leo Vivier]

Hi there,

Kyle Meyer  writes:

> Thanks for the detailed write-up and the patch (and sorry for the slow
> reply).

No worries, and thanks for the review.

> It'd be good to at least point to the motivation/usecase for this change
> here.  (Your description section above already does a nice job of
> that.)

Done.  I’ve also added a link to this thread.

> Convention nit: please end your comment with a period.

Done.

> Perhaps add a brief mention of `org-capture-after-finalize' (or some
> other hint of why) here.

I’ve added some details to bridge the gap with the docstring for
`org-capture-current-plist'.

You’ll find the amended commit below.

Best,

-- 
Leo Vivier
Freelance Software Engineer
Website: www.leovivier.com | Blog: www.zaeph.net
>From ab47e50dae4029622d3e8378f816f77153c180d9 Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Sat, 25 Jul 2020 21:53:07 +0200
Subject: [PATCH] org-capture: Update plist before finalizing
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org-capture.el (org-capture-finalize): Update
`org-capture-plist' with local-value before finalizing.

We use the global-variable `org-capture-plist' to populate the
local-variable `org-capture-current-plist' on the init of the
`org-capture' buffer.  However, we do not do the opposite (i.e. update
the global-variable with the local-variable) on
`org-capture-finalize'.

This is fine for the majority of `org-capture-finalize', since we’re
using the LOCAL arg of `org-capture-get' to read
`org-capture-current-plist' instead of `org-capture-list', but this
trick does not work for `org-capture-after-finalize', since the hook
is run after the `org-capture-buffer' has been closed.

This causes problem with `:kill-buffer t', and it limits what can be
done with cleanup functions in `org-capture-after-finalize'.

See  for details.
---
 lisp/org-capture.el | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 0ca75c772..b74978c82 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -735,6 +735,11 @@ captured item after finalizing."
 
   (run-hooks 'org-capture-prepare-finalize-hook)
 
+  ;; Update `org-capture-plist' with the buffer-local value.  Since
+  ;; captures can be run concurrently, this is to ensure that
+  ;; `org-capture-after-finalize-hook' accesses the proper plist.
+  (setq org-capture-plist org-capture-current-plist)
+
   ;; Did we start the clock in this capture buffer?
   (when (and org-capture-clock-was-started
 	 org-clock-marker
-- 
2.28.0

Re: Org mode patch: when building sparse tree, suggest only local tags in minibuffer

[Bastien]

Hi,

"E.L.K."  writes:

> I found that if I do "C-c C-c" on heading, it suggests only local
> tags in the minibuffer, but when I do "C-m / m" (build sparse tree)
> it suggests agenda tags together with local tags.
>
> It does not make sense to build sparse tree in buffer using tags that
> are not in this buffer, I think. So there is small patch in attempt
> to fix it.

thanks for the patch.  I add a Changelog and documented the new
parameter `only-local-tags' in the docstring, then applied it as
f2d41de3e in maint.

If you can provide complete patches for the next ones, that'd be
great, thanks in advance.

Best,

-- 
 Bastien

Re: Website revamp?

[Martin Schöön]

On Fri, 4 Sep 2020 at 11:37, Bastien  wrote:

> Hi Timothy,
>
> TEC  writes:
>
> > If you haven't already please give my revamp project a look:
> > http://orgmode.tecosaur.com, and let me know if you've got any feedback
> > or suggestions.
>
> Sorry for being so late in commenting but here are my two cents:

* Nice, 'modern' look and feel.
* Code examples are over-sized. I think they should be smaller and yet
would not be hard to read. Disclaimer: I have only tried your work on my
Linux desk-top computer and its 24 inch screen.
* The link to the documentation is a one-way link. I have to use the 'back'
functionality of my browser to get back to the main site.

That's all for now. I have not had time for anything ambitious such as
proof reading the text.

-- 
Martin Schöön

http://hem.bredband.net/b262106/index.html

Re: org-tables, export only certain column (csv)

[Bastien]

Hi Uwe,

Uwe Brauer  writes:

> 4 years ago Michael Brand provided the following nice solution, which as
> far as I know is still not in master.

Please let us know if you find a generic solution for this, we could
then add it to worg/org-hacks.org or perhaps.

-- 
 Bastien

Re: Bug: Clock table documentation [9.3.7 (release_9.3.7-644-ge3a724 @ /home/nick/elisp/org-mode/lisp/)]

[Bastien]

Hi Nick,

thanks for reporting this, I fixed it with 00a782112 in the maint
branch.

All best,

-- 
 Bastien

Re: [bug?] should ltxpng be ltximg in ox-html?

[Bastien]

Hi Eric,

Eric S Fraga  writes:

> line 1696 of ox-html.el (up to date version on git) is:
>
>:alt (if (string-match-p "^ltxpng/" source)
>
> I wonder whether "^ltxpng" should actually be "^ltximg"?
>
> Better yet, should it not be built from the value of
> org-preview-latex-image-directory, defined as a custom variable and used
> in one place in ox-html?  Or have I confused two different aspects of
> LaTeX images?  I'm asking because the hardcoded pattern doesn't pick up
> the alt= text for accessibility in HTML export of LaTeX fragments.

I think using `org-preview-latex-image-directory' is the way to go.

I did this in 9ad3606bf in the master branch.

If you have a chance to test and confirm the fix, that'd help.

Thanks,

-- 
 Bastien

Re: Bug: customize type for `org-agenda-category-icon-alist' [9.3 (release_9.3 @ /usr/share/emacs/27.0.91/lisp/org/)]

[Bastien]

Hi,

applied as 8ae058ebe in the maint branch, thanks.

If you need directions on how to make a patch, please just say so,
it helps a lot by reducing the maintainance burden.

Thanks,

-- 
 Bastien

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

[Bastien]

Hi Adam,

Adam Faryna  writes:

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

Can you show the first of org-at-timestamp-p you would need for your
purpose? 

Does it solve a general problem?

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

We cannot amend the implementation of org-at-timestamp-p just for
flexibility's sake, because there would be no good reason not to 
change other functions as well.

If you have a generic change to propose to org-at-timestamp-p please
go ahead.

Thanks,

-- 
 Bastien

Re: vertical spacing between lines in a list at odt-export

[Bastien]

Hi Heinz,

Heinz Tuechler  writes:

> Modifying it from within LibreOffice would mean to change every list by
> hand.

You can also create a dedicated ODT style and use it from within your
Org file -- see "Applying custom styles: the easy way" in the manual:

https://orgmode.org/manual/Applying-custom-styles.html

 To apply an ODT style to a particular file, use the
 ‘ODT_STYLES_FILE’ keyword as shown in the example below:

  #+ODT_STYLES_FILE: "/path/to/example.ott"

 or

  #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))

HTH,

-- 
 Bastien

Re: ical2org.awk

[Bastien]

Hi Eric,

Eric S Fraga  writes:

> On Friday,  4 Sep 2020 at 12:34, Bastien wrote:
>> So please feel free to move ahead with moving ical2org.awk.
>
> I'm not entirely sure what is meant to be done and by whom!  If you wish
> to replace the link on Worg to the github site you found, by all means
> do so.  

yes, this is what I mean and what I've partially just done in Worg
(see commit 08276954).  I'm not removing the code yet, as it may have
been referenced on the web, but at least we point to a more recent
version of it.

Thanks,

-- 
 Bastien

Re: Where to customize the generated ID of html export? i.e outline-container-org

[Bastien]

Hi Ivan,

Ivan Tadeu Ferreira Antunes Filho  writes:

> (I use Org mode 9.1.9, I haven't tested this code with more recent
> versions)

When you upgrade Org, please report whether your code still works so
that we can discussing its integration as a feature in Org, if that's
useful to others as well.

Thanks,

-- 
 Bastien

Re: [PATCH] ob-python.el: Fix issue with sessions on remote machines

[Bastien]

Hi Jack,

Jack Kamm  writes:

>> Would you be okay to add yourself as the ob-python.el maintainer?
>
> Sure, I've added myself as maintainer to the header of ob-python.el.

Thanks!

>> I suggest we have a policy that "Org maintainer(s)" have the last
>> words on everything in Org's core, but that individual maintainers,
>> when known from the header section of an Elisp file, have the very
>> "first look" on bug reports and feature suggestions.
>>
>> WDYT?
>
> I'm trying to review ob-python related patches and mail as I notice
> them, and monitor the list for mails with "python" in the subject,
> though some may fall through the cracks occasionally, especially when my
> workload is heavy.
>
> Should I merge in patches to ob-python.el, as I did here? Or should I
> simply review them, and let the core maintainers merge them in after
> review?

Sorry, my policy proposal was incomplete:

- A local maintainer is expected to reply to requests and bug reports
  regarding the local functionalities he oversees.

- A local maintainer can commit changes directly to the file(s) he
  maintains (either submitted changes or his own).

- Core maintainers have the final word on any change in any file (so
  in case of a disagreement with a local maintainer, core maintainers
  have priority.)

In general, I would like to encourage "optimistic merging" from more
"local" maintainers.

Does that sound right?  When in doubt, always discuss changes first.

Thanks!

-- 
 Bastien

Re: [PATCH] Re: Export to attach directory?

[Bastien]

flare  writes:

> While on the topic of attachments, a low priority goal which may be nice
> is to have a org-attach method that allows for automatic encryption of
> attachments. But again, not very important

Patch welcome!

-- 
 Bastien

Re: [PATCH] improve ol-man.el with occur searching

[Bastien]

Hi,

"numbch...@gmail.com"  writes:

> Thanks for reviewing my code and points. :)
> Fixed in this attached patch.

Applied in master, thanks.

-- 
 Bastien

Re: [PATCH] Org-mode publish avoids inserting licensed content into target documents.

[Bastien]

Hi Anthony,

sorry for the late reply.  I applied your change on the master 
branch as 471054136, thanks for this.

All best,

-- 
 Bastien

Re: [BUG] [C-u C-u C-c C-o] open link with external program invalid to open file

[Bastien]

Hi,

stardiviner  writes:

> When I press =[C-u C-u C-c C-o]= to open an image file link with system 
> external
> program. It can't open the image file.

I cannot reproduce the problem here.

If you still have this issue, can you provide a minimal reproducible
example?

Thanks,

-- 
 Bastien

Re: FWD: Org-Babel Support for Powershell

[Bastien]

Hi Stanislaw,

stanislaw_lem--- via "General discussions about Org-mode."
 writes:

> I ask the maintainer of org-babel Bastien Guerry, if it is possible
> to include Powershell support for org-babel. Monsieur Guerry told me
> to ask you via email.

sorry for the late reply.  As I just said to Ian, new Babel libraries
are always good, but the route ahead for Org is to have *less* of such
libraries in Org's core, not more.

So please host and share your code in a way that is easy for anyone to
find, and we will do our best to promote external useful Babel libraries.

Thanks,

-- 
 Bastien

Re: How to annotate past clock entries so the note shows in agenda?

[Bastien]

Hi Tory,

torys.ander...@gmail.com (Tory S. Anderson) writes:

> How can I add clock-out notes after the event? Must I manually go to
> the clock event and type in my note there, or can I utilize the same
> prompt somehow?

No, you need to manually type your note in a different prompt.

I don't think we should tangle Org note-taking functions with other
functions, they are very specific, both in their usage and in their
implementation.

Best,

-- 
 Bastien

Re: [PATCH] Re: Export to attach directory?

[flare]

While on the topic of attachments, a low priority goal which may be nice
is to have a org-attach method that allows for automatic encryption of
attachments. But again, not very important

Bastien writes:

> Hi Eric,
>
> sorry for the late reply -- I don't use attachments that much
> but I see how this could be useful once correctly advertized and
> documented.
>
> Eric Abrahamsen  writes:
>
>> Would something along these lines be considered for inclusion?
>
> Yes, sure, for after 9.4 -- please go ahead with a proper patch.
>
> Thanks,

Re: [PATCH] New function org-agenda-filter-set

[Bastien]

Hi Kyle and Stefan,

Kyle Meyer  writes:

> Bastien writes:
>
>> I've seen problems with this new function when completing in agendas:
>> hitting '/' does not see what tags are available for completion in the
>> current buffer.
>>
>> I'm reverting e9b1b8fde5 from master for now. If you see what's wrong,
>> please resubmit a patch.
>
> Stepping through both versions, it looks like the crucial thing is that
> org-agenda-get-represented-tags needs to be called _before_ the
> completion function.  If it's not, org-agenda-filter-completion-function
> calls -get-represented-tags with an unset cache, and it returns nil
> because the (derived-mode-p 'org-agenda-mode) condition is nil.
>
> The same goes for org-agenda-get-represented-categories.

Thanks for analysing this -- Stefan, if you still feel like going
through this refactoring, this would be a welcome improvement for
after 9.4 (coming soon).

-- 
 Bastien

Re: [PATCH] Re: Export to attach directory?

[Bastien]

Hi Eric,

sorry for the late reply -- I don't use attachments that much
but I see how this could be useful once correctly advertized and
documented.

Eric Abrahamsen  writes:

> Would something along these lines be considered for inclusion?

Yes, sure, for after 9.4 -- please go ahead with a proper patch.

Thanks,

-- 
 Bastien

Re: [PATCH] goto: Avoid invoking org-mode for outline navigation

[Bastien]

Hi Kyle,

Kyle Meyer  writes:

> Kyle Meyer writes:
>
>> Ihor Radchenko writes:
>>
>>> Is there even a need to call the whole (org-mode). The new buffer is
>>> an indirect buffer. It should already have org-mode activated (at least,
>>> we can check for it and not call (org-mode) unnecessarily). If we just
>>> want to reset initial visibility, (org-overview) is already doing the
>>> job of (org-set-startup-visibility) from (org-mode).
>>
>> Hmm, thanks for taking a step back.  It does seem like the org-mode call
>> should be unnecessary. (I haven't tried yet.)
>
> Based on light testing, dropping the org-mode call doesn't seem to break
> anything.  I don't use the outline interface to org-goto, so it'd be
> appreciated if anyone who does could try it out and see if anything
> feels off.

I tested the patch and M-x org-goto RET and things run fine here.

I applied your patch against maint.

Thanks!

-- 
 Bastien

Re: restore window configuration after org-edit-src-exit

[Bastien]

Hi Edgar,

ed...@openmail.cc writes:

> Hello. I would like to request this to be pushed onto the =maint=
> branch (7684b59c7) or make it the default, please.

this has been applied in the master branch back in January,
it will be part of Org 9.4.

Best,

-- 
 Bastien

Re: Bug: issue with babel and sqlite [9.3 (release_9.3 @ /usr/share/emacs/27.0.91/lisp/org/)]

[Bastien]

Hi,

rrandr...@gmail.com writes:

> Hi. I am testing the pretest. And I have try the snippet below on
> emacs -Q

Thanks for reporting this.

Can you instrument the `org-babel-read' function?

You can do this with C-h f org-babel-read RET and then C-u C-M-x
on the function's definition.

Then run your code and see where `org-babel-read' exactly fail at
parsing.

Thanks,

-- 
 Bastien

Re: WIP: Org-plot work

[Bastien]

Hi Timothy,

TEC  writes:

> I now have a more complete patch set if any maintainers would be
> ready to receive and review it.

Please share it on the list if you feel it's ready for a review.

Also, Mario has been working on org-plot.el too -- see these threads:

https://orgmode.org/list/c7768c14-711e-a719-87d7-8f7ab2317...@anche.no
https://orgmode.org/list/2abe19ad-2237-991d-5325-82b3f8704...@gmail.com
https://orgmode.org/list/d9f86ea0-0ee6-0ff0-219a-e0dbc27e1...@anche.no
https://orgmode.org/list/f55ce1a9-9c96-119f-ad8a-d28ba66e1...@anche.no
https://orgmode.org/list/2296ccd0-e6eb-5d0b-c5d9-c33b60932...@anche.no

I'm not an org-plot.el user so I cannot comment on the usefulness and
correctness of the code, but perhaps you need to coordinate your work?

That would be for after 9.4.

Thanks!

-- 
 Bastien

Re: org-babel support for haxe

[Bastien]

Hi Ian,

ian martins  writes:

> Hello. The included patch adds org-babel support for haxe (https://
> haxe.org/). It allows main class and function definitions to be
> optional, accepts variables and supports babel functional mode.
> Please review.

I'm not an Haxe user, so I cannot review the functionnalities, but
from a cursory look, it seems fine.

After 9.4, we will probably remove some Babel libraries from Org's
core: we still need to decide on what criterium, but one candidate
is to remove a Babel library if the corresponding language is not
supported within Emacs core itself.

If we go that route, we also need to do a better job at promoting
external Babel libraries: perhaps a page on https://orgmode.org/worg
would help.

2 cents,

-- 
 Bastien

Re: [PATCH] prevent mangled output in ob-J by allowing sit-time duration to be customized

[Bastien]

Hi Joseph,

Joseph Novakovich  writes:

> Sure, I'd be happy to help!

Thanks!  I added you as the ob-J.el maintainer in 0e580d169.

-- 
 Bastien

Re: Folding headings which contain only blank lines

[Bastien]

Hi Dmitrii,

Dmitrii Korobeinikov  writes:

> When everything is folded (e.g. on startup), ellipses show after every
> heading which has anything in it at all. This is true as well for the
> headings containing only one or more blank lines. And while you can
> unfold such lines, you can't fold them back unless you use Shift-Tab.
> This appears to be inconsistent. Shouldn't it be possible to tab fold
> such headings too?

this should be fixed now (in ee3c3b554), thanks for reporting this.

-- 
 Bastien