Re: Volunteering to maintain ob-asymptote.el within Org

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>> As this module has never been part of org core, there is considerable
>> work which would need to be done as a prerequisite e.g. updating the
>> manual and adding documentation and examples, adding unit tests
>> etc. Therefore, I don't think there is any need to make a decision on
>> this now.
>
> You are not right.
> ob-asymptote has been moved out of the core after
>
> https://orgmode.org/list/87bl9rq29m@gnu.org
> Subject: Moving some lisp/ob-*.el files to org-contrib - your advice?
>
> So, we are not talking about adding a new library into the core. Rather
> about a late voice against moving it out.
>

Interesting. I made that assumption based on the org-contrib git log,
which showed edtries for this module back in 2010.

Still, I don't think that invalidates any of the points I was
making. The module has not been part of core for over 12 months and this
is the first mention of it. I think we should wait 12 months and see how
the maintenance and development of the module goes. After 12 months, if
there is still interest in moving it into core and if it has sufficient
documentation, examples and unit tests, this can be reviewed. 

Re: Volunteering to maintain ob-asymptote.el within Org

[Jarmo Hurri]

Greetings again, Ihor.

Ihor Radchenko  writes:

> After removing org-contrib over a year ago, your email is the first
> issue raised regarding ob-asymptote removal.

This is an interesting observation.

I have been using Asymptote with Org all the time, with the latest Org
from ELPA. Only when my distribution upgraded Emacs to 28.1 did errors
about ob-asymptote.el start popping up. So ob-asymptote.el must have
crept in from some directory this entire time.

I am not claming there are (lots of) ob-asymptote.el users out there,
just pointing out why this discussion takes place one year after the
fact.

Will return to other messages later, got to run now (literally).

All the best,

Jarmo

