org-capture-fill-template %T drops end time

[General discussions about Org-mode.]

Hello, new to emacs and elisp. 

Full context can be seen here: 
https://www.reddit.com/r/emacs/comments/1ju3pk8/comment/mm0o5la/

I'm trying to use org-capture templates (file+datetree+prompt) to enter the 
time I spend on things at work. I want to have the date and begin and end times 
in the note added without re-selecting the date.

The suggestion was to use %T, but I noticed the end time was cut off. The other 
user in the thread sent this: 
I dug into org-capture-fill-template, and discovered that the code handling the 
%T placeholder uses a (let* ((org-end-time-was-given nil))) to suppress the 
end-time.

I was curious if this was something that could be changed, or if we could get a 
different placeholder that could have end times?

I managed to work around this with the code below, it works, but doesn't do as 
much to verify the time.
  (setopt org-capture-templates
  (append org-capture-templates
  '(("s" "Schedule entry" entry
 (file+datetree+prompt "~/org/schedule.org")
 "* %^{Timecode}\nDescr: %^{Description}\nSCHEDULED: 
<%<%Y-%m-%d %a %^{Time}>> \n:PROPERTIES:\n:TIMECODE: %\\1\n:END:")

Enjoying my dive into emacs/org mode. Seeming like I'll be sticking around.

P.S. I'm in digest mode so I'm a bit unsure how replies will work.

Re: Q: Export if *not* using a particular backend?

[Ihor Radchenko]

David Masterson  writes:

> Is there a way to export a section of an Org file only if the export
> backend is *NOT* a particular backend?  For instance, some things don't
> work in Texinfo, but are fine in HTML and LATEX.
>
> Is there a generalized IF for processing an Org file?

Nothing out of the box, but you can, for example, introduce a custom
attribute that will control that.

#+attr_all: :export (not texinfo)
Some text _not_ for texinfo here.

Then,
(defun yant/org-export-conditional-export (data backend info)
  (org-element-map data org-element-all-elements
(lambda (el)
  (pcase (car (read-from-string (or (org-export-read-attribute :attr_all el 
:export) "nil")))
(`nil t)
(`(not . ,backends)
 (when (member backend backends)
   (org-element-extract el)))
(backends
 (unless (member backend backends)
   (org-element-extract el)
info nil nil t)
  data)
(add-to-list 'org-export-filter-parse-tree-functions  
#'yant/org-export-conditional-export)


-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Unintuitive indentation behavior when editing org-src blocks

[Ihor Radchenko]

l...@phdk.org writes:

>> Applied, onto main.
> Great!
>
>> May you elaborate on the edge cases you encountered?
>> It may be a good idea to add such cases to the tests as well.
>
> I think they all reduced to the case where adding the spaces increased
> the minimum indent of the block, in which case `org-indent-line' would
> remove `block-content-ind' spaces from all other lines in the block. I
> attached a patch with a simple test where I also cleaned up the use of
> obsolete function `org-get-indentation' in `test-org.el'.

May you please explain how the test in the patch is related to the
change you made in the code? The test seems to be passing both with and
without your change.

> As a final thing on this patch in particular, I thought for a second
> that I might have caused a regression in modes where the
> indent-function cycles indentation (e.g. python-mode). Seems like
> python-mode in particular relies on `last-command' and not current
> indentation so it never worked.  Idk if there's a good solution to
> this issue from our side. Still, I think it makes sense to at least
> refrain from moving stuff around unnecessarily, just in case some
> modes do rely on current indentation.

What do those modes suggest for users who bind custom command for indentation?

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: `org-indent-line' indents the end tag of some blocks but doesn't do so with src blocks (was: [BUG] Unintuitive indentation behavior when editing org-src blocks)

[Ihor Radchenko]

l...@phdk.org writes:

>> Not just src-blocks, I think.
>> Also other kinds of verbatim blocks: example blocks, latex environments,
>> and comment blocks.
>
> All block elements which are not greater elements, so verse and export as 
> well.
> Here's a cleaned up version of the patch.

Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f66b130c95

>> In the future, there will be :value-being/:value-end property to avoid
>> the skip-chars-backwad dance, but not yet.
>> See https://git.sr.ht/~yantar92/org-mode/commit/f8e2eeae21e99492cb
>
> Should we add a comment noting this, or are you keeping track in your branch?

No need to comment. It is not like the code is wrong, but it can be
simplified in future.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] Org-babel inline overwriting src block outputs when using async + session

[Ihor Radchenko]

Jack Kamm  writes:

> I'm attaching an updated patch to fix the inline async session issue
> that incorporates this feedback along with some other changes.
>
> Rather than creating a general function in ob-core to find the previous
> src or inline src block, I decided to create a private function in
> ob-comint that is specialized for finding the block of an async result
> (`org-babel-comint-async--find-src').  In addition to using
> `org-element-context' to make sure we really are at a source block, I
> also added a check that the block's result contains the hash
> (`uuid-or-tmpfile') that the async result replaces.
>
> I also created a constant for the regexp in org-element.el, and added
> unit tests in test-ob-python.el for inline and async inline session
> blocks.

Thanks! The logic is not ideal, but babel is not ideal in general, so
let's not worry too much about various edge cases. The patch is an
improvement over the existing state of affairs anyway.

Feel free to push.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Problem with finding css file with orgmode blogging setup

[Ashish Panigrahi]

Hi,

Sorry about the late response. Life got in the way.

> Org-publish, by default, only processes org files. If you want to include CSS
> 
> files, images, and other non-org content, you need to process them as
> 
> attachments.

Sure, but I don't see a reason why my original snippet wouldn't work. If I 
replace the local css file with a cdn link instead, for example

(setq org-html-validation-link nil
  org-html-head-include-scripts nil
  org-html-doctype "html5"
  org-html-html5-fancy t
  org-html-html-include-default-style nil
  ;; org-html-head "")
  org-html-head "https://cdn.jsdelivr.net/npm/@exampledev/new.css@1.1.2/new.min.css\"; />")

works just fine. It only seems to have a problem when the css file is local. 
Any way to mitigate this? I initially thought that perhaps its an issue with 
orgmode being unable to find the stylesheet due to some incorrect path but 
doesn't seem to be the case.

Kind regards,
Ashish

March 23, 2025 at 6:42 AM, "Rohit Patnaik"  wrote:



> 
> Org-publish, by default, only processes org files. If you want to include CSS
> 
> files, images, and other non-org content, you need to process them as
> 
> attachments.
> 
> So, for example, this is what I have:
> 
> (setq org-publish-project-alist 
> 
>  '(("website-orgfiles"
> 
>  :base-directory "$HOME/website_src/"
> 
>  :publishing-directory "$HOME/website_publish/"
> 
>  :recursive t
> 
>  :headline-levels 6
> 
>  :sections-numbers nil
> 
>  :html-head-include-default-style nil
> 
>  :html-head 
> 
>  ") 
> 
>  ("website-images"
> 
>  :base-directory "$HOME/website_src/images/"
> 
>  :publishing-directory "$HOME/website_publish/images/"
> 
>  :recursive t
> 
>  :base-extension "png\\|jpg\\|gif"
> 
>  :publishing-function org-publish-attachment)
> 
>  ("website-css"
> 
>  :base-directory "$HOME/website_src/css/"
> 
>  :publishing-directory "$HOME/website_publish/"
> 
>  :base-extension "css"
> 
>  :publishing-function org-publish-attachment)
> 
>  ("website"
> 
>  :components ("website-orgfiles"
> 
>  "website-images"
> 
>  "website-css"
> 
> In other words, I break up my website project into separate subprojects for 
> CSS,
> 
> images, and org-files, and include them as components of the main website
> 
> project.
> 
> -- Rohit
>

Re: org-persist-write:index takes minutes to run

[Ihor Radchenko]

Karthik Chikmagalur  writes:

> It's definitely better than the version of org-persist on main right
> now.  Emacs blocks intermittently over the ~3 seconds it takes to
> preview 600 fragments in my test file, but it's not completely blocked
> for 30 seconds like before.  Emacs does not block when previewing
> without caching in org-persist, but that's expected because of the
> reasons you presented.

Ok. I now installed the patches onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ab7df301d2
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b8d01a745b
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=38cd9b0a3a

>> 2. We can allow file containers to store an actual directory. Then, you
>>will only need to write/read the directory once per session, obtain
>>its real path from org-persist API, and read/write files inside
>>manually, as you do without org-persist enabled. This will eliminate
>>most of the overheads you experience.
>
> Either of these solutions can work.  2 will probably perform better, but
> org-persist offers some niceties like expiring previews -- I don't know
> if that continues to work with 2.

With (2), expiry will still work. But for the directory as a whole.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Q: Export if *not* using a particular backend?

[Ihor Radchenko]

David Masterson  writes:

> Interesting. My elisp is not strong, so a few questions:
>
> 1. Are you saying attr_all does not exist in Org and this code is
>creating it?

Anything in the form of #+attr_ is treated by Org mode as
affiliated keyword. This keyword is stored alongside the following
paragraph/drawer/block/etc in the syntax tree passed to the exporter.
Export backend can then access it as needed. By convention, the backends
make use of #+attr_ keywords (#+attr_html, #+attr_latex,
etc) and ignore other. But nothing is technically stopping you from
examining values of arbitrary #+attr_ keywords during
export. That's what I did in this code.

> 2. I assume 'backends' is a list I must create, correct?

That's simply parsing #+attr_all: :export ... value.
With my filter, you can write

#+attr_all: :export (ascii html latex)
Paragraph to be exported only to ascii, html, and latex backends.

Or

#+attr_all: :export (not ascii html)
Paragraph _not_ to be exported to ascii and html and to be exported for
all other export backends.

> 3. What does the last argument ('t') to org-element-map do?
> 4. Doesn't org-element-map return data, so isn't the last data
>unnecessary?

The filter should return the modified syntax tree, while
`org-element-map' returns a flattened list. So, we cannot use its return
value. Instead, `org-element-extract' calls modify the tree by side
effect and the whole filter later returns the modified tree (the last
line in the function).

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Q: Export if *not* using a particular backend?

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> Is there a way to export a section of an Org file only if the export
>> backend is *NOT* a particular backend?  For instance, some things don't
>> work in Texinfo, but are fine in HTML and LATEX.
>>
>> Is there a generalized IF for processing an Org file?
>
> Nothing out of the box, but you can, for example, introduce a custom
> attribute that will control that.
>
> #+attr_all: :export (not texinfo)
> Some text _not_ for texinfo here.
>
> Then,
> (defun yant/org-export-conditional-export (data backend info)
>   (org-element-map data org-element-all-elements
> (lambda (el)
>   (pcase (car (read-from-string (or (org-export-read-attribute :attr_all 
> el :export) "nil")))
>   (`nil t)
> (`(not . ,backends)
>  (when (member backend backends)
>(org-element-extract el)))
> (backends
>  (unless (member backend backends)
>(org-element-extract el)
> info nil nil t)
>   data)
> (add-to-list 'org-export-filter-parse-tree-functions 
> #'yant/org-export-conditional-export)

Interesting. My elisp is not strong, so a few questions:

1. Are you saying attr_all does not exist in Org and this code is
   creating it?
2. I assume 'backends' is a list I must create, correct?
3. What does the last argument ('t') to org-element-map do?
4. Doesn't org-element-map return data, so isn't the last data
   unnecessary?

Thanks
-- 
David Masterson

Re: [PATCH] org-element.el; significant optimizations for org-element--interpret-affiliated-keywords

[Ihor Radchenko]

Ihor Radchenko  writes:

>> Adding back standard properties to the loop reduces performance by 5-20% 
>> depending on the element (see attached), but that's taking off of an already 
>> 5-10x speedup (see attached pdf).
>
> Then, I'd rather not make assumptions about keywords being or not being
> in standard properties. To avoid subtle bugs in the future.
>
> An alternative approach to address searching affiliated keyword
> properties could be storing the list of all the affiliated keyword
> property names in a special property. Like what is done for :secondary.
> ...

It has been a while since the last activity in this thread.
Nathan, may I know if you had a chance to look into my comments?

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at