Re: [BUG] ob-python hangs on second start [9.5.4 (release_9.5.4-763-g06373a @ ~/emacs/org-mode/lisp/)]

[Jack Kamm]

Ihor Radchenko  writes:

> LGTM! Feel free to push.

Pushed to bugfix (c81dba2fb) and merged to main (b49275acb). Pushed the
unit test as a separate commit to main only (8000b1120).

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

[Adam Porter]

Hi Ihor,

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

Adam Porter  writes:


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

May you try to re-generate the backtrace again?


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


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

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

Handled.
Not an Org bug.


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


Adam

Re: [BUG] org-get-outline-path misbehave in some scenarios when org-element-use-cache is t Inbox

[Rodrigo Morales]

For those interested: here's another minimal working example:

#+HEADER: :results output
#+begin_src elisp
(with-temp-buffer
  (org-mode)
  (insert "* 1
,** 1.1
,* 2
")
  ;; jump to the first headline to print the value of :end
  (goto-char (point-min))
  (princ (format "%s\n" (org-element-property :end (org-element-context
  ;; search
  (search-forward "* 2")
  (beginning-of-line)
  (insert "a" "\n")
  ;; jump to the first headline to print the value of :end
  (goto-char (point-min))
  (princ (format "%s\n" (org-element-property :end (org-element-context)
#+end_src

Results of evaluation in v9.6.7 (unexpected behavior)

#+RESULTS:
#+begin_example
12
18
#+end_example

Results of evaluation in latest development main (expected behavior)

#+RESULTS:
#+begin_example
12
14
#+end_example

On Tue, 15 Aug 2023 at 19:03, Rodrigo Morales
 wrote:
>
> I've noticed that =org-get-outline-path= report incorrect information
> when =org-element-use-cache= is =t=. This mail shows some experiments
> that demonstrates this bug.
>
> * Experiment 1
>
> In this experiment, we define a =func= which contains the sexps that
> we want to run when =org-element-use-cache= is =t= and when it is
> =nil=. In =func=, we use =org-map-entries= to loop through headlines
> that have depth 2. In each headline, we move the point two lines below
> and insert a new line containing =FOO=.
>
> #+HEADER: :results output
> #+begin_src elisp
> (let ((func (lambda ()
>   (with-temp-buffer
> (org-mode)
> (insert "* 1
> ,** 1-1
> a
> ,** 1-2
> a
> ,* 2
> ,** 2-1
> b
> ,** 2-2
> b
> ")
> (princ (format "--- before\n%s\n--- before\n"
>  (buffer-substring-no-properti
> es
>   (point-min) (point-max
> (org-map-entries
>  (lambda ()
>;; We get the outline path before calling
>;; (forward-line 2) to ensure that we are referring
>;; to the headline in the current iteration
>(princ (format "org-get-outline-path: %s\n"
> (org-get-outline-path t)))
>;; Move two lines below the current headline A. After
>;; executing (forward-line 2), the point is where
>;; the next headline B starts.
>(forward-line 2)
>;; We add a line which moves the headline B, one
>;; line below
>(insert "FOO" "\n"))
>  "LEVEL=2")
> (princ (format "--- after \n%s\n---after\n"
>  (buffer-substring-no-properti
> es
>   (point-min) (point-max
>   (princ "Experiment 1.1 (org-element-use-cache nil)\n")
>   (let ((org-element-use-cache nil))
> (funcall func))
>   (princ "Experiment 1.2 (org-element-use-cache t)\n")
>   (let ((org-element-use-cache t))
> (funcall func)))
> #+end_src
>
> #+RESULTS:
> #+begin_example
> Experiment 1.1 (org-element-use-cache nil)
> --- before
> ,* 1
> ,** 1-1
> a
> ,** 1-2
> a
> ,* 2
> ,** 2-1
> b
> ,** 2-2
> b
>
> --- before
> org-get-outline-path: (1 1-1)
> org-get-outline-path: (1 1-2)
> org-get-outline-path: (2 2-1)
> org-get-outline-path: (2 2-2)
> --- after
> ,* 1
> ,** 1-1
> a
> FOO
> ,** 1-2
> a
> FOO
> ,* 2
> ,** 2-1
> b
> FOO
> ,** 2-2
> b
> FOO
>
> ---after
> Experiment 1.2 (org-element-use-cache t)
> --- before
> ,* 1
> ,** 1-1
> a
> ,** 1-2
> a
> ,* 2
> ,** 2-1
> b
> ,** 2-2
> b
>
> --- before
> org-get-outline-path: (1 1-1)
> org-get-outline-path: (1 1-1 1-2)
> org-get-outline-path: (1 2 2-1)
> org-get-outline-path: (1 2 2-2)
> --- after
> ,* 1
> ,** 1-1
> a
> FOO
> ,** 1-2
> a
> FOO
> ,* 2
> ,** 2-1
> b
> FOO
> ,** 2-2
> b
> FOO
>
> ---after
> #+end_example
>
> In the results above, we can see that in =Experiment 1.2=,
> =org-get-outline-path= returns wrong information (note that the
> results are lists of length 3), while in =Experiment 1.1= this doesn't
> happen.
>
> * Experiment 2
>
> I noticed that when we pass one paameter (i.e. ="FOO\n"=) instead of
> two as we did in the previous experiment (i.e. ="FOO" "\n"=) to
> =insert=, the bug doesn't happen. See minimal reproducible example
> below.
>
> In this group of experiments we pass ="FOO\n"= instead of ="FOO" "\n"=
> to =insert=.
>
> #+HEADER: :results output
> #+begin_src elisp
> (let ((func (lambda ()
>   (with-temp-buffer
> (org-mode)
> (insert "* 1
> ,** 1-1
> a
> ,** 1-2
> a
> ,* 2
> ,** 2-1
> b
> ,** 2-2
> b
> ")
> (princ (format "--- before\n%s\n--- before\n"
>  (buffer-substring-no-properties
>   (point-min) (point-max
> (org-map-entries
>  (lambda ()
>(princ (format "org-get-outline-path: %s\n"
> (org-get-outline-path t)))
>(forward-line 2)
>   

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Russell Adams  writes:

> That said, I think the question is would any code for interpreting
> embedded org source blocks be cleaner than the existing inline task code.

I disagree. Src blocks are usually excluded from agendas and other
normal Org interactions - they are normally considered verbatim text
from the point of view of Org parser.

Special treatment of org src blocks would still introduce extra special
handling and on top of that interfere with the existing uses of org src
blocks, where the inner Org structure is not expected to have any effect.

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

Re: Unclear where ob-spice.el is being maintained

[Jonas Bernoulli]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> "Christopher M. Miles"  writes:
>>
>>> Thanks, Updated now.
 ...
> Jonas Bernoulli  writes:
>
>> In 2022 I changed Melpa to get ob-spice.el from
>> https://repo.or.cz/ob-spice.git in response to
>> https://github.com/melpa/melpa/issues/7872#issuecomment-1034945112.
>>
>> But org-contrib still contains that file and the README at the new
>> location still contains
>>
>> Bastien, it looks like we can now remove ob-spice from org-contrib.
>> Please, confirm.
>
> I do, thanks.
>
> -- 
>  Bastien Guerry

 Thanks to all!
 Jonas

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

[Jens Schmidt]

On 2023-08-26  14:54, Jens Schmidt wrote:
> On 2023-08-26  14:22, Ihor Radchenko wrote:

>> Looks good to me.
> 
> Implemented in the next version of the patch, please check.

Gentle ping ...

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Wed, Aug 30, 2023 at 05:08:40PM +0200, Russell Adams wrote:
> On Wed, Aug 30, 2023 at 04:39:50PM +0200, alain.coch...@unistra.fr wrote:
> > Russell Adams writes on Wed 30 Aug 2023 16:31:
> >
> >  > > What would be the equivalent of:
> >  > >
> >  > >* head :foo:
> >  > >*** inlt :bar:
> >  > >*** END
> >  > >
> >  > > where the 'bar' tag could be used in exactly the same way as the 'foo'
> >  > > tag.
> >
> >  > Please give some examples of "bar used in exactly the same way as
> >  > foo".
> >
> > M-x org-agenda m bar
>
> Is bar used across many headings with inline tasks? Then it may not.

That said, I think the question is would any code for interpreting
embedded org source blocks be cleaner than the existing inline task code.


--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Wed, Aug 30, 2023 at 04:39:50PM +0200, alain.coch...@unistra.fr wrote:
> Russell Adams writes on Wed 30 Aug 2023 16:31:
>
>  > > What would be the equivalent of:
>  > >
>  > >* head :foo:
>  > >*** inlt :bar:
>  > >*** END
>  > >
>  > > where the 'bar' tag could be used in exactly the same way as the 'foo'
>  > > tag.
>
>  > Please give some examples of "bar used in exactly the same way as
>  > foo".
>
> M-x org-agenda m bar

Is bar used across many headings with inline tasks? Then it may not.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Alain . Cochard]

Russell Adams writes on Wed 30 Aug 2023 16:31:

 > > What would be the equivalent of:
 > >
 > >* head :foo:
 > >*** inlt :bar:
 > >*** END
 > >
 > > where the 'bar' tag could be used in exactly the same way as the 'foo'
 > > tag.

 > Please give some examples of "bar used in exactly the same way as
 > foo".

M-x org-agenda m bar

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Wed, Aug 30, 2023 at 04:06:51PM +0200, alain.coch...@unistra.fr wrote:
> Russell Adams writes on Wed 30 Aug 2023 14:36:
>  > On Wed, Aug 30, 2023 at 01:49:26PM +0200, alain.coch...@unistra.fr wrote:
>  > > Russell Adams writes on Tue 29 Aug 2023 15:00:
>  > >  > On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote:
>  > >  > > Why not just put the TODO heading in a code block with type org?
>  > >  > >
>  > >  > > Then you get all the toys, ignored by the main file.
>  > >  >
>  > >  > If inline tasks are supposed to be Org enabled headings, but
>  > >  > NOT treated like headings in the current file, why not put
>  > >  > them in a src block?
>  > >  >
>  > >  > Doesn't this allow the same functionality without any new syntax
>  > >  > elements, or silly long *'s?
>  > >
>  > > Are regular Org tags allowed in this scenario?  If not, I'd be
>  > > miserable.
>  >
>  > It's a source block of type Org. That means *everything* that works in
>  > Org works inside that block. You might open it with C-c C-' to open it
>  > in an indirect buffer to enable everything.
>
> Sorry, that's not enough for me to understand.  What would be the
> equivalent of:
>
>* head :foo:
>*** inlt :bar:
>*** END
>
> where the 'bar' tag could be used in exactly the same way as the 'foo'
> tag.

Please give some examples of "bar used in exactly the same way as
foo".

Off the top of my head, I can only think that some agenda views and
collapsing to sparse tree may not recognize :bar: because it's inside
a source block.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Alain . Cochard]

Russell Adams writes on Wed 30 Aug 2023 14:36:
 > On Wed, Aug 30, 2023 at 01:49:26PM +0200, alain.coch...@unistra.fr wrote:
 > > Russell Adams writes on Tue 29 Aug 2023 15:00:
 > >  > On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote:
 > >  > > Why not just put the TODO heading in a code block with type org?
 > >  > >
 > >  > > Then you get all the toys, ignored by the main file.
 > >  >
 > >  > If inline tasks are supposed to be Org enabled headings, but
 > >  > NOT treated like headings in the current file, why not put
 > >  > them in a src block?
 > >  >
 > >  > Doesn't this allow the same functionality without any new syntax
 > >  > elements, or silly long *'s?
 > >
 > > Are regular Org tags allowed in this scenario?  If not, I'd be
 > > miserable.
 > 
 > It's a source block of type Org. That means *everything* that works in
 > Org works inside that block. You might open it with C-c C-' to open it
 > in an indirect buffer to enable everything.

Sorry, that's not enough for me to understand.  What would be the
equivalent of:

   * head :foo:
   *** inlt :bar:
   *** END

where the 'bar' tag could be used in exactly the same way as the 'foo'
tag.

Thanks.


-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: [DISCUSSION] Re-design of inlinetasks

[Russell Adams]

On Wed, Aug 30, 2023 at 01:49:26PM +0200, alain.coch...@unistra.fr wrote:
> Russell Adams writes on Tue 29 Aug 2023 15:00:
>  > On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote:
>  > > Why not just put the TODO heading in a code block with type org?
>  > >
>  > > Then you get all the toys, ignored by the main file.
>  >
>  > If inline tasks are supposed to be Org enabled headings, but NOT
>  > treated like headings in the current file, why not put them in a src block?
>  >
>  > Doesn't this allow the same functionality without any new syntax
>  > elements, or silly long *'s?
>
> Are regular Org tags allowed in this scenario?  If not, I'd be
> miserable.

It's a source block of type Org. That means *everything* that works in
Org works inside that block. You might open it with C-c C-' to open it
in an indirect buffer to enable everything.


--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [DISCUSSION] Re-design of inlinetasks

[Alain . Cochard]

Russell Adams writes on Tue 29 Aug 2023 15:00:
 > On Sat, Aug 26, 2023 at 08:01:16PM +0200, Russell Adams wrote:
 > > Why not just put the TODO heading in a code block with type org?
 > >
 > > Then you get all the toys, ignored by the main file.
 > 
 > If inline tasks are supposed to be Org enabled headings, but NOT
 > treated like headings in the current file, why not put them in a src block?
 > 
 > Doesn't this allow the same functionality without any new syntax
 > elements, or silly long *'s?

Are regular Org tags allowed in this scenario?  If not, I'd be
miserable.

Re: [ANM] org-timeblock: Schedule your day visually, using timeblocking technique inside Emacs

[Dr. Arne Babenhauserheide]

Ilya Chernyshov  writes:

> I don't understand why I need latex for this. Today I added command
> org-timeblock-write (bound to [w]) which you can use now to write
> org-timeblock buffer to SVG|PDF|PNG file. However, inkscape has to be
> installed in your system.

That’s just for print-quality, but outputting via inkscape should
provide similar quality for the usecase.

Building on existing LaTeX packages was just to not have to implement
the PDF layout yourself, but exporting what’s defined directly sounds
better — thank you!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: [ANM] org-timeblock: Schedule your day visually, using timeblocking technique inside Emacs

[Ilya Chernyshov]

"Dr. Arne Babenhauserheide"  writes:

> Wow, that looks nice!

Thank you!

>
> If you want to provide a print-export (i.e. for hanging on the door of a
> lecture room), you could see whether it’s easy to translate it to a
> latex time table like this:
> https://hg.sr.ht/~arnebab/stundenplan-wochenplan/browse/stundenplan-7days.tex?rev=tip
> https://www.draketo.de/software/stundenplan.pdf
> https://www.draketo.de/software/stundenplan-wochenplan-latex

I don't understand why I need latex for this. Today I added command
org-timeblock-write (bound to [w]) which you can use now to write
org-timeblock buffer to SVG|PDF|PNG file. However, inkscape has to be
installed in your system.

Fallback fonts in LaTeX export for non latin scripts

[Juan Manuel Macías]

The Unicode TeX engines, LuaTeX and XeTeX, have certain features to
apply fonts to scripts (Greek, Cyrillic, Arabic, etc.), without the need
to switch fonts explicitly. But LaTeX does not include any functionality
for loading 'fallback fonts' out of the box. Seeing things from TeX and
LaTeX this is understandable: since LaTeX is a typographic tool, the
user has the responsibility of choosing the fonts and knowing which
fonts to use. But from the Org side things may look different, as the
average user (who may not be interested in typographical or font
complexities) is looking for immediate readability of their texts when
exporting to any format. We know that, when exporting to LaTeX, this
does not always happen, if texts include non-Latin scripts.

These days I'm working on some experimental code to try to provide Org
with some sort of fallbacks fonts on LaTeX export. The functionality
would (for now) be linked to LuaTeX + babel package, since XeTeX,
although it has the ucharclasses package, is more limited.

The idea is to start from a defcustom that is an alist where each element
has the structure (script font). There would also be a default script +
font, for example ("latin" "Linux Libertine"). At the moment it would
only work for the default roman font, but it can be extended to default
sans serif, mono, etc.

The functionality would not be activated by default. When activated, it
also enables LuaTeX as the default LaTeX engine, and on each export a
list of non-latin scripts in the buffer is extracted. Perhaps with
some code like this, which checks for any non-latin characters:

(let ((scripts))
  (save-excursion
(goto-char (point-min))
(while
(re-search-forward "\\([^\u-\u007F\u0080-\u00FF\u0100-\u017F]\\)" 
nil t)
  (let ((script (aref char-script-table
  (string-to-char (match-string 1)
(add-to-list 'scripts script)
(setq script-list scripts
  script-list)

?

Once the list has been extracted, an ad hoc preamble would be formatted
assigning each script the chosen font.

WDYT? Do you think this would be a viable path? I think that in a few
days I can offer something usable for discussion.

Best regards,

Juan Manuel

--
Juan Manuel Macías

Re: Unclear where ob-spice.el is being maintained

[Bastien Guerry]

Ihor Radchenko  writes:

> "Christopher M. Miles"  writes:
>
>> Thanks, Updated now.
>>> ...
 Jonas Bernoulli  writes:

> In 2022 I changed Melpa to get ob-spice.el from
> https://repo.or.cz/ob-spice.git in response to
> https://github.com/melpa/melpa/issues/7872#issuecomment-1034945112.
>
> But org-contrib still contains that file and the README at the new
> location still contains
>
> Bastien, it looks like we can now remove ob-spice from org-contrib.
> Please, confirm.

I do, thanks.

-- 
 Bastien Guerry

Re: Unclear where ob-spice.el is being maintained

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> Thanks, Updated now.
>> ...
>>> Jonas Bernoulli  writes:
>>>
 In 2022 I changed Melpa to get ob-spice.el from
 https://repo.or.cz/ob-spice.git in response to
 https://github.com/melpa/melpa/issues/7872#issuecomment-1034945112.

 But org-contrib still contains that file and the README at the new
 location still contains

Bastien, it looks like we can now remove ob-spice from org-contrib.
Please, confirm.

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