Re: Notes about citations in Org (part 3)

[Eric S Fraga]

On Tuesday,  4 May 2021 at 22:22, Nicolas Goaziou wrote:
> I meant: is it useful to even mention it? Is it used at all when other
> more complete solutions exist?

Actually, to avoid misunderstanding, natbib is not more "complete" than
the default LaTeX support.  It simply supports a particular style and,
because of that style, it has more options that are necessary due to
what it exposes/uses for the actual citations.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd

Re: Notes about citations in Org (part 3)

[Eric S Fraga]

On Tuesday,  4 May 2021 at 18:59, Nicolas Goaziou wrote:
> Is the default \cite{key} command (without any other package) used? 

Yes, it is.  But I wouldn't be able to tell you anything about relative
frequency etc.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd

Multiple calc commands with orgbabel

[pietru]

Have been trying to execute multiple calc commands, but when I evaluate the calc
expressions, I get just one result.



This does not work

#+begin_src calc
fsolve(x*2+x=4,x)
fsolve([x + y = a, x - y = b],[x,y])
#+end_src



But this works

#+begin_src calc
fsolve(x*2+x=4,x)
#+end_src

#+begin_src calc
fsolve([x + y = a, x - y = b],[x,y])
#+end_src>

orgbabel with fortran code

[pietru]

Have been looking to find some examples on using orgbabel with fortran code
but have not found information.

Regards
P*

Re: Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

Sébastien Miquel  writes:


Hi Bastien,

Bastien writes:
I tried to apply this (transitory?) patch against maint and it 
did not
apply. It applies okay on master. For bug fixes, please make 
patches

againt the maint branch.
This fixes a bug introduced by a commit in master. I've attached 
the same
patch here, properly formated. I think it should be applied to 
master.


It reverts a part of a2cb9b853: permissions are no longer set 
before writing

to the tangled file.

I've CC'd Tom, which made the original suggestion. I guess we 
could set the
write and execute permissions before writing, and set the read 
permissions

afterwards.



Another related bug to the changes:

I have the :tangle header-arg set to evaluate some elisp to return 
the file name:


org-babel no longer interprets this elisp. It is being used 
literally as the file name:

e.g.

Wrote /home/n/.emacs.d/(concat (file-name-sans-extension 
(buffer-file-name)) ".el")

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

[Ihor Radchenko]

Fr Ml  writes:
> If the cursor is on a <> and the item has a CUSTOM_ID then a
> link to the headline (with the CUSTOM_ID) is stored - and not the link to the 
> target.
> This behavior is not always the same.

Confirmed on master.

Recipe:

1. Create the following org file:

* test
:PROPERTIES:
:CUSTOM_ID: testasd
:END:

<>

