Re: babel default header args as functions

2021-09-28 Thread Matt Huszagh
Timothy  writes:

> I just read your docs patch, and that’s lead to a quick question: does this 
> patch
> support a header arg function in the form “(:file . 
> #’my-org-file-name-generator)”?

Unfortunately it doesn't. It's been about a year since I wrote this
patch, so I'm a bit hazy on some of the details, but IIRC it has to deal
with org-mode's use of lexical binding. If you're interested in digging
deeper (or maybe even getting it to work, which would be great) I'd look
at `org-babel-eval-headers'. The `functionp' line in there returns nil
and the function isn't evaluated unless it's a closure.

Matt



Re: Merging latest org-mode for Emacs 28.1

2021-09-28 Thread Tim Cross


Timothy  writes:

> Hi  Tim,
>
>> A new version org 9.5 is going to be released this week. Not sure if
>> Emacs maintainers want to bundle this new version or prefer to just
>> continue with current 9.4 version. I suspect the latest 9.4 will be the
>> preferred version given 9.5 is only going to be released in the next day
>> or so. The 9.5 version will be in ELPA, so those interested can update
>> to it with minimal hassle.
>>
>> As far as I understand it, which version is bundled with Emacs is really
>> down to the Emacs maintainers and not the org maintainers.
>
> It’s worth noting that Org 9.5 is being released /for/ Emacs 28. Hence the 
> recent
> merge-athon by Bastien.
>

OK. I thought the push was more about Bastien's aim to step back from
org maintenance by October and getting the 9.5 version out before he
does. 





Re: Merging latest org-mode for Emacs 28.1

2021-09-28 Thread Timothy
Hi  Tim,

> A new version org 9.5 is going to be released this week. Not sure if
> Emacs maintainers want to bundle this new version or prefer to just
> continue with current 9.4 version. I suspect the latest 9.4 will be the
> preferred version given 9.5 is only going to be released in the next day
> or so. The 9.5 version will be in ELPA, so those interested can update
> to it with minimal hassle.
>
> As far as I understand it, which version is bundled with Emacs is really
> down to the Emacs maintainers and not the org maintainers.

It’s worth noting that Org 9.5 is being released /for/ Emacs 28. Hence the 
recent
merge-athon by Bastien.

All the best,
Timothy


Re: Merging latest org-mode for Emacs 28.1

2021-09-28 Thread Tim Cross


Stefan Kangas  writes:

> Hi org-mode,
>
> Stefan Kangas  writes:
>
>> As a heads up, Emacs is getting ready to cut the emacs-28 branch in
>> preparation of the upcoming release of Emacs 28.1:
>>
>> https://lists.gnu.org/archive/html/emacs-devel/2021-07/msg00812.html
>>
>> It would be good if we could merge the most recent stable Org-mode
>> version before the first Emacs 28.1 pretest release.  Could you please
>> start looking into what is needed to make this happen?
>
> Could you please provide us with a brief update on the status of this?
>

I'm not an org maintainer, but can possibly provide some info. Not
really sure what your concerns are though.

Org has recently moved the git repository to be hosted on savannah. 
>From a recent post to the org mode list


from now on, here are the official Org repositories:
   
- org-mode: https://git.savannah.gnu.org/cgit/emacs/org-mode.git
- worg: https://git.sr.ht/~bzg/worg
- orgweb: https://git.sr.ht/~bzg/orgweb
   
org-contrib will continue to be on https://git.sr.ht/~bzg/org-contrib
until it disappears, thanks to volunteers taking over maintainance of
the various packages.
   
You can forget code.orgmode.org.
   
The latest version of the current 9.4 version can be pulled from the
repository. Emacs 28 is already bundling this version (though an update
to get latest bug fixes is probably warranted).

A new version org 9.5 is going to be released this week. Not sure if
Emacs maintainers want to bundle this new version or prefer to just
continue with current 9.4 version. I suspect the latest 9.4 will be the
preferred version given 9.5 is only going to be released in the next day
or so. The 9.5 version will be in ELPA, so those interested can update
to it with minimal hassle. 

As far as I understand it, which version is bundled with Emacs is really
down to the Emacs maintainers and not the org maintainers.

There were some issues with org mode and native compilation relating to
file dependencies. I don't know if they have been resolved, but as I
understand it, this is a native compilation issue rather than an
org-mode issue. I'm not using native compilation due to issues with
packages that have more complex dependencies (i.e. emacspeak and
org-mode), so not sure what the current status is - perhaps the issues
have been resolved.



Re: [SOLVED] (was: how to export checkboxes to odt?)

2021-09-28 Thread Timothy
Hello,

>> Any idea how to export checkboxes to odt?
>> I mean not just simply having [ ] in the odt document but having them 
>> translated as actual boxes.
>
> Either using latex ⊠
> or   UTF8 ☒

I’m wondering, would this be worth adding to ox-odt?

All the best,
Timothy


Re: babel default header args as functions

2021-09-28 Thread Timothy
Hi  Matt,

> Here’s the patch for the news item. Bear in mind that the last part
> about lazy evaluation is only true for the newest patch.

I just read your docs patch, and that’s lead to a quick question: does this 
patch
support a header arg function in the form “(:file . 
#’my-org-file-name-generator)”?

All the best,
Timothy


Re: babel default header args as functions

2021-09-28 Thread Matt Huszagh
Matt Huszagh  writes:

> I've tested it, and if you revert
> 78783f4e47901255695031dae0efcbb301a40878 and apply the new patch, it
> will apply with conflicts. Let me know if you run into any difficulties,
> have any concerns, etc.

That "with" should be "without"...

Matt



Re: babel default header args as functions

2021-09-28 Thread Matt Huszagh
Matt Huszagh  writes:

> Thanks Bastien, and no worries about the delay. However, I hate to say
> it but I think you may have applied an old patch. The most recent patch
> is
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/txtzi_PffIaG1.txt
>
> Let me know what I can do.

I've tested it, and if you revert
78783f4e47901255695031dae0efcbb301a40878 and apply the new patch, it
will apply with conflicts. Let me know if you run into any difficulties,
have any concerns, etc.

>> It deserves an entry in etc/ORG-NEWS for Org 9.5, would you be willing
>> to submit a patch for this?
>
> Yep, I'll send one over.

Here's the patch for the news item. Bear in mind that the last part
about lazy evaluation is only true for the newest patch.

>From ae721d089854e3b6b2d71ab6829b0cace25f0968 Mon Sep 17 00:00:00 2001
From: Matt Huszagh 
Date: Tue, 28 Sep 2021 18:26:04 -0700
Subject: [PATCH] etc/ORG-NEWS: Add news item about
 org-babel-default-header-args accepting closures

---
 etc/ORG-NEWS | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index b0a893946..db6df83f2 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -151,7 +151,7 @@ enable Calc units simplification mode.
 
 *** Support fontification of inline export snippets
 
-Inline 
+Inline
 
 See [[msg:87im57fh8j@gmail.com][this thread]].
 
@@ -443,6 +443,33 @@ See [[msg:875z8njaol@protesilaos.com][this thread]].
 attachment directory at calls of ~org-attach-sync~.  There is
 Never delete, Always delete and Query the user (default).
 
+*** ~org-babel-default-header-args~ can now be specified as closures or strings
+
+~org-babel-default-header-args~ now also accepts closures that
+evaluate to a string. Previously, only direct strings were
+supported. These closures are evaluated when point is at the source
+block, which allows them to make use of contextual information at the
+relevant source block. One example that illustrates the usefulness of
+this addition (also given in the documentation for
+~org-babel-default-header-args~) is:
+
+#+begin_src elisp
+(defun org-src-sha ()
+  (let ((elem (org-element-at-point)))
+(concat (sha1 (org-element-property :value elem)) \".svg\")))
+
+(setq org-babel-default-header-args:latex
+  `((:results . \"file link replace\")
+(:file . (lambda () (org-src-sha)
+#+end_src
+
+This will set the ~:file~ header argument to the sha1 checksum of the
+contents of the current latex source block.
+
+Finally, the closures are only evaluated if they're not overridden for
+a source block. This improves efficiency in cases where the result of
+a compute-expensive closure would otherwise be discarded.
+
 ** Miscellaneous
 *** =org-bibtex= includes =doi= and =url= entries when exporting to BiBTeX
 =doi= and =url= entries have been made optional for some publication
-- 
2.31.1


Matt


Re: babel default header args as functions

2021-09-28 Thread Matt Huszagh
Bastien  writes:

> Applied, thanks, and sorry again for the lng delay.

Thanks Bastien, and no worries about the delay. However, I hate to say
it but I think you may have applied an old patch. The most recent patch
is

https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/txtzi_PffIaG1.txt

Let me know what I can do.

> It deserves an entry in etc/ORG-NEWS for Org 9.5, would you be willing
> to submit a patch for this?

Yep, I'll send one over.

Matt



Re: Release 9.5 tomorrow

2021-09-28 Thread Yasushi SHOJI
Hi Bastien,

It's not that important, but if you have time would you please take a
look at this:
https://list.orgmode.org/44f768b5-bade-e07a-29a7-15999eefd...@binghamton.edu/t/#mc90ae0a5266fe201d44e6f8f174b2d874f7c57fd

Thanks,
-- 
  yashi

On Tue, Sep 28, 2021 at 11:44 PM Bastien  wrote:
>
> Hi all,
>
> I'll release Org 9.5 tomorrow between 2pm and 3pm, Paris time.
>
> Feel free to email me at b...@gnu.org if there is an important bugfix
> (or a forgotten low-hanging patch) that needs to be committed.
>
> Thanks,
>
> --
>  Bastien
>



Re: Bug: Org mode fails to compile using Emacs 24.5-r10

2021-09-28 Thread Tim Cross


Max Nikulin  writes:

> On 28/09/2021 12:33, Bastien wrote:
>> Tim Cross writes:
>> 
>>> I do think it is probably time to drop support for Emacs 24 in the next
>>> major release. However, we cannot drop it 'mid release'.
>> I've added a section called "Compatibility with Emacs versions" on
>> this page: https://orgmode.org/worg/org-maintenance.html
>> We now make it clear that latest Org stable aims at being compatible
>> with Emacs current stable, and the two previous one.
>> That is: Org 9.4.6 is compatible with 27.x, 26.x and 25.x but maybe
>> not with 24.x (24.1 being 9 years old now).
>
> lisp/org.el:;; Package-Requires: ((emacs "24.3"))
>
> Should not it be updated?
>

I would expect it should be updated in org-mode v9.5, but not 9.4.x as
we should only change such things for major version releases. 

> https://orgmode.org/worg/org-maintenance.html:
>> For example, if the current major version of Emacs is 28.x, then the
>> latest stable version of Org should be compatible with Emacs 28.x, 27.x
>> and 26.x – but not with Emacs 25.x.
>
> Ubuntu-18.04 bionic is a Long Time Support release (April 2018), emacs-25.2.2
> provided from system repository. Maybe it should be supported even though next
> LTS release Ubuntu-20.04 focal is available.

Perhaps we need to clarify that the supported versions is based on the
version of Emacs which was stable at the time of release of the org
version. For example, org 9.5, being released this week, means it would
support Eamcs 27.x, 26.x and 25.x, but not Emacs 24.x. If Emacs 28 is
released next month, this would not alter the supported versions as 9.5
was released before Emacs 28. When org 9.6 is released, the supported
versions would be updated to include whatever version of Emacs is stable
at that point (likely 28.x) and the two previous versions. 



Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]

2021-09-28 Thread Tim Cross


Bastien  writes:

> Hi Tim,
>
> Tim Cross  writes:
>
>> I do think it is probably time to drop support for Emacs 24 in the next
>> major release. However, we cannot drop it 'mid release'.
>
> I've added a section called "Compatibility with Emacs versions" on
> this page: https://orgmode.org/worg/org-maintenance.html
>
> We now make it clear that latest Org stable aims at being compatible
> with Emacs current stable, and the two previous one.
>
> That is: Org 9.4.6 is compatible with 27.x, 26.x and 25.x but maybe
> not with 24.x (24.1 being 9 years old now).
>

Thanks Bastien. I think it is good to have a clear statement on this,
even if not everyone agrees, as it makes things explicit. I
suspect this will need to be reviewed after each release of a new Emacs
version though as the effort to maintain backwards compatibility will
depend on what has changed in Emacs. Especially given that Emacs release
cycles seem to be getting shorter. 



Adjust git redirect to [correct] savannah repo

2021-09-28 Thread John Hendy
Greetings,

I haven't updated org in quite some time. Doing my typical git pull, I
got this notice:

$ git pull
make clfatal: unable to update url base from redirection:
  asked for: 
https://code.orgmode.org/bzg/org-mode.git/info/refs?service=git-upload-pack
   redirect: 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/?service=git-upload-pack

I tried manually using `git remote set-url` to force the savannah
address, but from looking at the docs, it seems it should just be
.../git/..., not the supplied .../cgit/..., which fails:

$ git remote set-url origin https://git.savannah.gnu.org/cgit/emacs/org-mode.git
$ git pull
fatal: repository
'https://git.savannah.gnu.org/cgit/emacs/org-mode.git/' not found

Looking at the savannah site, they provide these three clone URLs:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/

#+begin_quote
Clone
git://git.savannah.gnu.org/emacs/org-mode.git
https://git.savannah.gnu.org/git/emacs/org-mode.git
ssh://git.savannah.gnu.org/srv/git/emacs/org-mode.git
#+end_quote

I'm just passing this along in case there are other lingering stale
updaters out there who might have this occur. Could the redirect at
code.orgmode.org be adjusted accordingly?


Best regards,
John



[PATCH] Treat :tangle-mode as an octal value not integer

2021-09-28 Thread Jeremy Cowgar
As an org user I would expect :tangle-mode 0660 to produce a file that
has user rw, group rw, other nothing. Instead, what really happens
currently is 0660 is treated as an integer which is actually
3140. This produces unexpected file permissions.

Prior to this patch to have rw,rw,none, one has to convert 0660 octal
into an integer (432) and then specify :tangle-mode 432. This is counter
intuitive and requires multiple steps.

After this patch, one just specifies the octal code as you do with
chmod. :tangle-mode 0660 results in a file that is rw,rw,none.
---
 lisp/ob-tangle.el | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 2dd1d031c..154bd5145 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -246,7 +246,12 @@ matching a regular expression."
 (get-spec (lambda (name) (cdr (assq name (nth 4 
spec)
 (she-bang (let ((sheb (funcall get-spec :shebang)))
 (when (> (length sheb) 0) sheb)))
-(tangle-mode (funcall get-spec :tangle-mode)))
+(tangle-mode (let ((tmode (funcall get-spec 
:tangle-mode)))
+(when tmode
+  ;; convert integer representing 
an octal
+  ;; number to its real octal value
+  (string-to-number
+   (number-to-string tmode) 8)
(unless (string-equal block-lang lang)
  (setq lang block-lang)
  (let ((lang-f (org-src-get-lang-mode lang)))
-- 
2.30.2




[PATCH] manual: Remove a couple of stray words from the citation handling section

2021-09-28 Thread András Simonyi
Dear All,

the patch which I attached removes some stray/leftover words from the
manual's section on citations.

best wishes,
András
From 1936c8a3e4668192cb279f417d980fa353fc6bbb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A1s=20Simonyi?= 
Date: Tue, 28 Sep 2021 23:13:07 +0200
Subject: [PATCH] doc/org-manual.org: Remove a couple of stray words

* doc/org-manual.org (Citation handling): Remove a pair of unnecessary words.
---
 doc/org-manual.org | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 4ebc315cb..2002a05f3 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -16515,9 +16515,9 @@ keywords.
 :END:
 #+cindex: citation
 
-As of Org 9.5, a includes a new library =oc.el= provides tooling to
-handle citations in Org via "citation processors" that offer some or
-all of the following capabilities:
+As of Org 9.5, a new library =oc.el= provides tooling to handle
+citations in Org via "citation processors" that offer some or all of
+the following capabilities:
 
 - "activate" :: Fontification, tooltip preview, etc.
 - "follow" :: At-point actions on citations via ~org-open-at-point~.
-- 
2.25.1



Re: how to export checkboxes to odt?

2021-09-28 Thread Juan Manuel Macías
Hi Uwe,

Uwe Brauer writes:

> Any idea how to export checkboxes to odt?
>
> I mean not just simply having [ ] in the odt document but having them 
> translated as actual boxes.

You can try:

(defun my/org-odt--checkbox (item)
  "Return check-box string associated to ITEM."
  (let ((checkbox (org-element-property :checkbox item)))
(if (not checkbox) ""
  (format "%s"
  "OrgCode" (cl-case checkbox
  (on "\u2611 ") ; CHECK MARK
  (off "\u2610 ")
  (trans "[-] ")) ;; I don't know which character 
to choose here...

(advice-add 'org-odt--checkbox :override  #'my/org-odt--checkbox)

Best regards,

Juan Manuel 



Re: [PATCH] async process in R

2021-09-28 Thread Jeremie Juste
Hello Chuck,

> OK. The patch works when applied on top of the previous 2 (but the second one 
> has the same name, so there is that to watch out for).
Thanks for the feedback, I'll make sure to provide unique names for
patches in the future.
>
> However, I think we are not quite home free. With `:async no', this works as 
> expected:
>
> #+begin_src R :session *R*  :results output :async no
>   Sys.sleep(2)
>   1:5
>   10:
> a
>   1:2
> #+end_src
>
> #+RESULTS:
> : 
> : [1] 1 2 3 4 5
> : 
> : Error: object 'a' not found
> : 
> : [1] 1 2
>
> But changing to `:async yes', the error aborts in a way that omits the output.

Interesting, I haven't thought about errors cases enough. Async process
will be on the 9.5 release and this issue will be next on the todo list.
Many thanks again for the feedback.


It does help,

Jeremie



Re: Bug: Org mode fails to compile using Emacs 24.5-r10

2021-09-28 Thread Samuel Wales
in debian lts stretch, which goes to June 30, 2022, there is both with
24 being the default.  there are a bunch of packages made into debian
packages.  idk if they work with both.


On 9/28/21, Max Nikulin  wrote:
> On 28/09/2021 12:33, Bastien wrote:
>> Tim Cross writes:
>>
>>> I do think it is probably time to drop support for Emacs 24 in the next
>>> major release. However, we cannot drop it 'mid release'.
>>
>> I've added a section called "Compatibility with Emacs versions" on
>> this page: https://orgmode.org/worg/org-maintenance.html
>>
>> We now make it clear that latest Org stable aims at being compatible
>> with Emacs current stable, and the two previous one.
>>
>> That is: Org 9.4.6 is compatible with 27.x, 26.x and 25.x but maybe
>> not with 24.x (24.1 being 9 years old now).
>
> lisp/org.el:;; Package-Requires: ((emacs "24.3"))
>
> Should not it be updated?
>
> https://orgmode.org/worg/org-maintenance.html:
>> For example, if the current major version of Emacs is 28.x, then the
>> latest stable version of Org should be compatible with Emacs 28.x, 27.x
>> and 26.x – but not with Emacs 25.x.
>
> Ubuntu-18.04 bionic is a Long Time Support release (April 2018),
> emacs-25.2.2 provided from system repository. Maybe it should be
> supported even though next LTS release Ubuntu-20.04 focal is available.
>
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html



[SOLVED] (was: how to export checkboxes to odt?)

2021-09-28 Thread Uwe Brauer
>>> "UB" == Uwe Brauer  writes:

> Hi

> Any idea how to export checkboxes to odt?

> I mean not just simply having [ ] in the odt document but having them 
> translated as actual boxes.

Either using latex $\boxtimes$
or   UTF8 ☒




smime.p7s
Description: S/MIME cryptographic signature


Re: [PATCH] async process in R

2021-09-28 Thread Berry, Charles
Jeremie,

> On Sep 28, 2021, at 12:34 AM, Jeremie Juste  wrote:
> 
> Thanks for the feedback. With the following patch, I made sure that
> ess-inject-source is set to default before evaluating the buffer.
> 
> So even if I set
> (setq ess-inject-source 'function-and-buffer), I get the following
> output. Note that I get the same output in the IESS console buffer when
> I execute the command following command.
> 
> #+begin_src R :session *R*  :results output :async yes
>  Sys.sleep(2)
>  1:5
> 
>  10:20
>  1:2
> #+end_src


OK. The patch works when applied on top of the previous 2 (but the second one 
has the same name, so there is that to watch out for).

However, I think we are not quite home free. With `:async no', this works as 
expected:

#+begin_src R :session *R*  :results output :async no
  Sys.sleep(2)
  1:5
  10:
a
  1:2
#+end_src

#+RESULTS:
: 
: [1] 1 2 3 4 5
: 
: Error: object 'a' not found
: 
: [1] 1 2


But changing to `:async yes', the error aborts in a way that omits the output.

HTH,
Chuck



Re: Would it be possible to color horizontal lines in org mode?

2021-09-28 Thread John Kitchin
you can add a rule like this in an org-mode hook:

#+BEGIN_SRC emacs-lisp :results silent
(font-lock-add-keywords
 nil
 '(("^-\\{5,\\}"  0 '(:foreground "red" :weight bold
#+END_SRC

that will make a line starting with at least 5 - be red and bold in color.

John

---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Tue, Sep 28, 2021 at 4:00 AM Eric S Fraga  wrote:

> You could use hi-lock-mode to define your own colouring for such
> lines.  But I'm sure those that under font-locking better might be able
> to add appropriate rules for this horizontal line construct.
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org 9.5-g9a4a24
> : Latest paper written in org: https://arxiv.org/abs/2106.05096
>
>


Re: Bug: Org mode fails to compile using Emacs 24.5-r10

2021-09-28 Thread Max Nikulin

On 28/09/2021 12:33, Bastien wrote:

Tim Cross writes:


I do think it is probably time to drop support for Emacs 24 in the next
major release. However, we cannot drop it 'mid release'.


I've added a section called "Compatibility with Emacs versions" on
this page: https://orgmode.org/worg/org-maintenance.html

We now make it clear that latest Org stable aims at being compatible
with Emacs current stable, and the two previous one.

That is: Org 9.4.6 is compatible with 27.x, 26.x and 25.x but maybe
not with 24.x (24.1 being 9 years old now).


lisp/org.el:;; Package-Requires: ((emacs "24.3"))

Should not it be updated?

https://orgmode.org/worg/org-maintenance.html:

For example, if the current major version of Emacs is 28.x, then the
latest stable version of Org should be compatible with Emacs 28.x, 27.x
and 26.x – but not with Emacs 25.x.


Ubuntu-18.04 bionic is a Long Time Support release (April 2018), 
emacs-25.2.2 provided from system repository. Maybe it should be 
supported even though next LTS release Ubuntu-20.04 focal is available.





Re: [PATCH] oc-csl: Add support for the text and year citation styles

2021-09-28 Thread Bastien Guerry
Hi András,

András Simonyi  writes:

> I've attached a patch with the pcase pattern refactored following
> Nicolas's example -- hopefully this solves the problem.

Applied - as you guess, I'm in "optimistic push" mode.  Hopefully
this will help have someone review this if needed.

Thanks, and thanks to Nicolas for alerting soon enough,

-- 
 Bastien



Re: Possible bug? Combine emphasis marker faces?

2021-09-28 Thread Juan Manuel Macías
Hi Protesilaos,

Protesilaos Stavrou writes:

> Is there a way to get composite styles?  Such as bold and italic or
> verbatim and underline, etc.?

A somewhat dirty solution (without patching the code) could be
evaluating highlight-regexp, for example as a local variable:

#+begin_src emacs-lisp
  (defface my/org-it-bold
'((t :slant italic :bold t))
"")

(highlight-regexp 
"\\([-[:space:]('\"{]\\|^\\)\\(\\([*/_+]\\)\\([*/_+]\\)\\([^[:space:]]\\|[^[:space:]].*?\\(?:
.*?\\)\\{0,15\\}[^[:space:]]\\)\\3\\)\\([-[:space:].,:!?;'\")}\\[]\\|$\\)" 
'my/org-it-bold)
#+end_src

Best regards,

Juan Manuel 



Re: [PATCH] oc-csl: Add support for the text and year citation styles

2021-09-28 Thread Max Nikulin

On 28/09/2021 23:39, András Simonyi wrote:


I've attached a patch with the pcase pattern refactored following
Nicolas's example -- hopefully this solves the problem.


I do not see the issue any more. No pause during compilation, reasonable 
file size


-rw-rw-r-- 1 ubuntu ubuntu 24992 Sep 28 16:48 lisp/oc-csl.el
-rw-rw-r-- 1 ubuntu ubuntu 15767 Sep 28 16:48 lisp/oc-csl.elc


On Tue, 28 Sept 2021 at 17:16, András Simonyi  wrote:


Thanks, I'll try to put together a patch fixing the problem and send it shortly.
best wishes,
András

On Tue, 28 Sept 2021 at 17:03, Max Nikulin wrote:

András Simonyi writes:


the attached patch adds support for the text (textual) and year
(year-only) citation styles in the CSL org-cite processor.


This patch has a problem similar to ones earlier fixed by Nicolas:
https://orgmode.org/list/seomi1$785$1...@ciao.gmane.io "Re: citations: rx
problems with emacs-26.3" Sun, 8 Aug 2021 20:34:55 +0700

Compiling single /home/ubuntu/org-mode/lisp/oc-csl.el...

In toplevel form:
oc-csl.el:330:10:Error: Bytecode overflow
Makefile:59: recipe for target 'oc-csl.elc' failed
make[2]: [oc-csl.elc] Error 1 (ignored)

It is for emacs-26.3 (Ubuntu-18.04 LTS bionic).


Sorry for confusion, emacs-25.2 is shipped in ubuntu-18.04.




[BUG] [PATCH] org-id: Fix checkdoc warnings [9.5 (9.5-g9364b2 @ /home/n/.emacs.d/straight/build/org/)]

2021-09-28 Thread No Wayman


See attached.

>From 7fbdca5dc81dfe0dd542ed0e2352d3334b16fd7f Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Mon, 27 Sep 2021 20:35:12 -0400
Subject: [PATCH] org-id: Fix checkdoc warnings

* org-id: Fix checkdoc warnings.
---
 lisp/org-id.el | 31 +--
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/lisp/org-id.el b/lisp/org-id.el
index 3725ff9e5..56783d108 100644
--- a/lisp/org-id.el
+++ b/lisp/org-id.el
@@ -419,15 +419,15 @@ So a typical ID could look like \"Org:4nd91V40HI\"."
 	(substring rnd 18 20)
 	(substring rnd 20 32
 
-(defun org-id-int-to-b36-one-digit (i)
-  "Turn an integer between 0 and 61 into a single character 0..9, A..Z, a..z."
+(defun org-id-int-to-b36-one-digit (integer)
+  "Convert INTEGER between 0 and 61 into a single character 0..9, A..Z, a..z."
   (cond
-   ((< i 10) (+ ?0 i))
-   ((< i 36) (+ ?a i -10))
+   ((< integer 10) (+ ?0 integer))
+   ((< integer 36) (+ ?a integer -10))
(t (error "Larger that 35"
 
 (defun org-id-b36-to-int-one-digit (i)
-  "Turn a character 0..9, A..Z, a..z into a number 0..61.
+  "Convert character 0..9, A..Z, a..z into a number 0..61.
 The input I may be a character, or a single-letter string."
   (and (stringp i) (setq i (string-to-char i)))
   (cond
@@ -435,9 +435,11 @@ The input I may be a character, or a single-letter string."
((and (>= i ?a) (<= i ?z)) (+ (- i ?a) 10))
(t (error "Invalid b36 letter"
 
-(defun org-id-int-to-b36 (i  length)
-  "Convert an integer to a base-36 number represented as a string."
-  (let ((s ""))
+(defun org-id-int-to-b36 (integer  length)
+  "Convert an INTEGER to a base-36 number represented as a string.
+The returned string is padded with leading zeros to LENGTH if necessary."
+  (let ((s "")
+(i integer))
 (while (> i 0)
   (setq s (concat (char-to-string
 		   (org-id-int-to-b36-one-digit (mod i 36))) s)
@@ -447,11 +449,11 @@ The input I may be a character, or a single-letter string."
 	(setq s (concat (make-string (- length (length s)) ?0) s)))
 s))
 
-(defun org-id-b36-to-int (s)
-  "Convert a base-36 string into the corresponding integer."
+(defun org-id-b36-to-int (string)
+  "Convert a base-36 STRING into the corresponding integer."
   (let ((r 0))
 (mapc (lambda (i) (setq r (+ (* r 36) (org-id-b36-to-int-one-digit i
-	  s)
+	  string)
 r))
 
 (defun org-id-time-to-b36 ( time)
@@ -489,7 +491,8 @@ and TIME is a Lisp time value (HI LO USEC)."
 Store the relation between files and corresponding IDs.
 This will scan all agenda files, all associated archives, and all
 files currently mentioned in `org-id-locations'.
-When FILES is given, scan also these files."
+When FILES is given, scan also these files.
+If SILENT is non-nil, messages are suppressed."
   (interactive)
   (unless org-id-track-globally
 (error "Please turn on `org-id-track-globally' if you want to track IDs"))
@@ -610,7 +613,7 @@ When FILES is given, scan also these files."
   (add-hook 'kill-emacs-hook 'org-id-locations-save))
 
 (defun org-id-hash-to-alist (hash)
-  "Turn an org-id hash into an alist.
+  "Turn an org-id HASH into an alist.
 This is to be able to write it to a file."
   (let (res x)
 (maphash
@@ -622,7 +625,7 @@ This is to be able to write it to a file."
 res))
 
 (defun org-id-alist-to-hash (list)
-  "Turn an org-id location list into a hash table."
+  "Turn an org-id location LIST into a hash table."
   (let ((res (make-hash-table
 	  :test 'equal
 	  :size (apply '+ (mapcar 'length list
-- 
2.33.0



how to export checkboxes to odt?

2021-09-28 Thread Uwe Brauer


Hi

Any idea how to export checkboxes to odt?

I mean not just simply having [ ] in the odt document but having them 
translated as actual boxes.

Thanks and regards

Uwe Brauer 




Re: Merging latest org-mode for Emacs 28.1

2021-09-28 Thread Stefan Kangas
Hi org-mode,

Stefan Kangas  writes:

> As a heads up, Emacs is getting ready to cut the emacs-28 branch in
> preparation of the upcoming release of Emacs 28.1:
>
> https://lists.gnu.org/archive/html/emacs-devel/2021-07/msg00812.html
>
> It would be good if we could merge the most recent stable Org-mode
> version before the first Emacs 28.1 pretest release.  Could you please
> start looking into what is needed to make this happen?

Could you please provide us with a brief update on the status of this?

Thanks!



Re: [PATCH] oc-csl: Add support for the text and year citation styles

2021-09-28 Thread András Simonyi
Dear All,

I've attached a patch with the pcase pattern refactored following
Nicolas's example -- hopefully this solves the problem.

best wishes,
András

On Tue, 28 Sept 2021 at 17:16, András Simonyi  wrote:
>
> Thanks, I'll try to put together a patch fixing the problem and send it 
> shortly.
> best wishes,
> András
>
> On Tue, 28 Sept 2021 at 17:03, Max Nikulin  wrote:
> >
> > On 28/09/2021 21:40, Bastien wrote:
> > > András Simonyi writes:
> > >
> > >> the attached patch adds support for the text (textual) and year
> > >> (year-only) citation styles in the CSL org-cite processor.
> > >
> > > Applied, thank you very much!
> >
> > This patch has a problem similar to ones earlier fixed by Nicolas:
> > https://orgmode.org/list/seomi1$785$1...@ciao.gmane.io "Re: citations: rx
> > problems with emacs-26.3" Sun, 8 Aug 2021 20:34:55 +0700
> >
> > Compiling single /home/ubuntu/org-mode/lisp/oc-csl.el...
> >
> > In toplevel form:
> > oc-csl.el:330:10:Error: Bytecode overflow
> > Makefile:59: recipe for target 'oc-csl.elc' failed
> > make[2]: [oc-csl.elc] Error 1 (ignored)
> >
> > It is for emacs-26.3 (Ubuntu-18.04 LTS bionic).
From 2ec9af9693c236b6afae7e3d286eb8c6c87283b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A1s=20Simonyi?= 
Date: Tue, 28 Sep 2021 18:13:11 +0200
Subject: [PATCH 2/2] oc-csl: Refactor code to help byte-compilation

* lisp/oc-csl.el (org-cite-csl--create-structure-params): Refactor pcase pattern
to avoid slow or in some cases non-terminating byte compilation.
---
 lisp/oc-csl.el | 82 +++---
 1 file changed, 38 insertions(+), 44 deletions(-)

diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index 51d3d3d8a..3c77e0354 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -284,50 +284,44 @@ INFO is the export state, as a property list."
   "Return citeproc structure creation params for CITATION object.
 STYLE is the citation style, as a string or nil. INFO is the export state, as
 a property list."
-  (let* ((style (org-cite-citation-style citation info)))
-   (pcase style
- ;; "author" style.
- (`(,(or "author" "a") . ,(or "caps" "c"))
-  '(:mode author-only :capitalize-first t :suppress-affixes t))
- (`(,(or "author" "a") . ,(or "full" "f"))
-  '(:mode author-only :ignore-et-al t :suppress-affixes t))
- (`(,(or "author" "a") . ,(or "caps-full" "cf"))
-  '(:mode author-only :capitalize-first t :ignore-et-al t :suppress-affixes t))
- (`(,(or "author" "a") . ,_)
-  '(:mode author-only :suppress-affixes t))
- ;; "noauthor" style.
- (`(,(or "noauthor" "na") . ,(or "bare" "b"))
-  '(:mode suppress-author :suppress-affixes t))
- (`(,(or "noauthor" "na") . ,(or "caps" "c"))
-  '(:mode suppress-author :capitalize-first t))
- (`(,(or "noauthor" "na") . ,(or "bare-caps" "bc"))
-  '(:mode suppress-author :suppress-affixes t :capitalize-first t))
- (`(,(or "noauthor" "na") . ,_)
-  '(:mode suppress-author))
- ;; "year" style.
- (`(,(or "year" "y") . ,(or "bare" "b"))
-  '(:mode year-only :suppress-affixes t))
- (`(,(or "year" "y") . ,_)
-  '(:mode year-only))
- ;; "text" style.
- (`(,(or "text" "t") . ,(or "caps" "c"))
-  '(:mode textual :capitalize-first t))
- (`(,(or "text" "t") . ,(or "full" "f"))
-  '(:mode textual :ignore-et-al t))
- (`(,(or "text" "t") . ,(or "caps-full" "cf"))
-  '(:mode textual :ignore-et-al t :capitalize-first t))
- (`(,(or "text" "t") . ,_)
-  '(:mode textual))
- ;; Default "nil" style.
- (`(,_ . ,(or "bare" "b"))
-  '(:suppress-affixes t))
- (`(,_ . ,(or "caps" "c"))
-  '(:capitalize-first t))
- (`(,_ . ,(or "bare-caps" "bc"))
-  '(:suppress-affixes t :capitalize-first t))
- (`(,_ . ,_) nil)
- ;; This should not happen.
- (_ (error "Invalid style: %S" style)
+  (let ((style (org-cite-citation-style citation info)))
+(pcase style
+  ;; "author" style.
+  (`(,(or "author" "a") . ,variant)
+   (pcase variant
+	 ((or "caps" "c") '(:mode author-only :capitalize-first t))
+	 ((or "full" "f") '(:mode author-only :ignore-et-al t))
+	 ((or "caps-full" "cf") '(:mode author-only :capitalize-first t :ignore-et-al t))
+	 (_ '(:mode author-only
+  ;; "noauthor" style.
+  (`(,(or "noauthor" "na") . ,variant)
+   (pcase variant
+	 ((or "bare" "b") '(:mode suppress-author :suppress-affixes t))
+	 ((or "caps" "c") '(:mode suppress-author :capitalize-first t))
+	 ((or "bare-caps" "bc")
+  '(:mode suppress-author :suppress-affixes t :capitalize-first t))
+	 (_ '(:mode suppress-author
+  ;; "year" style.
+  (`(,(or "year" "y") . ,variant)
+   (pcase variant
+	 ((or "bare" "b") '(:mode year-only :suppress-affixes t))
+	 (_ '(:mode year-only
+  ;; "text" style.
+  (`(,(or "text" "t") . ,variant)
+   (pcase variant
+ ((or "caps" "c") '(:mode textual :capitalize-first t))
+ ((or "full" "f") '(:mode 

Re: [PATCH]

2021-09-28 Thread Timothy
Bastien Guerry  writes:

>> It seems to me that the defvar declaration is good enough.
>
> I just pushed this.

Ah, cool. Thanks for taking care of this Bastien.

All the best,
Timothy


Re: [PATCH]

2021-09-28 Thread Bastien Guerry
Bastien  writes:

> It seems to me that the defvar declaration is good enough.

I just pushed this.

-- 
 Bastien



Re: [PATCH] (minor) Use lower case keywords in ox-org

2021-09-28 Thread Bastien
Hi Timothy,

Timothy  writes:

> Just a little thing, if it’s of interest. A while ago I remember upper/lower
> case keywords being discussed and the conclusion being that upper case 
> keywords
> were only to be used in the manual. Since `ox-org' isn’t the manual, I’ve 
> gone and
> lowered the case of all the keywords used there.

Applied, thanks.

-- 
 Bastien



Re: [PATCH] oc-csl: Add support for the text and year citation styles

2021-09-28 Thread András Simonyi
Thanks, I'll try to put together a patch fixing the problem and send it shortly.
best wishes,
András

On Tue, 28 Sept 2021 at 17:03, Max Nikulin  wrote:
>
> On 28/09/2021 21:40, Bastien wrote:
> > András Simonyi writes:
> >
> >> the attached patch adds support for the text (textual) and year
> >> (year-only) citation styles in the CSL org-cite processor.
> >
> > Applied, thank you very much!
>
> This patch has a problem similar to ones earlier fixed by Nicolas:
> https://orgmode.org/list/seomi1$785$1...@ciao.gmane.io "Re: citations: rx
> problems with emacs-26.3" Sun, 8 Aug 2021 20:34:55 +0700
>
> Compiling single /home/ubuntu/org-mode/lisp/oc-csl.el...
>
> In toplevel form:
> oc-csl.el:330:10:Error: Bytecode overflow
> Makefile:59: recipe for target 'oc-csl.elc' failed
> make[2]: [oc-csl.elc] Error 1 (ignored)
>
> It is for emacs-26.3 (Ubuntu-18.04 LTS bionic).



Possible bug? Combine emphasis marker faces?

2021-09-28 Thread Protesilaos Stavrou
Hello everyone,

I have noticed that it is not possible to combine org-emphasis-alist
characters.  When applying multiple types of emphasis, the face
corresponding to the outermost pair overrides its innermost counterparts.

For example, */emphasise/* will render with the 'bold' face, while
/*emphasise*/ will use the 'italic' face.

Looking at the code, this seems to be intentional or unavoidable, while
I do not know of a way to blend faces dynamically.

Is there a way to get composite styles?  Such as bold and italic or
verbatim and underline, etc.?

All the best,
Protesilaos (or simply "Prot")

* * *

M-x org-version: Org mode version 9.4.4 (release_9.4.4 @
/usr/share/emacs/28.0.50/lisp/org/)

M-x emacs-version: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+
Version 3.24.30, cairo version 1.17.4) of 2021-09-28

-- 
Protesilaos Stavrou
https://protesilaos.com



[PATCH] (minor) Use lower case keywords in ox-org

2021-09-28 Thread Timothy
Hello,

Just a little thing, if it’s of interest. A while ago I remember upper/lower
case keywords being discussed and the conclusion being that upper case keywords
were only to be used in the manual. Since `ox-org' isn’t the manual, I’ve gone 
and
lowered the case of all the keywords used there.

All the best,
Timothy
>From d5c0cb92198d315031a5e4539e227b22a1f0b98b Mon Sep 17 00:00:00 2001
From: TEC 
Date: Tue, 28 Sep 2021 22:45:55 +0800
Subject: [PATCH] ox-org: Use lower case keywords

* lisp/ox-org.el (org-org-identity, org-org-template): As it has
previously been clarified on the mailing list that upper-case keywords
are only intended for the manual[1], an Org export of an Org file should
use lower-case keywords.

[1]: https://list.orgmode.org/87tuuw3n15@nicolasgoaziou.fr/
---
 lisp/ox-org.el | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/lisp/ox-org.el b/lisp/ox-org.el
index c2b85473c..0c4290ebf 100644
--- a/lisp/ox-org.el
+++ b/lisp/ox-org.el
@@ -141,7 +141,7 @@ (defun org-org-identity (blob contents _info)
 CONTENTS is its contents, as a string or nil.  INFO is ignored."
   (let ((case-fold-search t))
 (replace-regexp-in-string
- "^[ \t]*#\\+ATTR_[-_A-Za-z0-9]+:\\(?: .*\\)?\n" ""
+ "^[ \t]*#\\+attr_[-_a-za-z0-9]+:\\(?: .*\\)?\n" ""
  (org-export-expand blob contents t
 
 (defun org-org-headline (headline contents info)
@@ -185,26 +185,26 @@ (defun org-org-template (contents info)
 	   (org-element-map (plist-get info :parse-tree) 'keyword
 		 (lambda (k)
 		   (and (string-equal (org-element-property :key k) "OPTIONS")
-			(concat "#+OPTIONS: "
+			(concat "#+options: "
 (org-element-property :value k)
 	   "\n"))
(and (plist-get info :with-title)
-	(format "#+TITLE: %s\n" (org-export-data (plist-get info :title) info)))
+	(format "#+title: %s\n" (org-export-data (plist-get info :title) info)))
(and (plist-get info :with-date)
 	(let ((date (org-export-data (org-export-get-date info) info)))
 	  (and (org-string-nw-p date)
-	   (format "#+DATE: %s\n" date
+	   (format "#+date: %s\n" date
(and (plist-get info :with-author)
 	(let ((author (org-export-data (plist-get info :author) info)))
 	  (and (org-string-nw-p author)
-	   (format "#+AUTHOR: %s\n" author
+	   (format "#+author: %s\n" author
(and (plist-get info :with-email)
 	(let ((email (org-export-data (plist-get info :email) info)))
 	  (and (org-string-nw-p email)
-	   (format "#+EMAIL: %s\n" email
+	   (format "#+email: %s\n" email
(and (plist-get info :with-creator)
 	(org-string-nw-p (plist-get info :creator))
-	(format "#+CREATOR: %s\n" (plist-get info :creator)))
+	(format "#+creator: %s\n" (plist-get info :creator)))
contents))
 
 (defun org-org-timestamp (timestamp _contents _info)
-- 
2.33.0



Re: [PATCH] oc-csl: Add support for the text and year citation styles

2021-09-28 Thread Max Nikulin

On 28/09/2021 21:40, Bastien wrote:

András Simonyi writes:


the attached patch adds support for the text (textual) and year
(year-only) citation styles in the CSL org-cite processor.


Applied, thank you very much!


This patch has a problem similar to ones earlier fixed by Nicolas: 
https://orgmode.org/list/seomi1$785$1...@ciao.gmane.io "Re: citations: rx 
problems with emacs-26.3" Sun, 8 Aug 2021 20:34:55 +0700


Compiling single /home/ubuntu/org-mode/lisp/oc-csl.el...

In toplevel form:
oc-csl.el:330:10:Error: Bytecode overflow
Makefile:59: recipe for target 'oc-csl.elc' failed
make[2]: [oc-csl.elc] Error 1 (ignored)

It is for emacs-26.3 (Ubuntu-18.04 LTS bionic).



Re: [PATCH] oc-csl: Add support for the text and year citation styles

2021-09-28 Thread Nicolas Goaziou
Hello,

Bastien  writes:

> Dear András,
>
> András Simonyi  writes:
>
>> the attached patch adds support for the text (textual) and year
>> (year-only) citation styles in the CSL org-cite processor.
>
> Applied, thank you very much!

The function `org-cite-csl--create-structure-params' probably needs to
be refactored, as the pcase pattern is going to put the byte-compiler to
a knee. See, e.g., a6d93cfb621356893dc69fc779894c0984cedbd1 and related
thread at .

Regards,
-- 
Nicolas Goaziou



Release 9.5 tomorrow

2021-09-28 Thread Bastien
Hi all,

I'll release Org 9.5 tomorrow between 2pm and 3pm, Paris time.

Feel free to email me at b...@gnu.org if there is an important bugfix
(or a forgotten low-hanging patch) that needs to be committed.

Thanks,

-- 
 Bastien



Re: [PATCH] oc-csl: Add support for the text and year citation styles

2021-09-28 Thread Bastien
Dear András,

András Simonyi  writes:

> the attached patch adds support for the text (textual) and year
> (year-only) citation styles in the CSL org-cite processor.

Applied, thank you very much!

-- 
 Bastien



[PATCH] oc-csl: Add support for the text and year citation styles

2021-09-28 Thread András Simonyi
Dear All,

the attached patch adds support for the text (textual) and year
(year-only) citation styles in the CSL org-cite processor.

best wishes,

András
From ce91f9332ed154fd14f36177bc6dd96cdda0690e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A1s=20Simonyi?= 
Date: Tue, 28 Sep 2021 11:45:13 +0200
Subject: [PATCH] oc-csl: Add support for the text and year citation styles

* lisp/oc-csl.el (org-cite-csl--create-structure-params): Introduce this new
function to map the extended list of supported citation styles and variants to
the corresponding citeproc-el citation structure creation parameters.
(org-cite-csl--no-affixes-p, org-cite-csl--capitalize-p,
org-cite-csl--no-author-p): Remove them since their functionality is provided
now by `org-cite-csl--create-structure-params'.
(org-cite-csl--parse-reference): Don't generate `suppress-author' cite
information as that is treated now by citeproc-el as a citation style.
(org-cite-csl--create-structure): Use `org-cite-csl--create-structure-params' to
generate style-dependent citation structure parameters.
---
 lisp/oc-csl.el | 95 ++
 1 file changed, 64 insertions(+), 31 deletions(-)

diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index 645b1c0f9..51d3d3d8a 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -54,7 +54,10 @@
 
 ;; The library supports the following citation styles:
 ;;
+;; - author (a), including caps (c), full (f), and caps-full (cf) variants,
 ;; - noauthor (na), including bare (b), caps (c) and bare-caps (bc) variants,
+;; - year (y), including a bare (b) variant,
+;; - text (t). including caps (c), full (f), and caps-full (cf) variants,
 ;; - default style, including bare (b), caps (c) and bare-caps (bc) variants.
 
 ;; CSL styles recognize "locator" in citation references' suffix.  For example,
@@ -277,26 +280,54 @@ INFO is the export state, as a property list."
(citeproc-proc-style
 (org-cite-csl--processor info
 
-(defun org-cite-csl--no-affixes-p (citation info)
-  "Non-nil when CITATION should be exported without affix.
-INFO is the export data, as a property list."
-  (pcase (org-cite-citation-style citation info)
-(`(,(or "noauthor" "na" `nil) . ,(or "bare" "b" "bare-caps" "bc")) t)
-(_ nil)))
-
-(defun org-cite-csl--capitalize-p (citation info)
-  "Non-nil when CITATION should be capitalized.
-INFO is the export-data, as a property list."
-  (pcase (org-cite-citation-style citation info)
-(`(,(or "noauthor" "na" `nil) . ,(or "caps" "c" "bare-caps" "bc")) t)
-(_ nil)))
-
-(defun org-cite-csl--no-author-p (reference info)
-  "Non-nil when citation REFERENCE should be exported without author.
-INFO is the export data, as a property list."
-  (pcase (org-cite-citation-style (org-element-property :parent reference) info)
-(`(,(or "noauthor" "na") . ,_) t)
-(_ nil)))
+(defun org-cite-csl--create-structure-params (citation info)
+  "Return citeproc structure creation params for CITATION object.
+STYLE is the citation style, as a string or nil. INFO is the export state, as
+a property list."
+  (let* ((style (org-cite-citation-style citation info)))
+   (pcase style
+ ;; "author" style.
+ (`(,(or "author" "a") . ,(or "caps" "c"))
+  '(:mode author-only :capitalize-first t :suppress-affixes t))
+ (`(,(or "author" "a") . ,(or "full" "f"))
+  '(:mode author-only :ignore-et-al t :suppress-affixes t))
+ (`(,(or "author" "a") . ,(or "caps-full" "cf"))
+  '(:mode author-only :capitalize-first t :ignore-et-al t :suppress-affixes t))
+ (`(,(or "author" "a") . ,_)
+  '(:mode author-only :suppress-affixes t))
+ ;; "noauthor" style.
+ (`(,(or "noauthor" "na") . ,(or "bare" "b"))
+  '(:mode suppress-author :suppress-affixes t))
+ (`(,(or "noauthor" "na") . ,(or "caps" "c"))
+  '(:mode suppress-author :capitalize-first t))
+ (`(,(or "noauthor" "na") . ,(or "bare-caps" "bc"))
+  '(:mode suppress-author :suppress-affixes t :capitalize-first t))
+ (`(,(or "noauthor" "na") . ,_)
+  '(:mode suppress-author))
+ ;; "year" style.
+ (`(,(or "year" "y") . ,(or "bare" "b"))
+  '(:mode year-only :suppress-affixes t))
+ (`(,(or "year" "y") . ,_)
+  '(:mode year-only))
+ ;; "text" style.
+ (`(,(or "text" "t") . ,(or "caps" "c"))
+  '(:mode textual :capitalize-first t))
+ (`(,(or "text" "t") . ,(or "full" "f"))
+  '(:mode textual :ignore-et-al t))
+ (`(,(or "text" "t") . ,(or "caps-full" "cf"))
+  '(:mode textual :ignore-et-al t :capitalize-first t))
+ (`(,(or "text" "t") . ,_)
+  '(:mode textual))
+ ;; Default "nil" style.
+ (`(,_ . ,(or "bare" "b"))
+  '(:suppress-affixes t))
+ (`(,_ . ,(or "caps" "c"))
+  '(:capitalize-first t))
+ (`(,_ . ,(or "bare-caps" "bc"))
+  '(:suppress-affixes t :capitalize-first t))
+ (`(,_ . ,_) nil)
+ ;; This should not happen.
+ (_ (error "Invalid style: %S" style)
 
 (defun 

Re: Suggestions for improved suffix parsing in oc-biblatex

2021-09-28 Thread Bruce D'Arcus
On Tue, Sep 28, 2021 at 7:42 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> Bastien  writes:
>
> > Denis Maier  writes:
> >
> >> I think the suffix parsing in oc-biblatex could be improved.
> >
> > Can you provide a patch for this?
>
> I don't think this improvement is needed. We could get away with it in
> most cases using, e.g., global suffix:
>
>   [cite:@doe 4; with some more text]

That won't work if you have more than one reference in a citation?

[cite:@doe 4, with some more text; @jones]

> Note the example above is not supported yet, but it might be a more
> sensible development than
>
>   [cite:@doe {4}, with some more text]

I recall you're not thrilled with adding brackets for this purpose.

Any other ideas?

Bruce



Re: Suggestions for improved suffix parsing in oc-biblatex

2021-09-28 Thread Nicolas Goaziou
Hello,

Bastien  writes:

> Denis Maier  writes:
>
>> I think the suffix parsing in oc-biblatex could be improved. 
>
> Can you provide a patch for this?

I don't think this improvement is needed. We could get away with it in
most cases using, e.g., global suffix:

  [cite:@doe 4; with some more text]

Note the example above is not supported yet, but it might be a more
sensible development than

  [cite:@doe {4}, with some more text]

Regards,
-- 
Nicolas Goaziou



Re: LaTeX export: grffile is a stub package

2021-09-28 Thread Stefan Nobis
Timothy  writes:

> meedst...@teknik.io writes:

> Oh, that reminds me, we can also get rid of texcomp.
> 

Hmmm... one note about xcolor in your list: Some configuration options
are load-time options that have to be set as package load options. If
xcolor is already loaded with no options, its much harder to load it
with special options like [table,svgnames*]. Also some classes like
beamer are very special with reagads to xcolor.

But what about some other tweaks?

To better support lualatex and xelatex in the default configuration,
we should add

("" "fontspec" t ("lualatex" "xelatex"))

Personally, I would also add the following two lines for better
multilingual support with all three engines:

("AUTO,safe=none,math=normal" "babel" t ("pdflatex" "lualatex"))
("AUTO" "polyglossia" t ("xelatex"))

Then, for math it may be nice to substitute "amsmath" with "mathtools"
and for lualatex and xelatex add something like this:

("warnings-off={mathtools-colon,mathtools-overbracket}" "unicode-math" t 
("lualatex" "xelatex"))

What do you think?

-- 
Until the next mail...,
Stefan.



Re: Would it be possible to color horizontal lines in org mode?

2021-09-28 Thread Eric S Fraga
You could use hi-lock-mode to define your own colouring for such
lines.  But I'm sure those that under font-locking better might be able
to add appropriate rules for this horizontal line construct.

-- 
: Eric S Fraga via Emacs 28.0.50, Org 9.5-g9a4a24
: Latest paper written in org: https://arxiv.org/abs/2106.05096



Re: [PATCH] async process in R

2021-09-28 Thread Jeremie Juste
Hello Chuck,

On Monday, 27 Sep 2021 at 23:40, Berry, Charles wrote:
> Jeremie,
>
>> On Sep 27, 2021, at 3:56 PM, Berry, Charles  wrote:
>> 
>> There is something in my init that doesn't play nice with this.  
>
> (setq ess-inject-source nil)

Thanks for the feedback. With the following patch, I made sure that
ess-inject-source is set to default before evaluating the buffer.

So even if I set
(setq ess-inject-source 'function-and-buffer), I get the following
output. Note that I get the same output in the IESS console buffer when
I execute the command following command.

#+begin_src R :session *R*  :results output :async yes
  Sys.sleep(2)
  1:5

  10:20
  1:2
#+end_src

#+RESULTS:
: [1] 1 2 3 4 5
:  [1] 10 11 12 13 14 15 16 17 18 19 20
: [1] 1 2

It might be good to fix this on the ESS side. I'll see what can be
done, but I'd appreciate any input you might have on this. Thanks again.

Best regards,
Jeremie

>From db2ad631247a5c52d9d6f6779948f6d0cf34c698 Mon Sep 17 00:00:00 2001
From: Jeremie Juste 
Date: Tue, 28 Sep 2021 09:04:25 +0200
Subject: [PATCH] ob-R.el: Patch async evaluation when :results output

* lisp/ob-R.el (ob-session-async-org-babel-R-evaluate-session): Make
sure that `ess-inject-source' is set to the default
'function-and-buffer before running (ess-eval-buffer). Return
`ess-inject-source' to its user-specified state afterwards.
---
 lisp/ob-R.el | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 188b9ac8f..7e050c094 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -528,9 +528,13 @@ by `org-babel-comint-async-filter'."
  (insert (format ob-session-async-R-indicator
 			 "end" uuid))
  (setq tmp ess-eval-visibly)
+ (setq user-inject-src-param ess-inject-source)
  (setq ess-eval-visibly nil)
+ (setq  ess-inject-source 'function-and-buffer)
  (ess-eval-buffer nil))
- (setq ess-eval-visibly tmp)
+   (setq ess-eval-visibly tmp)
+   (setq ess-inject-source user-inject-src-param)
+   
uuid
 
 (defun ob-session-async-R-value-callback (params tmp-file)
-- 
2.30.2