Re: Bug: Appointments duration and effort sums in agenda column view [9.3.7 (release_9.3.7-700-ga1e5be @ ~/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Mamoru Miura  writes:

>>But I am not even sure if this calculation is always same in different agenda 
>>types...
>
> Where can I get the specification of agenda types? I'm interested in
> the refactoring (but cannot work on it immediately...)

1. 11.2 The Agenda Dispatcher section of the manual
2. org-agenda-custom-commands docstring
3. org-agenda function inside org-agenda.el
   Look for the lines
   (pcase type
(`agenda

Hope it helps.

Best,
Ihor

P.S. Take your time if you need some and feel free to ask questions if
 you have any. We are not in hurry here. It is unlikely that anyone
 else will make significant changes in the agenda code any time
 soon.

Re: [PATCH] org-test: Run all ol tests on make test

[Ihor Radchenko]

Max Nikulin  writes:

> Hi,
>
> I figured out why "make test" is passing successfully while the same 
> with BTEST_RE="test-ol/insert-link-insert-description" is failing for a 
> proposed patch. Default selection pattern is ignoring most test-ol 
> cases. See the attachment.

Thanks a lot for narrowing this down!

> --- a/testing/org-test.el
> +++ b/testing/org-test.el
> @@ -424,7 +424,7 @@ setting `pp-escape-newlines' to nil manually."
>  "^\\([^.]\\|\\.\\([^.]\\|\\..\\)\\).*\\.org$")))
>  
>  (defun org-test-run-batch-tests ( org-test-selector)
> -  "Run all tests matching an optional regex which defaults to 
> \"\\(org\\|ob\\)\".
> +  "Run all tests matching an optional regex which defaults to 
> \"\\(org\\|ob\\|-ol\\)\".
>  Load all test files first."
>(interactive)
>(let ((org-id-track-globally t)

You missed the

(org-test-selector
 (if org-test-selector org-test-selector "\\(org\\|ob\\)"))

inside org-test-run-batch-tests

Also, org-test-run-all-tests

Best,
Ihor

Re: Something has happened such that I can't export to latex

[Ihor Radchenko]

Sharon Kimble  writes:

> Sorry, I forgot that I can do it from the menu. Now I've updated I get this 
> error message -
>
> - 
> |   Debugger entered--Lisp error: (void-variable 
> org-link--description-folding-spec)
> |  org-fold-initialize(" ▶▶▶")

Please restart Emacs.

Best,
Ihor

Re: [BUG] inserting notes at end

[Ihor Radchenko]

Tor Kringeland  writes:

> If our Org file is
>
> #+begin_example
> * a heading
>
> text
> #+end_example
>
> And we insert an empty note, we get
>
> #+begin_example
> * a heading
>
> - Note taken on [2022-07-26 Tue 16:10]
> text
> #+end_example
>
> instead of the expected
>
> #+begin_example
> * a heading
> - Note taken on [2022-07-26 Tue 16:10]
>
> text
> #+end_example

I get note after empty lines below the headline in both the cases.
This behavior is intentional according to org-log-beginning.

Best,
Ihor

[PATCH] * lisp/org.el (org-store-log-note): Do not indent empty lines

[Ihor Radchenko]

Tor Kringeland  writes:

> Currently if you insert a note on a heading that has double newlines in
> it, the empty newlines will be padded with spaces.  For example
>
> #+begin_example
> * heading
>   - Note taken on [2022-07-26 Tue 16:00] \\
> note with
> 
> newlines it in
> #+end_example
>
> It would be nice to (if this is not considered a bug) to have an option
> which would not insert these unecessary spaces when adding notes 

See the attached patch.

Best,
Ihor

>From 49b1092d7f82354390304dcc40e72cea73618956 Mon Sep 17 00:00:00 2001
Message-Id: <49b1092d7f82354390304dcc40e72cea73618956.1658892670.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Wed, 27 Jul 2022 11:30:19 +0800
Subject: [PATCH] * lisp/org.el (org-store-log-note): Do not indent empty lines
 in notes

See https://orgmode.org/list/m235eo9d8b@ntnu.no
---
 lisp/org.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index ca0b12550..6817e44c1 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10397,8 +10397,9 @@ (defun org-store-log-note ()
 	   (let ((ind (org-list-item-body-column (line-beginning-position
 	 (dolist (line lines)
 	   (insert-and-inherit "\n")
-	   (indent-line-to ind)
-	   (insert-and-inherit line)))
+   (unless (string-empty-p line)
+	 (indent-line-to ind)
+	 (insert-and-inherit line
 	   (message "Note stored")
 	   (org-back-to-heading t))
   ;; Don't add undo information when called from `org-agenda-todo'.
-- 
2.35.1

Re: [PATCH] org-export: Remove zero-width space escapes during export

[Max Nikulin]

On 26/07/2022 19:59, Ihor Radchenko wrote:


I am attaching a tentative patch that will make Org export remove
zero-width spaces when those spaces actually separate the object
boundaries.


Ihor, I have realized that you did not address another use case: zero 
width spaces may be added to suppress activation of markup. In such 
cases they are in the middle of text objects, but they should be removed.


Switch to the *​scratch​* buffer.

I consider zero width spaces as a workaround that is acceptable in some 
cases but awkward in others. It is tricky to deal with it in some 
general way.


I do not agree with the stance "just maintain status quo" expressed in 
response to Juan Manuel Macías. On zero width spaces and Org syntax. 
Fri, 03 Dec 2021 12:48:16 + 
https://list.orgmode.org/orgmode/87ilw5yhv3@posteo.net/


An idea. At certain moment I was surprised that markup markers are not 
activated at the borders of export snippets:


intra@@org:@@*w*@@org:@@ord

It is not really lightweight markup but at least it is purely ASCII and 
visible by default. It might be breaking change in some edge cases. I am 
unsure concerning increasing complexity of the parser. Macro markers 
{{{macro}}} have similar behavior.

Re: The fate of ob-asymptote.el

[Ihor Radchenko]

Jarmo Hurri  writes:

>> The advantage of maintaining ob-asymptote.el in the main asymptote
>> repo is that people who are intimately familiar with the asymptote
>> features can directly contribute and enhance the Org
>> integration. Moreover, distributing together with the asymptote means
>> no headache with back-compatibility issues.
>>
>> Maintaining on Org side will have an advantage of using the latest
>> additions to Org babel features.
>>
>> I feel like it is more important to make use of the asymptote features
>> if its devs are going to be interested. Of course, IMHO.
>
> I have a very bad feeling about tying ob-asymptote.el with Asymptote,
> and I am trying to put my finger on this feeling. I think the problem is
> this one.
>
> ob-asymptote.el is coupled very loosely with Asymptote. Basically the
> only thing ob-asymptote.el requires from Asymptote is the ability to
> call the executable with some established parameters.
>
> Then again, ob-asymptote.el is coupled much more tightly with Org. It
> uses many more properties of Org (Babel) than of the Asymptote
> program.
>
> As a result, changes in Org are much more likely to affect
> ob-asymptote.el than changes in Asymptote. I think basic software
> development rules of thumb suggest that ob-asymptote.el should then be
> bundled with Org.

>From my point of view ob-asymptote.el is as bare bones as babel library
can be. It does not use any fancy Org babel features like sessions,
error display of converting the output to various :results output
options.

In contrast, it does a lot of work trying to convert Elisp types to
Asymptote in `org-babel-asymptote-var-to-asymptote`.

Of course, my view is a subject of discussion. Or maybe you have plans
to implement advanced Org babel features for Asymptote. IDK.

>From my point of view, any kind of new functionality in ob-asymptote.el
requires a deep knowledge about the Asymptote programming - the
knowledge most of the Org devs lack. At the same time, changes in Org
babel core functionality are unlikely to cause any issues in
ob-asymptote - we try our best to keep backwards compatibility with
third-party babel packages anyway.

Best,
Ihor

Re: Volunteering to maintain ob-asymptote.el within Org

[Ihor Radchenko]

Jarmo Hurri  writes:

>> Then, it would help to have more practical examples compared to what
>> we have in
>> https://www.orgmode.org/worg/org-contrib/babel/languages/ob-doc-asymptote.html
>
> Absolutely. I have plenty of examples from the domains of math and
> computer science.

Feel free to submit patches against https://git.sr.ht/~bzg/worg

>> That a common minimalist argument. Some people dislike the fact that
>> software includes features they do not personally use. Similar
>> arguments are often raised regarding, for example, games shipped with
>> Emacs.
>
> I do not see Org as a "minimalist" system. I see it as glue.
>
> I think one of the great powers of Org mode is its capability to act
> together with various systems, including LaTeX and a host of programming
> languages. I would never imagine that Org would only support the tools I
> use, but I expect to be positively surprised by the fact that Org will
> support, out of the box, something that I am not using now but will be
> using in the future.

I am not arguing with you. Just pointed that some people have different
point of view.

>> I disagree in this particular case. Having ob-asymptote.el is not a
>> featurism - I would not expect people to play around a full new
>> programming language just because ob-language.el is in Org. The
>> barrier of entry is too high to make it destructing.
>
> I am not sure I can interpret your text correctly. But if you are saying
> that builtin support for Asymptote will not lower the threshold of its
> use among Org users, I would ask the following questions:
> - How many Org users are already capable of programming?
> - How many Org users prefer code-based representations to other forms?

Nope. This is not what I am saying.
I am saying that ob-asymptote will not be on the way of users who are
exploring Org and do not intend to use Asymptote. It is only useful for
people who deliberately look into Asymptote code blocks. Others will not
ever need to try it (that would require installing Asymptote and other
high-threshold actions).

Best,
Ihor

Re: Volunteering to maintain ob-asymptote.el within Org

[Ihor Radchenko]

Jarmo Hurri  writes:

>> Then, it would help to have more practical examples compared to what
>> we have in
>> https://www.orgmode.org/worg/org-contrib/babel/languages/ob-doc-asymptote.html
>
> Absolutely. I have plenty of examples from the domains of math and
> computer science.

Feel free to submit patches against https://git.sr.ht/~bzg/worg

>> That a common minimalist argument. Some people dislike the fact that
>> software includes features they do not personally use. Similar
>> arguments are often raised regarding, for example, games shipped with
>> Emacs.
>
> I do not see Org as a "minimalist" system. I see it as glue.
>
> I think one of the great powers of Org mode is its capability to act
> together with various systems, including LaTeX and a host of programming
> languages. I would never imagine that Org would only support the tools I
> use, but I expect to be positively surprised by the fact that Org will
> support, out of the box, something that I am not using now but will be
> using in the future.

I am not arguing with you. Just pointed that some people have different
point of view.

>> I disagree in this particular case. Having ob-asymptote.el is not a
>> featurism - I would not expect people to play around a full new
>> programming language just because ob-language.el is in Org. The
>> barrier of entry is too high to make it destructing.
>
> I am not sure I can interpret your text correctly. But if you are saying
> that builtin support for Asymptote will not lower the threshold of its
> use among Org users, I would ask the following questions:
> - How many Org users are already capable of programming?
> - How many Org users prefer code-based representations to other forms?

Nope. This is not what I am saying.
I am saying that ob-asymptote will not be on the way of users who are
exploring Org and do not intend to use Asymptote. It is only useful for
people who deliberately look into Asymptote code blocks. Others will not
ever need to try it (that would require installing Asymptote and other
high-threshold actions).

Best,
Ihor

Re: Volunteering to maintain ob-asymptote.el within Org

[Ihor Radchenko]

Tim Cross  writes:

> As this module has never been part of org core, there is considerable
> work which would need to be done as a prerequisite e.g. updating the
> manual and adding documentation and examples, adding unit tests
> etc. Therefore, I don't think there is any need to make a decision on
> this now.

You are not right.
ob-asymptote has been moved out of the core after

https://orgmode.org/list/87bl9rq29m@gnu.org
Subject: Moving some lisp/ob-*.el files to org-contrib - your advice?

So, we are not talking about adding a new library into the core. Rather
about a late voice against moving it out.

Best,
Ihor

Re: Volunteering to maintain ob-asymptote.el within Org

[Tim Cross]

Ihor Radchenko  writes:

> Another question is long-term maintainability. We have a limited
> manpower and cannot cater too many support requests or take care about
> parts of code not used by most people. After removing org-contrib over a
> year ago, your email is the first issue raised regarding ob-asymptote
> removal. Since you are volunteering to maintain it, things gets easier.
> However, the final decision is after Bastien.
>

and I don't think it is a decision which has to be made now.

It is fantastic someone has stepped up to maintain this code. However,
it may be wise to wait 12 months before making an important decision
like moving it into core. While moving something into core may seem
easy, moving it back out tends to be more problematic and require more
change management to avoid unexpected impact to org users (including
none users of this module who could also be impacted by any breakage
introduced).

As this module has never been part of org core, there is considerable
work which would need to be done as a prerequisite e.g. updating the
manual and adding documentation and examples, adding unit tests
etc. Therefore, I don't think there is any need to make a decision on
this now.

I also think it is prudent to allow any new maintainer some period of
time to get to grips with the maintenance role. Once something becomes
part of core, maintenance demands can increase significantly. For
example, any significant change in org mode or Emacs will need to be
addressed in a timely manner to prevent issues with ob-asymptote
impacting org usage generally. From a maintainers perspective, it often
means having to run multiple versions of both Emacs and org mode,
keeping an eye on org and Eamcs bug reports and responding to user
queries.

In addition to all of this, there is also the unexpected burden of
success. If you actually do a good job, the amount of maintenance work
can actually increase. I speak from personal experience. I took over
maintenance of a small nodejs module about 5 years ago. At the time,
this module had only a few thousand downloads per week. It now averages
around 225k weekly downloads. Code maintenance has not been a
problem. However, user maintenance has been a considerable burden. I
have ended up spending far more time writing documentation, providing
usage examples and helping users than I expected. I would estimate over
80% of all the issues raised by users are due to errors in user code
(most have nothing to do with my module, but I still need to
investigate to verify that). What makes matters harder is that the
module concerned is not one I need any longer. At some point, I will
likely hand maintenance on (assuming someone wants it of course). The
thing to note is that the level of expected maintenance and actual
maintenance can be surprisingly different and it doesn't take much
before that role can become a burden, especially if you have other
demanding work needing attention.  

Finally, we don't actually know what the user base size for asymptote
currently is or could be. I've used org for many years and I've used
plantuml, ditta, graphviz and gnuplot, but I've never used
ob-asymptote. While this may appear to be a critical tool in some use
case groups, it may not be an overall critical module for the overall
org user base. I'm also not convinced that being in contrib rather than
core is really an impediment as suggested. Now that org-contrib is part
of non-gnu ELPA and that archive is automatically configured in new
versions of Emacs, adding org-contrib is fairly trivial. I suspect many
users already add it as part of their setup anyway.

While personally I don't agree with adding more things into core, my
main point is we don't need to make this decision now. We can wait 12
months and if whoever is maintaining the mode still wants to see it
moved into core and if all the prerequisite work has been completed, we
can then put it to the community and see what the overall consensus
is. In the meantime, the mode maintainer can work on building the use
base and strengthening their case for inclusion and getting a real feel
for what the maintenance demands are. 

Re: Bug: Appointments duration and effort sums in agenda column view [9.3.7 (release_9.3.7-700-ga1e5be @ ~/.emacs.d/straight/build/org/)]

[Mamoru Miura]

Thank you for reviewing my patch.

>Ideally, we should factor out the duration calculation from the depths of the 
>agenda code into a separate function and then use it.

I agree with it.

>But I am not even sure if this calculation is always same in different agenda 
>types...

Where can I get the specification of agenda types? I'm interested in
the refactoring (but cannot work on it immediately...)

Kind regards,
Mamoru

2022年7月21日(木) 20:47 Ihor Radchenko :
>
> Mamoru Miura  writes:
>
> > ...
> > Steps to see this issue:
> >
> > 1. run M-x org-agenda
> > 2. type "a" to show "agenda for current week or day"
> > 3. run M-x org-agenda-columns (C-c C-x C-c)
>
> Thanks for providing the details! I have also found the relevant thread.
> It was not immediately visible because of my MUA settings.
>
> > -  (get-text-property (point) 'duration)
> > -  (propertize (org-duration-from-minutes
> > -   (get-text-property (point) 
> > 'duration))
> > -  'face 'org-warning))
> > +  (when-let* ((formatted-item 
> > (org-agenda-format-item nil (org-get-entry) nil nil nil t))
> > +  (duration-string (get-text-property 
> > 0 'duration formatted-item)))
> > +(propertize (org-duration-from-minutes 
> > duration-string) 'face 'org-warning)))
>
> I cannot say that I like calling org-agenda functions, but I cannot
> propose anything better either (agenda code sucks...).
>
> Ideally, we should factor out the duration calculation from the depths
> of the agenda code into a separate function and then use it. But I am
> not even sure if this calculation is always same in different agenda
> types...
>
> For the code, it will err when the time range is located inside the
> headline and org-agenda-search-headline-for-time is set to non-nil
> (which it is, by default)
>
> Best,
> Ihor

Re: Something has happened such that I can't export to latex

[Sharon Kimble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Ihor Radchenko  writes:

>  Just trying to export to latex this afternoon and this showed in the
>  mini-buffer -
>  - 
>  | (void-variable org-latex-babel-language-alist) in org-latex-template
>  - 
>
> Please update again. The bug has been introduced recently, but should be 
> fixed on main already.
>
> Best,
> Ihor
Sorry, I forgot that I can do it from the menu. Now I've updated I get this 
error message -

- 
|   Debugger entered--Lisp error: (void-variable 
org-link--description-folding-spec)
|  org-fold-initialize(" ▶▶▶")
|  org-mode()
|  #f(compiled-function () #)()
|  org-export-copy-buffer()
|  org-export-as(latex nil nil nil (:output-file "kpe.tex"))
|  org-export-to-file(latex "kpe.tex" nil nil nil nil nil)
|  org-latex-export-to-latex()
|  funcall-interactively(org-latex-export-to-latex)
|  call-interactively(org-latex-export-to-latex nil nil)
|  command-execute(org-latex-export-to-latex)   
-    

Any ideas please?

Thanks
Sharon.
- -- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 11, fluxbox 1.3.7, emacs 29.0.50, org 9.5.4
-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmLgGNUdHGJvdWRpY2Nh
c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1vA2w//ZvrfqUW3C2BrlPDh
E1K4OZrC8TC4AsyqFpsVWs3P8ByVv21wi8Rhgo7iSpxx/+nE//oPjGm7kk6nXwna
DWDou8edxBIdHc6HXCRlCS3YbHtfzxr8D/k46JFN+JwrgbocMQtIM6a2AwYW7eV6
zccAPQ/TVyW5fRp9ew/N17Jg/yhqI2SrG5G0NpZMLCbIx/crtYxXGg5N80ouz7JD
pvgmQThz06tiU//Zoct8VGB7ubzBmta96ixV0gIOhQ6dplZ+FCyiBpbfG9wSUHTY
4dwa/ArZHDSFpAk2m5ylF8hyYdy2C+dKDyIjpV/nfTuHyXznJvka6Sc7TfN3Xw5b
5itrp4elz8iGrNr7ENehmplOwfPanqETibeOpC+GHkDGls1hgmCfn6cl35dcAJQ7
YobvHJhlnYwFNAALCp28KXZGdOY0m9J+y3txeTBEQPKGNIX/SRFfJCpOiEUP28Q+
Snw441U75tCcq1xvYvT7aopxOLBnUmSqEc01CAZYEMRx1fqdtRd9IS3ObgtbZaru
5L0raAFh3YRqnQvJY3a+T9tpvZYEm0GG/bOP4lOsSrZbVXy+OtTeKq7SFDETSK1n
KPD0a+uGsalIVjO3e/IotRDftgiS1oz6IfJ4GNs3et8pijZ+B9ViLcA6VTXFOAS6
bVcAXSlUDaLJ19WVVmD7ea7MQHE=
=YtLj
-END PGP SIGNATURE-

Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Hi Ihor,

A thousand apologies for my horrible carelessness with the parentheses.
I should have checked the code. Here goes the patch again corrected. I
hope it's alright now.

Ihor Radchenko writes:

> Also, the original code contained the clause:
> (or (get lang from the alist1)
> (get lang from the alist2)
> lang ; Fallback to provided language if not known.
> )
>
> Your variant does not have the fallback part. Is it intentional?

Yes, I removed it because I thought it was not necessary, because after
all the user must put a supported language as the value of #+language.
Anyway, in case it breaks something backwards I have replaced it. Now
the or expression is:

(or (nth 1 (assoc-string lang org-latex-language-alist t))
lang)

Best regards,

Juan Manuel 

>From 483cf69e0ca56c560c3bd53db13887a63d529ec9 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Tue, 26 Jul 2022 18:01:52 +0200
Subject: [PATCH] lisp/ox-latex.el: Remove Babel and Polyglossia alists

* (org-latex--format-spec): The new variable is now `org-latex-language-alist'
---
 lisp/ox-latex.el | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 121a3f84c..14728f0ba 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1861,8 +1861,10 @@ INFO is a plist used as a communication channel."
   "Create a format-spec for document meta-data.
 INFO is a plist used as a communication channel."
   (let ((language (let ((lang (plist-get info :language)))
-		(or (cdr (assoc-string lang org-latex-babel-language-alist t))
-			(nth 1 (assoc-string lang org-latex-polyglossia-language-alist t))
+;; Here it would suffice to obtain the second
+;; element, which always returns the name
+;; language name in `org-latex-language-alist'
+(or (nth 1 (assoc-string lang org-latex-language-alist t))
 			lang
 `((?a . ,(org-export-data (plist-get info :author) info))
   (?t . ,(org-export-data (plist-get info :title) info))
-- 
2.37.1

Re: [PATCH] org-export: Remove zero-width space escapes during export

[Max Nikulin]

On 26/07/2022 19:59, Ihor Radchenko wrote:


This is a bug. While escape symbols do not affect export in most common
scenarios, your report is adding yet another case when zero-width space
is actually altering the export result.


I agree is zero-width space used as an escape character is too 
intrusive. It adds stray line breakpoints, it may be unwanted during 
copy of text, especially if such text is code or a command.



I am attaching a tentative patch that will make Org export remove
zero-width spaces when those spaces actually separate the object
boundaries.

Any objections?


I think, you broke a valid use case when zero width space allows to wrap 
objects in the case of narrow page


[[unicorn-1.jpg]]​[[unicorn-2.jpg]]​[[unicorn-3.jpg]]​[[unicorn-4.jpg]]

It was briefly discussed, see
https://list.orgmode.org/874k7qboaq@nicolasgoaziou.fr/
Nicolas Goaziou. Re: Org-syntax: Intra-word markup. Fri, 03 Dec 2021 
00:05:33 +0100



The idea was indeed inspired by Markdown.
However, Markdown is different - **bold** is the official syntax to
indicate bold markup.


Or by asciidoc 
https://list.orgmode.org/1ef0e093-c165-2a5f-954d-6a33b64c8...@mailbox.org/



+(setq processed-string
+  (replace-regexp-in-string "\\`​" "" string))
+(setq processed-string
+  (replace-regexp-in-string "​\\'" "" processed-string))


Please, use \u200B instead of the invisible character.
info "(elisp) Non-ASCII Characters in Strings"
https://www.gnu.org/software/emacs/manual/html_node/elisp/Non_002dASCII-in-Strings.html

Re: Something has happened such that I can't export to latex

[Sharon Kimble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Ihor Radchenko  writes:

>  Just trying to export to latex this afternoon and this showed in the
>  mini-buffer -
>  - 
>  | (void-variable org-latex-babel-language-alist) in org-latex-template
>  - 
>
> Please update again. The bug has been introduced recently, but should be 
> fixed on main already.
>
> Best,
> Ihor

Thanks Ihor.

How can I install my new org-mode setup from git please? The only way
that I know of is to close emacs down, and then start it again.

So can you advise please?

Thanks
Sharon.
- -- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 11, fluxbox 1.3.7, emacs 29.0.50, org 9.5.2
-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmLgF0cdHGJvdWRpY2Nh
c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1vZMhAAyPWGvoRn9TkxiDrs
GTa188ybcGuDQoRbRlcdncXeLdmFB7ijJT89QNiJdO52Ni2GPHRS76akwocmdUSJ
vriQX7wneOMqF29FYrkUwmt5V5TOEAHflIRD/YIfONqOCf9zi8TI+0AZOhFsZh3f
m+PkHlNmiwJftF/QnUMJDqf858CB0CYz6qO/ghRDQXrpQYCPNFF7iyqYp4enEiwY
V+VWtJXaP7RiKU6+E2cBzLlU4OkdzsAKBiVmqiosF52n3yNPNeUJgpzswedVitkU
Jwhc7KBI6NwEhYIx10EXhoZUi4h/OChDmfStbsmGXtjsieR846RjDb0MVifJx+7p
Yb5Ofio52V/B2qzJROrCPkJ0+OiH/Ty6sKDQnS3uCpdAUCy+5yQ2YoA9e3w5D9zc
nhN2fkRr/6buMGLadfgZ8tF7LBOyNgbIHmEIKmne+pP3kYv2wtuVYERSW/nyjk/D
3Hu2YyvGk8ixC2X3P75AAnJlhDx4RL4r5kbIyXB8ahdF7xktCJQPSW2DI18W0ozW
CjytZgescYst2v5FaV/G7tJjGw2Bc72KUhlzjTWCciwFXS9t1x5PY1XT/yULcWCH
8T0n9NzaPIn2KFboO0ZvdszdxfePHBXjLFjGOjm9cVi18T5lw2T/y20Qwz7y2FXI
99BPaoSKowyBvdmzzLqEI18uLyA=
=IYKy
-END PGP SIGNATURE-

[PATCH] org-test: Run all ol tests on make test

[Max Nikulin]

Hi,

I figured out why "make test" is passing successfully while the same 
with BTEST_RE="test-ol/insert-link-insert-description" is failing for a 
proposed patch. Default selection pattern is ignoring most test-ol 
cases. See the attachment.From 0cb30c77d888a38360f11657f7a391ab72fa312e Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Tue, 26 Jul 2022 22:11:40 +0700
Subject: [PATCH] org-test: Run all ol tests on make test

* mk/default.mk (BTEST_RE): Add -ol to the default pattern.
* testing/org-test.el (org-test-run-batch-tests): Update default regexp
for test selection in the docstring.

Only `test-ol/org-toggle-link-display' from test-ol.el was executed
since it is matched by "org" part of the pattern. The leading dash is
added to make tests a bit more specific. Reported in:
Ihor Radchenko to emacs-orgmode. Re [PATCH v7] ol.el: add
description format parameter to org-link-parameters.
Sun, 24 Jul 2022 21:15:31 +0800.
https://list.orgmode.org/87v8rmd53g.fsf@localhost/
---
 mk/default.mk   | 2 +-
 testing/org-test.el | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/mk/default.mk b/mk/default.mk
index 33e737da3..7371d3a99 100644
--- a/mk/default.mk
+++ b/mk/default.mk
@@ -72,7 +72,7 @@ REPRO_ARGS ?=
 req-ob-lang = --eval '(require '"'"'ob-$(ob-lang))'
 lst-ob-lang = ($(ob-lang) . t)
 req-extra   = --eval '(require '"'"'$(req))'
-BTEST_RE   ?= \\(org\\|ob\\)
+BTEST_RE   ?= \\(org\\|ob\\|-ol\\)
 BTEST_LOAD  = \
 	--eval '(add-to-list '"'"'load-path (concat default-directory "lisp"))' \
 	--eval '(add-to-list '"'"'load-path (concat default-directory "testing"))'
diff --git a/testing/org-test.el b/testing/org-test.el
index 0520e82f9..6defa9cc9 100644
--- a/testing/org-test.el
+++ b/testing/org-test.el
@@ -424,7 +424,7 @@ setting `pp-escape-newlines' to nil manually."
 "^\\([^.]\\|\\.\\([^.]\\|\\..\\)\\).*\\.org$")))
 
 (defun org-test-run-batch-tests ( org-test-selector)
-  "Run all tests matching an optional regex which defaults to \"\\(org\\|ob\\)\".
+  "Run all tests matching an optional regex which defaults to \"\\(org\\|ob\\|-ol\\)\".
 Load all test files first."
   (interactive)
   (let ((org-id-track-globally t)
-- 
2.25.1

Re: Something has happened such that I can't export to latex

[Ihor Radchenko]

>
> Just trying to export to latex this afternoon and this showed in the
> mini-buffer -
> - 
> | (void-variable org-latex-babel-language-alist) in org-latex-template
> - 

Please update again. The bug has been introduced recently, but should be
fixed on main already.

Best,
Ihor

Something has happened such that I can't export to latex

[Sharon Kimble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Just trying to export to latex this afternoon and this showed in the
mini-buffer -

- 
| (void-variable org-latex-babel-language-alist) in org-latex-template
- 

and this showed in the debugger -

- 
|Debugger entered--Lisp error: (void-variable org-latex-babel-language-alist)
|  org-latex--format-spec((:export-options nil :back-end #s(org-export-backend 
:name latex :parent nil :transcoders (... ... ... ... ... ... ... ... ... ... 
... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...) :options 
(... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 
... ... ... ... ... ... ... ...) :filters (... ... ... ...) :blocks nil :menu 
(108 "Export to LaTeX" ...)) :translate-alist ((bold . org-latex-bold) 
(center-block . org-latex-center-block) (clock . org-latex-clock) (code . 
org-latex-code) (drawer . org-latex-drawer) (dynamic-block . 
org-latex-dynamic-block) (entity . org-latex-entity) (example-block . 
org-latex-example-block) (export-block . org-latex-export-block) 
(export-snippet . org-latex-export-snippet) (fixed-width . 
org-latex-fixed-width) (footnote-definition . org-latex-footnote-definition) 
(footnote-reference . org-latex-footnote-reference) (headline . 
org-latex-headline) (horizontal-rule . org-latex-horizontal-rule) 
(inline-src-block . org-latex-inline-src-block) (inlinetask . 
org-latex-inlinetask) (italic . org-latex-italic) (item . org-latex-item) 
(keyword . org-latex-keyword) (latex-environment . org-latex-latex-environment) 
(latex-fragment . org-latex-latex-fragment) (line-break . org-latex-line-break) 
(link . org-latex-link) (node-property . org-latex-node-property) (paragraph . 
org-latex-paragraph) ...) :exported-data # :input-buffer "kpe.org" :input-file 
"/home/boudiccas/research/w..." :latex-class "my-report" :latex-class-options 
"[a4paper,11pt,twoside,open..." :latex-header "\\input{/home/boudiccas/res..." 
:latex-header-extra nil :description nil :keywords nil :subtitle nil ...))
|  org-latex-template(#("\n\n\\chapter{Boo..." 11 25 ... 90 94 ... 96 138 ... 
249 253 ... ...) (:export-options nil :back-end ... :translate-alist ... 
:exported-data # :input-buffer 
"kpe.org" :input-file "/home/boudicca..." :latex-class "my-report" ...))
|  org-export-as(latex nil nil nil (:output-file "kpe.tex"))
|  org-export-to-file(latex "kpe.tex" nil nil nil nil nil)
|  org-latex-export-to-latex()
|  funcall-interactively(org-latex-export-to-latex)
|  call-interactively(org-latex-export-to-latex nil nil)
|  command-execute(org-latex-export-to-latex)
- 

I just updated my emacs's packages, and also my org-mode installation,
but its still failing such that I cannot export to latex like I have
been able to.

Thanks
Sharon.
- -- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 11, fluxbox 1.3.7, emacs 29.0.50, org 9.5.2
-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmLgCP0dHGJvdWRpY2Nh
c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1tuwxAAnGf+OjubV45Bl9dq
ZJvm1YaSSq0N9XCtOF3eqF1kWpldXWuHxPlVa//4lsfU747m1UPorqj6a5mw7zPx
RmQf65uxAxPqAjrSekAc7MSOJ1+OqfvyFSeVwHjQzeDV18pMtayfl4FRF7fz1kwD
thHfZY+61h+y+ePuJhhlzAIX4++HpwYELq6SGHAhOHAN1CIQ9yaL11AK27SDE8Ey
H1wv3C7M2e8AeaZ4I4irXCOjDfCiSG1kQGOTs3g42FGBj5ykSkihC4tOgECdOCrP
RKebJQWtbSP4Mu8OmvrorD0Xf5Rt6ZSZXQT/x62nAcT3dbgA+RIqn0FB5zyX31vd
epsi1aYZoZlMzlcc+R4XZQNh3wfZB2/U7t9/mQfnQHiRFnItztzXe6DHo6EcfC7H
VfmADk3Gada8qI8nVWKfuImDiwvy/naQbNSzWSOCRDBRTJ6y0wJlxnvNbbr9puQP
CXflxGFWb5nlnRI+qVSALgeT4gLG1mdHUtuXEjavRUhFMg2DNxUs2cGStb0BijEN
KaXelNeFk//G34w0IM3OPtf2l16AWqBKv5BGiJg8TpNc0ck1+SryLJ4KflT/S/Iq
rfDOKDJdDR3r1EwVknAMseK3r0/6A5jLldpwjJWSuF3NmtGS9mfp60DNtJGBfp6D
wejP4v7PzB1s/OkqZeQiQWv6z1Y=
=HjWD
-END PGP SIGNATURE-

Re: [PATCH] org-export: Remove zero-width space escapes during export

[András Simonyi]

Dear All,

this might be a very stupid question as I'm not familiar with the
internals of the Org export engine, but couldn't this change lead to
problems with the Org-to-Org export of documents containing these
"semantic separators"?

thanks and best wishes,
András

On Tue, 26 Jul 2022 at 16:52, Timothy  wrote:
>
> Hi Ihor,
>
> > I am attaching a tentative patch that will make Org export remove
> > zero-width spaces when those spaces actually separate the object
> > boundaries.
> >
> > Any objections?
>
> IMO this is an immanently sensible idea. I added an export filter like this to
> my config basically as soon as I found out about zero-width spaces.
>
> One minor quibble, I find the name mildly misleading. When you say “escaped” I
> think of escaped characters, which isn’t really connected to what the zero 
> width
> does. I’d personally be inclined to call the zero width space an “invisible
> semantic separator”.
>
> > +(defun org-export–remove-escaped (data info)
> > +  “Remove escape symbols from plain-text in DATA.
> > +DATA is a parse tree or a secondary string.  INFO is a plist
> > +containing export options.  It is modified by side effect and
> > +returned by the function.”
>
> How about:
>
> ┌
> │ (defun org-export--remove-semantic-separators (data info)
> │   "Remove Org-specific semantic separators from plain-text in DATA.
> │ DATA is a parse tree or a secondary string.  INFO is a plist
> │ containing export options.  It is modified by side effect and
> │ returned by the function."
> └
>
> All the best,
> Timothy

Re: [PATCH] org-export: Remove zero-width space escapes during export

[Timothy]

Hi Ihor,

> I am attaching a tentative patch that will make Org export remove
> zero-width spaces when those spaces actually separate the object
> boundaries.
>
> Any objections?

IMO this is an immanently sensible idea. I added an export filter like this to
my config basically as soon as I found out about zero-width spaces.

One minor quibble, I find the name mildly misleading. When you say “escaped” I
think of escaped characters, which isn’t really connected to what the zero width
does. I’d personally be inclined to call the zero width space an “invisible
semantic separator”.

> +(defun org-export–remove-escaped (data info)
> +  “Remove escape symbols from plain-text in DATA.
> +DATA is a parse tree or a secondary string.  INFO is a plist
> +containing export options.  It is modified by side effect and
> +returned by the function.”

How about:

┌
│ (defun org-export--remove-semantic-separators (data info)
│   "Remove Org-specific semantic separators from plain-text in DATA.
│ DATA is a parse tree or a secondary string.  INFO is a plist
│ containing export options.  It is modified by side effect and
│ returned by the function."
└

All the best,
Timothy

[BUG] inserting notes at end

[Tor Kringeland]

If our Org file is

#+begin_example
* a heading

text
#+end_example

And we insert an empty note, we get

#+begin_example
* a heading

- Note taken on [2022-07-26 Tue 16:10]
text
#+end_example

instead of the expected

#+begin_example
* a heading
- Note taken on [2022-07-26 Tue 16:10]

text
#+end_example

If POINT is at the heading or the line below, behavior is as expected.
If a note has already been inserted correctly before (as in the third
snippet), then subsequent notes are insert corrected as well, regardless
of POINT.  Conversely, if one first is inserted wrongly, then subsequent
will also be inserted wrongly.

[WISH LIST] Remove leading spaces in notes

[Tor Kringeland]

Currently if you insert a note on a heading that has double newlines in
it, the empty newlines will be padded with spaces.  For example

#+begin_example
* heading
  - Note taken on [2022-07-26 Tue 16:00] \\
note with

newlines it in
#+end_example

It would be nice to (if this is not considered a bug) to have an option
which would not insert these unecessary spaces when adding notes 

[PATCH] org-export: Remove zero-width space escapes during export

[Ihor Radchenko]

K K  writes:

> My use case is to emphasize chinese characters without spaces being inserted, 
> even those zero-width spaces. For example "中文*测*试" should be enough to 
> emphasize "测".
>
> I am using zero-width spaces right now, and it works fine in org-mode 
> buffers, but if exported to latex-pdf files, the U+200B ZERO WIDTH SPACE 
> character will not be zero-width for certain fonts. So I hope not to use that 
> character.

This is a bug. While escape symbols do not affect export in most common
scenarios, your report is adding yet another case when zero-width space
is actually altering the export result.

I am attaching a tentative patch that will make Org export remove
zero-width spaces when those spaces actually separate the object
boundaries.

Any objections?

> On Tue, 26 Jul 2022 09:26:42 +0800, Ihor Radchenko wrote:
>> Another idea we have discussed is using something similar to Markdown
>> format: **bold**, //italics//, __underline__, etc. It is less verbose
>> compared to the special blocks, which should be valuable for
>> Japanese/Chinese/other languages with no spaces between words.
>
> By the way, it seems that my use case has already been implemented by 
> markdown-mode. In a markdown-mode buffer "中文**测**试" will certainly make "测" 
> bold.

The idea was indeed inspired by Markdown.
However, Markdown is different - **bold** is the official syntax to
indicate bold markup. Though things are more complex in reality:
https://www.markdownguide.org/basic-syntax/ Markdown has its own edge
cases.

Best,
Ihor

>From 5764b41b858bff3d56dcb24741cf550a7e245d36 Mon Sep 17 00:00:00 2001
Message-Id: <5764b41b858bff3d56dcb24741cf550a7e245d36.1658840330.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Tue, 26 Jul 2022 20:50:47 +0800
Subject: [PATCH] org-export: Remove zero-width space escapes during export

* lisp/ox.el (org-export--remove-escaped): New function removing
zero-width spaces when they separate object boundaries.
(org-export-as): Call `org-export--remove-escaped'.
* testing/lisp/test-ox.el (test-org-export/remove-escaped): New test.
---
 lisp/ox.el  | 22 ++
 testing/lisp/test-ox.el | 13 +
 2 files changed, 35 insertions(+)

diff --git a/lisp/ox.el b/lisp/ox.el
index 40ad7ae4e..de034fd22 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -2916,6 +2916,25 @@ (defun org-export--remove-uninterpreted-data (data info)
   ;; Return modified parse tree.
   data)
 
+(defun org-export--remove-escaped (data info)
+  "Remove escape symbols from plain-text in DATA.
+DATA is a parse tree or a secondary string.  INFO is a plist
+containing export options.  It is modified by side effect and
+returned by the function."
+  (org-element-map data '(plain-text)
+(lambda (string)
+  (let (processed-string)
+(setq processed-string
+  (replace-regexp-in-string "\\`​" "" string))
+(setq processed-string
+  (replace-regexp-in-string "​\\'" "" processed-string))
+(unless (equal string processed-string)
+  (org-element-insert-before processed-string string)
+  (org-element-extract-element string
+info nil nil t)
+  ;; Return modified parse tree.
+  data)
+
 ;;;###autoload
 (defun org-export-as
 (backend  subtreep visible-only body-only ext-plist)
@@ -3046,6 +3065,9 @@ (defun org-export-as
 	   ;; communication channel.
 	   (org-export--prune-tree tree info)
 	   (org-export--remove-uninterpreted-data tree info)
+   ;; Remove zero-width spaces that escape Org syntax
+   ;; elements.
+   (org-export--remove-escaped tree info)
 	   ;; Call parse tree filters.
 	   (setq tree
 	 (org-export-filter-apply-functions
diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
index 7c71b6e24..ea4fce363 100644
--- a/testing/lisp/test-ox.el
+++ b/testing/lisp/test-ox.el
@@ -982,6 +982,19 @@ (ert-deftest test-org-export/uninterpreted ()
 			 (section . (lambda (s c i) c
 	 nil nil nil '(:with-sub-superscript {}))
 
+(ert-deftest test-org-export/remove-escaped ()
+  "Test removing escape symbols."
+  ;; Remove zero-width space around markup.
+  (should
+   (equal "This*is*test.\n"
+  (org-test-with-temp-text "This​*is*​test.\n"
+(org-export-as (org-test-default-backend)
+  ;; Do not remove zero-width space in other places.
+  (should
+   (equal "This​is​test.\n"
+  (org-test-with-temp-text "This​is​test.\n"
+(org-export-as (org-test-default-backend))
+
 (ert-deftest test-org-export/export-scope ()
   "Test all export scopes."
   ;; Subtree.
-- 
2.35.1

Re: BUG Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Here is the new patch. I have realized that it is not necessary to put a
> cond, since in this case it is only necessary to obtain the name of the
> language for the metadata, so this new patch is simpler.

Thanks for the update!

The patch has some misplaced parenthesis.

> -  (let ((language (let ((lang (plist-get info :language)))
> - (or (cdr (assoc-string lang org-latex-babel-language-alist 
> t))
> - (nth 1 (assoc-string lang 
> org-latex-polyglossia-language-alist t))
> - lang
> +  (let ((language (let ((lang (plist-get info :language))
> +;; Here it would suffice to obtain the second
> +;; element, which always returns the name
> +;; language name in `org-latex-language-alist'
> + (nth 1 (assoc-string lang org-latex-language-alist 
> t))

Your (nth 1 ...) sexp is inside the let definition:
(let ((lang ...)
  (nth 1 ..))
  nil)

Please pay attention to the compiler warnings.

Also, the original code contained the clause:
(or (get lang from the alist1)
(get lang from the alist2)
lang ; Fallback to provided language if not known.
)

Your variant does not have the fallback part. Is it intentional?

Best,
Ihor

Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note

[Ihor Radchenko]

Bhavin Gandhi  writes:

>> Thanks for the idea, I'm exploring (recursion-depth),
>> (minibuffer-depth). I will come up with a patch to fix this bug.
>
> So, I saved this-command and (recursion-depth) value, and I'm checking
> for it in the org-add-log-note (attaching diff of my changes). But this
> doesn't guarantee that we are not in the minibuffer when the
> post-command-hook runs.
>
> This is what I did, and it failed after answering the question about 10
> repeated intervals:
> 1. M-: (y-or-n-p "Some question")
> 2. Now I switched to Org mode buffer.
> 3. Did C-c C-t on the entry.
>
> When org-log-add-setup runs, (recursion-depth) is 1, and
> (minibuffer-depth) is also 1.
> Now, the question about 10 repeated intervals is asked, once I answer
> it, post-command-hook runs. And it runs while we are in the minibuffer
> waiting for 'Some question'.

Yikes! Then, can also check for window-minibuffer-p, but I feel that it
will be a fight against all kinds of edge cases.

> So, I changed the second condition to (= (minibuffer-depth) 0).
> This has a different effect when org-todo finishes the execution and we
> are still in minibuffer:
> this-command won't be org-todo again unless it is invoked again by the
> user. org-add-log-note post-command-hook is never removed, and it keeps
> executing as the condition is not fulfilled.
>
> I'm going through the code of org-add-log-note to see if we can avoid
> calling (delete-other-windows) in the minibuffer. Or move out of minibuffer
> and then proceed.

what about

(when (or (and (equal org-log-note-this-command this-command)
   (= org-log-note-recursion-depth (recursion-depth)))
   (> org-log-note-recursion-depth (recursion-depth)))

Best,
Ihor

Notice: change of my email address

[tec]

Hi All,

Short version

  t...@tecosaur.com ⟶ g...@tecosaur.net (in commits) *
  tecos...@gmail.com ⟶ orgm...@tec.tecosaur.net (in communications here)

 * I've sent this email from the (old) commit address to leave a paper 
trail so
  it's (hopefully) clear to anybody who searches for the address what's 
happened,
  and that the FSF copyright assignment continues on with the new 
address.


Long(er) version

It was recently brought to my attention that the email forwarding I set 
up for
this address (t...@tecosaur.com) is a tad borked. Its domain and email 
hosting
was set up years ago on a shared VPS, and it's become increasingly 
fragile over
the past ~year. I'm currently shifting to a new (better) setup, and have 
grabbed
a new domain (tecosaur.net) so I can do this gradually without breaking 
anything

currently on tecosaur.com.

I've taken this as a push to get a move on with my email migration, and 
shift a
bit more of my communication away from google (with a bit of extra 
organisation
too). Hopefully, if anybody emails t...@tecosaur.com the email will 
actually be
forwarded (I switched the method) or you'll see an auto-responder (just 
set up)
directing you to try my new address. At some point, this will likely 
stop
working completely. On this mailing list, I'll still get emails to my 
Gmail
address just as before, so it's no problem if any of you auto-complete 
that
address (I'm liable to accidentally use it every now), but I'll be 
trying to

use the orgmode@ email for less google and better filtering :)

All the best,
Timothy.

Re: org-cature-ref

[Henrik Frisk]

Den tis 19 juli 2022 kl 15:39 skrev Ihor Radchenko :

>
> There is nothing fancy there. Just
>
> "%{fetch-bibtex}* TODO %?%(org-capture-ref-get-bibtex-field :title)"
> ":PROPERTIES:"
> ":ID: %(org-capture-ref-get-bibtex-field :key)"
> ":CREATED: %U"
> ":END:"
> "#+begin_src bibtex"
> "%(org-capture-ref-get-bibtex-field :bibtex)"
> "#+end_src bibtex"
>
> Yeah, now that I see it I'm embarrased I didn't figure it out by myself.
Sigh.


> > 2. When you write that there is support for Google Scholar "BiBTeX page",
> > what do you mean? In a Google scholar search, if I click "Cite" and then
> > choose BiBTeX, I don't get the expected result, but maybe you are
> referring
> > to something else?
>
> I am referring to what you said: "Cite" → "BibTeX". The opened page
> should contain the BibTeX entry text. This page can be captured.
>
> For example, the first item (Cite → BibTeX) in
> https://scholar.google.com.sg/scholar?q=test
>
> can be captured on my side.
>
> I do not recommend this method though. Google Scholar does not provide
> high quality BibTeX entries with DOI and sometimes provides plain wrong
> entries.
>
> This doesn't actually work for me. From the link above I'm getting:

#+begin_src bibtex
@misc{Scholar_Googleusercontent__506,
  created =  {[2022-07-26 tis 12:31]},
  howpublished = {Scholar.Googleusercontent},
  note = {Online; accessed 26 juli 2022},
  url =
  {
https://scholar.googleusercontent.com/scholar.bib?q=info:4QIfrBW26fcJ:scholar.google.com/=citation=CgXRptZKEN2CnUnCgY8:AAGBfm0AYt_EmY-OX1Eyi54caLD4JrIGdgFtjnKP=AAGBfm0AYt_EmSP-yLhTDNSeuVdqtJ0UcrDks5SL=4=citation=-1=sv
},
}
#+end_src bibtex

where the expected would be

#+begin_src bibtex
@article{algozzine2001effects,
  title={Effects of interventions to promote self-determination for
individuals with disabilities},
  author={Algozzine, Bob and Browder, Diane and Karvonen, Meagan and
Test, David W and Wood, Wendy M},
  journal={Review of Educational Research},
  volume={71},
  number={2},
  pages={219--277},
  year={2001},
  publisher={Sage Publications Sage CA: Thousand Oaks, CA}
}
#+end_src bibtex

But, for the reasons you note below, this is not that important. I'm really
happy to have the general capture template working.

Thanks again!

Re: How to force markup without spaces

[K]

On Tue, 2022-07-26 at 13:30 +0700, Max Nikulin wrote:

> I have not tested it, but I expect you can use
> - export filter that removes zero-width spaces at the last export
> stage.
> I assume that your documents do not contain them besides markup
> workaround
> - #+latex_header: \DeclareUnicodeCharacter{200B}{}
> - custom link
> 
> #+begin_src elisp :results none :exports both
>   (org-link-set-parameters
>"sep"
>:export (lambda (path desc backend)
>(if (org-export-derived-backend-p backend 'org)
>(org-link-make-string (concat "sep:" path) desc)
>  (or desc ""
> #+end_src
> "中文[[sep:][*测*]]试"

I tested the second workaround, and replaced the 
\DeclareUnicodeCharacter{200B}{} sequence with \newunicodechar{​}{} sequence 
since I am using xelatex, which does not support the former.
It works fine so far.

> In other thread we are discussing advantages and problems of
> switching
> from PdfLaTeX to LuaLaTeX for non-latin scripts. The latter is a
> Unicode
> engine. I am curious what is your opinion from standpoint of Chinese
> language, namely amount of required customization in both cases. I
> think, it is better to either start a dedicated thread, or find the
> part
> of discussion related to fonts and babel (LaTeX package) setup.

As far as I know, Chinese users commonly use ctex package 
https://ctan.org/pkg/ctex to handle Chinese typesetting problem, and they 
prefer xelatex and lualatex over pdflatex. They don't support more fonts when 
using pdflatex, compared with using xelatex etc. (you can see that on page 7 of 
their pdf document). So I just use xelatex and don't have much experience using 
pdflatex.

When using ctex, you just need to declare \documentclass{ctexart} (ctexart is a 
ctex version article) to use Chinese characters. Then if your system has the 
required default fonts, the pdf documents should be OK.

Re: The fate of ob-asymptote.el

[Jarmo Hurri]

Greetings Ihor.

Ihor Radchenko  writes:

> Jarmo Hurri  writes:
>
>>> Then, would it make more sense to include ob-asymptote.el into the
>>> asymptote distribution?
>>
>> I do not think this is a good idea:
>>
>> - I am not involved in the development of asymptote, so this solution
>>   would put maintenance of ob-asymptote.el beyond my reach.
>
> AFAIK, it is developed publicly. Anyone can open a pull request or
> post on their forum.

It might be possible, but certainly not as straightforward as working
with Org.

> The advantage of maintaining ob-asymptote.el in the main asymptote
> repo is that people who are intimately familiar with the asymptote
> features can directly contribute and enhance the Org
> integration. Moreover, distributing together with the asymptote means
> no headache with back-compatibility issues.
>
> Maintaining on Org side will have an advantage of using the latest
> additions to Org babel features.
>
> I feel like it is more important to make use of the asymptote features
> if its devs are going to be interested. Of course, IMHO.

I have a very bad feeling about tying ob-asymptote.el with Asymptote,
and I am trying to put my finger on this feeling. I think the problem is
this one.

ob-asymptote.el is coupled very loosely with Asymptote. Basically the
only thing ob-asymptote.el requires from Asymptote is the ability to
call the executable with some established parameters.

Then again, ob-asymptote.el is coupled much more tightly with Org. It
uses many more properties of Org (Babel) than of the Asymptote
program.

As a result, changes in Org are much more likely to affect
ob-asymptote.el than changes in Asymptote. I think basic software
development rules of thumb suggest that ob-asymptote.el should then be
bundled with Org.

All the best,

Jarmo

Re: Volunteering to maintain ob-asymptote.el within Org

[Jarmo Hurri]

Ihor Radchenko  writes:

> Jarmo Hurri  writes:
>>> TBH, this is the first time I'm hearing about it.  I've looked it
>>> up, and indeed it seems to be useful.
>>
>> For some reason, even people who would certainly benefit from
>> Asymptote often have not heard of it. The developers do not really
>> advertise. Asymptote is amazingly powerful and sophisticated.
>
> Then, it would help to have more practical examples compared to what
> we have in
> https://www.orgmode.org/worg/org-contrib/babel/languages/ob-doc-asymptote.html

Absolutely. I have plenty of examples from the domains of math and
computer science.

>>> That said, shouldn't this be in org-contrib?  Too many features in a
>>> tool - featurism - may be distracting, in the sense that you focus
>>> more on your tool than work at hand.
>>
>> I do not understand this. Why would supporting a professional-level
>> graphics programming language be distracting someone from their work
>> when using Org?
>
> That a common minimalist argument. Some people dislike the fact that
> software includes features they do not personally use. Similar
> arguments are often raised regarding, for example, games shipped with
> Emacs.

I do not see Org as a "minimalist" system. I see it as glue.

I think one of the great powers of Org mode is its capability to act
together with various systems, including LaTeX and a host of programming
languages. I would never imagine that Org would only support the tools I
use, but I expect to be positively surprised by the fact that Org will
support, out of the box, something that I am not using now but will be
using in the future.

> I disagree in this particular case. Having ob-asymptote.el is not a
> featurism - I would not expect people to play around a full new
> programming language just because ob-language.el is in Org. The
> barrier of entry is too high to make it destructing.

I am not sure I can interpret your text correctly. But if you are saying
that builtin support for Asymptote will not lower the threshold of its
use among Org users, I would ask the following questions:
- How many Org users are already capable of programming?
- How many Org users prefer code-based representations to other forms?

All the best,

Jarmo

Re: Volunteering to maintain ob-asymptote.el within Org

[Jarmo Hurri]

Hello Munyoki.

Munyoki Kilyungi  writes:

>> I do not understand this. Why would supporting a professional-level
>> graphics programming language be distracting someone from their work
>> when using Org?
>
> I'm not _against_ supporting a proffesional-level graphics PL.  What
> I'm trying to say is that having it installed should be a choice made
> by the end-user.

I think someone already mentioned that having ob-asymptote.el within Org
does not require the end users to install anything.

> I reckon I'll give this is a shot this coming weekend and see how this
> goes.  Is this:
> 
> sufficient to get me started?

It is sufficient, but I am not sure whether those examples are a good
way to start.

If you want to get acquainted with Asymptote, I suggest that after
setting it up you take a minimal example like the following

#+begin_src asymptote :file result-figure.pdf
size (8cm, 0);
#+end_src

and then use various sources such as the ones below to explore and learn:

- Charles Staats' Asymptote tutorial

  https://asymptote.sourceforge.io/asymptote_tutorial.pdf

- Asymptote manual

  https://asymptote.sourceforge.io/asymptote.pdf

- Art of Problem Solving forums, which use Asymptote as their built-in
  graphics language, e.g.

  https://artofproblemsolving.com/community/c5h2782914_another_hexagon_problem

  (click on a diagram to see the corresponding Asymptote code).

  see also

  https://artofproblemsolving.com/wiki/index.php/Asymptote:_Getting_Started

All the best,

Jarmo

org-babel execute source context

[Jan Ulrich Hasecke]

Dear all,

is there a package to use org-babel execute function on ConTeXt blocks?

I would like to do a presentation with org-mode about ConTeXt.

It would be nice if I could execute source blocks with the executable
"context" and store the result in a file.

I found the tangle option that exports the source to a file, which is
fine as I could manually build the pdf on the command line.

Even nicer would be a build into a pdf file that I can display on a
parallel screen.

I am completely new to this corner of org-mode.

juh
-- 
Autoren-Homepage: . http://literatur.hasecke.com
Satiren & Essays: . http://www.sudelbuch.de
Privater Blog:  http://www.hasecke.eu
Netzliteratur-Projekt:  http://www.generationenprojekt.de




signature.asc
Description: PGP signature

Re: How to force markup without spaces

[Max Nikulin]

On 26/07/2022 11:26, K K wrote:

On 2022-07-26 Tue. 09:23 +0700，Max Nikulin wrote：


> However the suggestion was namely to use U+200B ZERO WIDTH SPACE and
> it
> is actually implemented since `org-emphasis-regexp-components'
> currently
> contains [:space:].
> ...
> K, could you, please, clarify what is your particular use case?


My bad, I misunderstood the "feature" mentioned in the old post.

My use case is to emphasize chinese characters without spaces being 
inserted, even those zero-width spaces. For example "中文*测*试" should 
be enough to emphasize "测".


I am using zero-width spaces right now, and it works fine in org-mode 
buffers, but if exported to latex-pdf files, the U+200B ZERO WIDTH SPACE 
character will not be zero-width for certain fonts. So I hope not to use 
that character.


I have not tested it, but I expect you can use
- export filter that removes zero-width spaces at the last export stage. 
I assume that your documents do not contain them besides markup workaround

- #+latex_header: \DeclareUnicodeCharacter{200B}{}
- custom link

   #+begin_src elisp :results none :exports both
 (org-link-set-parameters
  "sep"
  :export (lambda (path desc backend)
   (if (org-export-derived-backend-p backend 'org)
   (org-link-make-string (concat "sep:" path) desc)
 (or desc ""
   #+end_src
   "中文[[sep:][*测*]]试"

  https://list.orgmode.org/ssp8e7$ah2$1...@ciao.gmane.io/
  Max Nikulin Re: [RFC] Creole-style / Support for 
**emphasis**__within__**a word** Tue, 25 Jan 2022 23:27:50 +0700


In other thread we are discussing advantages and problems of switching 
from PdfLaTeX to LuaLaTeX for non-latin scripts. The latter is a Unicode 
engine. I am curious what is your opinion from standpoint of Chinese 
language, namely amount of required customization in both cases. I 
think, it is better to either start a dedicated thread, or find the part 
of discussion related to fonts and babel (LaTeX package) setup.

Re: [PATCH] oc-csl: Add support for sub-bibliographies

[Fraga, Eric]

"Printing a bibliography" would also work.
-- 
: Eric S Fraga, with org release_9.5.4-648-gdf1814 in Emacs 29.0.50