Re: Question about cite_export basic

[Ihor Radchenko]

Dominik Schrempf  writes:

>> For now, I reached Emacs devs asking to provide the parsing within
>> bibtex.el. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57712
>> Lets see what they reply first.
>>
>
> Dear Ihor!
>
> Thank you for posting the BibTeX brace problem upstream. From what I can
> see by reading through the conversation, we are going down a rabbit
> hole. It seems to be pretty difficult to convert a BibTeX entry to a
> proper ascii string (I think this is what the basic export processor is
> doing). Is that true?
>
> Not sure how to proceed. I do not think that post processing
> `bibtex-parse-entry` output which seems to contain LaTeX code makes
> sense.

Parsing itself is not that hard, actually. We just need to follow
http://www.bibtex.org/SpecialSymbols/. However, it will be better if the
parsing is done on bibtex.el side.

If bibtex.el maintainer refuses to implement the request, we will just
do the parsing on Org side.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: error org export to pdf when latex letter class has been added to org-latex-classes

[Ihor Radchenko]

"M. Pger"  writes:

> When I export it using C-c C-e l o, an error appears:
> ```
> (/usr/share/texlive/texmf-dist/tex/latex/natbib/natbib.sty
>
> ! LaTeX Error: Environment thebibliography undefined.
>
> Any thoughts?

I cannot reproduce on my side.
I suggest you to follow https://orgmode.org/manual/Feedback.html
The issue is likely related to your personal configuration tweaks.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: org-assert-version considered harmful

[Ihor Radchenko]

Stefan Monnier  writes:

>>> Yup.  But there's no option to automatically find those dependencies in
>>> ELisp, and (IIRC from last time I looked at it, in many packages obeying
>>> such dependencies would end up introducing circular dependencies in
>>> the Makefile), so we'd have to depend on the package's author to provide
>>> a working set of file dependencies.
>>
>> It would be nice to have such an option.
>
> Agreed.  The "last time" mentioned above, I looked at changing the
> byte-compiler to keep track of the macros that were expanded so we can
> auto-generate the dependencies.

Then, I am inclined towards easing the version check to (org-version)
instead of (org-git-version). It will be no worse than the existing
situation with re-compiling updated .el files.

>> For reference, one simple way to trigger "mixed" state of Org is doing
>> something like:
>>
>> 1. emacs -Q
>> 2. (require 'org)
>> 3. Add the newer Org version to load-path
>> 4. (require 'ob-python)
>>
>> When and which version of org-autoloads.el will be loaded in
>> such scenario?
>
> None :-(
>
> In my book step 3 above is a mistake (even if moved to step 2).

I am confused.
AFAIK, changing the load-path is a common way for users to install
packages manually.

We do recommend setting the load-path in
https://orgmode.org/org.html#Installation and
https://orgmode.org/manual/Feedback.html

Moreover, it is also the recommendation from Emacs manual section
"28.8 Libraries of Lisp Code for Emacs":

>>>The default value of ‘load-path’ is a list of directories where the
>>> Lisp code for Emacs itself is stored.  If you have libraries of your own
>>> in another directory, you can add that directory to the load path.
>>> Unlike most other variables described in this manual, ‘load-path’ cannot
>>> be changed via the Customize interface (*note Easy Customization::), but
>>> you can add a directory to it by putting a line like this in your init
>>> file (*note Init File::):
>>> 
>>>  (add-to-list 'load-path "/path/to/my/lisp/library")

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[Ihor Radchenko]

andrés ramírez  writes:

> Ihor> Now, can you execute the following and let me know if the 
> performance is back to
> Ihor> satisfactory?
>
> [...]

[Note that I pushed the change in org-back-to-heading upstream]
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2737128aa778297f41971cc93c464faf17718e34


> I have tested your suggested changes.
> emacs28 with bundled org have recovered and it is a little bit quicker
> than emacs27 (around 17s).

You should be missing something. The code I suggested should have
exactly 0 impact on the built-in Org.

> emacs28 with org 9.6 took 44 seconds. So on 9.6 performance is not
> satisfactory yet.

Then, can you provide the updated profiler report again?
Please use the latest development version of Org +
(setq org-element--cache-self-verify nil)

> second observation:
>
> on emacs28+bundled-org this very detailed line is shown:
> --8<---cut here---start->8---
> bbdb:   [[bbdb:erlinda massco][erlinda massco's 49th custom anniversary]]
> --8<---cut here---end--->8---
>
> But. on emacs28+org9.6 this short detailed line is showed:
> --8<---cut here---start->8---
> bbdb:   custom
> --8<---cut here---end--->8---
>
> Could this behaviour be restored on latest development?.

Could you detail steps how to reproduce this? I cannot, on my side.
See https://orgmode.org/manual/Feedback.html

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Reinstalling compat fixed everything breaking

[William Denton]

Yesterday I pulled the current source trees for Org and Emacs and compiled as I 
usually do ... and everything broke, with Org complaining about mixed versions, 
and all kinds of warnings and backtraces and "Invalid function: 
compat-declare-version" errors.


After looking at various things I noticed a couple of mild warnings related to 
the package compat, which I'd seen for a while (several weeks, at least) but 
never bothered about, because everything worked.  I thought maybe it was all 
connected, what with the new version-checking and such, and indeed "M-x 
package-reinstall compat" did the trick and now everything works.


In case someone else has the same problem I thought I'd mention this.

Cheers,

Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[andrés ramírez]

Hi. Ihor.

> "Ihor" == Ihor Radchenko  writes:


[...]


Ihor> Now, can you execute the following and let me know if the performance 
is back to
Ihor> satisfactory?

[...]

I have tested your suggested changes.
emacs28 with bundled org have recovered and it is a little bit quicker
than emacs27 (around 17s).

emacs28 with org 9.6 took 44 seconds. So on 9.6 performance is not
satisfactory yet.

second observation:

on emacs28+bundled-org this very detailed line is shown:
--8<---cut here---start->8---
bbdb:   [[bbdb:erlinda massco][erlinda massco's 49th custom anniversary]]
--8<---cut here---end--->8---

But. on emacs28+org9.6 this short detailed line is showed:
--8<---cut here---start->8---
bbdb:   custom
--8<---cut here---end--->8---

Could this behaviour be restored on latest development?.

Best Regards

Re: error org export to pdf when latex letter class has been added to org-latex-classes

[M. Pger]

Hi,

Thank you for your answer.

> Are you including citations in your letter? 

No, that's also why it is puzzling. You should be able to reproduce the issue 
by creating a really minimalist init file including the following:
```
(with-eval-after-load 'ox-latex
  (add-to-list 'org-latex-classes '("letter" "\\documentclass{letter}"))
  )