2. Put point at the target
3. org-store-link
4. org-insert-link
5. The inserted link is pointing to the custom ID
[[#testasd][file:/tmp/4.org::targetasd]]

Best,
Ihor

Re: [PATCH] Bug: fragile org refile cache

[Ihor Radchenko]

Maxim Nikulin  writes:

> helm-org-ql.el that is a part of org-ql does not use cache when calling 
> org-get-outline-path. helm-org performs sequential scan similar to 
> org-refile-get-targets.

Hmm. You are right. But they could. I myself ran into an issue with
helm-org-ql exactly because formatting displayed headings was slow. If
org-refile-use-cache is deprecated, there would be no option to use
cache at all.

Best,
Ihor

Re: Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

[Sébastien Miquel]

Hi Bastien,

Bastien writes:

I tried to apply this (transitory?) patch against maint and it did not
apply.  It applies okay on master.  For bug fixes, please make patches
againt the maint branch.

This fixes a bug introduced by a commit in master. I've attached the same
patch here, properly formated. I think it should be applied to master.

It reverts a part of a2cb9b853: permissions are no longer set before writing
to the tangled file.

I've CC'd Tom, which made the original suggestion. I guess we could set the
write and execute permissions before writing, and set the read permissions
afterwards.

--
Sébastien Miquel

>From e56a05f4f5a3cce9cfdeb71854475e29aac1a6e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Tue, 4 May 2021 22:59:36 +0200
Subject: [PATCH] ob-tangle.el (org-babel-tangle): Fix readonly tangle

* lisp/ob-tangle.el (org-babel-tangle): Fix readonly tangle.
---
 lisp/ob-tangle.el | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 36144d6ae..96a4ef049 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -268,11 +268,11 @@ matching a regular expression."
 		lspecs)
 		   (when make-dir
 		 (make-directory fnd 'parents))
-   ;; erase previous file and set permissions on empty
-   ;; file before writing
-   (write-region "" nil file-name nil 0)
-		   (mapc (lambda (mode) (set-file-modes file-name mode)) modes)
+   ;; erase previous file
+   (when (file-exists-p file-name)
+ (delete-file file-name))
 		   (write-region nil nil file-name)
+		   (mapc (lambda (mode) (set-file-modes file-name mode)) modes)
(push file-name path-collector))
 	 (if (equal arg '(4))
 	 (org-babel-tangle-single-block 1 t)
-- 
2.31.1

Re: [PATCH] Fix truncated output in ob-sqlite.el

[Bastien]

Hi Nick,

Nick Savage  writes:

> I've attached a patch to address this.

Applied in maint, thanks a lot!

-- 
 Bastien

[PATCH] Fix truncated output in ob-sqlite.el (Was: Bug: sqlite output truncated?)

[Nick Savage]

I've attached a patch to address this.

The issue is that ob-sqlite.el uses org-babel-string-read, which 
purposefully removes double-quotes. I think this is unintended 
behaviour, and it only seems to be used with ob-sqlite.el. I added a 
minor function to bypass the part of org-babel-string-read that was 
stripping out the double-quotes and use the rest of the function.


I tried ob-sql with the mysql engine and didn't experience the same bug, 
so I'm pretty confident that this is an isolated issue.



On 5/3/21 6:22 PM, learn orchids wrote:

I am using Org mode version 9.4.5 (9.4.5-73-g4c7696-elpaplus and I have the 
following code snippet. Values in the 'sql' column of the second row is 
truncated. Am I missing something?

#+begin_src sqlite :db /tmp/rip.db  :colnames yes
   drop table if exists testtable;
   create table testtable(id int, sql varchar);
   insert into testtable values (1, "Select id from foo");
   insert into testtable values (2, 'Select "id" from foo');
   select* from testtable;
#+end_src

#+RESULTS: testsql
| id | sql                |
|+|
|  1 | Select id from foo |
|  2 | id                 |
>From 3dd868bcd798e6763ec67ba0d2661834e09bb6e9 Mon Sep 17 00:00:00 2001
From: Nicholas Savage 
Date: Tue, 4 May 2021 11:02:20 -0400
Subject: [PATCH] lisp/ob-sqlite.el: Prevent output from being incorrectly
 parsed if it contains double-quotes.

* lisp/ob-sqlite.el (org-babel-sqlite--read-cell): New function.
lisp/ob-sqlite.el (org-babel-sqlite-table-or-scalar): Use
`org-babel-sqlite--read-cell' instead of `org-babel-string-read' to
prevent data from being ignored if it contains double-quotes.

Reported-by: learnorch...@gmail.com
Link: https://orgmode.org/list/cak5xwica4i8h09obzcvpx2pe-t6b0_ju_mxiduriy7gh+pk...@mail.gmail.com/
---
 lisp/ob-sqlite.el | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-sqlite.el b/lisp/ob-sqlite.el
index c0c6f3c97..d227ba69d 100644
--- a/lisp/ob-sqlite.el
+++ b/lisp/ob-sqlite.el
@@ -125,7 +125,7 @@ This function is called by `org-babel-execute-src-block'."
 (mapcar (lambda (row)
 	  (if (eq 'hline row)
 		  'hline
-		(mapcar #'org-babel-string-read row)))
+		(mapcar #'org-babel-sqlite--read-cell row)))
 	result)))
 
 (defun org-babel-sqlite-offset-colnames (table headers-p)
@@ -139,6 +139,10 @@ This function is called by `org-babel-execute-src-block'."
 Prepare SESSION according to the header arguments specified in PARAMS."
   (error "SQLite sessions not yet implemented"))
 
+(defun org-babel-sqlite--read-cell (cell)
+  "Process CELL to remove unnecessary characters."
+  (org-babel-read cell t))
+
 (provide 'ob-sqlite)
 
 ;;; ob-sqlite.el ends here
-- 
2.20.1

Re: Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

[Bastien]

Hi Sébastien,

Sébastien Miquel  writes:

> I'll see if I can fix this bug and keep the security improvements. In
> the meantime, you can apply the attached patch that should fix
> your issue.

I tried to apply this (transitory?) patch against maint and it did not
apply.  It applies okay on master.  For bug fixes, please make patches
againt the maint branch.

Thanks!

PS: While Org 9.5 is (slowly) maturing, we will have time to release yet
another bugfix release.

-- 
 Bastien

Re: Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

[Sébastien Miquel]

No Wayman writes:

Subsequent tangles did not fail for me.

Ah yes, I understand, it is possible to delete a file without write
permission.

I'll see if I can fix this bug and keep the security improvements. In
the meantime, you can apply the attached patch that should fix
your issue.

Thank you for the report.

--
Sébastien Miquel

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 36144d6ae..c041ff4b3 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -270,9 +270,10 @@ matching a regular expression."
 		 (make-directory fnd 'parents))
;; erase previous file and set permissions on empty
;; file before writing
-   (write-region "" nil file-name nil 0)
-		   (mapc (lambda (mode) (set-file-modes file-name mode)) modes)
+   (when (file-exists-p file-name)
+ (delete-file file-name))
 		   (write-region nil nil file-name)
+		   (mapc (lambda (mode) (set-file-modes file-name mode)) modes)
(push file-name path-collector))
 	 (if (equal arg '(4))
 	 (org-babel-tangle-single-block 1 t)

Re: Bug: Double colon in org link description breaks the link [9.4.4 (release_9.4.4 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Bastien]

Hi,

"Steven Bagley"  writes:

> Yes, that works for the example I quoted. The source of the original
> "::" is org-mac-link, not my typing. Maybe that could insert a
> different character sequence to avoid any confusion.

I had a look at org-mac-link.el but could not figure out what was
causing this.

org-mac-link.el lives in https://git.sr.ht/~bzg/org-contrib and
we make no promise on whether it's compatible with Org's core.

I'm closing this now.

-- 
 Bastien

Re: Notes about citations in Org (part 3)

[Nicolas Goaziou]

"Bruce D'Arcus"  writes:

> On Tue, May 4, 2021 at 12:59 PM Nicolas Goaziou  
> wrote:

>> Is the default \cite{key} command (without any other package) used? I'm
>> not sure we should provide it since we are working towards more complete
>> solutions.
>
> Not ATM.
>
> The table only has suggested mappings for natbib, biblatex, and
> citeproc-el/org, though Eric was wondering about adding also one for
> standard latex.

I meant: is it useful to even mention it? Is it used at all when other
more complete solutions exist?

>> AFAIU, the idea is to use styles from you wiki. However, sub-styles are
>> not mentioned.
>
> I just have the note they are a good idea, but wasn't sure on details.

OK. Let's go for the verbose path.

>> They could be "full" for the starred variants, "caps" for
>> the capitalized ones, and "alt" for those without parenthesis, so one
>> could write:
>>
>>   [cite/text/alt/full/caps:...]  (in any order)
>>
>> and obtain
>>
>>   \Citealt*{...}
>
> I'll add them to the wiki page.
>
> It did occur to me that ideally users could customize what the default
> command is. My choices for natbib and biblatex defaults are I think
> defensible, but some may disagree.

Customizing default command is the point of the third parameter in
"cite_export" keyword.

When using:

   #+cite_export: natbib harvard text

[cite:...] is equivalent to [cite/text: ...]

So the processor must choose a default value, but the user may choose
another one.

Regards,

Re: Question about citation processors [wip-cite branch]

[Joost Kremers]

On Tue, May 04 2021, Denis Maier wrote:
> Well, IIRC, in author-year styles \autocite is equivalent to \parencite. I
> think, what the manual talks about is not that \autocite wouldn't be 
> appropriate
> for author-year styles, but rather that relying /solely/ on \autocite doesn't
> give authors the flexibility they might want in these styles, 

Yes, I did a quick test and you're right.

> So, I think \autocite is the better choice.

Yes.

-- 
Joost Kremers
Life has its moments

Re: Question about citation processors [wip-cite branch]

[Joost Kremers]

Hi Nicolas,

On Tue, May 04 2021, Nicolas Goaziou wrote:
> If you think my assumption is incorrect, please let me know what kind of
> hook would be required.

No, I don't think there's anything Org should provide. I just wanted to be sure
I hadn't missed anything.

>> - =:active= just means "font-lock", right?
>
> Yes, with the emphasis that more than faces could be provided (e.g.,
> help-echo, specific keymap, …).

Ah, that's good to know. I hadn't realised that.

>> - What kind of data structure do the =:follow= and =:activate= functions 
>> take?
>>   Should I just look at =oc-basic.el= or is this written down
>>   somewhere?
>
> Processors must be registered using `org-cite-register-processor'
> function from "oc.el". See its docstring for details. All arguments are
> detailed.

The docstring talks about a "citation object", and the "citation or citation
reference object at point". Do I assume correctly that these are structures as
returned by =org-element-parse-buffer=?

> At some point, we will need to write some documentation in the manual,
> too...

For the moment, I can follow the lead in =oc-basic.el= and do what it does.

> "oc.el" provides a number of hopefully useful tools. Among them,
> `org-cite-list-bibliography-files' function returns what you're asking
> for. Global variable and keywords are cumulative.

Great, thanks!

> HTH!

Yes, this was certainly very helpful. Thank you for your answer and thank you
for all the hard work you've put in.

The same goes for everyone else who put time and effort into making org-cite
happen, of course. :-)

-- 
Joost Kremers
Life has its moments

Re: [IMPORTANT] The contrib/ directory now lives outside of Org's repository

[Bastien]

Hi Jonas,

Jonas Bernoulli  writes:

> All the *ELPAs extract metadata from the "main library", which by
> default is the library whose name matches the name of the package.
>
> If the name doesn't match, then it can be overridden, but some
> main library is required, even if it does nothing but provide
> the metadata and (provide 'org-contrib).
>
> I've already added "org-contrib" to the Emacsmirror, but because
> nothing like "org-contrib.el" exists, I had to randomly pick a
> library and as a result the package description for all of
> "org-contrib" currently is "Org-mode Babel support for Arduino".
>
> Please add "org-contrib.el" containing some juicy metadata.

Well, I don't know if they are *that* juicy but I just added some.
Let me know how this look!  And thanks for the above instructions,
that's very useful.

Best,

-- 
 Bastien

Re: Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

Sébastien Miquel  writes:


Hi,

No Wayman writes:
I'm tangling my early-init/init.el with the :tangle-mode header 
arg set to

(identity (#o444)).

This should be `(identity #o444)` I believe ?



Apologies, I transcribed that incorrectly. I do have `(identity 
#o444)`. 

File permissions are now set before writing to the file, for 
security
reasons. In this case, you remove write permission so emacs 
fails to
write to the file. Perhaps we should try to support this use 
case.


However, even with the previous version, it seems that 
subsequent
tangles should have failed (emacs should fail to delete the 
previous
tangled file). Can you confirm this and explain how you dealt 
with it ?



Subsequent tangles did not fail for me. I just tested by building 
Org from a2cb9b853's parent: f84033b08.
Multiple tangles work with no permission errors on subsequent 
tangles.


Here's my init.org, if that's useful:

https://raw.githubusercontent.com/progfolio/.emacs.d/master/init.org


As a workaround, you could use a file-local
`org-babel-post-tangle-hook` to set file permission. Although
subsequent tangles will still fail.


Unfortunately, I don't have much use for the workaround if 
subsequent tangles will fail.
I currently have an after-save-hook function which tangles the 
files if I've edited any of the
src blocks. It's very convenient and I often will edit/tangle 
files set up like this multiple times.

Re: Question about citation processors [wip-cite branch]

[Denis Maier]

Am 04.05.2021 um 17:27 schrieb Joost Kremers:


On Tue, May 04 2021, Bruce D'Arcus wrote:

On Tue, May 4, 2021 at 10:47 AM Joost Kremers  wrote:


I can add some comments regarding biblatex:

- default: \parencite[1]


WDYT of \autocite for default?

It's conceptually the same as the CSL default.


If that is the case then it's probably the better choice. The biblatex manual
states that \autocite requires that the citation style defines a command for it
and that it is not appropriate for author-year style citations. I assume that's
something for the user to be aware of when using such citations?


Well, IIRC, in author-year styles \autocite is equivalent to \parencite. 
I think, what the manual talks about is not that \autocite wouldn't be 
appropriate for author-year styles, but rather that relying /solely/ on 
\autocite doesn't give authors the flexibility they might want in these 
styles, like when you want something like in your example:

```
According to \textcite[]{Jones1998} , ``students often had difficulty 
using APA
style, especially when it was their first time'' 
\pnotecite[][199]{Jones1998}.

```

So, I think \autocite is the better choice.

Denis

Re: Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

[Sébastien Miquel]

Hi,

No Wayman writes:
I'm tangling my early-init/init.el with the :tangle-mode header arg 
set to (identity (#o444)).

This should be `(identity #o444)` I believe ?

The idea behind this was to prevent myself from accidentally editing 
the tangled source files
instead of the Org files. 
Unfortunately, since a3cb9b853 there seems to be a behavior change for 
org-babel-tangle which prevents this.

File permissions are now set before writing to the file, for security
reasons. In this case, you remove write permission so emacs fails to
write to the file. Perhaps we should try to support this use case.

However, even with the previous version, it seems that subsequent
tangles should have failed (emacs should fail to delete the previous
tangled file). Can you confirm this and explain how you dealt with it ?

As a workaround, you could use a file-local
`org-babel-post-tangle-hook` to set file permission. Although
subsequent tangles will still fail.

--
Sébastien Miquel

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

[Fr Ml]

  
  
Hello,

I have a problem with the function org-store-link it doesn't
work as
described in the documentation:
https://orgmode.org/manual/Handling-Links.html
"For Org files, if there is a '<>' at point,
the link points to
the target."

If the cursor is on a <> and the item has a
CUSTOM_ID then a
link to the headline (with the CUSTOM_ID) is stored - and not
the link to the target.
This behavior is not always the same. 

Also:
https://emacs.stackexchange.com/questions/64693/make-link-using-the-target-at-point-and-ignore-the-id-or-custom-id

Kind regards 
Frank

Emacs  : GNU Emacs 27.2 
Package: Org mode version 9.4.4 (release_9.4.4 @
/usr/share/emacs/27.2/lisp/org/)

  
  

Re: Notes about citations in Org (part 3)

[András Simonyi]

Dear All,

this is just to indicate that I've started to look into the
wip-cite-new branch with an eye on updating citeproc-org to use the
new API -- everything seems to be working perfectly, thanks again for
this, Nicholas! One issue I also noticed is the separation of citation
style and bibliography style, which does not exist in CSL.
Accordingly, it would be nice to have ways of specifying a single
style for both of them (both in the Org syntax and in the Liisp API),
if this is not possible already.

best regards,
András

On Tue, 4 May 2021 at 20:25, Bruce D'Arcus  wrote:
>
> On Tue, May 4, 2021 at 12:59 PM Nicolas Goaziou  
> wrote:
>
> > AFAIU, the idea is to use styles from you wiki. However, sub-styles are
> > not mentioned. They could be "full" for the starred variants, "caps" for
> > the capitalized ones, and "alt" for those without parenthesis, so one
> > could write:
>
> "Alt" and "full" I understand.
>
> By "caps", you're referring to the biblatex variants?
>
> Does this basically mean "force initial capitalization"?
>
> Bruce
>

Re: About multilingual documents

[Aleksandar Dimitrov]

Maxim Nikulin writes:

> On 04/05/2021 14:30, Aleksandar Dimitrov wrote:
>> 
>> I don't usually switch input methods. Instead I rely on the X-Server's
>> facilities, including group toggles and XCompose. For example I use
>> XCompose to write all languages with a Latin alphabet without having to
>> switch layouts/input methods.
>
> You mentioned Cyrillic, and it is inconvenient to switch keyboard layout 
> (Xkb group) for any command (C-c ...). Unfortunately keymaps in emacs 
> are unaware of keysyms from "base" group when another group is active. 
> On the other hand, emacs input method requires special tricks to keep 
> emacs window (almost) always with latin keyboard layout while other 
> applications rely on xkb.

Yeah, I know the issue, which is why I rely on XCompose for Latin
scripts. For Cyrillic, alas, that is impossible. It means that I
basically can't control Emacs while using a Cyrillic layout, which is a
pity. I have no good workaround.

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Victor A. Stoichita]

Le 04 May 2021, Bastien  a écrit :
>> I typically use it directly, but if the maintenance burden is
>> manageable, I could offer maintenance here, too (once I have the papers
>> in place).
>
> Thanks also for this then!
>

Thanks as well ! It’s good to know that knowledgeable people might care
for this little tool which I find very useful.

Regards,
Victor

Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

I'm tangling my early-init/init.el with the :tangle-mode header 
arg set to (identity (#o444)).
The idea behind this was to prevent myself from accidentally 
editing the tangled source files
instead of the Org files. Unfortunately, since a3cb9b853 there 
seems to be a behavior change for org-babel-tangle which prevents 
this. An abbreviated stacktrace which shows the error when I try 
to tangle my files:


Debugger entered--Lisp error: (file-error "Opening output file" 
"Permission denied" "/home/n/.emacs.d/early-init.el")

 write-region("" nil "~/.emacs.d/early-init.el" nil 0)

Any way to work around this?

Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X 
toolkit, cairo version 1.17.4, Xaw3d scroll bars)

of 2021-05-03
Package: Org mode version 9.4.5 (9.4.5-gbc2659 @ 
/home/n/.emacs.d/straight/build/org/)

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

On Tue, May 4, 2021 at 12:59 PM Nicolas Goaziou  wrote:

> AFAIU, the idea is to use styles from you wiki. However, sub-styles are
> not mentioned. They could be "full" for the starred variants, "caps" for
> the capitalized ones, and "alt" for those without parenthesis, so one
> could write:

"Alt" and "full" I understand.

By "caps", you're referring to the biblatex variants?

Does this basically mean "force initial capitalization"?

Bruce

Re: [IMPORTANT] The contrib/ directory now lives outside of Org's repository

[Jonas Bernoulli]

Bastien  writes:

> The files previously stored in the contrib/ directory of Org's repo
> now lives here: https://git.sr.ht/~bzg/org-contrib

Congrats.

Better late than never.  ;D

> The plan is to build a NonGNU ELPA package called "org-contrib",
> we will see if that's feasible.

All the *ELPAs extract metadata from the "main library", which by
default is the library whose name matches the name of the package.

If the name doesn't match, then it can be overridden, but some
main library is required, even if it does nothing but provide
the metadata and (provide 'org-contrib).

I've already added "org-contrib" to the Emacsmirror, but because
nothing like "org-contrib.el" exists, I had to randomly pick a
library and as a result the package description for all of
"org-contrib" currently is "Org-mode Babel support for Arduino".

Please add "org-contrib.el" containing some juicy metadata.

Cheers,
Jonas

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

On Tue, May 4, 2021 at 12:59 PM Nicolas Goaziou  wrote:

> "Bruce D'Arcus"  writes:
...
> > I guess the question at this stage is how to iterate this.
> >
> > I already added a change or two based on feedback from Joost, and it
> > does make sense to add a new column for latex.
> >
> > It seems easier to me to do it on the wiki, rather than post a new
> > version to the list every time, in part because it allows others to
> > edit it.
> >
> > Any thoughts Nicolas?
>
> Is the default \cite{key} command (without any other package) used? I'm
> not sure we should provide it since we are working towards more complete
> solutions.

Not ATM.

The table only has suggested mappings for natbib, biblatex, and
citeproc-el/org, though Eric was wondering about adding also one for
standard latex.

> I'd like to give a shot at "oc-natbib.el" in a few hours. It may give an
> incentive to start out "oc-biblatex.el" (which is a bit harder).
>
> AFAIU, the idea is to use styles from you wiki. However, sub-styles are
> not mentioned.

I just have the note they are a good idea, but wasn't sure on details.

> They could be "full" for the starred variants, "caps" for
> the capitalized ones, and "alt" for those without parenthesis, so one
> could write:
>
>   [cite/text/alt/full/caps:...]  (in any order)
>
> and obtain
>
>   \Citealt*{...}

I'll add them to the wiki page.

It did occur to me that ideally users could customize what the default
command is. My choices for natbib and biblatex defaults are I think
defensible, but some may disagree.

Bruce

Re: About multilingual documents

[Maxim Nikulin]

On 04/05/2021 14:30, Aleksandar Dimitrov wrote:


I don't usually switch input methods. Instead I rely on the X-Server's
facilities, including group toggles and XCompose. For example I use
XCompose to write all languages with a Latin alphabet without having to
switch layouts/input methods.


You mentioned Cyrillic, and it is inconvenient to switch keyboard layout 
(Xkb group) for any command (C-c ...). Unfortunately keymaps in emacs 
are unaware of keysyms from "base" group when another group is active. 
On the other hand, emacs input method requires special tricks to keep 
emacs window (almost) always with latin keyboard layout while other 
applications rely on xkb.


On 04/05/2021 15:19, Eric S Fraga wrote:

So, on this note, without hopefully hijacking the thread, maybe somebody
can tell me: what is the "default" input method, i.e. the one I get when
I start Emacs and haven't changed input methods at all?


Default input method depend on locale. E.g. en_US.UTF-8 does not require 
anything special.

Re: [PATCH] Bug: fragile org refile cache

[Maxim Nikulin]

On 02/05/2021 13:59, Ihor Radchenko wrote:

Maxim Nikulin writes:


Some additions. org-outline-path-cache is used solely by
org-refile-get-targets (maybe there are some calls in other packages)
but it efficiency is questionable. It was not clear for me earlier that
the cache is reset before each scan through a buffer. So if
org-refile-use is disabled, org-outline-path-cache from previous run of
org-refile or org-goto is not used as well. A query to
org-outline-path-cache requires at least one backward search and hash
lookup. During sequential scan in org-refile-get-targets it is enough to
have previous heading path to update it when new heading is found. I
think, org-outline-path-cache should be deprecated.


At least helm-org-ql and helm-org are using `org-get-outline-path' with
cache. I do think it is useful. Though, indeed, not as fast as
single-pass scan. Probably, we can rewrite the code of
`org-get-outline-path' instead of deprecating it?


helm-org-ql.el that is a part of org-ql does not use cache when calling 
org-get-outline-path. helm-org performs sequential scan similar to 
org-refile-get-targets. Maybe a new function should be introduced to 
address such case.


On 29/04/2021 21:12, Ihor Radchenko wrote:

Note that Org mode has integration with imenu. It is an alternative you
can use to jump around current buffer.


I do not see any advantages of imenu over jumping using org-goto or 
org-refile with enabled cache.

Re: Notes about citations in Org (part 3)

[Nicolas Goaziou]

"Bruce D'Arcus"  writes:

> On Tue, May 4, 2021 at 11:46 AM Eric S Fraga  wrote:
>
>> I wonder whether it might be good to have a default LaTeX column as
>> well, i.e. not natbib, a column that represents what LaTeX supports out
>> of the box which is only the \cite{key} command.
>
> Makes sense to me.
>
> I guess the question at this stage is how to iterate this.
>
> I already added a change or two based on feedback from Joost, and it
> does make sense to add a new column for latex.
>
> It seems easier to me to do it on the wiki, rather than post a new
> version to the list every time, in part because it allows others to
> edit it.
>
> Any thoughts Nicolas?

Is the default \cite{key} command (without any other package) used? I'm
not sure we should provide it since we are working towards more complete
solutions.

I'd like to give a shot at "oc-natbib.el" in a few hours. It may give an
incentive to start out "oc-biblatex.el" (which is a bit harder).

AFAIU, the idea is to use styles from you wiki. However, sub-styles are
not mentioned. They could be "full" for the starred variants, "caps" for
the capitalized ones, and "alt" for those without parenthesis, so one
could write:

  [cite/text/alt/full/caps:...]  (in any order)

and obtain

  \Citealt*{...}

I hope we can find a shortcut, but it doesn't matter for now.

About sub-styles. The style is parsed as a string, so in the example
above, (org-element-property :style citation-object) returns
"text/alt/full/caps". 

Supporting sub-styles could be as simple as providing a function that
returns a non-nil value if a given sub-style belongs to the style. e.g.,

  (org-cite-has-substyle-p style "full") => t

  (org-cite-has-substyle-p style "author") => nil

I.e, sub-styles are not formally supported in the parser, but tooling
can take them into account.

Of course, we can also support them fully, i.e.
(org-element-property :style citation-object) returns a list of strings.
It depends how simple the common single style case should be.

To limit verbosity, we may want to stay (it's not mandatory) at one
sub-level instead, and use single characters for processor specific
variants, e.g.,

  [cite//aC*:...]  <-- default style with alt+full+caps

If style are in common use, processors might as well declare them in
`org-cite-register-processor' as a help for, e.g., functions inserting
citations. Hmm.

WDYT?

Regards,
-- 
Nicolas Goaziou

Re: Question about citation processors [wip-cite branch]

[Nicolas Goaziou]

Hello,

Joost Kremers  writes:

> - A user should be able to insert citations into an Org document. IIUC nothing
>   in org-cite provides any functionality for this, right? Is there a default
>   list of styles a user would expect to be supported, or does this depend 
> solely
>   on the bibliography style one uses?

Org Cite does not provide anything in that area because there nothing to
provide. You can write your own function inserting citations without
plugging it anywhere in Org. For others capabilities (activate, follow,
export), you need Org to cooperate.

If you think my assumption is incorrect, please let me know what kind of
hook would be required.

> - =:active= just means "font-lock", right?

Yes, with the emphasis that more than faces could be provided (e.g.,
help-echo, specific keymap, …). I think that Org Ref only needs this
property (barring its export part).

> - Since I don't plan on writing an exporter, I assume that it is possible to
>   mix and match processors? Say, have one for the =:follow= property, another
>   for =:activate= and a third one for =:export-*=?

Exactly! A processor may only provide an :activate property.

> - What kind of data structure do the =:follow= and =:activate= functions take?
>   Should I just look at =oc-basic.el= or is this written down
>   somewhere?

Processors must be registered using `org-cite-register-processor'
function from "oc.el". See its docstring for details. All arguments are
detailed.

As an example, "oc-basic.el" is a citation processor. It calls the
function above at the end of the file and registers all three
capabilities (activate, follow and export).

At some point, we will need to write some documentation in the manual,
too...

> - Is there a function or buffer-local variable that gives me a list of all the
>   bibliography files of a buffer? Related to that: if a user has set
>   =org-cite-global-bibliography= and also provides a =#+bibliography= keyword,
>   are both sources used, or only the keyword?

"oc.el" provides a number of hopefully useful tools. Among them,
`org-cite-list-bibliography-files' function returns what you're asking
for. Global variable and keywords are cumulative.

HTH!

Regards,
-- 
Nicolas Goaziou

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

On Tue, May 4, 2021 at 11:46 AM Eric S Fraga  wrote:

> I wonder whether it might be good to have a default LaTeX column as
> well, i.e. not natbib, a column that represents what LaTeX supports out
> of the box which is only the \cite{key} command.

Makes sense to me.

I guess the question at this stage is how to iterate this.

I already added a change or two based on feedback from Joost, and it
does make sense to add a new column for latex.

It seems easier to me to do it on the wiki, rather than post a new
version to the list every time, in part because it allows others to
edit it.

Any thoughts Nicolas?

Bruce

Re: Notes about citations in Org (part 3)

[Eric S Fraga]

On Tuesday,  4 May 2021 at 11:20, Bruce D'Arcus wrote:
> I'm attaching the tentative style/command and shortcut mapping I came
> up with, with help from Eric and Joost.

Thank you for this.

I wonder whether it might be good to have a default LaTeX column as
well, i.e. not natbib, a column that represents what LaTeX supports out
of the box which is only the \cite{key} command.

Then there is the list of the default possible BiBTeX bibliography
styles (again, not natbib) itemised here:

   http://www.cs.stir.ac.uk/~kjt/software/latex/showbst.html


-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd

Re: Question about citation processors [wip-cite branch]

[Bruce D'Arcus]

On Tue, May 4, 2021 at 11:26 AM Joost Kremers  wrote:

> In order to get ... parentheses around the locator, you need to use 
> \pnotecite:
> ...
> \notecite gives the locator without parentheses.

Ah, right then.

I updated the wiki table with that.

This is an example where sub-styles could be helpful.

Bruce

Re: Question about citation processors [wip-cite branch]

[Joost Kremers]

On Tue, May 04 2021, Bruce D'Arcus wrote:
> On Tue, May 4, 2021 at 10:47 AM Joost Kremers  
> wrote:
>
>> I can add some comments regarding biblatex:
>>
>> - default: \parencite[1]
>
> WDYT of \autocite for default?
>
> It's conceptually the same as the CSL default.

If that is the case then it's probably the better choice. The biblatex manual
states that \autocite requires that the citation style defines a command for it
and that it is not appropriate for author-year style citations. I assume that's
something for the user to be aware of when using such citations?

-- 
Joost Kremers
Life has its moments

Re: Question about citation processors [wip-cite branch]

[Joost Kremers]

On Tue, May 04 2021, Bruce D'Arcus wrote:
> One other little thing:
>
> On Tue, May 4, 2021 at 10:47 AM Joost Kremers  
> wrote:
>
>> - locators: \notecite[3]
>
> Are you sure about this?

Well, no, I hadn't tried it... I did mention there were variants, though. ;-)

> Here's the use case:
>
> https://github.com/jgm/pandoc/issues/7205

In order to get:

```
According to Jones (1998) , “students often had difficulty using APA
style, especially when it was their first time” (p. 199).
```

i.e., with parentheses around the locator, you need to use \pnotecite:

```
According to \textcite[]{Jones1998} , ``students often had difficulty using APA
style, especially when it was their first time'' \pnotecite[][199]{Jones1998}.
```

\notecite gives the locator without parentheses.

-- 
Joost Kremers
Life has its moments

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

I'm attaching the tentative style/command and shortcut mapping I came
up with, with help from Eric and Joost.

HTH.

I do have \autocite as default for biblatex. Joost can weigh in if he
thinks this is a problem.

Bruce


org-cite-styles.org
Description: Binary data

Re: Question about citation processors [wip-cite branch]

[Bruce D'Arcus]

One other little thing:

On Tue, May 4, 2021 at 10:47 AM Joost Kremers  wrote:

> - locators: \notecite[3]

Are you sure about this?

Here's the use case:

https://github.com/jgm/pandoc/issues/7205

Bruce

Re: Question about citation processors [wip-cite branch]

[Bruce D'Arcus]

On Tue, May 4, 2021 at 10:47 AM Joost Kremers  wrote:

> I can add some comments regarding biblatex:
>
> - default: \parencite[1]

WDYT of \autocite for default?

It's conceptually the same as the CSL default.

> - text: \textcite
> - author: \citeauthor[2]
> - title: \citetitle[2]
> - year: \citeyear[2]
> - locators: \notecite[3]
> - nocite: \nocite

I will add these to the markdown, and include an org version of it to
the list when it is done-ish.

Thanks!

> Biblatex of course has a wealth of citation commands, most with variants of
> different kinds. Not sure if that's relevant right now.

Yes, why I like Nicolas' idea to allow sub-styles.

[cite/text/bar:@doe]

Bruce

[PATCH] Use cache in org-up-heading-safe

[Ihor Radchenko]

Hello,

While testing another patch for agenda fontification, I noticed that
agenda can spend up to half!! time doing org-up-heading-safe. Mostly
inside queries for inherited tags and properties.

I managed to make org-up-heading-safe up to 50x faster using position
cache.

If this patch also works for others, org-agenda-use-tag-inheritance
might become much less of an issue.

Benchmark:

1. (elp-instrument-function #'org-up-heading-safe)
2. Run agenda
3. (elp-results) ;; function, # calls, total time, avg time

Without cache:
org-up-heading-safe  27555   8.4234025759  0.0003056941

With cache, first run:
org-up-heading-safe  23227   0.5300747539  2.282...e-05

With cache, second run on unchanged buffer:
org-up-heading-safe  23227   0.1447754880  6.233...e-06

Best,
Ihor

>From fe1e7094a7b76ba6bf282c5c4409a32b36827d56 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Tue, 4 May 2021 22:55:14 +0800
Subject: [PATCH] Use cache in org-up-heading-safe

* lisp/org.el (org-up-heading-safe): Use buffer-local cache to store
positions of parent headings.  The cache is invalidated when buffer
text is changed, according to `buffer-chars-modified-tick'.
(org--up-heading-cache):  Buffer-local hash-table storing the cache.
(org--up-heading-cache-tick):  The buffer modification state for
currently active `org--up-heading-cache'.

The optimisation is critical when running agenda or org-entry-get
queries using property/tag inheritance.  In such scenarios
`org-up-heading-safe' can be called thousands of times.  For example,
building todo agenda on large number of headings lead to the following
benchmark results:

Benchmark:

1. (elp-instrument-function #'org-up-heading-safe)
2. Run agenda
3. (elp-results) ;; function, # calls, total time, avg time

Without cache:
org-up-heading-safe  27555   8.4234025759  0.0003056941

With cache, first run:
org-up-heading-safe  23227   0.5300747539  2.282...e-05

With cache, second run on unchanged buffer:
org-up-heading-safe  23227   0.1447754880  6.233...e-06

The final speedup is 1-2 orders of magnitude (~15-56 times).
---
 lisp/org.el | 43 +++
 1 file changed, 39 insertions(+), 4 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index b8678359f..4385903ee 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19434,6 +19434,10 @@ (defun org-up-heading-all (arg)
 With argument, move up ARG levels."
   (outline-up-heading arg t))
 
+(defvar-local org--up-heading-cache (make-hash-table)
+  "Buffer-local `org-up-heading-safe' cache.")
+(defvar-local org--up-heading-cache-tick nil
+  "Buffer `buffer-chars-modified-tick' in `org--up-heading-cache'.")
 (defun org-up-heading-safe ()
   "Move to the heading line of which the present line is a subheading.
 This version will not throw an error.  It will return the level of the
@@ -19443,10 +19447,41 @@ (defun org-up-heading-safe ()
 because it relies on stars being the outline starters.  This can really
 make a significant difference in outlines with very many siblings."
   (when (ignore-errors (org-back-to-heading t))
-(let ((level-up (1- (funcall outline-level
-  (and (> level-up 0)
-	   (re-search-backward (format "^\\*\\{1,%d\\} " level-up) nil t)
-	   (funcall outline-level)
+(let ((level-cache (gethash (point) org--up-heading-cache)))
+  (if (and level-cache
+   (eq (buffer-chars-modified-tick) org--up-heading-cache-tick))
+  (when (<= (point-min) level-cache (point-max))
+;; Parent is inside accessible part of the buffer.
+(progn (goto-char level-cache)
+   (funcall outline-level)))
+;; Buffer modified.  Invalidate cache.
+(when level-cache
+  (clrhash org--up-heading-cache)
+  (setq-local org--up-heading-cache-tick
+  (buffer-chars-modified-tick)))
+(let ((level-up (1- (funcall outline-level)))
+  (pos (point)))
+  (let (result)
+(setq result
+  (and (> level-up 0)
+	   (re-search-backward
+(format "^\\*\\{1,%d\\} " level-up) nil t)
+	   (funcall outline-level)))
+(when result
+  (puthash pos (point) org--up-heading-cache
+;; (defun org-up-heading-safe ()
+;;   "Move to the heading line of which the present line is a subheading.
+;; This version will not throw an error.  It will return the level of the
+;; headline found, or nil if no higher level is found.
+
+;; Also, this function will be a lot faster than `outline-up-heading',
+;; because it relies on stars being the outline starters.  This can really
+;; make a significant difference in outlines with very many siblings."
+;;   (when (ignore-errors (org-back-to-heading t))
+;; (let ((level-up (1- (funcall outline-level
+;;   (and (> level-up 0)
+;; 	   (re-search-backward (format "^\\*\\{1,%d\\} " level-up) nil t)
+;; 	   (funcall 

Re: prettify-symbols-mode in org agenda?

[Ihor Radchenko]

Ihor Radchenko  writes:

> Bastien  writes:
>> Could it slow down agenda generation for some configurations?

> The total slowdown is ~30%, though the second part will only be slow
> before the headings are fontified first time by
> org-buffer-substring-fontified. Subsequent agenda rebuilds will be
> faster.

I have updated the code to avoid creating temporary org buffers. Now, I
got 8% slowdown during first agenda run. The slowdown diminishes as the
headlines contributing to agenda get fontified (i.e. for all next
org-agenda-redo).

> Please move the comments after the change log themselves.

Done.

> Here and for the rest of the patch: please try to keep lines below 80
> characters.  I'm aware this is not always feasible, especially given
> long functions with many nested s-exps, but let's try to come as close
> as possible to 80.

Done.

William Xu  writes:
> The only issue I still see, is that when you org-agenda-redo-all, or
> org-agenda-log-mode (which triggers org-agenda-redo-all), the
> prettify gets lost again. Maybe org-buffer-substring-fontified call is
> also required somewhere during org-agenda-redo-all? 

I managed to reproduce it. This time, I went through all the agenda.el
and updated places where the strings are fetched from Org buffers into
agenda. The updated patch is attached.

Best,
Ihor

>From 8a6f629669772ff4561180ace320eb0a6365969f Mon Sep 17 00:00:00 2001
Message-Id: <8a6f629669772ff4561180ace320eb0a6365969f.1620134057.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Tue, 4 May 2021 20:33:10 +0800
Subject: [PATCH] Make sure that fontification is preserved in agenda

* lisp/org-macs.el (org-string-width): Refactor old code and add
optional argument to return pixel width.  The old code used manual
parsing of text properties to find which parts of string are visible.
The new code defers this work to Emacs display engine via
`window-text-pixel-size'.  The visibility settings of current buffer
are taken into account.

(org--string-from-props): Removed.  It was only used by old
`org-string-width' code.

(org-buffer-substring-fontified): New function. Like
`buffer-substring', but make sure that the substring is fontified.

(org-looking-at-fontified): New function.  Like `looking-at', but make
sure that the match is fontified.

* lisp/org.el (org-get-heading): Make sure that heading is fontified.

(org--get-local-tags, org-get-tags): Add optional argument
`fontified'.  When non-nil, the returned tags are fontified.

* lisp/org-agenda.el (org-agenda-get-todos, org-agenda-get-progress,
org-agenda-get-deadlines, org-agenda-get-scheduled,
org-agenda-fix-displayed-tags, org-search-view, org-agenda-get-todos,
org-agenda-get-timestamps, org-agenda-get-sexps,
org-agenda-get-deadlines, org-agenda-get-progress,
org-agenda-get-blocks): Make sure that fontification is the same with
original Org buffers.

(org-agenda-highlight-todo): Preserve composition property used,
i.e. by `prettify-symbols-mode'.  The composition is usually set to be
removed on text change, so we do the changes inside
`with-silent-modifications'.

(org-agenda-align-tags): Use pixel width and (space . :align-to)
'display property to align tags in agenda.

Preserve fontification and composition of headlines and tags in
agenda.  If the headlines/tags are not yet fontified when building
agenda, make sure that they are fontified in the original Org mode
buffers first.

In addition, tags alignment is now done pixel-wise to avoid alignment
issues with variable-pitch symbols that may appear in fontified Org
mode buffers.  The alignment is utilising :align-to specification,
which means that the alignment will be automatically updated as the
agenda buffer is resized.
---
 lisp/org-agenda.el |  92 ++-
 lisp/org-macs.el   | 134 +++--
 lisp/org.el|  24 +---
 3 files changed, 138 insertions(+), 112 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 4c34ca5fe..420579ecf 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3984,7 +3984,7 @@ (defun org-agenda-finalize ()
 		  (put-text-property (point-at-bol) (point-at-eol)
  'tags
  (org-with-point-at mrk
-   (org-get-tags
+   (org-get-tags nil nil t
 	(setq org-agenda-represented-tags nil
 	  org-agenda-represented-categories nil)
 	(when org-agenda-top-headline-filter
@@ -4778,10 +4778,11 @@ (defun org-search-view ( todo-only string edit-at)
   (and (eq org-agenda-show-inherited-tags t)
    (or (eq org-agenda-use-tag-inheritance t)
 	   (memq 'todo org-agenda-use-tag-inheritance
-			  tags (org-get-tags nil (not inherited-tags))
+			  tags (org-get-tags
+nil (not inherited-tags) t)
 			  txt (org-agenda-format-item
    ""
-   (buffer-substring-no-properties
+   (org-buffer-substring-fontified
 beg1 (point-at-eol))
    level category tags t))

Re: Question about citation processors [wip-cite branch]

[Joost Kremers]

On Tue, May 04 2021, Bruce D'Arcus wrote:
> On Tue, May 4, 2021 at 9:27 AM Joost Kremers  wrote:
>
>> - A user should be able to insert citations into an Org document. IIUC 
>> nothing
>>   in org-cite provides any functionality for this, right? Is there a default
>>   list of styles a user would expect to be supported, or does this depend
>> solely
>>   on the bibliography style one uses?
>
> I'll just comment on this Joost.

Thanks. :-)

> Correct on your first question.

ACK

> As for your second, that's what the activity today is about. TBD, but
> it seems there's some good ideas on that.
>
> I tried to put this together into this wiki page, because doing it on
> an email list is hard.
>
> https://github.com/bdarcus/bibtex-actions/wiki/Org-cite

I can add some comments regarding biblatex:

- default: \parencite[1]
- text: \textcite
- author: \citeauthor[2] 
- title: \citetitle[2]
- year: \citeyear[2]
- locators: \notecite[3]
- nocite: \nocite

Biblatex of course has a wealth of citation commands, most with variants of
different kinds. Not sure if that's relevant right now.

HTH

Joost



Footnotes:
[1] Note that biblatex also has \cite, which produces a citation without
 parentheses. But the natbib column has \citep here, so \parencite seems
 appropriate.

[2]  The biblatex manual states that this does not do "citation tracking",
 though what this implies is not clear to me.

[3]  There are variants \pnotecite and \fnotecite for parenthetical and
 footnote citations, respectively.

-- 
Joost Kremers
Life has its moments

Re: Question about citation processors [wip-cite branch]

[Bruce D'Arcus]

On Tue, May 4, 2021 at 9:27 AM Joost Kremers  wrote:

> - A user should be able to insert citations into an Org document. IIUC nothing
>   in org-cite provides any functionality for this, right? Is there a default
>   list of styles a user would expect to be supported, or does this depend 
> solely
>   on the bibliography style one uses?

I'll just comment on this Joost.

Correct on your first question.

As for your second, that's what the activity today is about. TBD, but
it seems there's some good ideas on that.

I tried to put this together into this wiki page, because doing it on
an email list is hard.

https://github.com/bdarcus/bibtex-actions/wiki/Org-cite

Bruce

Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export

[Timothy]

Hello,

Nicolas Goaziou  writes:

>> Should one want to convert LaTeX images say to an SVG for HTML export, I
>> do not think one would want this behaviour to also apply to LaTeX being
>> exported to markdown.
>
> Why do you think so? This is consistent with everything else not
> supported by vanilla Markdown.

To speak personally, at the moment I use mathjax for HTML. I'm quite
content with the markdown output from this patch without what's
discussed below.
However, if/when I can get the SVG baseline to work with dvisvgm I plan
on switching to that for HTML files. However, I'd consider this
behaviour undesirable for markdown.

The main reason why I'm hesitant about including s in Markdown, is
because unlike  etc. the output now relies on external files.

>> As such I see two 'sensible' paths forward: (1) just include LaTeX
>> verbatim when :with-latex is non-nil, or (2) introduce
>> `org-markdown-with-latex' which can be set to t/'verbatim or 'html.
>>
> Obeying to :with-latex property means "ox-md" is somehow actively
> handling LaTeX fragments, which was not the initial intent, IIUC. The
> first idea was to provide a sensible default for such objects, because
> we're outside the specification anyway. I'd rather not overdo it.

I'm happy to strip this out of the patch (there's always advice for my
own config...), I just thought there may be people who like me are
interested in s for LaTeX in HTML, but not in Markdown.

--
Timothy

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

Sorry, just to be crytal clear ...

On Tue, May 4, 2021 at 9:21 AM Bruce D'Arcus  wrote:

> > It is possible to include sub-styles, e.g.,
>
> I agree it would be better to allow variants ...

I should have written "sub-styles"; as in, I agree with Nicolas.

Also agree on shortcuts, which I've started to add to my table as well.

Bruce

Question about citation processors [wip-cite branch]

[Joost Kremers]

Hi list,

As the maintainer of Ebib, I have of course been following the threads on
citation support for Org with some interest. I have not been able to follow
every detail, however, in part probably due to my limited experience with CSL
and citeproc. (I use biblatex myself.)

Now I find myself with some specific questions that I cannot find an answer to.
(Possibly because I'm just daft enough to overlook them in the e-mails Nicolas
sent, but in that case feel free to point this out.)

So, on the assumption that there are Org users out there that may want to use
Ebib to manage their citations, what would Ebib need to do in order to be a good
citizen?

- A user should be able to insert citations into an Org document. IIUC nothing
  in org-cite provides any functionality for this, right? Is there a default
  list of styles a user would expect to be supported, or does this depend solely
  on the bibliography style one uses?

- =:active= just means "font-lock", right?

- Since I don't plan on writing an exporter, I assume that it is possible to
  mix and match processors? Say, have one for the =:follow= property, another
  for =:activate= and a third one for =:export-*=?

- What kind of data structure do the =:follow= and =:activate= functions take?
  Should I just look at =oc-basic.el= or is this written down somewhere?

- Is there a function or buffer-local variable that gives me a list of all the
  bibliography files of a buffer? Related to that: if a user has set
  =org-cite-global-bibliography= and also provides a =#+bibliography= keyword,
  are both sources used, or only the keyword?

Thanks for any and all comments!

-- 
Joost Kremers
Life has its moments

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

On Tue, May 4, 2021 at 9:15 AM Nicolas Goaziou  wrote:

> Also, what styles (including shortcuts if necessary) names could we
> chose? Asterisk is not allowed in the citation style (but that could
> change, if necessary).

I'll let the bibtex folks speak to that perspective, but ...

> E.g.,
>
>   "parens" or "p" -> citep

... in the start of my mapping table, I suggest this as default. This
may be a CSL bias though.

>   "text" or "t" -> citet (default?)
>   "pf" or "parens-full" -> citep*
>
> What about alt, alp, alt*, alt*, and all Cite variants?
>
> It is possible to include sub-styles, e.g.,

I agree it would be better to allow variants, because it would make it
easier to have the top level consistent among export processors (and
therefore better for users in the end), without ending up with long
lists of style names that only apply to, say, biblatex.

Bruce

Re: Notes about citations in Org (part 3)

[Nicolas Goaziou]

Eric S Fraga  writes:

> On Tuesday,  4 May 2021 at 07:58, Bruce D'Arcus wrote:
>> Perhaps the bibtex/biblatex folks can help with those details?
>
> For natbib, there is a good summary at
>
> http://merkel.texture.rocks/Latex/natbib.php

Thanks.

Naive question: it doesn't say how to print the references, how is it
done?

Also, what styles (including shortcuts if necessary) names could we
chose? Asterisk is not allowed in the citation style (but that could
change, if necessary).

E.g.,

  "parens" or "p" -> citep
  "text" or "t" -> citet (default?)
  "pf" or "parens-full" -> citep*

What about alt, alp, alt*, alt*, and all Cite variants?

It is possible to include sub-styles, e.g.,

 [cite/alt/caps:...] could be equivalent to [cite/caps/alt:...] and
 would return \Citealt{}

Naming is hard (and boring ;). Suggestions welcome.


Regards,

Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export

[Nicolas Goaziou]

Hello,

Timothy  writes:

> Should one want to convert LaTeX images say to an SVG for HTML export, I
> do not think one would want this behaviour to also apply to LaTeX being
> exported to markdown.

Why do you think so? This is consistent with everything else not
supported by vanilla Markdown.

> As such I see two 'sensible' paths forward: (1) just include LaTeX
> verbatim when :with-latex is non-nil, or (2) introduce
> `org-markdown-with-latex' which can be set to t/'verbatim or 'html.
>
> In the attached patch, I've taken the first approach. Let me know if
> you'd like to take the second approach, or just inherit the HTML
> behaviour for LaTeX after all.

Obeying to :with-latex property means "ox-md" is somehow actively
handling LaTeX fragments, which was not the initial intent, IIUC. The
first idea was to provide a sensible default for such objects, because
we're outside the specification anyway. I'd rather not overdo it.

WDYT?

Regards,
-- 
Nicolas Goaziou

Re: Notes about citations in Org (part 3)

[Eric S Fraga]

On Tuesday,  4 May 2021 at 07:58, Bruce D'Arcus wrote:
> Perhaps the bibtex/biblatex folks can help with those details?

For natbib, there is a good summary at

http://merkel.texture.rocks/Latex/natbib.php

I only ever typically use "Author (year)" (\citet{key}) and "(Author,
year)" (\citep{key}) in most of my writing, i.e. my use case is very
simple compared with many here.  For some journals, the citing style
will be numeric, typically a superscript but sometimes "[1]" with
bibliography sorted by order of appearance.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd

Re: Notes about citations in Org (part 3)

[Eric S Fraga]

On Tuesday,  4 May 2021 at 06:11, Bruce D'Arcus wrote:
> It should be trivial to map this to latex; cite/text -> \citet and such.

Indeed.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd

Re: Notes about citations in Org (part 3)

[Eric S Fraga]

On Tuesday,  4 May 2021 at 12:10, Joost Kremers wrote:
> Pedantic nit-pick: they *should* be expecting and using biblatex. (But
> perhaps that is what you meant already. :-) )

Well, luckily, in my field most of the journals allow submissions in
LaTeX and provide style files.  The bibliography is usually the contents
as generated by BiBTeX inserted directly into the LaTeX file.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

On Tue, May 4, 2021 at 6:48 AM Bruce D'Arcus  wrote:

> It seems like those interested in this could collaborate on a table of
> style/command mappings for the above export processors.
>
> Anyone interested in working on this?
>
> If yes, how/where?

I added a wiki page on the bibtex-actions site here:

https://github.com/bdarcus/bibtex-actions/wiki/Org-cite

Perhaps the bibtex/biblatex folks can help with those details?

Bruce

Re: About multilingual documents

[autofrettage]

Hi,

I must confess I haven't followed all the nooks and crannies of this subject, 
but when I browsed through the latest batch of contributions, I noticed that 
one simple (=crude) workaround hasn't been mentioned; Indirect buffers.

If one uses one indirect buffer per language, it should be possible to select a 
separate flyspell language for each buffer. Jumping between buffers/windows is 
perhaps less of a hassle than constantly switching spell checking languages.

I suspect the ambitions of the general list member is higher than that, but 
this workaround could ease the pain for some of us.

Cheers
Rasmus

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Hi Victor,

"Victor A. Stoichita"  writes:

> Le 03 May 2021, Bastien  a écrit :
>> I suggest a criterium for keeping ob*.el files in Org could be that
>> the extension is known by Emacs _or_ that the supported language is
>> well-established.
>
> I happen to be an active user of ob-lilypond. Lilypond is certainly
> peripheral to the world of programming languages. It is well established
> and active as an equivalent of LaTeX for music though ([1][2][3]).
> It comes with built-in support for Emacs [4].

Agreed, thanks for the references!

> I see no reason to not move ob-lilypond to org-contrib. I understand
> that only few of us use it these days. I can’t stand up as a maintainer
> since my Lisp skills and my knowledge of org-mode are quite insufficient
> for that. I was happy to see that someone submitted a patch for
> ob-lilypond in January. I hope that by the time something breaks I’ll be
> able to submit a patch myself.

I hope too.

PS: Also, in general, we are not talking about shutting down a
feature: ob-*.el packages in org-contrib.git continue to be available.

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Hi,

"Dr. Arne Babenhauserheide"  writes:

> Lilypond is not just well-established, it is the dominant tool for note
> engraving. One of the few domains in which no proprietary comes close in
> terms of quality.
>
> I typically use it directly, but if the maintenance burden is
> manageable, I could offer maintenance here, too (once I have the papers
> in place).

Thanks also for this then!

> Having support in core directly helps a lot when using the tool, because
> that enables working zero-setup org-files (with some load-language in an
> elisp block).

... which is good if the package is really maintained, and calling for
trouble if it is not.  Anyway, I agree with you about the importance
of ob-lilypond.el.

Best,

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Hi,

"Dr. Arne Babenhauserheide"  writes:

> This is well-established, and once I have my paperwork in place I would
> offer maintenance, because this is a major part of the lectures I write
> in org-mode.

Thanks for volunteering here.  Let me know when the paperwork is done
so that I can you as the maintainer.

Best,

-- 
 Bastien

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

On Tue, May 4, 2021 at 2:47 AM Nicolas Goaziou  wrote:

> "Bruce D'Arcus"  writes:

> > And if the processor is citeproc-org, where does one put the "foo.csl"
> > style?
>
> That may be orthogonal. If you use a given "foo.csl", does it still make
> sense to provide styles to print_bibliography keywords and citations?
>
> If that's the case, the citeproc style file could be introduced with
> a oc-citeproc specific keyword.

Yes, that probably makes sense.

András can figure that it out in any case.

Bruce

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

On Tue, May 4, 2021 at 6:29 AM Nicolas Goaziou  wrote:

> The branch provides an API to develop citation processors. The goal is
> not to ultimately use "oc-basic.el", but to activate more specialized
> processors, like, for example "oc-citeproc.el", but also
> "oc-biblatex.el" or "oc-natbib.el", depending on your requirements.
> Those are not implemented yet, however.
>
> You can help, for example, by providing a list of style that you would
> like to be provided by hypothetical (at this point) "oc-natbib.el" (or
> another one), with the desired LaTeX output in different cases:

It seems like those interested in this could collaborate on a table of
style/command mappings for the above export processors.

Anyone interested in working on this?

If yes, how/where?

I did add an issue to the citeproc-org repo, but it's aimed at that
processor, and we really need a wiki or something to do this.

https://github.com/andras-simonyi/citeproc-org/issues/16

Bruce

Re: Checkboxes in headings - opinions wanted

[Arthur Miller]

Ihor Radchenko  writes:

> Arthur Miller  writes:
>> ... Example can be seen in attached screenshot from
>> my init file where I use org headings to form a list of packages to
>> install, and checkboxes to indicate if a package configuration is used
>> or not. 
>
> Depending on details of your workflow, you might also use
> org-toggle-comment for indication of configuration usage. As a bonus, if
Actually I am thinking of re-purposing TODO for "pin to repository"
purpose, so that is why I needed a more general checkbox independent of
TODO states. I am using planning on using tags for some other stuff.

> you use literate config, commenting the heading will also disable
> tangling for that heading.
>
I don't use tangling
from org-mode, I tangle all code myself. I have written a small
optimizer so I am generating actual init file from the literal config,
it is a small application in org-mode. You can see hacked TODO (per
file) in "Generator" section below the ";; og hacks" comment of
init.org, if you are interested.

https://github.com/amno1/.emacs.d

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Dr. Arne Babenhauserheide]

Bastien  writes:

> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:
>
> - ob-ditaa.el --- Babel Functions for ditaa

This is well-established, and once I have my paperwork in place I would
offer maintenance, because this is a major part of the lectures I write
in org-mode.

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


signature.asc
Description: PGP signature

Re: Notes about citations in Org (part 3)

[Denis Maier]

Am 04.05.2021 um 12:10 schrieb Joost Kremers:


On Tue, May 04 2021, Eric S Fraga wrote:

Question for the longer term: for LaTeX export, I will be wanting to
have the [cite:] constructs export to BiBTeX code.  Will this be
possible in due course?  For other targets (ODT, HTML), what has been
done in this branch is fantastic but, for LaTeX, publishers will expect
BiBTeX.


Pedantic nit-pick: they *should* be expecting and using biblatex. (But perhaps
that is what you meant already. :-) )


But they most likely won't, or has that changed in recent years?

Denis

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Dr. Arne Babenhauserheide]

Victor A. Stoichita  writes:

> Le 03 May 2021, Bastien  a écrit :
>> I suggest a criterium for keeping ob*.el files in Org could be that
>> the extension is known by Emacs _or_ that the supported language is
>> well-established.
>
> I happen to be an active user of ob-lilypond. Lilypond is certainly
> peripheral to the world of programming languages. It is well established
> and active as an equivalent of LaTeX for music though ([1][2][3]).
> It comes with built-in support for Emacs [4].

Lilypond is not just well-established, it is the dominant tool for note
engraving. One of the few domains in which no proprietary comes close in
terms of quality.

I typically use it directly, but if the maintenance burden is
manageable, I could offer maintenance here, too (once I have the papers
in place).

Having support in core directly helps a lot when using the tool, because
that enables working zero-setup org-files (with some load-language in an
elisp block).

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


signature.asc
Description: PGP signature

Re: Notes about citations in Org (part 3)

[Nicolas Goaziou]

Hello,

Eric S Fraga  writes:

> Question for the longer term: for LaTeX export, I will be wanting to
> have the [cite:] constructs export to BiBTeX code.  Will this be
> possible in due course?  For other targets (ODT, HTML), what has been
> done in this branch is fantastic but, for LaTeX, publishers will expect
> BiBTeX.

The branch provides an API to develop citation processors. The goal is
not to ultimately use "oc-basic.el", but to activate more specialized
processors, like, for example "oc-citeproc.el", but also
"oc-biblatex.el" or "oc-natbib.el", depending on your requirements.
Those are not implemented yet, however.

You can help, for example, by providing a list of style that you would
like to be provided by hypothetical (at this point) "oc-natbib.el" (or
another one), with the desired LaTeX output in different cases:

  [cite:@key] => ???
  [cite:prefix @key suffix] => ???
  [cite:global; prefix @key1; @key2; suffix] => ???

Ditto for "print_bibliography" keywords. I think you get the idea.

Regards,
-- 
Nicolas Goaziou

Re: Notes about citations in Org (part 3)

[Bruce D'Arcus]

On Tue, May 4, 2021, 5:51 AM Eric S Fraga  wrote:

> On Tuesday,  4 May 2021 at 11:33, Nicolas Goaziou wrote:
> > Done.
>
> Thank you.  Seems to work just fine.
>
> Question for the longer term: for LaTeX export, I will be wanting to
> have the [cite:] constructs export to BiBTeX code.  Will this be
> possible in due course?


It should be trivial to map this to latex; cite/text -> \citet and such.

I agree it makes sense to include.

Bruce

Re: Notes about citations in Org (part 3)

[Joost Kremers]

On Tue, May 04 2021, Eric S Fraga wrote:
> Question for the longer term: for LaTeX export, I will be wanting to
> have the [cite:] constructs export to BiBTeX code.  Will this be
> possible in due course?  For other targets (ODT, HTML), what has been
> done in this branch is fantastic but, for LaTeX, publishers will expect
> BiBTeX.

Pedantic nit-pick: they *should* be expecting and using biblatex. (But perhaps
that is what you meant already. :-) )

-- 
Joost Kremers
Life has its moments

Re: Notes about citations in Org (part 3)

[Eric S Fraga]

On Tuesday,  4 May 2021 at 11:33, Nicolas Goaziou wrote:
> Done.

Thank you.  Seems to work just fine.

Question for the longer term: for LaTeX export, I will be wanting to
have the [cite:] constructs export to BiBTeX code.  Will this be
possible in due course?  For other targets (ODT, HTML), what has been
done in this branch is fantastic but, for LaTeX, publishers will expect
BiBTeX.

Thanks again,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd

Re: Input methods [was: Re: About multilingual documents]

[Eric S Fraga]

On Tuesday,  4 May 2021 at 10:29, Joost Kremers wrote:
> It's not really an input method, more like the lack of one. You're probably
> using =set-input-method= to change input methods? Check out
> =toggle-input-method=. :-)

Ah, interesting.  A lack of input method.  Kind of non-obvious.  But the
documentation for toggle-input-method explains it perfectly.

Thank you!

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-480-g479a3d

Re: Notes about citations in Org (part 3)

[Nicolas Goaziou]

Nicolas Goaziou  writes:

> Oops. I'll fix it in a few hours. I need to treat LaTeX-derived
> back-ends specially in the context of BibTeX files. 
>
> I'll let you know when it's done.

Done.

Re: About multilingual documents

[Aleksandar Dimitrov]

Hi Juan,

> Thank you very much for your interesting comments. I think your idea of
> applying org-babel to (multi) language support is tremendously
> suggestive and, of course, more org-centric. I suppose it could be
> applied also to languages within the paragraph by inline blocks... I
> really liked what you propose.
>
> Well, I admit that my marks are a bit exotic :-D. The main problem I see
> is that they are not as robust as Org's own marks, since they are
> controlled by an export filter. Doing some further tests, by the way, I
> think it would be better to add the filter to
> `org-export-filter-plain-text-functions', instead of
> `...final-output-functions'. I also see that it would be convenient to
> avoid their expansion in verbatim texts, with a `(unless
> (org-in-verbatim-emphasis)...)'.

What I like about =org-edit-special= is that it gives you a dedicated
little environment in a different language (either natural, or
programming language!) This allows me to focus on the task of editing it
really easily.

I must admit that I find the inline org-src notation (of which I didn't
know yet) somewhat jarring, and certainly less pleasant to read. Perhaps
we could use a similar mechanism to =org-hide-emphasis-markers= to make
it more pleasant to read. [1]

> Anyway, I think (in general terms) it would be interesting for Org to
> incorporate some multilingual support and the ability to toggle between
> languages in a document, and the idea you propose seems to
> me that it makes a lot of sense.

I definitely agree that Org would benefit from more multilingual
support. I'm not very experienced in emacs-lisp but would love to contribute.

One problem I foresee is the translation of locales into LaTeX macros
for either (LaTeX)-Babel or Polyglossia (which is what I use.) So a
string like "en" or "en_UK" (which is readily understood by
([ai]|hun)spell) would have to be translated to the necessary
macros. For example for Polyglossia [2] the preamble would read

\setdefaultlanguage[variant=uk]{english}

And then the inline commands would have to be rendered as
\textenglish{…} or \textlang{english}{…} (probably the latter would be easier.)

I forgot what it is for LaTeX-Babel.

Note that the HTML export backend, too, could (or should) support
declaring multiple languages. [3]

There's a lot of work in there, but I would say that any implementation
effort should focus on one thing first. That could be switching the
dictionary on org-edit-special if a :lang-variable is set, or it could
be re-using what you, Juan, already wrote for LaTeX-Babel
exports. Support for Polyglossia or HTML could come at a later time.

Cheers,
Aleks

[1] 
https://stackoverflow.com/questions/20309842/how-to-syntax-highlight-for-org-mode-inline-source-code-src-lang/28059832#28059832
[2] 
https://ftp.rrze.uni-erlangen.de/ctan/macros/unicodetex/latex/polyglossia/polyglossia.pdf
[3] https://www.w3.org/International/questions/qa-html-language-declarations


>
> Best regards,
>
> Juan Manuel 
>
> Aleksandar Dimitrov writes:
>
>> Hi Juan,
>>
>> this sounds very interesting to me, as I, too, mostly write in Org
>> and, sometimes write documents in multiple languages, usually with
>> different varieties of either Latin or Cyrillic.
>>
>> I have some suggestions:
>>
>> Apart from the export, one of my biggest gripes is
>> flyspell. Specifically, the fact that you have to choose one language to
>> spell check the entire document with. That is insufficient in my case.
>>
>> I think that the syntax you're suggesting looks good, but I'm not
>> sure how well it'd fit into org-mode's ecosystem. I had something in
>> mind that was closer to how org-babel works (it's called *babel*
>> for a reason, isn't it? :D)
>>
>> #+begin_src org :lang pl
>>   … po polsku
>> #+end_src
>>
>> #+begin_src org :lang de
>>   … auf deutsch
>> #+end_src
>>
>>
>> This would make use of org-mode's edit special environment function. It
>> would make it easier to persuade flyspell to do the right thing. You
>> could, perhaps, add
>>
>> #+LANGUAGE: en
>>
>> to the parent document, and then org would take care to set the correct
>> flyspell language (and the correct macros on LaTeX-export) and change
>> these parameters in the special environments.
>>
>> I'm not 100% sure it should be #+begin_src org, maybe introducing a
>> different special environment would be better, say #+begin_lang XX where
>> XX is the ISO-code of said language, or the locale (think en_US
>> vs. en_GB.)
>>
>> The drawback, and the clear disadvantage compared to your method is that
>> this works great only when the languages are separated by paragraph
>> breaks.
>>
>> Therefore, I think our suggestions might be somewhat orthogonal. Yours
>> could be a shorthand syntax for introducing inline foreign-language
>> snippets.
>>
>> What do you think?
>>
>> Regards,
>> Aleks
>>
>> Juan Manuel Macías writes:
>>
>>> Hi all,
>>>
>>> I'm curious to see how other Org users deal with multilingual documents,
>>> that is, 

Input methods [was: Re: About multilingual documents]

[Joost Kremers]

On Tue, May 04 2021, Eric S Fraga wrote:
> So, on this note, without hopefully hijacking the thread, maybe somebody
> can tell me: what is the "default" input method, i.e. the one I get when
> I start Emacs and haven't changed input methods at all?  I see no way to
> get back to it once I have switched to a different one.

It's not really an input method, more like the lack of one. You're probably
using =set-input-method= to change input methods? Check out
=toggle-input-method=. :-)

-- 
Joost Kremers
Life has its moments

Re: About multilingual documents

[Eric S Fraga]

On Monday,  3 May 2021 at 20:47, Greg Minshall wrote:
> but, for me (maybe i'm missing something?) it means i switch input
> methods.  

Which is what I do.

So, on this note, without hopefully hijacking the thread, maybe somebody
can tell me: what is the "default" input method, i.e. the one I get when
I start Emacs and haven't changed input methods at all?  I see no way to
get back to it once I have switched to a different one.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-480-g479a3d

Re: About multilingual documents

[Aleksandar Dimitrov]

> I like Aleksandar's solution quite a bit because it also works inline
> e.g. as src_org[:lang de]{Meine deutsch ist zher schlect!}. In
> principle this means that you could leverage the org-babel and org-src
> buffer system to get flyspell results in that language in line as well
> (though I don't think transporting overlays into the original buffer
> has been implemented). Best!

Oh wow, I'm learning lots of new things today, including inline-babel in
Org. I'm not sure highlighting typos in src-blocks is necessary. I think
it's enough if you can see them while you're editing the block.

Re: About multilingual documents

[Aleksandar Dimitrov]

Hi Joost

> [Not directly related to the OP, but might be useful to know.]
>
> On Mon, May 03 2021, Aleksandar Dimitrov wrote:
>> this sounds very interesting to me, as I, too, mostly write in Org
>> and, sometimes write documents in multiple languages, usually with
>> different varieties of either Latin or Cyrillic.
> [...]
>> Apart from the export, one of my biggest gripes is
>> flyspell. Specifically, the fact that you have to choose one language to
>> spell check the entire document with. That is insufficient in my case.
>
> flyspell is basically just ispell, and ispell can be configured with different
> backends. One possible backend is hunspell, which allows you to set multiple
> dictionaries. So if you regularly use different languages in a buffer, you
> should give hunspell a try.
>
> [...]
>> The drawback, and the clear disadvantage compared to your method is that
>> this works great only when the languages are separated by paragraph
>> breaks.
>
> If that is the case, you could also check out the =guess-language= package:
> . It tries to detect the
> language of the current paragraph and sets the ispell (and hence flyspell)
> dictionary accordingly. I use it because I write in three different languages,
> but usually don't mix them in one buffer.

Thanks for your hints! =guess-language= seems really cool! I also didn't
know hunspell supported more than one dictionary.

Thanks!
Aleks

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Eric S Fraga]

On Tuesday,  4 May 2021 at 01:49, Timothy wrote:
> For the future, I'd think Julia actually warrants 1st class inclusion in
> Org, and I've instigated an effort to write an ob-julia that works well.

+1!  Happy to help test if you wish.  I use Julia as my programming
language these days.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-480-g479a3d

Re: Notes about citations in Org (part 3)

[Eric S Fraga]

On Monday,  3 May 2021 at 09:58, Bruce D'Arcus wrote:
>> 2. the suppressed author case does not seem to work.
>
> He removed the suppress author variant on the individual cited items,
> so I think the same effect he means to achieve with the "year" style.

Makes sense.  Thank you.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-480-g479a3d

Re: Notes about citations in Org (part 3)

[Eric S Fraga]

On Monday,  3 May 2021 at 18:48, Nicolas Goaziou wrote:
> I don't know how to do that cleanly. However, I think this is already
> too smart a feature for "basic" back-end. So, I'd like to punt on this
> one.

Point taken.  Reasonable approach.  Thank you.
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-480-g479a3d

Re: About multilingual documents

[Aleksandar Dimitrov]

Hi Greg,

>> Apart from the export, one of my biggest gripes is
>> flyspell. Specifically, the fact that you have to choose one language to
>> spell check the entire document with. That is insufficient in my case.
>
> in case it's relevant:
>
> i also switch between languages.  but, for me (maybe i'm missing
> something?) it means i switch input methods.  so, i've code bound to
> (toggle-input-method) that, depending on the input method, changes the
> dictionary "for" that input method.  this is not org-specific, but,
> rather, works for all my emacs buffers.

I don't usually switch input methods. Instead I rely on the X-Server's
facilities, including group toggles and XCompose. For example I use
XCompose to write all languages with a Latin alphabet without having to
switch layouts/input methods.

Cheers,
Aleks

Re: Notes about citations in Org (part 3)

[Denis Maier]

Hi,

Am 04.05.2021 um 08:47 schrieb Nicolas Goaziou:

Hello,

"Bruce D'Arcus"  writes:


On Mon, May 3, 2021 at 12:42 PM Nicolas Goaziou  wrote:


Anyway, I suggest to let it nil, and select it at the document level
instead, with

   #+cite_export: basic bibstyle citestyle


What is the significance of the last two items?


These are the default styles used for bibliography and citations, in the
sense of Org "styles", i.e.,

   [cite/citestyle:...]
   #+print_bibliography: bibstyle


In a CSL implementation like citeproc-el, both are defined in a single
style.

Are they defined separately in other systems?


IIUC, you can combine different bibliography and citation styles in
LaTeX. Maybe some LaTeX users could confirm this.

Yes, that's true for biblatex.

Denis

Re: Notes about citations in Org (part 3)

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> On Mon, May 3, 2021 at 12:42 PM Nicolas Goaziou  
> wrote:
>
>> Anyway, I suggest to let it nil, and select it at the document level
>> instead, with
>>
>>   #+cite_export: basic bibstyle citestyle
>
> What is the significance of the last two items?

These are the default styles used for bibliography and citations, in the
sense of Org "styles", i.e.,

  [cite/citestyle:...]
  #+print_bibliography: bibstyle

> In a CSL implementation like citeproc-el, both are defined in a single
> style.
>
> Are they defined separately in other systems?

IIUC, you can combine different bibliography and citation styles in
LaTeX. Maybe some LaTeX users could confirm this.

> And if the processor is citeproc-org, where does one put the "foo.csl"
> style?

That may be orthogonal. If you use a given "foo.csl", does it still make
sense to provide styles to print_bibliography keywords and citations?

If that's the case, the citeproc style file could be introduced with
a oc-citeproc specific keyword.

Regards,
-- 
Nicolas Goaziou

Re: Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

[Bastien]

Hi Gustavo,

Gustavo Barros  writes:

> some time ago, I've reported an issue regarding duplicity of the default 
> candidate in `org-refile' 
> (https://orgmode.org/list/87lftw1k2n@gmail.com/).  The problem was 
> that, when using `org-refile-use-outline-path' an "extra" slash was 
> appended at the end of every path, but candidates were stored in 
> `org-refile-history' without that extra slash.  Bastien took care of 
> that and indeed changed things so as to pass the elements to 
> `org-refile-history' with the trailing slash as appropriate.
>
> At the time, I reported a difference of behavior between 
> `completing-read-default' and `ivy-completing-read' after the mentioned 
> commit by Bastien.  But the issue did not appear for Bastien, which does 
> not use Ivy, and I also was not able to diagnose the problem properly. 
> I felt I didn't have enough to offer as to insist, so I resorted to an 
> old hack of mine.  But the new release this week (thank you very much!, 
> btw) has bitten me again on this, so I went back to some digging, and 
> hopefully I can do a better job this time in diagnosing the problem and 
> suggesting a fix.

Bump this thread so that it appears on updates.orgmode.org.

Thanks,

-- 
 Bastien