Re: [PATCH] Have C-c C-c recognise #+plot lines

[Bastien]

Hi Eric,

Eric S Fraga  writes:

> On Monday, 26 Apr 2021 at 17:11, Timothy wrote:
>> Since you don't seem to have pushed yet, here's an updated patche that
>> takes into account Nicolas' comments.
>
> Oh, and to clarify: I don't have push access; I can only do testing but
> not installation!

If you need push access for areas you want to maintain, just let us
know.  Thanks!

Re: Bug: [PATCH] define-minor-mode: prefer keyword args [9.4.5 (9.4.5-ga02a3b @ /home/n/.emacs.d/straight/build/org-plus-contrib/)]

[Bastien]

Hi Kyle,

Kyle Meyer  writes:

> Bastien writes:
>
>> Hi,
>>
>> thanks for the patch, we do indeed need to move forward for this.
>>
>> Could you propose the patch against the master branch (not the maint
>> branch, since this is not a bugfix) and perhaps fix *all* warnings?
>
> Thanks, but these were already taken care of by 8c29cbdef (Backport
> commit c45bfd3c4 from Emacs, 2021-04-18), which was merged into master
> with 664b65344.

Er, my bad - I'm marking this "bug" as "fixed" then.

Re: Bug: org-plot gives Invalid function error

[Ihor Radchenko]

Timothy  writes:

> That's why the reset command is run:
> https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-plot.el#L560

Sorry, I missed that. It should indeed make things much less likely to
break. One exception is when plot depends on settings defined in
.gnuplot file. reset command clears user customisations in .gnuplot.

Of course, the described bug may be related to something else.
[after some testing...]
Of course, it is:

> plot '/tmp/org-plotiPs0To' using 1:3 with histograms title 'H-index'

This is not valid gnuplot command to create histograms. One needs to use:

plot '/tmp/org-plotiPs0To' using 3:tics(1) with histograms title 'H-index'

Best,
Ihor

Re: On using to-do lists efficiently

[Ihor Radchenko]

Bastien  writes:

> Slightly offtopic but I sat down this week-end trying to grasp with
> very few words what I learned on how to use to-do lists efficiently
> over the years, and here it is:

I am wondering if we can incorporate such or similar tips into Org mode
manual. Similar to Elisp manual section info:elisp#tips, Org mode may
introduce recommended usage of Agenda, TODO-lists, and other major Org
mode components.

Similar idea was also discussed in
https://orgmode.org/list/x9e%2ffv%2f9hd4bl...@protected.rcdrun.com/ 

> I'm curious if this resonates with your experience.

I have very similar experience, though I have several subtle comments on
some points you raise.

> Write less to-do items and more notes.

Having less TODO items is really helpful. At some point, I found myself
cherry-picking tasks that are easy to do, but not important in place of
tasks that I really needed to do. Moving "wish to" tasks away from
visibility really helps to focus as the size of todo-lists grows to
thousands of tasks.

Yet, I found it helpful to have few "wish to" notes as actual tasks. When
you want to take a short break or have some free time it is handy to
have some "light" task within reach. Otherwise, social media tends to
fill all the free time slots.
I have a setup to quickly move groups of "wish to" tasks between notes
and tasks depending on my workload.

> Your to-do list should be a list of things to do, not to remember

While I generally agree with this, removing things to remember from
visibility most often results in forgetting them, especially as the
number remember notes grows to thousands. Thousands of notes are hard to
review regularly. I find it useful to bring such notes to my attention
from time to time using spaced repetition.

> don't mix notes and tasks

I agree with one exception - notes on literature/articles. For my work,
I need to deal with a lot of reading. It is common that some book may
need to be read multiple times looking for different kinds of
information. Having common summary notes right in the "reading" task is
quite helpful to get started, especially if the previous reading time
was months ago.

> Write precise, concise, atomic tasks

This is a great suggestion. Vague tasks tends to be ignored or
postponed. Having a very concrete action as a task makes it easy to do.
Yet, assigning concrete action to some tasks may itself take significant
time, especially for complex tasks requiring some research. For such
tasks, I often add one simple action required to get started on the
task. This does not require spending much time on planning each step to
complete the task, yet making complex tasks look less intimidating.

Best,
Ihor

Re: Bug: org-plot gives Invalid function error

[Timothy]

Ihor Radchenko  writes:

> ob-gnuplot does not refresh gnuplot session.
>
> A quick look through org-plot code shows that gnuplot session is also
> preserved:

That's why the reset command is run:
https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-plot.el#L560

>From the docs:
>  The reset command causes all graph-related options that can be set
>  with the set command to take on their default values. This command is
>  useful, e.g., to restore the default graph settings at the end of a
>  command file, or to return to a defined state after lots of settings
>  have been changed within a command file. Please refer to the set
>  command to see the default values that the various options take.
>
> The following set commands do not change the graph status and are thus
> left unchanged: the terminal set with set term, the output file set
> with set output and directory paths set with set loadpath and set
> fontpath.

Wouldn't this be sufficient?

--
Timothy

Re: Bug: org-plot gives Invalid function error

[Ihor Radchenko]

Timothy  writes:

> From a quick test myself, this appears reproducible, though I have no
> idea what's going on (yet). Please let me know if you find anything.

I remember seeing similar gnuplot errors using ob-gnuplot. They tend to
disappear upon restarting gnuplot process (M-x gnuplot-kill-gunplot-buffer),
probably because ob-gnuplot does not refresh gnuplot session.

A quick look through org-plot code shows that gnuplot session is also
preserved:

(when (get-buffer "*gnuplot*") ; reset *gnuplot* if it already running
  (with-current-buffer "*gnuplot*"
(goto-char (point-max

So, I suspect that the problem I encountered may also be relevant in
org-plot.

Hope it helps.

Best,
Ihor

Re: [PATCH] org-manual.org: Fix syntax

[Kyle Meyer]

Cheong Yiu Fung writes:

> Subject: [PATCH] org-manual.org: Fix syntax
>
> * doc/org-manual.org (HTML export commands): Fix kbd representation

Thanks.  Pushed (58cacdf0e), adding a period after "representation".

[PATCH] org-manual.org: Fix syntax

[Cheong Yiu Fung]

Hi, 

Here's a tiny syntax fix in org manual.

YiufungFrom 2b63acfdb9f48fd48bce180f4894ed89b3910fe3 Mon Sep 17 00:00:00 2001
From: Cheong Yiu Fung 
Date: Tue, 27 Apr 2021 10:10:14 +0800
Subject: [PATCH] org-manual.org: Fix syntax

* doc/org-manual.org (HTML export commands): Fix kbd representation

TINYCHANGE
---
 doc/org-manual.org | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 16dd4a52f..6d1a47637 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12600,7 +12600,7 @@ compatible with XHTML 1.0 strict standard.
   #+findex: org-html-export-to-html
 
   Export as HTML file with a =.html= extension.  For =myfile.org=, Org
-  exports to =myfile.html=, overwriting without warning.  {{{kbd{C-c
+  exports to =myfile.html=, overwriting without warning.  {{{kbd(C-c
   C-e h o)}}} exports to HTML and opens it in a web browser.
 
 - {{{kbd(C-c C-e h H)}}} (~org-html-export-as-html~) ::
-- 
2.31.1

Re: Bug: [PATCH] define-minor-mode: prefer keyword args [9.4.5 (9.4.5-ga02a3b @ /home/n/.emacs.d/straight/build/org-plus-contrib/)]

[Kyle Meyer]

Bastien writes:

> Hi,
>
> thanks for the patch, we do indeed need to move forward for this.
>
> Could you propose the patch against the master branch (not the maint
> branch, since this is not a bugfix) and perhaps fix *all* warnings?

Thanks, but these were already taken care of by 8c29cbdef (Backport
commit c45bfd3c4 from Emacs, 2021-04-18), which was merged into master
with 664b65344.

Re: (Not so) Short note about citations in Org

[Denis Maier]

 
 
  
   
  
  
   
Nicolas Goaziou  hat am 26.04.2021 23:11 geschrieben:
   
   

   
   

   
   
Denis Maier  writes:
   
   

   
   

 No, I was not talking about having multiple input files, but about


 having multiple bibliographies in the output doc.


 Perhaps each filtered in some way:

   
   

 #+print_bibliography: [style] [filter1]


 #+print_bibliography: [style] [filter2]

   
   

 Obviously, filter1 and filter2 must be defined somewhere. The use case


 would be something along these lines:


 - One bibliography with all the works by author X, a second


 bibliography with everything else.


 - One bibliography with books, the other with webpages

   
   
It is already possible to write multiple "print_bibliography" keywords
   
   
(even though some citation systems, like biblatex, do not support it,
   
   
IIUC). However their value is limited to style at the moment.
   
  
  
   Great, so the basic functionality is there. (by the way, biblatex is the only system that really supports multiple bibliographies.)
   
  
  
   
   
It may be possible to send anything past the style string (i.e.,
   
   
starting after the first space) to the processor, as a sixth (!)
   
   
argument, and let it deal with it.
   
   
  
  
   Ok. I've discussed this with John MacFarlane from Pandoc some time ago. IIRC, he said there are two different approaches to that problem: either do the filtering in the processor, or just let the processor return a structure that contains the necessary information and do the filtering itself in the backend.
   
  
  
   
  
  
   Denis
   
  
  
   
--
   
   
Nicolas Goaziou
   
  
 

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Eric S Fraga]

On Monday, 26 Apr 2021 at 17:11, Timothy wrote:
> Since you don't seem to have pushed yet, here's an updated patche that
> takes into account Nicolas' comments.

Oh, and to clarify: I don't have push access; I can only do testing but
not installation!

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-337-g29d4cc.dirty

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Eric S Fraga]

On Monday, 26 Apr 2021 at 17:11, Timothy wrote:
> Since you don't seem to have pushed yet, here's an updated patche that
> takes into account Nicolas' comments.

Thank you.  I've incorporated that patch and will test out tomorrow.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-337-g29d4cc.dirty

Re: (Not so) Short note about citations in Org

[Joost Kremers]

On Mon, Apr 26 2021, Denis Maier wrote:
> No, I was not talking about having multiple input files, but about having
> multiple bibliographies in the output doc.
> Perhaps each filtered in some way:
>
> #+print_bibliography: [style] [filter1]
> #+print_bibliography: [style] [filter2]
>
> Obviously, filter1 and filter2 must be defined somewhere. The use case would 
> be
> something along these lines:
> - One bibliography with all the works by author X, a second bibliography with
>  everything else.
> - One bibliography with books, the other with webpages

Another use case would be a book in which each chapter has its own bibliography.

A quick synopsis of the biblatex way:

https://texblog.org/2012/10/22/multiple-bibliographies-with-biblatex/


-- 
Joost Kremers
Life has its moments

Re: (Not so) Short note about citations in Org

[Nicolas Goaziou]

Denis Maier  writes:

> No, I was not talking about having multiple input files, but about
> having multiple bibliographies in the output doc.
> Perhaps each filtered in some way:
>
> #+print_bibliography: [style] [filter1]
> #+print_bibliography: [style] [filter2]
>
> Obviously, filter1 and filter2 must be defined somewhere. The use case
> would be something along these lines:
> - One bibliography with all the works by author X, a second
>   bibliography with everything else.
> - One bibliography with books, the other with webpages

It is already possible to write multiple "print_bibliography" keywords
(even though some citation systems, like biblatex, do not support it,
IIUC). However their value is limited to style at the moment.

It may be possible to send anything past the style string (i.e.,
starting after the first space) to the processor, as a sixth (!)
argument, and let it deal with it.

-- 
Nicolas Goaziou

Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]

[Anthony Carrico]

I've trimmed the CC's, and condensed my answers to the various threads 
below:


To Bastien: You are doing a good job respecting the code. Thank you.

The original implementation flip-flops between cached and normal classes 
(six statements removed in the original patch), whereas my clone adds 
and removes a class name from the classList (three statements inserted 
in the original patch). I did intend to make a material change which 
would create a new public domain implementation of the original API. I 
did not intended to disrespect Carsten's work or to detract from it, and 
I apologize to anyone who did not consider it to be a good-faith 
gesture. I did honestly believe that the org-mode code base would 
welcome a public domain clone of the script functionality to resolve the 
issue at hand.


To the other participants in the thread: To answer your questions, I 
have been around for the evolution of the FSF, the Open Source movement, 
and the Creative Commons. I did follow Lawrence Lessig's creation of 
CC0. I do understand its role. I have Richard Stallman's book on my 
shelf signed "Happy Hacking, Richard Stallman", and I understand that 
emacs is his baby. Next are Jessica Litman's and Clay Shirky's, and I 
also own Lawrence Lessig's and Siva Vaidhyanathan's (missing, 
somewhere...). I did attend Richard Stallman's lecture at Saint 
Michael's College, as well as Siva V.'s lecture at Middlebury College. I 
value the contributions of all these philosophers.


I have attempted to look for solutions that would solve both bug reports 
(license insertion + LibreJS incompatibility) without advocating or 
offering opinions on the broader philosophical issues. I hope my 
technical contributions are valued, even if they are not accepted.


I did offer an opinion on license insertion: My opinion is that 
org-export is a means to save an org-mode file in html format, and that 
org-mode authors don't view their documents as derivative works of the 
org-export markup. I still believe inserting a license into exported 
documents is a mistake.


The FSF encourages authors to choose an approved license for their work, 
but my impression is that the FSF is also anxious to avoid the notion 
that their products will do so unintentionally. There is a danger that 
such an impression would erode their market share, and therefore their 
ability to advocate for their mission. This stance is apparent in the 
FSF signalling around project pairs like GCC/LLVM, etc., and I imagine 
it would apply to equally to emacs, so I think it would be wise to fix 
both issues if possible.


Bastien: You certainly have my permission to use my 
CodeHighlightOn/CodeHighlightOff implementation as you see fit, 
including licensing it under the GPLv3+, and that is a reasonable choice 
for you to make. If you happen to agree with the notion that the 
org-export output should be license-free, and you want to avoid using a 
clone of these functions, a third option would be to remove the script 
in question: The functionality is pretty unusual for a document to 
trigger, and might not be missed in exchange for a javascript-free 
export, but I yield to your ultimate decision.


Thank you
--
Anthony Carrico

Re: (Not so) Short note about citations in Org

[Denis Maier]

Am 26.04.2021 um 22:33 schrieb Nicolas Goaziou:

Denis Maier  writes:


Oh, and what do you think regarding the multiple bibliographies
question?

As far as Org is concerned, you can have multiple "bibliography"
keywords, e.g.,

   #+bibliography: file1.bib
   #+bibliography: file2.bib

Internally, the bibliography is stored as a list of absolute file names.

Is that what you have in mind or are you talking about something else?

Regards,
No, I was not talking about having multiple input files, but about 
having multiple bibliographies in the output doc.

Perhaps each filtered in some way:

#+print_bibliography: [style] [filter1]
#+print_bibliography: [style] [filter2]

Obviously, filter1 and filter2 must be defined somewhere. The use case 
would be something along these lines:
- One bibliography with all the works by author X, a second bibliography 
with everything else.

- One bibliography with books, the other with webpages

Denis

Re: wip-cite status question and feedback

[Denis Maier]

Am 26.04.2021 um 16:54 schrieb Bruce D'Arcus:

I had an idea on this, though it may not be a good one ...

On Sat, Apr 24, 2021 at 2:39 PM Bruce D'Arcus  wrote:


On Sat, Apr 24, 2021 at 1:47 PM Nicolas Goaziou  wrote:


Hello,

"Bruce D'Arcus"  writes:


Some sentence with a concluding citation [cite:@key].

... that should end up like this:

Some sentence with a concluding citation.[1]

Aside: looking through the CSL spec, it doesn't seem this is
documented. It obviously should be.

And I don't remember if that convention is locale-specific; e.g. if
while that's the standard in English, it could be different in France.

In any case, this sort of punctuation modification should be possible.


Could you show more example of this, possibly including quotes the
citation, or better, a precise description of the punctuation
modification you have in mind?


Yes.

Denis lays it out in this comment:

https://github.com/citation-style-language/documentation/issues/139#issuecomment-825934813

What he's arguing is that the rules vary by locale, with German, for
example (he's employed at a Swiss-German institution, I believe),
having different conventions than English, and American English
different than British English.

But an example from American English for illustration, derived from
Denis' examples.

"A simple quote" [cite:@doe].

When rendered, that should be this in an author-date style:

"A simple quote" (Doe 2021).

... and this in a note style:

"A simple quote."[^1]

So that rule would suggest something like:

- if a citation concludes a sentence, move the note mark and whatever
trailing quotation mark, outside the period.

But, Denis continues, "While this is perfectly acceptable in American
English, it is not in German, or even in British English. Here we have
to know whether the final period is part of the original quotation. If
yes, it will be put inside the quotes, otherwise outside." I'll paste
the rest of his examples at the end.

It's possible his rule here is more general, and would still be
acceptable in American English.


The idea is this: make use of a "quote" style and abuse the item
prefix for the quote content?

So using his example:

[cite/quote:;A simple quote. @doe20]

A processor could then know the citation is associated with a quote
that ends a sentence, vs (note missing period):

[cite/quote:;A simple quote @doe20]

... and then more easily adjust accordingly, without needing to know
anything about the surrounding punctuation.

Does that make sense?


Reminds me a bit of how the latex csquotes package works, which is often 
used together with biblatex, it even was developped by the original 
biblatex author before he mysteriously disappeared about a decade ago.


In addition to simple commands like \enquote{something} that simply 
render the argument in quotes this package also has more complex 
commands such as \textcquote or blockcquote. With these commands you can 
combine a quotation with a citation:
\textcquote[〈prenote〉][〈postnote〉]{〈key〉}[〈punct〉]{〈text〉} 
〈tpunct〉


\textcquote[45]{doe}[.]{This is the quotation}
Note the punctuation of the original quote is included in a special 
argument in brackets.

If the period weren't part of the quotation, you'd simply do:
\textcquote[45]{doe}{This is the quotation}.

Regarding the proposal: I think that could go in the right direction, 
but in the current form it has the downside that you can't use the 
prefix anymore, right? What about keeping this separate, like so:


[quote: A simple quote.][cite: @doe p. 45]

But maybe even that is not necessary, and there might be simpler ways.

WDYT?

Denis

Re: (Not so) Short note about citations in Org

[Nicolas Goaziou]

Denis Maier  writes:

> Oh, and what do you think regarding the multiple bibliographies
> question?

As far as Org is concerned, you can have multiple "bibliography"
keywords, e.g.,

  #+bibliography: file1.bib
  #+bibliography: file2.bib

Internally, the bibliography is stored as a list of absolute file names.

Is that what you have in mind or are you talking about something else?

Regards,

inconsistency: closed-down and friends not allowed in sorting strategy

[Samuel Wales]

recent maint.

for some reason org agenda sorting strategy allows scheduled and
deadline but not closed.  seems inconsistent.

thanks.

-- 
The Kafka Pandemic

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

Re: (Not so) Short note about citations in Org

[Denis Maier]

Oh, and what do you think regarding the multiple bibliographies question?

Denis

Am 26.04.2021 um 22:02 schrieb Nicolas Goaziou:

Hello,

"Bruce D'Arcus"  writes:


On this, on the other (big) wip-cite thread, Nicolas said the following:

"A drawback with allowing emphasis there is that prefix and suffix become
parsed data and not plain string anymore. As a consequence, searching
through them, e.g., when looking for locator names, requires an
additional level of indirection, since you need to first transform
parsed data back into plain text."

Nicolas: I get that you need more code to do this, but are there other
practical consequences of allowing more than plain-text?


The code I need to write does not count, really. It is 10 locs at most,
without the tests.

My concern is the additional burden for processor developers. They will
need to shift from one representation to the other, this is not
convenient. Also some tasks then become an order of magnitude harder.

For example, let's consider the suffix: " p.32 and following" If it is
plain text, I can recognize p.32 as a locator, and replace it with "page
32" using something like `replace-regexp-in-string'.

Now, if it is a somewhat opaque parsed string, I need to first expand
it, for example with `org-element-interpret-data', modify the output as
above, and then parse it again to get a new parsed string.

I can no longer (concat "(" prefix author "," year suffix ")") either,
because prefix and suffix are not strings anymore. I need to

   (format "(%s%s, %s%s)"
   (org-export-data prefix info)
   (org-export-data author info)
   year;I assume year cannot contain problematic characters
   (org-export-data suffix info))

So, nothing impossible, but still slightly inconvenient.

Regards,

Re: (Not so) Short note about citations in Org

[Denis Maier]

Am 26.04.2021 um 22:02 schrieb Nicolas Goaziou:

Hello,

"Bruce D'Arcus"  writes:


On this, on the other (big) wip-cite thread, Nicolas said the following:

"A drawback with allowing emphasis there is that prefix and suffix become
parsed data and not plain string anymore. As a consequence, searching
through them, e.g., when looking for locator names, requires an
additional level of indirection, since you need to first transform
parsed data back into plain text."

Nicolas: I get that you need more code to do this, but are there other
practical consequences of allowing more than plain-text?


The code I need to write does not count, really. It is 10 locs at most,
without the tests.

My concern is the additional burden for processor developers. They will
need to shift from one representation to the other, this is not
convenient. Also some tasks then become an order of magnitude harder.


While I cannot speak for the processor developers, I still want to throw 
in that at least the major CSL processors do handle formatting in 
affixes in one way or the other. The Haskell citeproc that is used by 
pandoc treats the suffixes as markdown, citeproc-js uses some sort of 
HTML-like tags for things like italics, bold, sub-/superscript, and a 
few more things.




For example, let's consider the suffix: " p.32 and following" If it is
plain text, I can recognize p.32 as a locator, and replace it with "page
32" using something like `replace-regexp-in-string'.

Now, if it is a somewhat opaque parsed string, I need to first expand
it, for example with `org-element-interpret-data', modify the output as
above, and then parse it again to get a new parsed string.

I can no longer (concat "(" prefix author "," year suffix ")") either,
because prefix and suffix are not strings anymore. I need to

   (format "(%s%s, %s%s)"
   (org-export-data prefix info)
   (org-export-data author info)
   year;I assume year cannot contain problematic characters
   (org-export-data suffix info))

So, nothing impossible, but still slightly inconvenient.



If it isn't impossible I'd be strongly in favor of adding this. I'm 
pretty sure authors will miss it otherwises.


Denis

Re: (Not so) Short note about citations in Org

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> On this, on the other (big) wip-cite thread, Nicolas said the following:
>
> "A drawback with allowing emphasis there is that prefix and suffix become
> parsed data and not plain string anymore. As a consequence, searching
> through them, e.g., when looking for locator names, requires an
> additional level of indirection, since you need to first transform
> parsed data back into plain text."
>
> Nicolas: I get that you need more code to do this, but are there other
> practical consequences of allowing more than plain-text?

The code I need to write does not count, really. It is 10 locs at most,
without the tests. 

My concern is the additional burden for processor developers. They will
need to shift from one representation to the other, this is not
convenient. Also some tasks then become an order of magnitude harder.

For example, let's consider the suffix: " p.32 and following" If it is
plain text, I can recognize p.32 as a locator, and replace it with "page
32" using something like `replace-regexp-in-string'.

Now, if it is a somewhat opaque parsed string, I need to first expand
it, for example with `org-element-interpret-data', modify the output as
above, and then parse it again to get a new parsed string.

I can no longer (concat "(" prefix author "," year suffix ")") either,
because prefix and suffix are not strings anymore. I need to

  (format "(%s%s, %s%s)"
  (org-export-data prefix info)
  (org-export-data author info)
  year;I assume year cannot contain problematic characters
  (org-export-data suffix info))

So, nothing impossible, but still slightly inconvenient.

Regards,
-- 
Nicolas Goaziou

Re: Bug: table header line mode misaligned in org-indent-mode

[Bastien]

Hi Oorja,

thanks a lot for reporting this.  I fixed this with commit 058339d6e
in the maint branch, it will be in the next bugfix version.

Re: (Not so) Short note about citations in Org

[Bruce D'Arcus]

On Sun, Apr 25, 2021 at 5:20 PM Denis Maier  wrote:
>
> Hi everyone,
>
> great to see that there's been so much progress since this issue has
> last been discussed! Looks really impressive so far.
>
> Two comments/questions:
>
> - I think it should be possible to use some markup in prefixes and suffixes.

On this, on the other (big) wip-cite thread, Nicolas said the following:

"A drawback with allowing emphasis there is that prefix and suffix become
parsed data and not plain string anymore. As a consequence, searching
through them, e.g., when looking for locator names, requires an
additional level of indirection, since you need to first transform
parsed data back into plain text."

Nicolas: I get that you need more code to do this, but are there other
practical consequences of allowing more than plain-text?

Bruce

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Eric S Fraga]

On Monday, 26 Apr 2021 at 16:24, Timothy wrote:
> A while ago Eric raised two nice suggestions. (2) has just been
> implemented as Bastien reminded me that I can now just push straight to
> Org for org-plot.el without going through a patch-review process.
>
> This patch resolves (1).

Timothy,

I've updated org and applied the patch.  Both aspects seem to work just
fine.  I haven't done much testing, however, as it's beer time...  I'll
update tomorrow should I run into any strange behaviour.

thank you,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-335-gac3148.dirty

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Timothy]

... I didn't regenerate the patch after amending the commit.

:big sigh: Take 4

>From 4e5fcb4726711ff356656cb6fccf6e341656443d Mon Sep 17 00:00:00 2001
From: TEC 
Date: Tue, 27 Apr 2021 00:05:37 +0800
Subject: [PATCH] org: Enable plotting with C-c C-c

* lisp/org.el (org-ctrl-c-ctrl-c): When at a table, check if the current
line starts with "#+plot", and if so call `org-plot/gnuplot'.
As I think 4-deep nested if statements are bad for readability, I
refactored the nested if statements to use `cond' while I was at it.
---
 lisp/org.el | 41 +++--
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 3f9c9a284..94ef9660d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17693,24 +17693,29 @@ (defun org-ctrl-c-ctrl-c ( arg)
 	 ;; send the table if necessary.  If the table has
 	 ;; a `table.el' type, just give up.  At a table row or cell,
 	 ;; maybe recalculate line but always align table.
-	 (if (eq (org-element-property :type context) 'table.el)
-	 (message "%s" (substitute-command-keys "\\\
-Use `\\[org-edit-special]' to edit table.el tables"))
-	   (if (or (eq type 'table)
-		   ;; Check if point is at a TBLFM line.
-		   (and (eq type 'table-row)
-			(= (point) (org-element-property :end context
-	   (save-excursion
-		 (if (org-at-TBLFM-p)
-		 (progn (require 'org-table)
-			(org-table-calc-current-TBLFM))
-		   (goto-char (org-element-property :contents-begin context))
-		   (org-call-with-arg 'org-table-recalculate (or arg t))
-		   (orgtbl-send-table 'maybe)))
-	 (org-table-maybe-eval-formula)
-	 (cond (arg (call-interactively #'org-table-recalculate))
-		   ((org-table-maybe-recalculate-line))
-		   (t (org-table-align))
+ (cond
+  ((and (< (point) (org-element-property :post-affiliated context))
+(org-match-line "[ \t]*#\\+plot:"))
+   (org-plot/gnuplot))
+  ((eq (org-element-property :type context) 'table.el)
+   (message "%s" (substitute-command-keys "\\\
+Use `\\[org-edit-special]' to edit table.el tables")))
+  ((or (eq type 'table)
+   ;; Check if point is at a TBLFM line.
+   (and (eq type 'table-row)
+(= (point) (org-element-property :end context
+   (save-excursion
+ (if (org-at-TBLFM-p)
+ (progn (require 'org-table)
+(org-table-calc-current-TBLFM))
+   (goto-char (org-element-property :contents-begin context))
+   (org-call-with-arg 'org-table-recalculate (or arg t))
+   (orgtbl-send-table 'maybe
+  (t
+   (org-table-maybe-eval-formula)
+   (cond (arg (call-interactively #'org-table-recalculate))
+ ((org-table-maybe-recalculate-line))
+ (t (org-table-align))
 	((or `timestamp (and `planning (guard (org-at-timestamp-p 'lax
 	 (org-timestamp-change 0 'day))
 	((and `nil (guard (org-at-heading-p)))
-- 
2.31.1


Sorry for the noise,

Timothy

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Timothy]

Timothy  writes:

> Since you don't seem to have pushed yet, here's an updated patch that
> takes into account Nicolas' comments.

... and that patch didn't take into account the need to escape "+" in
the regex.
Take 3.

>From 4e5fcb4726711ff356656cb6fccf6e341656443d Mon Sep 17 00:00:00 2001
From: TEC 
Date: Tue, 27 Apr 2021 00:05:37 +0800
Subject: [PATCH] org: Enable plotting with C-c C-c

* lisp/org.el (org-ctrl-c-ctrl-c): When at a table, check if the current
line starts with "#+plot", and if so call `org-plot/gnuplot'.
As I think 4-deep nested if statements are bad for readability, I
refactored the nested if statements to use `cond' while I was at it.
---
 lisp/org.el | 41 +++--
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 3f9c9a284..94ef9660d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17693,24 +17693,29 @@ (defun org-ctrl-c-ctrl-c ( arg)
 	 ;; send the table if necessary.  If the table has
 	 ;; a `table.el' type, just give up.  At a table row or cell,
 	 ;; maybe recalculate line but always align table.
-	 (if (eq (org-element-property :type context) 'table.el)
-	 (message "%s" (substitute-command-keys "\\\
-Use `\\[org-edit-special]' to edit table.el tables"))
-	   (if (or (eq type 'table)
-		   ;; Check if point is at a TBLFM line.
-		   (and (eq type 'table-row)
-			(= (point) (org-element-property :end context
-	   (save-excursion
-		 (if (org-at-TBLFM-p)
-		 (progn (require 'org-table)
-			(org-table-calc-current-TBLFM))
-		   (goto-char (org-element-property :contents-begin context))
-		   (org-call-with-arg 'org-table-recalculate (or arg t))
-		   (orgtbl-send-table 'maybe)))
-	 (org-table-maybe-eval-formula)
-	 (cond (arg (call-interactively #'org-table-recalculate))
-		   ((org-table-maybe-recalculate-line))
-		   (t (org-table-align))
+ (cond
+  ((and (< (point) (org-element-property :post-affiliated context))
+(org-match-line "[ \t]*#\\+plot:"))
+   (org-plot/gnuplot))
+  ((eq (org-element-property :type context) 'table.el)
+   (message "%s" (substitute-command-keys "\\\
+Use `\\[org-edit-special]' to edit table.el tables")))
+  ((or (eq type 'table)
+   ;; Check if point is at a TBLFM line.
+   (and (eq type 'table-row)
+(= (point) (org-element-property :end context
+   (save-excursion
+ (if (org-at-TBLFM-p)
+ (progn (require 'org-table)
+(org-table-calc-current-TBLFM))
+   (goto-char (org-element-property :contents-begin context))
+   (org-call-with-arg 'org-table-recalculate (or arg t))
+   (orgtbl-send-table 'maybe
+  (t
+   (org-table-maybe-eval-formula)
+   (cond (arg (call-interactively #'org-table-recalculate))
+ ((org-table-maybe-recalculate-line))
+ (t (org-table-align))
 	((or `timestamp (and `planning (guard (org-at-timestamp-p 'lax
 	 (org-timestamp-change 0 'day))
 	((and `nil (guard (org-at-heading-p)))
-- 
2.31.1

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Timothy]

Since you don't seem to have pushed yet, here's an updated patche that
takes into account Nicolas' comments.

>From 04270b64315fed399748509f1c09428557b7742d Mon Sep 17 00:00:00 2001
From: TEC 
Date: Tue, 27 Apr 2021 00:05:37 +0800
Subject: [PATCH] org: Enable plotting with C-c C-c

* lisp/org.el (org-ctrl-c-ctrl-c): When at a table, check if the current
line starts with "#+plot", and if so call `org-plot/gnuplot'.
As I think 4-deep nested if statements are bad for readability, I
refactored the nested if statements to use `cond' while I was at it.
---
 lisp/org.el | 41 +++--
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 3f9c9a284..c4e2e132f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17693,24 +17693,29 @@ (defun org-ctrl-c-ctrl-c ( arg)
 	 ;; send the table if necessary.  If the table has
 	 ;; a `table.el' type, just give up.  At a table row or cell,
 	 ;; maybe recalculate line but always align table.
-	 (if (eq (org-element-property :type context) 'table.el)
-	 (message "%s" (substitute-command-keys "\\\
-Use `\\[org-edit-special]' to edit table.el tables"))
-	   (if (or (eq type 'table)
-		   ;; Check if point is at a TBLFM line.
-		   (and (eq type 'table-row)
-			(= (point) (org-element-property :end context
-	   (save-excursion
-		 (if (org-at-TBLFM-p)
-		 (progn (require 'org-table)
-			(org-table-calc-current-TBLFM))
-		   (goto-char (org-element-property :contents-begin context))
-		   (org-call-with-arg 'org-table-recalculate (or arg t))
-		   (orgtbl-send-table 'maybe)))
-	 (org-table-maybe-eval-formula)
-	 (cond (arg (call-interactively #'org-table-recalculate))
-		   ((org-table-maybe-recalculate-line))
-		   (t (org-table-align))
+ (cond
+  ((and (< (point) (org-element-property :post-affiliated context))
+(org-match-line "[ \t]*#+plot:"))
+   (org-plot/gnuplot))
+  ((eq (org-element-property :type context) 'table.el)
+   (message "%s" (substitute-command-keys "\\\
+Use `\\[org-edit-special]' to edit table.el tables")))
+  ((or (eq type 'table)
+   ;; Check if point is at a TBLFM line.
+   (and (eq type 'table-row)
+(= (point) (org-element-property :end context
+   (save-excursion
+ (if (org-at-TBLFM-p)
+ (progn (require 'org-table)
+(org-table-calc-current-TBLFM))
+   (goto-char (org-element-property :contents-begin context))
+   (org-call-with-arg 'org-table-recalculate (or arg t))
+   (orgtbl-send-table 'maybe
+  (t
+   (org-table-maybe-eval-formula)
+   (cond (arg (call-interactively #'org-table-recalculate))
+ ((org-table-maybe-recalculate-line))
+ (t (org-table-align))
 	((or `timestamp (and `planning (guard (org-at-timestamp-p 'lax
 	 (org-timestamp-change 0 'day))
 	((and `nil (guard (org-at-heading-p)))
-- 
2.31.1


Eric S Fraga  writes:

> On Monday, 26 Apr 2021 at 16:24, Timothy wrote:
>> A while ago Eric raised two nice suggestions. (2) has just been
>> implemented as Bastien reminded me that I can now just push straight to
>> Org for org-plot.el without going through a patch-review process.
>>
>> This patch resolves (1).
>
> Timothy,
>
> I've updated org and applied the patch.  Both aspects seem to work just
> fine.  I haven't done much testing, however, as it's beer time...  I'll
> update tomorrow should I run into any strange behaviour.
>
> thank you,
> eric

Re: Bug: org-plot gives Invalid function error

[Timothy]

Thank you for bringing this up, and bisecting the error. Interesting
that this hasn't been noticed/reported till now.

>From a quick test myself, this appears reproducible, though I have no
idea what's going on (yet). Please let me know if you find anything.

--
Timothy

ian martins  writes:

> I went to test the "Refresh inline" patch [1] and found that org-plot is
> broken for me. it
> seems to have broken in 1ac45d76e. I tested with =emacs -Q= (but loaded
> Org from master and gnuplot.el manually).  I was running the example from
>  the doc [2]. I tested on linux and mac, both using emacs 26.3, and got the
> same result.
>
> The error message is:
>
> org-plot/gnuplot: Invalid function: (dump-func (plist-get type
> :data-dump))
>
> But if I manually load =org-plot.el= it doesn't give that error, but
> still doesn't produce a plot.  I'm not sure what manually loading
> =org-plot.el= does since I'd just done a "make clean; make" and restarted.
>
> In the second case (after manually loading =org-plot.el=), this is what is
> in
> the *gnuplot* buffer:
>
> Terminal type is now 'qt'
> gnuplot> reset
> gnuplot> set term GNUTERM
>
> Terminal type is now 'qt'
> Options are '0 font "Sans,9"'
> gnuplot>
> gnuplot> set title 'Citas'
> gnuplot> set yrange [0:]
> gnuplot> set yrange [0:]
> gnuplot> set datafile separator "\t"
> gnuplot> plot '/tmp/org-plotiPs0To' using 1:3 with histograms title
> 'H-index'
>  warning: Skipping data file with no valid points
>
>  ^
>  x range is invalid
>
> this is the data file:
>
> "Chile" 257.72 21.39
> "Leeds" 165.77 19.68
> "Sao Paolo" 71.00 11.50
> "Stockholm" 134.19 14.33
> "Morelia" 257.56 17.67
>
> I'll try to look into it more later.
>
> [1] https://orgmode.org/list/87r1j0mg56@gmail.com/
> [2] https://orgmode.org/manual/Org-Plot.html#Org-Plot


--
Timothy

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Nicolas Goaziou]

Hello,

Timothy  writes:

> + (cond
> +  ((string-match-p "#\\+plot" (thing-at-point 'line t))

The whole `org-ctrl-c-ctrl-c' function relies on the parser. It would be
nice to use it for this case too.

Here a more accurate check would be:


(and (< (point) (org-element-property :post-affiliated context))

 (org-match-line (rx (zero-or-more (any " " "\t")) "#+plot:")))

Regards,
-- 
Nicolas Goaziou

Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]

[Bastien]

Hi Jorge,

Jorge P. de Morais Neto  writes:

> Therefore, when a verifiably public domain script
> is blocked by LibreJS, LibreJS users (like me) get unhappy; this ought
> to be solved.

this has just been resolved - see my other message today.

Legally, one could dispute the fact that these lines are copyrightable
because the code here is trivial and hardly qualifies as "orginal".

So I understand Anthony's willingness to put them in the public domain
and your proposal to put them under CC0, which is also valid.  But I'd
rather stick to the GPLv3+, because there is no real issue about this
licensing of these lines.

I hope both you and Anthony agree with this, or at least recognize
that the current solution is acceptable.

Bug: org-plot gives Invalid function error

[ian martins]

I went to test the "Refresh inline" patch [1] and found that org-plot is
broken for me. it
seems to have broken in 1ac45d76e. I tested with =emacs -Q= (but loaded
Org from master and gnuplot.el manually).  I was running the example from
 the doc [2]. I tested on linux and mac, both using emacs 26.3, and got the
same result.

The error message is:

org-plot/gnuplot: Invalid function: (dump-func (plist-get type
:data-dump))

But if I manually load =org-plot.el= it doesn't give that error, but
still doesn't produce a plot.  I'm not sure what manually loading
=org-plot.el= does since I'd just done a "make clean; make" and restarted.

In the second case (after manually loading =org-plot.el=), this is what is
in
the *gnuplot* buffer:

Terminal type is now 'qt'
gnuplot> reset
gnuplot> set term GNUTERM

Terminal type is now 'qt'
Options are '0 font "Sans,9"'
gnuplot>
gnuplot> set title 'Citas'
gnuplot> set yrange [0:]
gnuplot> set yrange [0:]
gnuplot> set datafile separator "\t"
gnuplot> plot '/tmp/org-plotiPs0To' using 1:3 with histograms title
'H-index'
 warning: Skipping data file with no valid points

 ^
 x range is invalid

this is the data file:

"Chile" 257.72 21.39
"Leeds" 165.77 19.68
"Sao Paolo" 71.00 11.50
"Stockholm" 134.19 14.33
"Morelia" 257.56 17.67

I'll try to look into it more later.

[1] https://orgmode.org/list/87r1j0mg56@gmail.com/
[2] https://orgmode.org/manual/Org-Plot.html#Org-Plot

[PATCH] Have C-c C-c recognise #+plot lines

[Timothy]

A while ago Eric raised two nice suggestions. (2) has just been
implemented as Bastien reminded me that I can now just push straight to
Org for org-plot.el without going through a patch-review process.

This patch resolves (1).

Eric S Fraga  writes:

> 1. it would be consistent and useful if "C-c C-c" executed
>org-plot/gnuplot when on such a #+PLOT line.
>
> 2. why does point move to the next line when I do execute the command?
>This is somewhat annoying when playing around with the settings.  It
>would be nice to have point remain where it is.
>
> Thank you all!

--
Timothy

>From fccd5f2c66fe8342da2a8eb405240f5247958597 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Tue, 27 Apr 2021 00:05:37 +0800
Subject: [PATCH] org: Enable plotting with C-c C-c

* lisp/org.el (org-ctrl-c-ctrl-c): When at a table, check if the current
line starts with "#+plot", and if so call `org-plot/gnuplot'.
As I think 4-deep nested if statements are bad for readability, I
refactored the nested if statements to use `cond' while I was at it.
---
 lisp/org.el | 40 ++--
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 3f9c9a284..950509bfd 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17693,24 +17693,28 @@ (defun org-ctrl-c-ctrl-c ( arg)
 	 ;; send the table if necessary.  If the table has
 	 ;; a `table.el' type, just give up.  At a table row or cell,
 	 ;; maybe recalculate line but always align table.
-	 (if (eq (org-element-property :type context) 'table.el)
-	 (message "%s" (substitute-command-keys "\\\
-Use `\\[org-edit-special]' to edit table.el tables"))
-	   (if (or (eq type 'table)
-		   ;; Check if point is at a TBLFM line.
-		   (and (eq type 'table-row)
-			(= (point) (org-element-property :end context
-	   (save-excursion
-		 (if (org-at-TBLFM-p)
-		 (progn (require 'org-table)
-			(org-table-calc-current-TBLFM))
-		   (goto-char (org-element-property :contents-begin context))
-		   (org-call-with-arg 'org-table-recalculate (or arg t))
-		   (orgtbl-send-table 'maybe)))
-	 (org-table-maybe-eval-formula)
-	 (cond (arg (call-interactively #'org-table-recalculate))
-		   ((org-table-maybe-recalculate-line))
-		   (t (org-table-align))
+ (cond
+  ((string-match-p "#\\+plot" (thing-at-point 'line t))
+   (org-plot/gnuplot))
+  ((eq (org-element-property :type context) 'table.el)
+   (message "%s" (substitute-command-keys "\\\
+Use `\\[org-edit-special]' to edit table.el tables")))
+  ((or (eq type 'table)
+   ;; Check if point is at a TBLFM line.
+   (and (eq type 'table-row)
+(= (point) (org-element-property :end context
+   (save-excursion
+ (if (org-at-TBLFM-p)
+ (progn (require 'org-table)
+(org-table-calc-current-TBLFM))
+   (goto-char (org-element-property :contents-begin context))
+   (org-call-with-arg 'org-table-recalculate (or arg t))
+   (orgtbl-send-table 'maybe
+  (t
+   (org-table-maybe-eval-formula)
+   (cond (arg (call-interactively #'org-table-recalculate))
+ ((org-table-maybe-recalculate-line))
+ (t (org-table-align))
 	((or `timestamp (and `planning (guard (org-at-timestamp-p 'lax
 	 (org-timestamp-change 0 'day))
 	((and `nil (guard (org-at-heading-p)))
-- 
2.31.1

On using to-do lists efficiently

[Bastien]

Slightly offtopic but I sat down this week-end trying to grasp with
very few words what I learned on how to use to-do lists efficiently
over the years, and here it is:

https://bzg.fr/en/on-using-to-do-lists-efficiently/

Posted it on HN: https://news.ycombinator.com/item?id=26944239

I'm curious if this resonates with your experience.

It took me quite long to appease this love-hate relationship I have
with my to-do lists.

As usual: enjoy!

Re: wip-cite status question and feedback

[Bruce D'Arcus]

I had an idea on this, though it may not be a good one ...

On Sat, Apr 24, 2021 at 2:39 PM Bruce D'Arcus  wrote:
>
> On Sat, Apr 24, 2021 at 1:47 PM Nicolas Goaziou  
> wrote:
> >
> > Hello,
> >
> > "Bruce D'Arcus"  writes:
> >
> > > Some sentence with a concluding citation [cite:@key].
> > >
> > > ... that should end up like this:
> > >
> > > Some sentence with a concluding citation.[1]
> > >
> > > Aside: looking through the CSL spec, it doesn't seem this is
> > > documented. It obviously should be.
> > >
> > > And I don't remember if that convention is locale-specific; e.g. if
> > > while that's the standard in English, it could be different in France.
> > >
> > > In any case, this sort of punctuation modification should be possible.
> >
> > Could you show more example of this, possibly including quotes the
> > citation, or better, a precise description of the punctuation
> > modification you have in mind?
>
> Yes.
>
> Denis lays it out in this comment:
>
> https://github.com/citation-style-language/documentation/issues/139#issuecomment-825934813
>
> What he's arguing is that the rules vary by locale, with German, for
> example (he's employed at a Swiss-German institution, I believe),
> having different conventions than English, and American English
> different than British English.
>
> But an example from American English for illustration, derived from
> Denis' examples.
>
> "A simple quote" [cite:@doe].
>
> When rendered, that should be this in an author-date style:
>
> "A simple quote" (Doe 2021).
>
> ... and this in a note style:
>
> "A simple quote."[^1]
>
> So that rule would suggest something like:
>
> - if a citation concludes a sentence, move the note mark and whatever
> trailing quotation mark, outside the period.
>
> But, Denis continues, "While this is perfectly acceptable in American
> English, it is not in German, or even in British English. Here we have
> to know whether the final period is part of the original quotation. If
> yes, it will be put inside the quotes, otherwise outside." I'll paste
> the rest of his examples at the end.
>
> It's possible his rule here is more general, and would still be
> acceptable in American English.

The idea is this: make use of a "quote" style and abuse the item
prefix for the quote content?

So using his example:

[cite/quote:;A simple quote. @doe20]

A processor could then know the citation is associated with a quote
that ends a sentence, vs (note missing period):

[cite/quote:;A simple quote @doe20]

... and then more easily adjust accordingly, without needing to know
anything about the surrounding punctuation.

Does that make sense?

Bruce

Re: [PATCH] Refresh inline plotted images

[Timothy]

Applied in dadbd025f.*

Timothy  writes:

> Hi All,
>
> This patch improves the result of running org-plot in the following
> situation
>
> #+plot: ... file:"somefile.png"
>
> [[file:somefile.png]]
>
> Previously, when somefile.png is re-plotted the [[file:]] inline image
> did not refresh. With this patch, after plotting, overlays of the
> replotted image are refreshed.

* As Bastien pointed out to me, I /am/ the org-plot maintainer...

Re: Bug: [PATCH] define-minor-mode: prefer keyword args [9.4.5 (9.4.5-ga02a3b @ /home/n/.emacs.d/straight/build/org-plus-contrib/)]

[Bastien]

Hi,

thanks for the patch, we do indeed need to move forward for this.

Could you propose the patch against the master branch (not the maint
branch, since this is not a bugfix) and perhaps fix *all* warnings?

Also, here the preferred format for the commit message:

* lisp/org-table.el (org-table-header-line-mode)
(org-table-follow-field-mode): Migrate minor mode
definitions from positional arguments to keyword args.

* lisp/org-src.el (org-src-mode): Ditto.

* lisp/org-list.el (org-list-checkbox-radio-mode): Ditto.

Don't worry too much about it, I can always rearrange it.

Thanks!

Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]

[Jorge P . de Morais Neto]

Hi all!

Em [2021-04-22 qui 16:29:15-0400], Anthony Carrico escreveu:

> Hi all.  Thanks for the note.  I took a look at the LibreJS docs to
> try to understand the problem.

I also took a look at the LibreJS docs, the linked article "The
JavaScript Trap", and the text of the CC0.

> LibreJS is a web filtering plugin.  Users are making a decision to
> block content which is not explicitly licensed in the LibreJS syntax,
> including public domain works marked in that syntax.  Apparently
> LibreJS is working as designed.  I don't think we should attempt to
> work around a user's web filtering software.

The purpose of LibreJS, from the Overview section of its manual, is to
detect and block *nonfree* nontrivial JavaScript.  Then the article [1]
in the gnu.org website says "Please ensure these licenses are free and
GPL-compatible."  So if some script in a webpage is free software, then
LibreJS users want it to run without issue, especially if its license is
also GPL-compatible.  Therefore, when a verifiably public domain script
is blocked by LibreJS, LibreJS users (like me) get unhappy; this ought
to be solved.

1: https://www.gnu.org/software/librejs/free-your-javascript.html "GNU
Project - Releasing your JavaScript as Free Software"

> My understanding is that authors who want to get through the web
> filter should include an approved LibreJS license notice at the top of
> their page, and a separate license in a 

Re: Bug: JavaScript in HTML export not recognized by LibreJS as free [9.4.5 (9.4.5-16-g94be20-elpaplus @ /home/jorge/.config/emacs/elpa/org-plus-contrib-20210412/)]

[Bastien]

Hi Anthony,

thanks for your explanations around this issue.

I made a mistake when applying your patch here:
https://code.orgmode.org/bzg/org-mode/commit/471054136
https://orgmode.org/list/20200617002335.l4lg3slfxm74vx3h@silver/

The original Javascript lines were written by Carsten 12 years ago
(time flies) with a4d72cbda, published under GPLv3+ by him.

Because these lines were under GPLv3+, they needed to be advertized as
such within the generated HTML, so adding the GPLv3+ license here was
correct but my mistake was not to ask Carsten if he was okay releasing
the lines in the public domain, since he was the author (sorry!)

My current stand on this, is that publishing these lines under GPLv3+
is okay: it does not imply that the author of the generated HTML has
any constraint regarding the license he wants to publish his contents
under, because his contents is not a "derivative work" of these few
Javascript lines.  With respect to your example, the generated HTML
(+js) page is not the result of including the Javascript code in a
compilation process, and it's easy enough to separate the contents
from these few lines.

I reverted your initial patch in maint (29d21ea6).

Still, the code enhancements you proposed there are still valid:
would you be okay to place submit them again in another patch?

Bug: [PATCH] define-minor-mode: prefer keyword args [9.4.5 (9.4.5-ga02a3b @ /home/n/.emacs.d/straight/build/org-plus-contrib/)]

[No Wayman]

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


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

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


The attached patch updates the calling convention for several 
minor-mode definitions to use keywords in place of the older 
positional arguments. With the native comp branch being merged 
into Emacs' master branch, these types of warnings become more 
apparent to end users, so I figure it's a good idea to stay on top 
of them.


Thanks,
Nick

>From b33e081225a441e43cd03cd127197e4abaa0966d Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Mon, 26 Apr 2021 08:25:25 -0400
Subject: [PATCH] Update define-minor-mode calling convention

* org-list.el, org-src.el, org-table.el, org.el: Migrate minor mode
definitions from positional arguments to keyword args.
---
 lisp/org-list.el  | 2 +-
 lisp/org-src.el   | 2 +-
 lisp/org-table.el | 4 ++--
 lisp/org.el   | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/lisp/org-list.el b/lisp/org-list.el
index 98d9e36da..4d84d99bb 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -2296,7 +2296,7 @@ is an integer, 0 means `-', 1 means `+' etc.  If WHICH is
 ;;;###autoload
 (define-minor-mode org-list-checkbox-radio-mode
   "When turned on, use list checkboxes as radio buttons."
-  nil " CheckBoxRadio" nil
+  :lighter " CheckBoxRadio"
   (unless (eq major-mode 'org-mode)
 (user-error "Cannot turn this mode outside org-mode buffers")))
 
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 20acee4e6..cabedecb6 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -682,7 +682,7 @@ This minor mode is turned on in two situations:
 \\{org-src-mode-map}
 
 See also `org-src-mode-hook'."
-  nil " OrgSrc" nil
+  :lighter " OrgSrc"
   (when org-edit-src-persistent-message
 (setq header-line-format
 	  (substitute-command-keys
diff --git a/lisp/org-table.el b/lisp/org-table.el
index 3030751cc..a0c354d86 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -499,7 +499,7 @@ This may be useful when columns have been shrunk."
 ;;;###autoload
 (define-minor-mode org-table-header-line-mode
   "Display the first row of the table at point in the header line."
-  nil " TblHeader" nil
+  :lighter " TblHeader"
   (unless (eq major-mode 'org-mode)
 (user-error "Cannot turn org table header mode outside org-mode buffers"))
   (if org-table-header-line-mode
@@ -1966,7 +1966,7 @@ lines."
 When this mode is active, the field editor window will always show the
 current field.  The mode exits automatically when the cursor leaves the
 table (but see `org-table-exit-follow-field-mode-when-leaving-table')."
-  nil " TblFollow" nil
+  :lighter " TblFollow"
   (if org-table-follow-field-mode
   (add-hook 'post-command-hook 'org-table-follow-fields-with-editor
 		'append 'local)
diff --git a/lisp/org.el b/lisp/org.el
index 675a614e2..f7fd90cf9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15640,7 +15640,7 @@ When a buffer is unmodified, it is just killed.  When modified, it is saved
 This mode supports entering LaTeX environment and math in LaTeX fragments
 in Org mode.
 \\{org-cdlatex-mode-map}"
-  nil " OCDL" nil
+  :lighter " OCDL"
   (when org-cdlatex-mode
 (require 'cdlatex)
 (run-hooks 'cdlatex-mode-hook)
-- 
2.31.1

Re: Blog announcement: This Month in Org

[Jose E. Marchesi]

> For a while now I thought Org would be well served by another channel to
> show off developments. Something in between the torrent of threads on
> this mailing list and serendipitous discoveries.
>
> I have finally acted on this thought and created /This Month in Org/ ---
> https://blog.tecosaur.com/tmio/. Inspired by This Week in KDE I plan on
> producing monthly development highlights.
>
> Perhaps you'll find it interesting too, or maybe you know a friend that
> would like a way to find out about Org developments without subscribing
> to the ML.
>
> If you have any feedback please don't hesitate to send me your
> thoughts .

It would be nice to get your blog aggregated in the GNU planet
(http://planet.gnu.org).  If you are interested, please write to
pla...@gnu.org requesting it.

Re: org-cite: make 'suppress-author' a citation 'style'

[Bruce D'Arcus]

On Mon, Apr 26, 2021 at 5:56 AM Joost Kremers  wrote:

...

> IOW it seems that in biblatex, suppress-author (obtained by the asterisk
> following the command) is a property of the citation command, even if it
> includes multiple citations. OTOH there are real cases (I have written
> references such as the example here myself) where you want it to be a property
> of the individual citation.

It would help at this point if you could show an example, as I can't
think of one that can't be addressed.

As I replied to Richard, a citation with references to different
authors can already be addressed.

> The thing about biblatex is that it offers low-level commands that allow you 
> to
> create unusual citations (my default LaTeX header contains three definitions 
> of
> citation commands that biblatex doesn't provide but which I use quite a lot). 
> So
> I would argue that it's better to keep the syntax =-@key=, just to keep the
> system flexible in case the need arises.

Adding complexity for hypotheticals has costs though.

We should be able to identify a concrete case here that won't work
with the change I suggest, but that we agree should be supported.

Bruce

Re: [PATCH] Babel: remove LaTeX environment -type #+results

[Greg Minshall]

Timothy,

> The rendering is just done by `org-latex-preview'.

> Hope that clears things up.

yes, thanks.

Re: org-cite: make 'suppress-author' a citation 'style'

[Joost Kremers]

On Mon, Apr 26 2021, Denis Maier wrote:
> [...] Interestingly, I 
> couldn't find an easy way to get "Doe (2021, p.34; see also Smith 2020) 
> ... argues". You'd probably have to resort to lower level commands such 
> as \citeauthor in combination with other commands.
> \citeauthor{doe} \parencites*[34]{doe}{smith}

Actually, that won't print the author name of =smith=. AFAIK If you want to
suppress the author in the first citation but not in the second, you need to be
even more low-level:

\citeauthor{Chomsky1995} (\cite*[34]{Chomsky1995}, \cite{Kayne1994})

At least that's the only way I've been able to find.

IOW it seems that in biblatex, suppress-author (obtained by the asterisk
following the command) is a property of the citation command, even if it
includes multiple citations. OTOH there are real cases (I have written
references such as the example here myself) where you want it to be a property
of the individual citation.

The thing about biblatex is that it offers low-level commands that allow you to
create unusual citations (my default LaTeX header contains three definitions of
citation commands that biblatex doesn't provide but which I use quite a lot). So
I would argue that it's better to keep the syntax =-@key=, just to keep the
system flexible in case the need arises.

-- 
Joost Kremers
Life has its moments

Re: Blog announcement: This Month in Org

[Detlef Steuer]

subscribed!

detlef

Am Mon, 26 Apr 2021 17:14:49 +0800
schrieb Timothy :

> Hello Everyone!
> 
> For a while now I thought Org would be well served by another channel
> to show off developments. Something in between the torrent of threads
> on this mailing list and serendipitous discoveries.
> 
> I have finally acted on this thought and created /This Month in Org/
> --- https://blog.tecosaur.com/tmio/. Inspired by This Week in KDE I
> plan on producing monthly development highlights.
> 
> Perhaps you'll find it interesting too, or maybe you know a friend
> that would like a way to find out about Org developments without
> subscribing to the ML.
> 
> If you have any feedback please don't hesitate to send me your
> thoughts .
> 
> ~
> 
> Now, since this is the Org ML I'll go into a little more detail about
> what's going on.
> 
> The source is publically availably at
> https://github.com/tecosaur/this-month-in-org/.
> 
> I have a publish.el script which has been rendered executable that is
> ostensibly a shell script but immediately calls emacs on itself then
> exits (credit to Doom/Emacs Wiki).
> 
> This script loads my personal configuration and then prepares for
> ox-publish. It also takes a -f flag to delete the publish dir and the
> force-publish.
> 
> I do a few fun things like fix org-latex-publish-to-pdf so it doesn't
> pollute the src directory, write a version of org-publish-attachment
> which attempts to optimise recognised filetypes, and some setup to
> generate a sitemap that can be converted into an RSS file with ox-rss.
> 
> Some of the functions which produce stdout via (message) have been
> advised to make the output easier to scan (see
> https://0x0.st/-mvq.png).
> 
> After all this, I just rsync the output directory to my server :)
> 
> --
> Timothy
> 

Re: org-cite: make 'suppress-author' a citation 'style'

[Bruce D'Arcus]

On Mon, Apr 26, 2021 at 3:51 AM Richard Lawrence
 wrote:

...

> That said, here is a possible use case for this: suppose you are
> referencing multiple works from a given author and want to avoid
> printing the author's name multiple times, but also want to include a
> further reference to a work by another author:
>
> e.g. you can write
>
> Smith claims foo [(cite): -@Smith2019; -@Smith2020; see also @Jones2018].
>
> to render
>
> Smith claims foo (2019; 2020; see also Jones 2018).
>
> Does that help?

Yes; thank you!

You identified the same case Andras and I discussed just above.

I think the solution is simple; with the updated syntax:

[cite/-:@Smith2019;@Smith2020; see also @Jones2018].

So the rule is (and this is for the processor to worry about, of
course, not org), when a suppress-author style is specified, the
suppression only applies to the author of the first citation
item/reference. That would generate the output you noted.

A processor like citeproc.el already knows how to group and sort by
author, so it could also be smart enough to handle that, without
requiring the user to individually mark some for suppression.

I worry we're making the general and simple case needlessly
complicated with the current model and syntax for this.

Bruce

Blog announcement: This Month in Org

[Timothy]

Hello Everyone!

For a while now I thought Org would be well served by another channel to
show off developments. Something in between the torrent of threads on
this mailing list and serendipitous discoveries.

I have finally acted on this thought and created /This Month in Org/ ---
https://blog.tecosaur.com/tmio/. Inspired by This Week in KDE I plan on
producing monthly development highlights.

Perhaps you'll find it interesting too, or maybe you know a friend that
would like a way to find out about Org developments without subscribing
to the ML.

If you have any feedback please don't hesitate to send me your thoughts .

~

Now, since this is the Org ML I'll go into a little more detail about
what's going on.

The source is publically availably at
https://github.com/tecosaur/this-month-in-org/.

I have a publish.el script which has been rendered executable that is
ostensibly a shell script but immediately calls emacs on itself then
exits (credit to Doom/Emacs Wiki).

This script loads my personal configuration and then prepares for
ox-publish. It also takes a -f flag to delete the publish dir and the
force-publish.

I do a few fun things like fix org-latex-publish-to-pdf so it doesn't
pollute the src directory, write a version of org-publish-attachment
which attempts to optimise recognised filetypes, and some setup to
generate a sitemap that can be converted into an RSS file with ox-rss.

Some of the functions which produce stdout via (message) have been
advised to make the output easier to scan (see https://0x0.st/-mvq.png).

After all this, I just rsync the output directory to my server :)

--
Timothy

Re: org-cite: make 'suppress-author' a citation 'style'

[Denis Maier]

Am 26.04.2021 um 09:53 schrieb Denis Maier:

Hi,

just some general remarks on that issue: I tend to think that treating 
"suppress-author" as a mode/style/command would indeed be appropriate. 
As the minus shorthand is inherited from pandoc, it might be worth 
pointing out that pandoc's syntax owes quite a lot to the markdown 
philosophy, which is also emphasized by pandoc:


Markdown is intended to be as easy-to-read and easy-to-write as is 

feasible.


Readability, however, is emphasized above all else

(https://daringfireball.net/projects/markdown/syntax#philosophy)

That is, markdown tries to use a syntax as concise as possible, without 
verbose commands and such. See e.g. this discussion: 
https://groups.google.com/g/pandoc-discuss/c/ydG9CI_XEEU/m/3LHxvp23BAAJ


The price for this is a certain opaqueness, and, to a certain degree, a 
loss of precision, expressiveness and extensibility.


Anyway, back to the modes question:

#+begin_example
[@doe]

[-@doe]

@doe

@doe [34]

-@doe [34]
#+end_example

gives us in pandos AST:

#+begin_pandoc_ast
[Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [], citationMode = NormalCitation, citationNoteNum = 1, 
citationHash = 0}] [Str "[@doe]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [], citationMode = SuppressAuthor, citationNoteNum = 2, 
citationHash = 0}] [Str "[-@doe]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [], citationMode = AuthorInText, citationNoteNum = 3, 
citationHash = 0}] [Str "@doe"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [Str "34"], citationMode = AuthorInText, 
citationNoteNum = 4, citationHash = 0}] [Str "@doe",Space,Str "[34]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [Str "34"], citationMode = SuppressAuthor, 
citationNoteNum = 5, citationHash = 0}] [Str "@doe",Space,Str "[34]"]]]

#+end_pandoc_ast

So, suppress author is essentially a mode here.


Addendum:

[@doe; -@foo]

gives us:

[Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [], citationMode = NormalCitation, citationNoteNum = 1, 
citationHash = 0},Citation {citationId = "foo", citationPrefix = [], 
citationSuffix = [], citationMode = SuppressAuthor, citationNoteNum = 1, 
citationHash = 0}] [Str "[@doe;",Space,Str "-@foo]"]]


So, each citation in that cite has an individual mode, which goes in the 
direction indicated by Richard Lawrence in his earlier message. Maybe 
that speaks for two levels of styles, one pertaining to the whole 
citation group, one to the individual citations. Does that make sense?




FWIW, it might also be interesting to look at biblatex:
biblatex has a textcite command:
\textcite{doe2021} => Doe (2021)

Now, if you want to cite multiple entries, each with prefix and suffix, 
you'll need a special variant \textcites!

\textcites[12]{foo}[34]{bar} argue ...
=> Foo (2021, p. 12) and Bar (2021, p. 34) argue ...

I'm not sure how that fits into the org context. Interestingly, I 
couldn't find an easy way to get "Doe (2021, p.34; see also Smith 2020) 
... argues". You'd probably have to resort to lower level commands such 
as \citeauthor in combination with other commands.

\citeauthor{doe} \parencites*[34]{doe}{smith}

Denis

Am 25.04.2021 um 22:12 schrieb Bruce D'Arcus:
On Sun, Apr 25, 2021 at 3:48 PM András Simonyi 
 wrote:


Dear All,

On Sun, 25 Apr 2021 at 14:50, Bruce D'Arcus  wrote:

How would you deal with these?

#+begin_example
[cite/-:@doe20; @doe21]
[cite/-:@doe20; see also @smith19]
[cite/text:@doe20; see also @smith19]
#+end_example

My thought is you want to treat the author of the first listed cite as
suppressed, or placed in-text in the last case, but that you wouldn't
touch the other author?


yes, exactly -- since it's difficult to see (at least for me) how the
context could supply the author information for the subsequent cites.


So the output for the first one would be:

(2020, 2021)

..., and not:

(2020, Doe 2021)

As in, you would suppress the author not on the first cite (what you
wrote in the original reply), but the author of the first cite?

To me, that's the only wrinkle of having this a citation-level style;
that a processor would need to be smart enough to handle cases like
that, for output styles that require it.

But otherwise it's easier and more efficient for the user.

Bruce

Re: org-agenda-list should respect org-agenda-max-entries

[Bastien]

Hi Ag,

Ag Ibragimov  writes:

> While going through the source code, I've noticed that org-agenda-list
> scans all the files in org-agenda-files and processes all Org items
> those files contain.
>
> However, it seems when org-agenda-max-entries or org-agenda-max-todos
> are not nil, it still processes every entry, and only after building
> the agenda it reduces the number of items in the list. It's okay, but
> if you have lots of files and tons of entries, it seems to be waste of
> time and resources.

Yes, agreed.  `org-agenda-max-entries' and `org-agenda-max-entries'
are less useful when the limitation is done *at the end* as it is now
(my bad, as I implemented this).

I would welcome a patch that take org-agenda-max-* variables into
account right after the list of agenda items has been collected and
just *before* any other filtering happens.

Let me know if this is something you can explore.  Thanks!

Re: [PATCH] ox-html.el: Add HTML_CONTENT_CLASS to support css classes in content tag

[Bastien]

Applied as 4efab7681, thanks.

I added "TINYCHANGE" at the bottom of your commit message to signal
this is small change done by someone who has not (yet) assigned his
copyright to the FSF.

Sameer Rahmani  writes:

> * ox-html.el (org-html-template): Added the support for a CSS class name
> to the content tag which wraps the entire content. The CSS class name
> can be set via in buffer HTML_CONTENT_CLASS property or :html-content-class
> for org publish.

Re: [PATCH] ob-lilypond: allow user configuration of header-args

[Bastien]

Hi Jamie,

thanks for the patch, I applied it as ea8f7610c.

ob-lilypond.el does not have a maintainer, would you be willing
to volunteer?

Thanks!

Re: [PATCH] Improve documentation of #+startup keyword

[Bastien]

Hi Detlef,

Detlef Steuer  writes:

> I really would like to have as much as possible in the manual.

Explanations are always good in the reference manual, yes, but
clarifications belong in the community-driven extended manual that
is Worg, IMO.  I think this change would overload the manual without
addding much to it.

Re: [PATCH] Improve documentation of #+startup keyword

[Detlef Steuer]

Am Mon, 26 Apr 2021 09:45:36 +0200
schrieb Bastien :

> > I think that this would be a good addition to the manual, and help
> > clarify the behaviour --- so I've prepared a little patch to the
> > manual.  
> 
> Thanks for the patch.  I think it better belongs to a worg page, as we
> try to avoid overloading the quite-already-big manual.  Can you make
> this a contribution to Worg?

I really would like to have as much as possible in the manual.

My guess is, nobody prints it anymore, so the old concers about thick
manuals are irrelevant today.

If I must start looking through worg to find some information, my chance
of finding it has already halfed. :-)

Just my 2c
Detlef

Re: [PATCH] Allow multiple %(expression) instances in org-agenda-prefix-format

[Bastien]

Applied as 0260d2fcf, thanks!

Ihor Radchenko  writes:

> * lisp/org-agenda.el (org-compile-prefix-format): Use non-greedy match
> for %(expression).

Re: [PATCH] Use tags for SVGs

[Bastien]

Applied as d96e89757, thanks.

Re: org-cite: make 'suppress-author' a citation 'style'

[Denis Maier]

Hi,

just some general remarks on that issue: I tend to think that treating 
"suppress-author" as a mode/style/command would indeed be appropriate. 
As the minus shorthand is inherited from pandoc, it might be worth 
pointing out that pandoc's syntax owes quite a lot to the markdown 
philosophy, which is also emphasized by pandoc:


> Markdown is intended to be as easy-to-read and easy-to-write as is 
feasible.

>
> Readability, however, is emphasized above all else
(https://daringfireball.net/projects/markdown/syntax#philosophy)

That is, markdown tries to use a syntax as concise as possible, without 
verbose commands and such. See e.g. this discussion: 
https://groups.google.com/g/pandoc-discuss/c/ydG9CI_XEEU/m/3LHxvp23BAAJ


The price for this is a certain opaqueness, and, to a certain degree, a 
loss of precision, expressiveness and extensibility.


Anyway, back to the modes question:

#+begin_example
[@doe]

[-@doe]

@doe

@doe [34]

-@doe [34]
#+end_example

gives us in pandos AST:

#+begin_pandoc_ast
[Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [], citationMode = NormalCitation, citationNoteNum = 1, 
citationHash = 0}] [Str "[@doe]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [], citationMode = SuppressAuthor, citationNoteNum = 2, 
citationHash = 0}] [Str "[-@doe]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [], citationMode = AuthorInText, citationNoteNum = 3, 
citationHash = 0}] [Str "@doe"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [Str "34"], citationMode = AuthorInText, 
citationNoteNum = 4, citationHash = 0}] [Str "@doe",Space,Str "[34]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [Str "34"], citationMode = SuppressAuthor, 
citationNoteNum = 5, citationHash = 0}] [Str "@doe",Space,Str "[34]"]]]

#+end_pandoc_ast

So, suppress author is essentially a mode here.

FWIW, it might also be interesting to look at biblatex:
biblatex has a textcite command:
\textcite{doe2021} => Doe (2021)

Now, if you want to cite multiple entries, each with prefix and suffix, 
you'll need a special variant \textcites!

\textcites[12]{foo}[34]{bar} argue ...
=> Foo (2021, p. 12) and Bar (2021, p. 34) argue ...

I'm not sure how that fits into the org context. Interestingly, I 
couldn't find an easy way to get "Doe (2021, p.34; see also Smith 2020) 
... argues". You'd probably have to resort to lower level commands such 
as \citeauthor in combination with other commands.

\citeauthor{doe} \parencites*[34]{doe}{smith}

Denis

Am 25.04.2021 um 22:12 schrieb Bruce D'Arcus:

On Sun, Apr 25, 2021 at 3:48 PM András Simonyi  wrote:


Dear All,

On Sun, 25 Apr 2021 at 14:50, Bruce D'Arcus  wrote:

How would you deal with these?

#+begin_example
[cite/-:@doe20; @doe21]
[cite/-:@doe20; see also @smith19]
[cite/text:@doe20; see also @smith19]
#+end_example

My thought is you want to treat the author of the first listed cite as
suppressed, or placed in-text in the last case, but that you wouldn't
touch the other author?


yes, exactly -- since it's difficult to see (at least for me) how the
context could supply the author information for the subsequent cites.


So the output for the first one would be:

(2020, 2021)

..., and not:

(2020, Doe 2021)

As in, you would suppress the author not on the first cite (what you
wrote in the original reply), but the author of the first cite?

To me, that's the only wrinkle of having this a citation-level style;
that a processor would need to be smart enough to handle cases like
that, for output styles that require it.

But otherwise it's easier and more efficient for the user.

Bruce

Re: org-cite: make 'suppress-author' a citation 'style'

[Richard Lawrence]

Hi all,

"Bruce D'Arcus"  writes:

>> We introduced :suppress-author because someone requested it at some
>> point. I don't remember who, but it may be worth asking that person.
>>
>
> I did some quick searching.
>
> Wow; this goes back a long time!
>
> Anyway, Richard Lawrence summarized previous discussions, which includes
> this detail, in this 2015 post:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2015-02/msg00932.html
>
> Not sure if he introduced the idea or not, but if not, he should know.

I don't remember exactly anymore, and a quick search does not turn up
the source, but I can say in general that the concern back then was to
make the citation syntax at least as flexible as the BibLaTeX citation
commands, to support users who currently use BibLaTeX (and don't have
much interest in non-LaTeX output).

> I think there are two points to consider before removing suppress-author
>> syntax:
>>
>> 1. does it make sense to apply it independently on references within
>>a full citation?

I don't remember what my thinking was exactly, but it was probably
something like this: (a) we need citations with multiple references; (b)
in some such citations we may need to suppress the author of some
references without suppressing the author of others; (c) thus
:suppress-author must be a reference-level property, not a property of
the whole citation object and (d) uniformity demands that every
reference should have it (even if it doesn't make sense in practice to
apply it to references in the middle of the list).

That said, here is a possible use case for this: suppose you are
referencing multiple works from a given author and want to avoid
printing the author's name multiple times, but also want to include a
further reference to a work by another author:

e.g. you can write

Smith claims foo [(cite): -@Smith2019; -@Smith2020; see also @Jones2018].

to render

Smith claims foo (2019; 2020; see also Jones 2018).

Does that help?

-- 
Best,
Richard

Re: [PATCH] ox-bb.el: Add BBCode exporter

[Bastien]

Hi Christian,

Christian Garbs via "General discussions about Org-mode."
 writes:

> after getting an encouraging reply to my initial proposal[1], I went
> forward and finished the patch to include the BBCode exporter in Org.
> The patch applies to current master and includes a suite of tests.

thanks for the patch.  IMHO, such an exporter does not belongs in
Org's core repository.  

In the past, we suggested to add these contributed packages to the
contrib/ directory, but since this we will extract "contrib/" from
the Git repo soon, I don't suggest doing so.

Instead, you can host your code where you see fit and advertize it
by contributing to Worg:

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

Thanks!

Re: [PATCH] Improve documentation of #+startup keyword

[Bastien]

Hi Timothy,

Timothy  writes:

> I was talking to someone who was finding the behaviour of `#+startup'
> confusing, and they managed to work out a table summarising the
> behaviour.
>
> I think that this would be a good addition to the manual, and help
> clarify the behaviour --- so I've prepared a little patch to the manual.

Thanks for the patch.  I think it better belongs to a worg page, as we
try to avoid overloading the quite-already-big manual.  Can you make
this a contribution to Worg?

> I notice that there are some `#+cindex' lines lying around but I'm not
> quite sure what they do. Please let me know if I should add anything
> like that etc.

#+cindex keywords add an entry in the concept index of other versions
of the manual (HTML, PDF, Info, etc.)

Re: [PATCH] Improve code readability in org-set-font-lock-defaults

[Bastien]

Applied as 38842b2ff, thanks.

Nick Savage  writes:

> I'm not sure what the appetite is for small changes like this, but I
> have attached a small patch to improve readability in
> org-set-font-lock-defaults. I was trying to understand how
> org-emphasize worked and came across some code that I thought could be
> simplified.

These small improvements are welcome, thanks again.

Re: Concerns about community contributor support

[Bastien]

Tim Cross  writes:

> OK, consider me 'singed up".

Done, thanks again.

> What is our position with bugs which can only be reproduced in the
> current development version of Emacs? 

They are extremely rare, so don't worry about this too much.

> I'd expect we track them, but focus more on Emacs stable given that
> dev is a moving target and any bugs may be resolved by later changes
> in Emacs?

Yes, I would do that too.

> Finally, is it also necessary to monitor org bugs reported to the emacs
> bug tracker or are they sent on to the emacs-orgmode list via some other
> process? (I currently do monitor emacs-devel but not the bug tracker). 

Yes, it is useful to monitor these bugs too, and they are also sent to
the org-mode list, so you can focus on this list.

Re: Maintaining babel packages — a list of packages that need help?

[Bastien]

Hi Arne,

"Dr. Arne Babenhauserheide"  writes:

> I’m currently in the process of enabling myself to contribute. Do we
> have a list of babel-packages that need maintenance? This is also
> something I’m personally interested in, because I use babel a lot,
> including in multi-language workflows.

Some files in lisp/ob-*.el (in the org-mode.git repository) already
have a maintainer, Kyle recently listed them.

If a file does not have a "Maintainer:" header and you want to take
over maintainance, that's very welcome.

Thanks!

Re: Concerns about community contributor support

[Bastien]

Hi Nick,

Nick Savage  writes:

> On a side note, I'd like some guidance though on whether or not the
> community is interested in a refactoring project (done in pieces of
> course). I'm wondering if I should be attempting to submit minor (or
> larger) patches moving things around to make it easier to maintain, if
> there is a way to go about this (since submitting a bunch at a time,
> breaking them up, etc), certain things I should focus on or ignore,
> etc. I haven't done much since that mostly because work has consumed
> my free time, but I'm going to have a significant amount more free
> time starting in the next week or so, so I'm looking for somewhere to
> direct my energies!

The way to go for structural changes is to work on them in a separate
branch of yours, then discuss the change on the list by suggesting to
test your branch.  Once the branch is stable enough, you can submit it
as a patch or a list of patches.

See https://orgmode.org/worg/org-contribute.html#org4a93bd0 and let
us know if that's clear enough - otherwise please enhance this page.

Thanks!

Re: [PATCH] Refresh inline plotted images

[Bastien]

Hi Timothy,

Timothy  writes:

> +(defun org-plot/redisplay-img-in-buffer (img-file)
> +  "Find any overlays for IMG-FILE in the current Org buffer, and refresh 
> them."

I guess M-x eldoc RET will choke because the first line of a docstring
should shorter.  Other than this nitpick, please feel free to commit,
as you are org-plot.el maintainer.

Thanks

Re: [PATCH] ob-java: Allow import to end with asterisk

[Bastien]

Hi Ian,

ian martins  writes:

> Thanks for fixing this. I re-read the woof documentation and realized
> I needed to put "Applied" at the beginning of the line.

Yes - and also add a "X-Woof-Patch: applied" header in your reply.

Re: Concerns about community contributor support

[Tim Cross]

Bastien  writes:

> Hi Tim,
>
> thank you very much for your detailed answer.
>
> Tim Cross  writes:
>
>> Yes, but with some caveats. 
>
> Thank you!
>
>> For these reasons, I'm probably not the best person to assist with the
>> review and guidance for patches aimed at adding/extending functionality.
>
> The role of a "contributor steward" is to address the issues Timothy
> originally raised about contributors not receiving answers when they
> take the time to send a patch or a bug report, it is not about making
> technical decisions.  Of course, your advice as a long-time user on
> these decisions is always very welcome.
>
>> However, I would be happy to
>>
>> - Assist in trying to reproduce and confirm bugs
>> - Assist in extracting additional information and providing
>>   guidance/clarification for bug reports 
>> - Assist with documentation
>> - Provide some guidance on patches, particularly bug fixes.
>
> That's exactly what is badly needed to discharge core maintainers from
> routine tasks and to let them focus on technical stuff.
>
> This has basically been my role in my early years of maintainership:
> making sure to keep this list as welcoming as possible, to continue to
> attract new people with new ideas (and new bug report).  This is a
> somewhat undervalued role, but a deeply necessary one -- so again,
> thanks for helping here.
>
>> My time availability can vary greatly depending on work. 
>
> That's no problem.  We have a team of Tim's :)
>
>> Also, as a
>> blind user, my ability to reproduce bugs can sometimes be hampered by
>> the necessity of running Emacspeak in conjunction with org mode (they
>> can sometimes interfere with each other). However, apart from that, more
>> than happy to help where I can, so if your happy, sign me up!
>
> If the task becomes too much for you, you can always say that you
> won't be available for a while.
>
> Thanks!

OK, consider me 'singed up". Today I will see if I can re-jig my mail
system to make it easier to track and respond. As Timothy seems to be
doing a fine job 'catching up' with what is already on updates.orgmode,
I'll leave that alone and will focus on responding to new bug reports,
patches etc which come through the list.

I'll also setup a 'clean' virtual image so that I have a vanilla, clean
Emacs config I can use for evaluating/reproducing bugs (current emacs
stable 27.2). .

What is our position with bugs which can only be reproduced in the
current development version of Emacs? I'd expect we track them, but
focus more on Emacs stable given that dev is a moving target and any
bugs may be resolved by later changes in Emacs?

Finally, is it also necessary to monitor org bugs reported to the emacs
bug tracker or are they sent on to the emacs-orgmode list via some other
process? (I currently do monitor emacs-devel but not the bug tracker). 

-- 
Tim Cross