(setq org-latex-pdf-process (list "latexmk -shell-escape -f -pdf %f"))
```

As mentioned in my previous mail, the error also appears when using `pdflatex` 
instead of `latexmk`.

Best,

M

--- Original Message ---
On Tuesday, September 13th, 2022 at 7:55 PM, Juan Manuel Macías 
 wrote:


> Hi,
> 
> M. Pger writes:
> 
> > (/usr/share/texlive/texmf-dist/tex/latex/natbib/natbib.sty
> > 
> > ! LaTeX Error: Environment thebibliography undefined.
> > 
> > See the LaTeX manual or LaTeX Companion for explanation.
> > Type H  for immediate help.
> > ...
> > 
> > l.1063 \renewenvironment{thebibliography}
> > [1]{%
> > ?
> > ! Emergency stop.
> > ...
> > 
> > l.1063 \renewenvironment{thebibliography}
> > [1]{%
> > ! ==> Fatal error occurred, no output PDF file produced!
> 
> 
> Are you including citations in your letter? Maybe this is related:
> https://latex.org/forum/viewtopic.php?f=4=3359
> 
> Best regards,
> 
> Juan Manuel
> 
> --
> --
> --
> Juan Manuel Macías
> 
> https://juanmanuelmacias.com
> 
> https://lunotipia.juanmanuelmacias.com
> 
> https://gnutas.juanmanuelmacias.com

Re: org-super-agenda global list of TODO items

[Christophe Schockaert]

On 2022-09-13 20:55, Angel de Vicente wrote:

Hello,


This looks correct. The only suspicious group is the one with
:time-grid. Time grid is not supported in todo list by vanilla
org-agenda. I am not sure how well org-super-agenda handles it.

I'd try to remove the "Schedule" group for TODO agenda. If it helps 
the

situation, you may consider reporting the issue to org-super-agenda
author at https://github.com/alphapapa/org-super-agenda/


thanks for the help. It turns out that this was already an issue in
org-super-agenda
(https://github.com/alphapapa/org-super-agenda/issues/212). User 
tuh

provided a possible fix
(https://github.com/alphapapa/org-super-agenda/pull/221), which has not
been accepted yet since apparently perhaps it can break other things,
but in my case it looks like it is working just fine, so I'll risk it
:-)

Cheers,


Hi,


Thank you for pointing this bug report.
I encountered the same myself, but if I remember correctly, I went 
through it another way, so I was not sure it was expected to work this 
way.


If I am right (I am playing with the config, it’s not in my daily setup 
yet for now), I could achieve this by defining 
"org-agenda-custom-commands" as shown in the "Projects" example : 
https://github.com/alphapapa/org-super-agenda/blob/master/examples.org#projects.


In that case, "org-super-agenda-groups" is defined differently according 
to the context, so the "time-grid" captures the timed entries in its 
scope. Then, "org-super-agenda-groups" applies to the TODOs in the 
"todo" or "alltodo" context (I used the latter one) where I don’t define 
the "time-grid" selection. Or, maybe I applied it to the "alltodo" only, 
and discarded it for the agenda grid to work only on the TODOs. I don’t 
remember exactly, however this might be a workaround to try that does 
not need an update of the code, especially if it is not expected to be 
stable and supported by the author.



Sincerely,

Christophe

--
--->  https://www.citadels.earth
Once it's perfectly aimed, the flying arrow goes straight to its target.
Thus, don't worry when things go right.
There will be enough time to worry about if they go wrong.
Then, it's time to fire a new arrow towards another direction.
Don't sink.  Adapt yourself !  The archer has to shoot accurately and
quickly.
[Words of Erenthar, the bowman ranger] <---

Re: error org export to pdf when latex letter class has been added to org-latex-classes

[Juan Manuel Macías]

M. Pger writes:

> Thank you for your answer.
>
>> Are you including citations in your letter? 
>
> No, that's also why it is puzzling. You should be able to reproduce
> the issue by creating a really minimalist init file including the
> following:
>
> ```
> (with-eval-after-load 'ox-latex
>   (add-to-list 'org-latex-classes '("letter" "\\documentclass{letter}"))
>   )
>
> (setq org-latex-pdf-process (list "latexmk -shell-escape -f -pdf %f"))
> ```
>
> As mentioned in my previous mail, the error also appears when using 
> `pdflatex` instead of `latexmk`.

Hmm, it's weird. With your configuration I cannot reproduce the problem.
Anyway, I have Org configured so that it doesn't load any package in the
preamble.

And if you directly compile the .tex file generated by org during
export, does it also give you an error? Could you please paste the
preamble of that tex file here, up to the \begin{document}?

Best regards,

Juan Manuel 

Re: org-super-agenda global list of TODO items

[Angel de Vicente]

Hello,

> This looks correct. The only suspicious group is the one with
> :time-grid. Time grid is not supported in todo list by vanilla
> org-agenda. I am not sure how well org-super-agenda handles it.
>
> I'd try to remove the "Schedule" group for TODO agenda. If it helps the
> situation, you may consider reporting the issue to org-super-agenda
> author at https://github.com/alphapapa/org-super-agenda/

thanks for the help. It turns out that this was already an issue in
org-super-agenda
(https://github.com/alphapapa/org-super-agenda/issues/212). User tuh
provided a possible fix
(https://github.com/alphapapa/org-super-agenda/pull/221), which has not
been accepted yet since apparently perhaps it can break other things,
but in my case it looks like it is working just fine, so I'll risk it
:-)

Cheers,
-- 
Ángel de Vicente
 Research Software Engineer (Supercomputing and BigData)
 Instituto de Astrofísica de Canarias (https://www.iac.es/en)

Re: error org export to pdf when latex letter class has been added to org-latex-classes

[Juan Manuel Macías]

Hi,

M. Pger writes:

> (/usr/share/texlive/texmf-dist/tex/latex/natbib/natbib.sty
>
> ! LaTeX Error: Environment thebibliography undefined.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H   for immediate help.
>  ...  
>   
> l.1063 \renewenvironment{thebibliography}
>  [1]{%
> ? 
> ! Emergency stop.
>  ...  
>   
> l.1063 \renewenvironment{thebibliography}
>  [1]{%
> !  ==> Fatal error occurred, no output PDF file produced!

Are you including citations in your letter? Maybe this is related:
https://latex.org/forum/viewtopic.php?f=4=3359

Best regards,

Juan Manuel 

-- 
--
--
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: org-assert-version considered harmful

[Stefan Monnier]

>> Yup.  But there's no option to automatically find those dependencies in
>> ELisp, and (IIRC from last time I looked at it, in many packages obeying
>> such dependencies would end up introducing circular dependencies in
>> the Makefile), so we'd have to depend on the package's author to provide
>> a working set of file dependencies.
>
> It would be nice to have such an option.

Agreed.  The "last time" mentioned above, I looked at changing the
byte-compiler to keep track of the macros that were expanded so we can
auto-generate the dependencies.

> At least, for the most critical macros.  Something similar to
> declare statements.

But that also requires manual intervention :-(

>> Hmm... after new-org-autoloads.el is loaded, the old-Org files will be
>> relegated to "late in the `load-path`" (i.e. after the directory that
>> holds the new-Org file) and should hence not be loaded any more (unless
>> someone goes through the trouble to explicitly load an old-Org files
>> with an absolute file name).
>
> I admit that I do not have sufficient knowledge about the autoload magic
> Emacs uses when loading packages.
>
> For reference, one simple way to trigger "mixed" state of Org is doing
> something like:
>
> 1. emacs -Q
> 2. (require 'org)
> 3. Add the newer Org version to load-path
> 4. (require 'ob-python)
>
> When and which version of org-autoloads.el will be loaded in
> such scenario?

None :-(

In my book step 3 above is a mistake (even if moved to step 2).

The `org-autoloads.el` is the file that adds the dir to `load-path`
(and in a normal ELPA install, that's the file that `package.el` loads
for you at startup).
So step 3 above is replaced by (load ".../org-autoloads"), and that's
where the problem would be detected.

But admittedly, that won't help users who made the mistake of
manually adding to `load-path` :-(


Stefan

error org export to pdf when latex letter class has been added to org-latex-classes

[M. Pger]

Dear All,

I've told Org about the letter class with the following in my init file:
```
(with-eval-after-load 'ox-latex
(add-to-list 'org-latex-classes '("letter" "\\documentclass{letter}")) )
```

After that I can create a org document containing e.g.:
```
#+latex_class: letter
#+latex_header: \signature{M. Pger}#+latex_header: \address{42 My Street \\ My 
Town}

#+latex: \begin{letter}{Org mailing-list \\ 42 GNU Street \\ GNU Town}
#+latex: \date{September 2022}#+latex: \opening{Dear Members of the Org 
mailing-list,}

Here is the text of the letter.

#+latex: \closing{Yours faithfully,}
#+latex: \end{letter}

```

When I export it using C-c C-e l o, an error appears:
```
(/usr/share/texlive/texmf-dist/tex/latex/natbib/natbib.sty

! LaTeX Error: Environment thebibliography undefined.

See the LaTeX manual or LaTeX Companion for explanation.
Type H  for immediate help.
...

l.1063 \renewenvironment{thebibliography}
[1]{%
?
! Emergency stop.
...

l.1063 \renewenvironment{thebibliography}
[1]{%! ==> Fatal error occurred, no output PDF file produced!
```

In order to have a pdf output, I can use -interaction=nonstopmode​ in the 
org-latex-pdf-process​, but of course the error is still there (but now I have 
a pdf, which is good). Exporting from org, the error is there whenever I use 
latexmk​ (with pdflatex​) or directly pdflatex​.

However, there is no error when creating such a letter from a .tex file in 
Auctex (which appears to also use pdflatex​ as the compiler).

Any thoughts?

Best,

M

Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency

[Karl Voit]

Hi Christophe,

* Christophe Schockaert  wrote:
>
> In a sense I can feel it’s useful to have an explicit cancel while 
> working.
> But I don’t know how to handle it (see below).
> I don’t think [/] would be a good candidate anyway, it’s used as a 
> statistic cookie, so it already has a meaning and would be confusing, 
> also it gets evaluated even in the body entry.
>
> Actually, I almost always use statistic cookies when using checkboxes, 
> and so how would we count the cancelled checkbox ?

That was a huge mistake by me. I obviously did not think before
choosing one of the few characters in between those brackets that
are a clear no-go as you have mentioned above. Sorry.

> As I didn’t imagine to alter the syntax as used it as it :
>
> - either, I add a note (usually dated) explicitly stating it’s 
> cancelled, and I check the box

A viable workaround, yes.

> - or, I force the closing of the whole entry with the C-u sequence, and 
> so it’s clear that some were cancelled or at least not fulfilled (which 
> in sort means that its follow up has been cancelled), as it writes [2/3] 
> in the heading for example. As the checkboxes don’t appear in the 
> agenda, it does not bother me so much to leave them uncompleted.

Yes, also a workaround. I never used the C-u sequence for overriding
that blocking feature so far.

> * DONE [2/3] Some tasks to check
>- [X] check 1
>- [ ] check 2
>  - [2022-09-13] Cancelled. Won’t check this one
>- [X] check 3
>
> So, to me the main use case to have an explicit cancel, is when I have a 
> long list, and to remember that I stated it as "cancelled".
> If we go that way, having no other nice idea at the moment, I quite like 
> the [C] which is explicit although language specific.

... if it is possible with the current implementation, we could
introduce an official convention that any single (upper case?)
character between the brackets is interpreted as a non-open
checkbox. So any user is able to choose her character of choice even
language-dependent.

> However, this rises the question for the completeness :
>
> * TODO [1/3] Some tasks to check
>- [X] check 1
>- [C] check 2 (or any other chosen token for [C])
>- [ ] check 3
>
> Should we display [1/3] or [2/3] ?
> Maybe we should align against the way it works for TODO/DONE/CANCELLED, 
> so it would be [2/3]...

I'd say we should stick to that pattern, yes.

> On the other hand, the "DONE [2/3]" above is quite visually explicit 
> that something was not fulfilled for the course of resolving the action.
>
> I hope this brought something useful for the thinking :)

Oh yes, thank you!

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: org-super-agenda global list of TODO items

[Ihor Radchenko]

Angel de Vicente  writes:

> Ihor Radchenko  writes:
>
>> How do you customize your org-super-agenda-groups variable?
>
> via customize-variable, which sets this in my custom-set-variables in my 
> .emacs:
>
> ,
> |  '(org-super-agenda-groups
> |'((:name "Schedule" :time-grid t :transformer
> | (--> it
> |  (propertize it 'face
> |  '(:foreground "yellow"
> |  (:name "Important" :priority "A")
> |  (:name "POLMAG" :tag "polmag")
> |  (:name "Astrophysics" :tag
> | ("astrophysics"))
> |  (:name "Personal" :tag "personal")
> |  (:priority<= "B" :order 1)))
> `

This looks correct. The only suspicious group is the one with
:time-grid. Time grid is not supported in todo list by vanilla
org-agenda. I am not sure how well org-super-agenda handles it.

I'd try to remove the "Schedule" group for TODO agenda. If it helps the
situation, you may consider reporting the issue to org-super-agenda
author at https://github.com/alphapapa/org-super-agenda/

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: org-assert-version considered harmful

[Ihor Radchenko]

Stefan Monnier  writes:

>>> - git pull  =>  switches to 9.5.5, but several .el files are left unchanged.
>>> - make autoloads  =>  this refreshes the autoloads, but the .elc files
>>>   of those .el files which didn't change still won't be recompiled.
>>
>> Isn't it a bug in the elpa scripts then?
>> If a macro definition is changed and the .elc file using that macro is
>> not changed, it still needs to be re-compiled. Otherwise, all kinds of
>> unexpected side effects may appear.
>
> Yup.  But there's no option to automatically find those dependencies in
> ELisp, and (IIRC from last time I looked at it, in many packages obeying
> such dependencies would end up introducing circular dependencies in
> the Makefile), so we'd have to depend on the package's author to provide
> a working set of file dependencies.

It would be nice to have such an option. At least, for the most critical
macros. Something similar to declare statements.

>>> PPS: Maybe instead of calling `org-assert-version` everywhere, the
>>>  `org-autoloads.el` (i.e. the file that sets up the `load-path` and
>>>  the autoloads) could look for traces of Org files in the
>>>  `load-history` and signal an error if such files are found coming
>>>  from a different directory.
>>
>> No, unfortunately.
>>
>> org-autoloads, when loaded from built-in Emacs version will not help
>> to catch newer Org libraries being loaded after built-in Org version is
>> loaded.
>
> Hmm... after new-org-autoloads.el is loaded, the old-Org files will be
> relegated to "late in the `load-path`" (i.e. after the directory that
> holds the new-Org file) and should hence not be loaded any more (unless
> someone goes through the trouble to explicitly load an old-Org files
> with an absolute file name).

I admit that I do not have sufficient knowledge about the autoload magic
Emacs uses when loading packages.

For reference, one simple way to trigger "mixed" state of Org is doing
something like:

1. emacs -Q
2. (require 'org)
3. Add the newer Org version to load-path
4. (require 'ob-python)

When and which version of org-autoloads.el will be loaded in such scenario?

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: org-super-agenda global list of TODO items

[Angel de Vicente]

Hello,

Ihor Radchenko  writes:

> How do you customize your org-super-agenda-groups variable?

via customize-variable, which sets this in my custom-set-variables in my .emacs:

,
|  '(org-super-agenda-groups
|'((:name "Schedule" :time-grid t :transformer
| (--> it
|  (propertize it 'face
|  '(:foreground "yellow"
|  (:name "Important" :priority "A")
|  (:name "POLMAG" :tag "polmag")
|  (:name "Astrophysics" :tag
| ("astrophysics"))
|  (:name "Personal" :tag "personal")
|  (:priority<= "B" :order 1)))
`
 
-- 
Ángel de Vicente
 Research Software Engineer (Supercomputing and BigData)
 Instituto de Astrofísica de Canarias (https://www.iac.es/en)

Re: org-super-agenda global list of TODO items

[Ihor Radchenko]

Angel de Vicente  writes:

>> Could you please elaborate what you mean by "organize"?
>
> Maybe the best is an image... If you look at
> https://github.com/alphapapa/org-super-agenda/blob/master/images/screenshots/index.org,
> you can see that the TODO items for a given date in the agenda are
> neatly organized by using org-super-agenda into user-defined groups
> (Important, Personal, etc.).
>
> I got this working fine, but then I have a long list of TODO items with
> no scheduled date. I was hoping that org-super-agenda would also work on
> those items, so that similar grouping would be applied to them, but I
> don't know if this is not possible or I'm missing something.

How do you customize your org-super-agenda-groups variable?

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [BUG] Unregistered buffer modifications detected [9.6 (9.6-??-00adad9 @ /Users/h1/.emacs.d/.local/straight/build-28.1/org/)]

[Ihor Radchenko]

Andrej Močan  writes:

> The error message below started to appear regularly whenever I save Org
> mode buffer in Org Roam. It does not matter how I save the buffer (:w or C-c)
>
> Error message:
> Warning (org-element-cache): org-element--cache: Unregistered buffer 
> modifications detected. Resetting.
> If this warning appears regularly, please report the warning text to Org mode 
> mailing list (M-x org-submit-bug-report).
> The buffer is: *temp*
> Current command: find-file
> Backtrace:
> nil Disable showing Disable logging

Thanks fore reporting!
Can you please share the value of your before-save-hook variable in Org
buffers? (go to an Org file and run M-x describe-variable 
before-save-hook ; then share the contents of *Help* buffer).

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [PATCH] Re: [BUG] Adding note to heading without newline at the end

[Ihor Radchenko]

Tor Kringeland  writes:

> Ihor Radchenko  writes:
>
>> Aha. Not saving is an important piece of information.
>> (said the person with compulsive saving syndrome)
>
> Thanks!  This fixes the bug (which was present in both Org 9.5 and 9.6)
> for me.  However, my original bug, which is only present in Org 9.6, is
> still there.  Do the same thing but set org-log-into-drawer to t.  Then

Fixed on main now.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8ec328e827edf67a09b6612ae32aba79ceb98e9f
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f8d740f707ceab1e865fd1745ffaaa531b9fdd0e

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Question about cite_export basic

[Dominik Schrempf]

Ihor Radchenko  writes:

> Dominik Schrempf  writes:
>
>>   title   = {{Introduction to Markov Chain Monte Carlo}},
>> ...
>> Is rendered as
>>
>> Geyer, Charles J (2011). {Introduction to Markov Chain Monte Carlo}, CRC 
>> press.
>>
>> In particular, the curly braces are printed. Curly braces are often
>> used in bib files to indicate that the capitalization is to be
>> preserved.
>>
>> Do we want to change the default behavior of the basic processor so
>> that it correctly handles these cases?
>
> This makes sense. However, I see it as something to be done by
> bibtex.el; not by Org. Or we may need to write a small exporter for
> BibTeX fields specifically. So that
> http://www.bibtex.org/SpecialSymbols/ is obeyed. We may also handle
> upcasing the title words in such exporter.
>
> For now, I reached Emacs devs asking to provide the parsing within
> bibtex.el. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57712
> Lets see what they reply first.
>

Dear Ihor!

Thank you for posting the BibTeX brace problem upstream. From what I can
see by reading through the conversation, we are going down a rabbit
hole. It seems to be pretty difficult to convert a BibTeX entry to a
proper ascii string (I think this is what the basic export processor is
doing). Is that true?

Not sure how to proceed. I do not think that post processing
`bibtex-parse-entry` output which seems to contain LaTeX code makes
sense.

Best,
Dominik

Re: org-assert-version considered harmful

[Stefan Monnier]

>> - git pull  =>  switches to 9.5.5, but several .el files are left unchanged.
>> - make autoloads  =>  this refreshes the autoloads, but the .elc files
>>   of those .el files which didn't change still won't be recompiled.
>
> Isn't it a bug in the elpa scripts then?
> If a macro definition is changed and the .elc file using that macro is
> not changed, it still needs to be re-compiled. Otherwise, all kinds of
> unexpected side effects may appear.

Yup.  But there's no option to automatically find those dependencies in
ELisp, and (IIRC from last time I looked at it, in many packages obeying
such dependencies would end up introducing circular dependencies in
the Makefile), so we'd have to depend on the package's author to provide
a working set of file dependencies.

Note that the same problem applies to Emacs's own ELisp files.
In Emacs we have `make bootstrap` to manually get out of such
a bad compilation.

>> PPS: Maybe instead of calling `org-assert-version` everywhere, the
>>  `org-autoloads.el` (i.e. the file that sets up the `load-path` and
>>  the autoloads) could look for traces of Org files in the
>>  `load-history` and signal an error if such files are found coming
>>  from a different directory.
>
> No, unfortunately.
>
> org-autoloads, when loaded from built-in Emacs version will not help
> to catch newer Org libraries being loaded after built-in Org version is
> loaded.

Hmm... after new-org-autoloads.el is loaded, the old-Org files will be
relegated to "late in the `load-path`" (i.e. after the directory that
holds the new-Org file) and should hence not be loaded any more (unless
someone goes through the trouble to explicitly load an old-Org files
with an absolute file name).

> Moreover, I consider loading personal forks of built-in Org libraries a
> valid use-case. Demanding all the org libraries to be loaded from the
> same directory will limit this possibility.

As long as they're loaded after new-org-autoloads.el, it would still be
fine since the test is only performed once when loading the
new-org-autoloads.el.


Stefan

Re: Images in org-mode

[Ihor Radchenko]

Timothy  writes:

>> Did it get merged? There are several patches proposed in that thread,
>> but I do not see them being actually merged upstream.
>
> Mmm, that thread ends with me proposing a specific approach and Matt saying it
> sounds good (, quoted 
> below),
> but from there no further patches are provided (unless I missed something).

Reading through the linked email, I have a feeling that Matt expected you
to provide further feedback:

>> Anyway, I still feel that the earlier patch (before regex changes is the
>> right one). But, if you want me to revert the documentation removal from
>> the function I will.

May you followup on his query?
 
-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: BUG: org-show-context 'lineage not showing direct parent of inlinetask

[Ihor Radchenko]

Michael Dauer  writes:

> This e.g. affects pressing TAB on an inlinetask in the agenda view.
>
> Org mode version 9.5 (9.5-gced2b3

Thanks for reporting!
Fixed on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4d8c6fbf7a0cf6f72aa91d03d3dcd6456e9c2b2b

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [PATCH v2] Re: Adding target and custom id links doesn't ask for description

[Ihor Radchenko]

Ihor Radchenko  writes:

>> Yes, I've tested it with target and custom_id links and, as you said, there
>> is no change in behavior. The entire URL is still pasted and no chance to
>> edit it is given to the user.
>
> Oops. Somehow some way things worked for me at some point when I was
> making the patch.
>
> See the updated version of the patch attached. It works on my side.

According to the further discussion, this patch does not resolve the
original problem. However, it improves similar cases with link
descriptions being set equal to the link values.

Applied.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4fc2c8dd89bfbe9f6ad7620c1b4d6def4114489b

The original problem is resolved in another applied patch from an
earlier discussion.
https://list.orgmode.org/e2c807a7-1924-6f08-9e63-4f70aee9d...@gmail.com

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Bug: org-store-link uses CUSTOM_ID instead of target point [9.4.4 (release_9.4.4 @ /usr/share/emacs/27.2/lisp/org/)]

[Ihor Radchenko]

Max Nikulin  writes:

>> Fixed in maint, thanks a lot for reporting this and Ihor for
>> confirming the bug.
>
> Bastien, unfortunately your fix caused duplication of stored links like 
> "file:~/org/file.org::#custom_id" when point is outside of <>. 
> Earlier #CUSTOM_ID link was stored in addition to 
> "file:~/org/file.org::*Heading" search link. My suggestion is to revert 
> your patch and to just reset custom-id variable when <> link is 
> stored. Another effect or your patch, that I consider unintentional, is 
> storing 
> [[file:~/org/file.org::#custom_id][file:~/org/file.org::#custom_id]] 
> instead of [[file:~/org/file.org::#custom_id][Heading]]. I prefer 
> "original" behavior.
>
> Third patch is intended to avoid links inserted as 
> [[target][file:~/org/file.org::target]] in the case of same file. I 
> suppose, just [[target]] is better. Current variant looks unbalanced and 
> misleading. Of course, you are free to skip last patch.

Thanks for reminding about this unresolved patch!
Applied all three patches onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=543a23a57d2947cd01c906d134ae9c5c8d0907c4
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f7b8510283537bda4eba3b54fce5eafc7cec9993
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c3d6672cfdbff8c9dd4c2ec70886ad3f62153d07

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency

[Christophe Schockaert]

On 2022-09-13 10:07, Karl Voit wrote:

Hi Ihor,

* Ihor Radchenko  wrote:

Karl Voit  writes:


I was using list checkboxes like that:
- [ ] open task
- [X] closed task
- [-] cancelled task


From the manual (5.6 Checkboxes):

‘C-c C-x C-b’ (‘org-toggle-checkbox’)
 Toggle checkbox status or—with prefix argument—checkbox presence 
at

 point.  With double prefix argument, set it to ‘[-]’, which is
 considered to be an intermediate state.

[-] is not considered done by our conventions

...

So, you can use something like
 - [C] cancelled task

But beware that this is an internal implementation detail that might 
be

changed in future unless we decide to document the existing behaviour.


In that case, I prefer not to depend on that internal detail and
start using +[ ]+ as a workaround which causes the parser to not
detect a checkbox at all, as far as I understood.

Thanks for clarification.

If we wanted to introduce a cancelled checkbox state, it seems to be
the case that this would require a new approach like [/] or similar.

Is it only me who is thinking that a non-blocking cancelled checkbox
state would be a good idea?

Hello Karl and all,


In a sense I can feel it’s useful to have an explicit cancel while 
working.

But I don’t know how to handle it (see below).
I don’t think [/] would be a good candidate anyway, it’s used as a 
statistic cookie, so it already has a meaning and would be confusing, 
also it gets evaluated even in the body entry.


Actually, I almost always use statistic cookies when using checkboxes, 
and so how would we count the cancelled checkbox ?


As I didn’t imagine to alter the syntax as used it as it :

- either, I add a note (usually dated) explicitly stating it’s 
cancelled, and I check the box


- or, I force the closing of the whole entry with the C-u sequence, and 
so it’s clear that some were cancelled or at least not fulfilled (which 
in sort means that its follow up has been cancelled), as it writes [2/3] 
in the heading for example. As the checkboxes don’t appear in the 
agenda, it does not bother me so much to leave them uncompleted.


* DONE [2/3] Some tasks to check

  - [X] check 1

  - [ ] check 2

- [2022-09-13] Cancelled. Won’t check this one

  - [X] check 3


So, to me the main use case to have an explicit cancel, is when I have a 
long list, and to remember that I stated it as "cancelled".
If we go that way, having no other nice idea at the moment, I quite like 
the [C] which is explicit although language specific.


However, this rises the question for the completeness :

* TODO [1/3] Some tasks to check

  - [X] check 1

  - [C] check 2 (or any other chosen token for [C])

  - [ ] check 3


Should we display [1/3] or [2/3] ?
Maybe we should align against the way it works for TODO/DONE/CANCELLED, 
so it would be [2/3]...
On the other hand, the "DONE [2/3]" above is quite visually explicit 
that something was not fulfilled for the course of resolving the action.



I hope this brought something useful for the thinking :)

Christophe



PS to Ihor while I am at it : Thank you very much for your answer to a 
(very) past question of mine, I made some progress meanwhile, I’ll make 
an update when I can :)


--
--->  https://www.citadels.earth
Once it's perfectly aimed, the flying arrow goes straight to its target.
Thus, don't worry when things go right.
There will be enough time to worry about if they go wrong.
Then, it's time to fire a new arrow towards another direction.
Don't sink.  Adapt yourself !  The archer has to shoot accurately and
quickly.
[Words of Erenthar, the bowman ranger] <---

Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency

[Marcin Borkowski]

On 2022-09-13, at 10:07, Karl Voit  wrote:

> Is it only me who is thinking that a non-blocking cancelled checkbox
> state would be a good idea?

No.

-- 
Marcin Borkowski
http://mbork.pl

Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency

[Karl Voit]

Hi Ihor,

* Ihor Radchenko  wrote:
> Karl Voit  writes:
>
>> I was using list checkboxes like that:
>> - [ ] open task
>> - [X] closed task
>> - [-] cancelled task
>
> From the manual (5.6 Checkboxes):
>
> ‘C-c C-x C-b’ (‘org-toggle-checkbox’)
>  Toggle checkbox status or—with prefix argument—checkbox presence at
>  point.  With double prefix argument, set it to ‘[-]’, which is
>  considered to be an intermediate state.
>
> [-] is not considered done by our conventions
>
>Here is an example of a checkbox list.
>
>  * TODO Organize party [2/4]
>- [-] call people [1/3]
>  - [ ] Peter
>  - [X] Sarah
>  - [ ] Sam
>- [X] order food
>- [ ] think about what music to play
>- [X] talk to the neighbors

Yes, that makes sense. [-] is not a candidate for a cancelled
checkbox for that reason. :-(

>> (setq org-enforce-todo-checkbox-dependencies t)
>> ... any [-] checkbox will be regarded as non-finished contrary to
>> the behavior of TODO/DONE/CANCELLED heading states.
>>
>> As a workaround, I may use:
>> - +[ ]+ cancelled task
>
> As you can see, we already have conflicting convention, and we cannot
> change it without breaking backwards compatibility.
>
> `org-block-todo-from-checkboxes', currently uses
>
> (org-list-search-forward
>(concat (org-item-beginning-re)
>"\\(?:\\[@\\(?:start:\\)?\\([0-9]+\\|[A-Za-z]\\)\\][ 
> \t]*\\)?"
>"\\[[- ]\\]")
>end t)
>
> as a condition that some list items are marked incomplete.
>
> So, you can use something like
>  - [C] cancelled task
>
> But beware that this is an internal implementation detail that might be
> changed in future unless we decide to document the existing behaviour.

In that case, I prefer not to depend on that internal detail and
start using +[ ]+ as a workaround which causes the parser to not
detect a checkbox at all, as far as I understood.

Thanks for clarification.

If we wanted to introduce a cancelled checkbox state, it seems to be
the case that this would require a new approach like [/] or similar.

Is it only me who is thinking that a non-blocking cancelled checkbox
state would be a good idea?

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

[BUG] Unregistered buffer modifications detected [9.6 (9.6-??-00adad9 @ /Users/h1/.emacs.d/.local/straight/build-28.1/org/)]

[Andrej Močan]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


The error message below started to appear regularly whenever I save Org
mode buffer in Org Roam. It does not matter how I save the buffer (:w or C-c)

Error message:
Warning (org-element-cache): org-element--cache: Unregistered buffer 
modifications detected. Resetting.
If this warning appears regularly, please report the warning text to Org mode 
mailing list (M-x org-submit-bug-report).
The buffer is: *temp*
Current command: find-file
Backtrace:
nil Disable showing Disable logging

Emacs  : GNU Emacs 28.1 (build 2, x86_64-apple-darwin20.6.0, NS appkit-2202.70 
Version 11.6.8 (Build 20G730))
of 2022-08-17
Package: Org mode version 9.6 (9.6-??-00adad9 @ 
/Users/h1/.emacs.d/.local/straight/build-28.1/org/)

current state:
==
(setq
org-archive-location "archive.org::datetree/"
org-roam-db-location "/Users/h1/.emacs.d/.local/etc/org-roam.db"
org-link-elisp-confirm-function nil
org-directory "~/edocs/orgfiles/"
org-after-refile-insert-hook '(save-buffer)
org-indirect-buffer-display 'current-window
org-roam-db-gc-threshold 2305843009213693951
org-crypt-key nil
org-hide-emphasis-markers t
org-bibtex-headline-format-function #[257 "\300%1\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
org-num-skip-tags '("noexport" "nonum")
org-log-done t
org-load-hook '(+org-init-org-directory-h +org-init-appearance-h 
+org-init-agenda-h +org-init-attachments-h +org-init-babel-h 
+org-init-babel-lazy-loader-h
 +org-init-capture-defaults-h +org-init-capture-frame-h 
+org-init-custom-links-h +org-init-export-h +org-init-habit-h +org-init-hacks-h
 +org-init-keybinds-h +org-init-popup-rules-h 
+org-init-smartparens-h +org-init-roam-maybe-h)
org-log-into-drawer t
org-roam-buffer-window-parameters '((no-delete-other-windows . t))
org-num-face '(:inherit org-special-keyword :underline nil :weight bold)
org-startup-folded nil
org-babel-after-execute-hook '(+org-redisplay-inline-images-in-babel-result-h)
org-link-abbrev-alist '(("doom-repo" . 
"https://github.com/doomemacs/doomemacs/%s;) ("doomdir" . 
"/Users/h1/.doom.d/%s") ("emacsdir" . "/Users/h1/.emacs.d/%s")
 ("doom" . "https://github.com/hlissner/doom-emacs/%s;) 
("wolfram" . "https://wolframalpha.com/input/?i=%s;)
 ("wikipedia" . "https://en.wikipedia.org/wiki/%s;) 
("duckduckgo" . "https://duckduckgo.com/?q=%s;)
 ("gmap" . "https://maps.google.com/maps?q=%s;) 
("gimages" . "https://google.com/images?q=%s;) ("google" . 
"https://google.com/search?q=;)
 ("youtube" . "https://youtube.com/watch?v=%s;) 
("github" . "https://github.com/%s;))
org-agenda-files '("~/edocs/orgfiles/")
org-capture-templates '(("t" "Personal todo" entry (file+headline 
+org-capture-todo-file "Inbox") "* [ ] %?\n%i\n%a" :prepend t)
 ("n" "Personal notes" entry (file+headline 
+org-capture-notes-file "Inbox") "* %u %?\n%i\n%a" :prepend t)
 ("j" "Journal" entry (file+olp+datetree 
+org-capture-journal-file) "* %U %?\n%i\n%a" :prepend t) ("p" "Templates for 
projects")
 ("pt" "Project-local todo" entry (file+headline 
+org-capture-project-todo-file "Inbox") "* TODO %?\n%i\n%a" :prepend t)
 ("pn" "Project-local notes" entry (file+headline 
+org-capture-project-notes-file "Inbox") "* %U %?\n%i\n%a" :prepend t)
 ("pc" "Project-local changelog" entry (file+headline 
+org-capture-project-changelog-file "Unreleased") "* %U %?\n%i\n%a" :prepend t)
 ("o" "Centralized templates for projects")
 ("ot" "Project todo" entry 
#'+org-capture-central-project-todo-file "* TODO %?\n %i\n %a" :heading "Tasks" 
:prepend nil)
 ("on" "Project notes" entry 
#'+org-capture-central-project-notes-file "* %U %?\n %i\n %a" :heading "Notes" 
:prepend t)
 ("oc" "Project changelog" entry 
#'+org-capture-central-project-changelog-file "* %U %?\n %i\n %a" :heading 
"Changelog" :prepend t))
org-persist-after-read-hook '(org-element--cache-persist-after-read)
org-roam-backlinks-mode-hook '(turn-on-visual-line-mode)
org-refile-targets '((nil :maxlevel . 3) (org-agenda-files :maxlevel . 3))
org-export-before-parsing-hook '(org-attach-expand-links)
org-cycle-tab-first-hook '(+org-yas-expand-maybe-h +org-indent-maybe-h 
org-babel-hide-result-toggle-maybe org-babel-header-arg-expand 
+org-clear-babel-results-h
+org-cycle-only-current-subtree-h)
org-default-notes-file "/Users/h1/edocs/orgfiles/notes.org"
org-auto-tangle-default t

[BUG] org-paste-subtree inserts empty line above paste

[Felix Wiemuth]

Emacs 28.1
Orgmode 9.5.2 (but discovered already 2020-01-20)

When pasting a subtree (of whichever level) with org-paste-subtree at 
any position (can be an empty line or a line with a header prefix, e.g. 
"*** "), always an empty line is inserted above the inserted subtree.


I would expect no new line to be inserted, and I think this was the 
behaviour before I noticed this.


The value of "org-blank-before-new-entry" is "((heading) 
(plain-list-item))".