Re: Empty headline titles unsupported: Bug?

[Tom Gillespie]

Hi all,
 Here is the 4th (or so) iteration of the grammar for titles that
I think deals with most of the issues in this thread along with a
bunch of nasty test cases. The previous attempts can be inspected in
the git history, but long story short, it is extremely hard to find a
grammar that follows the principle of least surprise and you have to
use the tokenizer to ensure that the tags pattern always parses as
such so that tags don't magically switch to being the title when you
remove the rest of the contents of the title. The final example
L1648-L1665 shows many of the things that should parse as tags and do
with this tokenizer/grammar combination. The key to dealing with the
ambiguity of empty title and tags vs something that looks like tags
but parses as a title (which is surprising) is to use the tokenizer to
greedily recognize tags at the end of the line. This ensures that the
tags pattern at the end of the line always parses as tags and doesn't
switch just because the title is empty. Happy to elaborate. Best,
Tom

https://github.com/tgbugs/laundry/blob/next/laundry/heading.rkt
https://github.com/tgbugs/laundry/blob/971cf35683cd60156868c12b070c2dd9e19d8d06/laundry/tokenizer.rkt#L98-L140

https://github.com/tgbugs/laundry/blob/971cf35683cd60156868c12b070c2dd9e19d8d06/laundry/test.rkt#L326-L367
https://github.com/tgbugs/laundry/blob/971cf35683cd60156868c12b070c2dd9e19d8d06/laundry/test.rkt#L400-L558
https://github.com/tgbugs/laundry/blob/971cf35683cd60156868c12b070c2dd9e19d8d06/laundry/test.rkt#L1298-L1369
https://github.com/tgbugs/laundry/blob/971cf35683cd60156868c12b070c2dd9e19d8d06/laundry/test.rkt#L1371-L1419
https://github.com/tgbugs/laundry/blob/971cf35683cd60156868c12b070c2dd9e19d8d06/laundry/test.rkt#L1648-L1665

Smart quotes not working correctly with single quotes

[Andreas Gösele]

Hi,

even using "smart quotes", single quotes are not correctly exported into
html, odt or latex.

I have as document:

| #+LANGUAGE: de
| #+OPTIONS: ':t
| #+OPTIONS: toc:nil
| It's a 'test'. "Please".

If I export it to html I get:

| Its a test. Please.

I should get:

| Its a test. Please.

If I export to latex I get:

| It's a 'test'. "`Please"'.

I should get:

| It's a \glq{}test\grq{}. "`Please"'.

If I export to odt I get:

| It’s a ’test’. „Please“.

I should get:

| It’s a ‚test‘. „Please“.

(The odt example outputs use utf8, I hope it gets transmitted.)

So in all three cases apostrophes and double quotes are correctly
exported, but not single quotes. Similar problem if I use "#+LANGUAGE:
en".

I have org-mode 9.3 with emacs 27.1.

What could I do to get single quotes to be exported correctly?

Thanks a lot!

Andreas

Re: [BUG] New error: (void-function org-url-p) when exporting to LaTeX [9.4.6 (9.4.6-gc5573b @ /Users/stanton/.emacs.d/straight/build/org/)]

[Tim Cross]

Unfortunately, I don't know anything about straight.el. However, I note
that the very first line of your grep is a line from the org-compat.el
for version 9.5, so you are still getting mixed versions.

My guess is that straight.el is installing from the master branch of the
org repo rather than the maint branch. You then also install the contrib
package from non-gnu ELPA, which has a dependency on org (the ELPA or
orgmode.org version, which is 9.4).

My advice would be to not use straight.el and just use the org package
from ELPA (which will be in sync with the contrib package from nongnu
ELPA) or use striaght.el for both org and contrib or ensure straight.el
is using the maint branch and not the master branch.

Richard Stanton  writes:

> Thanks, Tim. 
>
> I deleted all org-related files and started again, with the same result. 
>
> Oddly, I do find reference to org-url-p in my basic org setup:
>
> Richards-Mac-Pro:~/.emacs.d/straight/repos/org/lisp stanton$ grep -i 
> org-url-p *.el  
> org-compat.el:(define-obsolete-function-alias 'org-file-url-p 'org-url-p 
> "9.5")
> org-lint.el:   (and (not (org-url-p file))
> org-macs.el:(defun org-url-p (s)
> org.el:   (uri-is-url (org-url-p uri))
> org.el:  (let* ((is-url (org-url-p file))
> org.el:   (when (org-url-p file)
> Richards-Mac-Pro:~/.emacs.d/straight/repos/org/lisp stanton$ 
>
> I currently load org using straight.el as follows:
>
> (setq package-archives
> '(("melpa" . "http://melpa.org/packages/;)
>   ("gnu" . "http://elpa.gnu.org/packages/;)
>   ("nongnu" . "http://elpa.gnu.org/nongnu/;)))
> ;;;  ("org" . "http://orgmode.org/elpa/;)))
>
> (use-package org-contrib
>   :after org
>   :config
>   (require 'ox-extra)
>   (ox-extras-activate '(ignore-headlines))
> )
>
> (use-package org
>   :after (jupyter)
>   :straight t
>   :mode (("\\.org$" . org-mode))
> ;  :ensure org-plus-contrib
>   :config
>   (org-babel-do-load-languages
>'org-babel-load-languages
>'((jupyter . t)))
>   :bind
>   ("C-c l" . org-store-link)
>   ("C-c a" . org-agenda)
>   :init
>   (add-hook 'org-mode-hook (lambda () (setq-local 
> company-minimum-prefix-length 0)))
>
> Best,
>
> Richard
>
>  From: Tim Cross 
>  To: emacs-orgmode@gnu.org
>  Subject: Re: [BUG] New error: (void-function org-url-p) when exporting
>  to LaTeX [9.4.6 (9.4.6-gc5573b @
>  /Users/stanton/.emacs.d/straight/build/org/)]
>  Message-ID: <87tumomy05@gmail.com>
>  Content-Type: text/plain
>
>  OK, think I've worked out what the problem is.
>
>  The function org-url-p is defined in org 9.5, but not org 9.4. Your
>  running org 9.4.6, which does not have that function. The fact something
>  in your install is trying to call org-url-p would indicate you have a
>  mixed or messed up installation of org (i.e. your setup is loading code
>  from 2 different versions).
>
>  It is very important when upgrading or installing org that no org
>  functionality is yet loaded to avoid this type of issue. Your best bet
>  is to remove all org related packages and then try installing org again.
>  If your using package.el to install org, make sure the call to install
>  it is early in your init file (before any functionality is loaded which
>  depends on org). I also find the use-pacakge macro very useful in this
>  regard as you can also setup things so that no org functionality is
>  loaded until you try to use something which depends on org. This means
>  you can typically start Emacs and immediately install/upgrade org
>  without any issues. Where people tend to come undone is when they have
>  been running Emacs for a while, have been using org and then to a
>  package update and the system tries to install a new version of org
>  (usually only an issue with new major versions rather than patch fix
>  version updates). 
>
>  Richard Stanton  writes:
>
>  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.
>  
>
>  Everything worked fine until yesterday, but today when I try to export an 
> org file that contains the line
>
>  #+SETUPFILE: 
> https://fniessen.github.io/org-html-themes/org/theme-readtheorg.setup
>
>  I get the following error:
>
>  Debugger entered--Lisp error: (void-function org-url-p)
>   org-url-p("https://fniessen.github.io/org-html-themes/org/the...;)
>   org--collect-keywords-1(("SETUPFILE" "FILETAGS" "TAGS" "ARCHIVE" "CATEGORY" 
> "COLUMNS" "CONSTANTS" "LINK" "OPTIONS" "PRIORITIES"
>  "PROPERTY" "SEQ_TODO" "STARTUP" "TODO" "TYP_TODO") ("ARCHIVE" "CATEGORY" 
> "COLUMNS" "PRIORITIES") nil nil nil)
>   org-collect-keywords(("FILETAGS" "TAGS" "ARCHIVE" "CATEGORY" "COLUMNS" 
> "CONSTANTS" "LINK" "OPTIONS" "PRIORITIES" "PROPERTY"
>  "SEQ_TODO"
>  "STARTUP" "TODO" "TYP_TODO") ("ARCHIVE" 

Re: Empty headline titles unsupported: Bug?

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> Could an extensible pre-hook that runs a list of functions take care of
>> the inconsistencies where each function recognizes one change to the
>> standard grammar and adjusts the input accordingly?
>
> Could you elaborate? For now, this sounds like unnecessary
> over-complication. Why would we need to introduce deviations from
> grammar in different functions?

Testing the usefulness of extensions to the grammar before they're added
to the grammar..?

Thinking about it, though, I'm not sure how you could "pre-parse" a
section of the file, make changes to the file via an extension, then
roll back the file pointer and let the regular parser take over.  I was
thinking of a "hook" approach where, when the parser gets to a certain
point (beginning of a header?), it could call the hooks with the current
spot as input.  If the hooks try to "extract" something from the input
(to process it and hide it from the regular grammar), I have a feeling
that would mess up the base parser.

It was just an idea... ;)

-- 
David Masterson

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Matt Price]

I'm trying to run this on a fairly recent emacs-master w/ native-comp
enable, using  ~emacs -Q ~/test-cites.org~, where test-cites.org is this:

#+cite_export: csl
"/home/matt/Zotero/styles/chicago-manual-of-style-16th-edition-inline-notes-for-syllabi.csl"
#+bibliography: /home/matt/.emacs.d/zotero-refs.bib
#+begin_src emacs-lisp
  (package-initialize)
  (add-to-list 'package-archives
  '("melpa" . "https://melpa.org/packages/;))
  (add-to-list 'load-path "~/src/org-mode/emacs/site-lisp/org")

  (org-reload)
  (add-to-list 'load-path "~/src/org-mode/lisp")
  (require 'oc)
  (require 'citeproc)
  (require 'oc-csl)
#+end_src

[cite:@zittrain_future_2008]

trying to execute the src block gives me a segfault on org-reload, with
different messages each time. Any idea how I should diagnose, or am I
perhaps doing something wrong?

On Thu, May 27, 2021 at 12:18 PM Bruce D'Arcus  wrote:

> On Thu, May 27, 2021 at 11:02 AM Bruce D'Arcus  wrote:
>
> > One other thing I tested just now not yet accounted for: a locator
> > whose values is a list; for example, that renders as (Doe 2019, pp.
> > 23, 25).
> >
> > Is there an easy way to handle that?
>
> Nevermind; this works as expected.
>
> [cite:@latexcompanion p.23, 24]
>
> Bruce
>
>

Re: [BUG] New error: (void-function org-url-p) when exporting to LaTeX [9.4.6 (9.4.6-gc5573b @ /Users/stanton/.emacs.d/straight/build/org/)]

[Richard Stanton]

Thanks, Tim. 

I deleted all org-related files and started again, with the same result. 

Oddly, I do find reference to org-url-p in my basic org setup:

Richards-Mac-Pro:~/.emacs.d/straight/repos/org/lisp stanton$ grep -i org-url-p 
*.el  
org-compat.el:(define-obsolete-function-alias 'org-file-url-p 'org-url-p "9.5")
org-lint.el:  (and (not (org-url-p file))
org-macs.el:(defun org-url-p (s)
org.el:   (uri-is-url (org-url-p uri))
org.el:  (let* ((is-url (org-url-p file))
org.el:(when (org-url-p file)
Richards-Mac-Pro:~/.emacs.d/straight/repos/org/lisp stanton$ 

I currently load org using straight.el as follows:

(setq package-archives
'(("melpa" . "http://melpa.org/packages/;)
  ("gnu" . "http://elpa.gnu.org/packages/;)
  ("nongnu" . "http://elpa.gnu.org/nongnu/;)))
;;;  ("org" . "http://orgmode.org/elpa/;)))

(use-package org-contrib
  :after org
  :config
  (require 'ox-extra)
  (ox-extras-activate '(ignore-headlines))
)

(use-package org
  :after (jupyter)
  :straight t
  :mode (("\\.org$" . org-mode))
;  :ensure org-plus-contrib
  :config
  (org-babel-do-load-languages
   'org-babel-load-languages
   '((jupyter . t)))
  :bind
  ("C-c l" . org-store-link)
  ("C-c a" . org-agenda)
  :init
  (add-hook 'org-mode-hook (lambda () (setq-local company-minimum-prefix-length 
0)))

Best,

Richard



> From: Tim Cross 
> To: emacs-orgmode@gnu.org
> Subject: Re: [BUG] New error: (void-function org-url-p) when exporting
>   to LaTeX [9.4.6 (9.4.6-gc5573b @
>   /Users/stanton/.emacs.d/straight/build/org/)]
> Message-ID: <87tumomy05@gmail.com>
> Content-Type: text/plain
> 
> 
> OK, think I've worked out what the problem is.
> 
> The function org-url-p is defined in org 9.5, but not org 9.4. Your
> running org 9.4.6, which does not have that function. The fact something
> in your install is trying to call org-url-p would indicate you have a
> mixed or messed up installation of org (i.e. your setup is loading code
> from 2 different versions).
> 
> It is very important when upgrading or installing org that no org
> functionality is yet loaded to avoid this type of issue. Your best bet
> is to remove all org related packages and then try installing org again.
> If your using package.el to install org, make sure the call to install
> it is early in your init file (before any functionality is loaded which
> depends on org). I also find the use-pacakge macro very useful in this
> regard as you can also setup things so that no org functionality is
> loaded until you try to use something which depends on org. This means
> you can typically start Emacs and immediately install/upgrade org
> without any issues. Where people tend to come undone is when they have
> been running Emacs for a while, have been using org and then to a
> package update and the system tries to install a new version of org
> (usually only an issue with new major versions rather than patch fix
> version updates). 
> 
> Richard Stanton  writes:
> 
>> 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.
>> 
>> 
>> Everything worked fine until yesterday, but today when I try to export an 
>> org file that contains the line
>> 
>> #+SETUPFILE: 
>> https://fniessen.github.io/org-html-themes/org/theme-readtheorg.setup
>> 
>> I get the following error:
>> 
>> Debugger entered--Lisp error: (void-function org-url-p)
>>  org-url-p("https://fniessen.github.io/org-html-themes/org/the...;)
>>  org--collect-keywords-1(("SETUPFILE" "FILETAGS" "TAGS" "ARCHIVE" "CATEGORY" 
>> "COLUMNS" "CONSTANTS" "LINK" "OPTIONS" "PRIORITIES"
>> "PROPERTY" "SEQ_TODO" "STARTUP" "TODO" "TYP_TODO") ("ARCHIVE" "CATEGORY" 
>> "COLUMNS" "PRIORITIES") nil nil nil)
>>  org-collect-keywords(("FILETAGS" "TAGS" "ARCHIVE" "CATEGORY" "COLUMNS" 
>> "CONSTANTS" "LINK" "OPTIONS" "PRIORITIES" "PROPERTY" "SEQ_TODO"
>> "STARTUP" "TODO" "TYP_TODO") ("ARCHIVE" "CATEGORY" "COLUMNS" "PRIORITIES"))
>>  org-set-regexps-and-options()
>>  org-mode()
>>  org-export--prepare-file-contents("/Users/stanton/.org/setup" nil 0 1 1 
>> #
>> "/Users/stanton/teaching/MFE230I/mfe230i.org")
>>  org-export-expand-include-keyword()
>>  org-export-as(latex nil nil nil (:output-file "mfe230i.tex"))
>>  org-export-to-file(latex "mfe230i.tex" nil nil nil nil nil 
>> #f(compiled-function (file) #))
>>  org-latex-export-to-pdf(nil nil nil nil)
>>  org-export-dispatch(nil)
>>  funcall-interactively(org-export-dispatch nil)
>>  call-interactively(org-export-dispatch nil nil)
>>  command-execute(org-export-dispatch)
>> 
>> Thanks for any suggestions.
>> 
>> Emacs  : GNU Emacs 27.2 (build 1, x86_64-apple-darwin20.3.0, Carbon Version 
>> 164 AppKit 2022.3)
>> of 2021-04-06
>> Package: Org mode 

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Thu, May 27, 2021 at 11:02 AM Bruce D'Arcus  wrote:

> One other thing I tested just now not yet accounted for: a locator
> whose values is a list; for example, that renders as (Doe 2019, pp.
> 23, 25).
>
> Is there an easy way to handle that?

Nevermind; this works as expected.

[cite:@latexcompanion p.23, 24]

Bruce

Re: [PATCH] org-faq.org: Expand "What is the best setup for indenting?"

[Maxim Nikulin]

Hi Greg,

Bastien merged that patch just before I was going to modify it in 
response to your suggestions. I think, 3 commits is too much noise in 
git history for the single item in FAQ. However I can to prepare one 
more correction. Maybe you have got a better idea how to avoid confusion 
with Org versions in the tables.


On 21/05/2021 09:45, Greg Minshall wrote:



I have no idea how to express it in a better way. The tables are same
for Org >= 9.5 and for Org < 9.5 (modulo bugs in indentation fixed in
9.4.6).  Only default configuration evolves in time.


again, i apologize.  my confusion was in not having read the text to
understand that the "(Org >= 9.5)" was the default.  i assumed it meant,
"this is the behavior for Org >= 9.5", even though that meant the tables
really didn't make sense.  if you wanted to compensate for such a "user
feature" :), maybe remove "(Org >= 9.5)", and add that information as a
short "NB:" line after each table?

...

sorry, i should have caught *both* "relatively".  i'd suggest


a. "do not indent anything",
"always indent relative to the element above",
"indent just ~PROPERTIES/LOGBOOK~ drawers relative
to the current heading level"


which klings better to my ears.  (sadly, i can't explain any grammatical
reason why, though.)

Re: Bug: Priority Of A Task In Emacs 27.2 Cannot Be Removed With Space Key ("SPC to remove")

[Tim Cross]

Confirmed.

Yes, I would agree that not being able to clear the priority by entering
space when using numeric priorities is a bug. The minibuffer prompt even
states you can enter a space character to clear the priority.

To reproduce -

set the org variables


(setq org-priority-highest 1
  org-priority-lowest 10
  org-priority-default 5)

Use C-c , to set a priority on a TODO item.
Use C-c , and enter a space 

Observe the priority cookie is not removed.

This only occurs with numeric priority values. The default letter based
priority values and space to clear functionality work as expected.

Org version: 9.4.6
Emacs version 27.2

"Samuel Banya"  writes:

> Gotcha, yeah I only use priority 1 through 5 with a kind of "Getting Things 
> Done" mentality to file things away in their right place.
>
> I don't like using letters unfortunately, but thanks for this potential 
> workaround in that case.
>
> Clearing priorities with a space and enter doesn't work though, and I believe 
> this is a bug.
>
> On Thu, May 27, 2021, at 1:26 AM, Tim Cross wrote:
>
>  Not sure how easy it would be to restore the previous behaviour. I guess
>  if you restricted numerical priorities to 0 .. 9 it would be reasonably
>  easy as you only need to check for a single key press. However, once you
>  go above 9 and have the situation where the value could be more than a
>  single key press, you have no way to know when input is finished.
>
>  It should be noted that the old behaviour using letters for priorities
>  still works (as does clearing wiht a space). Personally, I've always
>  been happy with just letters and 3 priorities. I find once you go past
>  about 3 or 4, priorities don't have a lot of value. YMMV of course.
>
>  "Samuel Banya"  writes:
>
>  > Thanks for confirming this as I didn't know if it was my config or 
> something.
>  >
>  > I'd like to add if possible, if there would the ability to restore the 
> previously functionality of being able to just hit a number from 1 to 9 to 
> set the
>  priority
>  > of a task as well.
>  >
>  > Didn't want to conflate things too much, but it would be great if there 
> was a config option around this before I would have to make a workaround
>  in Elisp
>  > instead.
>  >
>  > On Thu, May 27, 2021, at 4:05 AM, Tim Cross wrote:
>  >
>  >  Confirmed
>  >
>  >  I can reproduce this in org 9.4.6, Emacs 27.2. Bug confirmed.
>  >
>  >  "Samuel Banya"  writes:
>  >
>  >  > Hello there,
>  >  >
>  >  > I noticed a weird bug within Emacs Org Mode as I use it often for my 
> TODO lists for both personal use and for work.
>  >  >
>  >  > I noticed that if you hit "C-c ," you are prompted nowadays to enter a 
> number from like 1 to whatever your highest priority was set to, and that
>  >  you have
>  >  > to enter in the number and THEN press enter.
>  >  >
>  >  > This behavior on a side note is a little annoying since I usually only 
> use priorities 1 through 5, and don't want to have to hit enter each time. I
>  kind
>  >  of wish
>  >  > I could just go back to just hitting '1' or '5' and moving on. But, I 
> understand this was to make the ceiling of the highest priority be like 65 or
>  >  something
>  >  > like that, so I understand why this was included.
>  >  >
>  >  > My main point is that the "SPC to remove" option doesn't actually work.
>  >  >
>  >  > If you try doing "C-c ," then hit Space, and then press Enter, the 
> priority of the task still remains the same.
>  >  >
>  >  > Workaround:
>  >  > I've had to manually delete the priority number as a workaround which 
> is a bit annoying.
>  >  > I've used F3 as a on-the-fly macro to quickly do this across multiple 
> todo list items as well.
>  >  > However, it does feel a little awkward having to do this, so I'm 
> wondering if anyone has encountered this as well.
>  >  >
>  >  > Thanks,
>  >  >
>  >  > Sam
>  >
>  >  -- 
>  >  Tim Cross
>
>  -- 
>  Tim Cross


-- 
Tim Cross

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Thu, May 27, 2021 at 10:34 AM Bruce D'Arcus  wrote:
>
> On Thu, May 27, 2021 at 10:18 AM Bruce D'Arcus  wrote:
>
> > I was expecting (not to say I should have necessarily) in this case:
> >
> > [cite:@doe p23]
> >
> > ... that either "p23" is recognized as a locator, or as a suffix
> > string for the citation reference.
>
> To be clear, Nicolas, your change to the regex this today, however,
> does recognize that as a locator, so this specific example is a
> non-issue ATM.

Although, users should probably be encouraged to use the "p.1" syntax,
so it's consistent with one or a range.

One other thing I tested just now not yet accounted for: a locator
whose values is a list; for example, that renders as (Doe 2019, pp.
23, 25).

Is there an easy way to handle that?

If not, it would seem even more important to output that as a suffix
string, so users can still get the output they want?

One other question:

Right now, citeproc-el, and hence also oc-csl, only supports the "bare" variant.

Would it be feasible, and make sense, to fall back all "bare" variants
to "bare" for now?

So this:

[cite//bare-caps:@latexcompanion]

... would render as:

Doe 2019

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Thu, May 27, 2021 at 10:18 AM Bruce D'Arcus  wrote:

> I was expecting (not to say I should have necessarily) in this case:
>
> [cite:@doe p23]
>
> ... that either "p23" is recognized as a locator, or as a suffix
> string for the citation reference.

To be clear, Nicolas, your change to the regex this today, however,
does recognize that as a locator, so this specific example is a
non-issue ATM.

I am still curious about the behavior though.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Thu, May 27, 2021 at 9:12 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > On Thu, May 27, 2021 at 4:01 AM Denis Maier  wrote:
>
> >> I think a plain "p" in front of a number is not recognized as a locator
> >> prefix.
> >> Nicolas's post mentions "page", "p.", "pp." as valid locator terms for
> >> page. So in your case this here seems to apply: "The part of the suffix
> >> before the locator is appended to reference's prefix."
> >
> > I missed the significance of that last part.
> >
> > What's the use case there Nicolas?
>
> This was ported from Citeproc Org library. I don't think there's a use
> case, but that information should not be dropped silently, so it's a way
> to do "something" about it.

OK, I guess the question is for Andras then.

I was expecting (not to say I should have necessarily) in this case:

[cite:@doe p23]

... that either "p23" is recognized as a locator, or as a suffix
string for the citation reference.

I'm having a hard time understanding why one would want that "p" to be
added to the prefix.

Andras? Anyone else?

Bruce

Re: bug#48676: Arbitrary code execution in Org export macros

[Rafael Ramirez Morales]

Thanks, you managed to understand my question. I was wondeing if there was
a risk of privilege escalation. Fortunately that seems not to be the case.


El jue., 27 may. 2021 15:13, Tim Cross  escribió:

>
> Rafael Ramirez Morales  writes:
>
> > Just a couple of questions:
> > who is the owner of the HELLO file?
> > OR
> > who is the owner of the "touch" process?
> >
> > Is the owner the unprivileged user or the "emacs" system?
> >
> > Thanks.
> >
>
> Not clear exactly what your asking. The process which will execute the
> 'touch' will be a sub-process of the process running Emacs. This will
> typically be the user who executes Emacs and willl have the same
> permissions and access rights as the user running Emacs. There is no
> 'emacs' system and the privileges will be the same as the user who runs
> Emacs. This is assuming a 'normal' installation, not some unusual setup
> which uses setuid or similar to alter the way Emacs runs or the
> ownership of files in a directory etc.
>
>

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> On Thu, May 27, 2021 at 4:01 AM Denis Maier  wrote:

>> I think a plain "p" in front of a number is not recognized as a locator
>> prefix.
>> Nicolas's post mentions "page", "p.", "pp." as valid locator terms for
>> page. So in your case this here seems to apply: "The part of the suffix
>> before the locator is appended to reference's prefix."
>
> I missed the significance of that last part.
>
> What's the use case there Nicolas?

This was ported from Citeproc Org library. I don't think there's a use
case, but that information should not be dropped silently, so it's a way
to do "something" about it.

> Aside from that, a bit more testing this morning, with plain, latex
> and html is looking good. I got exected output using default and the
> chicago-note-bibliography-16th-edition.csl style.

Great!

Regards,
-- 
Nicolas Goaziou

Re: Bug: Priority Of A Task In Emacs 27.2 Cannot Be Removed With Space Key ("SPC to remove")

[Samuel Banya]

Gotcha, yeah I only use priority 1 through 5 with a kind of "Getting Things 
Done" mentality to file things away in their right place.

I don't like using letters unfortunately, but thanks for this potential 
workaround in that case.

Clearing priorities with a space and enter doesn't work though, and I believe 
this is a bug.

On Thu, May 27, 2021, at 1:26 AM, Tim Cross wrote:
> 
> Not sure how easy it would be to restore the previous behaviour. I guess
> if you restricted numerical priorities to 0 .. 9 it would be reasonably
> easy as you only need to check for a single key press. However, once you
> go above 9 and have the situation where the value could be more than a
> single key press, you have no way to know when input is finished.
> 
> It should be noted that the old behaviour using letters for priorities
> still works (as does clearing wiht a space). Personally, I've always
> been happy with just letters and 3 priorities. I find once you go past
> about 3 or 4, priorities don't have a lot of value. YMMV of course.
> 
> "Samuel Banya" mailto:sbanya%40fastmail.com>> writes:
> 
> > Thanks for confirming this as I didn't know if it was my config or 
> > something.
> >
> > I'd like to add if possible, if there would the ability to restore the 
> > previously functionality of being able to just hit a number from 1 to 9 to 
> > set the priority
> > of a task as well.
> >
> > Didn't want to conflate things too much, but it would be great if there was 
> > a config option around this before I would have to make a workaround in 
> > Elisp
> > instead.
> >
> > On Thu, May 27, 2021, at 4:05 AM, Tim Cross wrote:
> >
> >  Confirmed
> >
> >  I can reproduce this in org 9.4.6, Emacs 27.2. Bug confirmed.
> >
> >  "Samuel Banya" mailto:sbanya%40fastmail.com>> writes:
> >
> >  > Hello there,
> >  >
> >  > I noticed a weird bug within Emacs Org Mode as I use it often for my 
> > TODO lists for both personal use and for work.
> >  >
> >  > I noticed that if you hit "C-c ," you are prompted nowadays to enter a 
> > number from like 1 to whatever your highest priority was set to, and that
> >  you have
> >  > to enter in the number and THEN press enter.
> >  >
> >  > This behavior on a side note is a little annoying since I usually only 
> > use priorities 1 through 5, and don't want to have to hit enter each time. 
> > I kind
> >  of wish
> >  > I could just go back to just hitting '1' or '5' and moving on. But, I 
> > understand this was to make the ceiling of the highest priority be like 65 
> > or
> >  something
> >  > like that, so I understand why this was included.
> >  >
> >  > My main point is that the "SPC to remove" option doesn't actually work.
> >  >
> >  > If you try doing "C-c ," then hit Space, and then press Enter, the 
> > priority of the task still remains the same.
> >  >
> >  > Workaround:
> >  > I've had to manually delete the priority number as a workaround which is 
> > a bit annoying.
> >  > I've used F3 as a on-the-fly macro to quickly do this across multiple 
> > todo list items as well.
> >  > However, it does feel a little awkward having to do this, so I'm 
> > wondering if anyone has encountered this as well.
> >  >
> >  > Thanks,
> >  >
> >  > Sam
> >
> >  -- 
> >  Tim Cross
> 
> 
> -- 
> Tim Cross
> 
> 

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

Denis Maier  writes:

> I think a plain "p" in front of a number is not recognized as
> a locator prefix.
> Nicolas's post mentions "page", "p.", "pp." as valid locator terms for
> page. So in your case this here seems to apply: "The part of the
> suffix before the locator is appended to reference's prefix."

That's correct.

I updated the regexp matching locators to handle this case (and others).
So "p23" is now recognized (but not "p23-25" for example).

Regards,
-- 
Nicolas Goaziou

Re: bug#48676: Arbitrary code execution in Org export macros

[Tim Cross]

Rafael Ramirez Morales  writes:

> Just a couple of questions:
> who is the owner of the HELLO file?
> OR
> who is the owner of the "touch" process?
>
> Is the owner the unprivileged user or the "emacs" system?
>
> Thanks.
>

Not clear exactly what your asking. The process which will execute the
'touch' will be a sub-process of the process running Emacs. This will
typically be the user who executes Emacs and willl have the same
permissions and access rights as the user running Emacs. There is no
'emacs' system and the privileges will be the same as the user who runs
Emacs. This is assuming a 'normal' installation, not some unusual setup
which uses setuid or similar to alter the way Emacs runs or the
ownership of files in a directory etc. 

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Wed, May 26, 2021 at 4:39 PM Nicolas Goaziou  wrote:

> The processor uses the "en-US" CSL locale file shipped with Org for rendering
> localized dates and terms in the references, independently of the language
> settings of the Org document.  Additional CSL locales can be made available
> by setting `org-cite-csl-locales-dir' to a directory containing the locale
> files in question (see 
> for such files).  The directory must contain at least the "en-US" CSL locale.

So if I setup a separate directory for different locales files, I also
have to include the default locale that's already shipped with org?

That seems a bit odd.

Related, could we also have a  `org-cite-csl-styles-dir' defcustom, to
avoid having to specify the full path?

And/or alternately just  `org-cite-csl-dir' for both locales and styles?

Also, is it possible for me to set things up so that export to latex
runs through the oc-biblatex processor, but otherwise it uses oc-csl,
where I have (obviously) different styles for each?

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Thu, May 27, 2021 at 4:01 AM Denis Maier  wrote:
>
> Am 27.05.2021 um 03:58 schrieb Bruce D'Arcus:
> > On Wed, May 26, 2021 at 8:47 PM Bruce D'Arcus  wrote:
> >
> >> BTW, I did get it all setup, and do seem to have run into a bug.
> >>
> >> Input:
> >>
> >> [cite/noauthor:@latexcompanion p23]
> >>
> >> Output (not position of the locator label):
> >>
> >> (p 1993, 23)
> >
> > Hmm ... experimenting some more, these work correctly.
> >
> > [cite/noauthor:@latexcompanion page 23]
> > [cite/noauthor:@latexcompanion p. 23]
> > [cite/noauthor:@latexcompanion p.23]
> >
> > Still not sure why the above with the p at the front though.
>
> I think a plain "p" in front of a number is not recognized as a locator
> prefix.
> Nicolas's post mentions "page", "p.", "pp." as valid locator terms for
> page. So in your case this here seems to apply: "The part of the suffix
> before the locator is appended to reference's prefix."

I missed the significance of that last part.

What's the use case there Nicolas?

Aside from that, a bit more testing this morning, with plain, latex
and html is looking good. I got exected output using default and the
chicago-note-bibliography-16th-edition.csl style.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

Denis Maier  writes:

> I've just tried to test this, but I can't get it to work.
>
> I've done
> git pull
> make
>
> And I'm getting:
> In toplevel form:
> oc-csl.el:93:1:Error: Cannot open load file: No such file or
> directory, citeproc
>
> Do you have an idea what's going wrong here?

You need to add the external Citeproc library
() to your load path.
Otherwise, the library won't compile.

Regards,
-- 
Nicolas Goaziou

bug#48676: Arbitrary code execution in Org export macros

[Rafael Ramirez Morales]

Just a couple of questions:
who is the owner of the HELLO file?
OR
who is the owner of the "touch" process?

Is the owner the unprivileged user or the "emacs" system?

Thanks.

On Wed, 26 May 2021 at 17:53, Glenn Morris  wrote:

> Package: emacs,org-mode
> Version: 28.0.50
> Severity: important
> Tags: security
>
> emacs -Q hello.org, where hello.org contains:
>
> #+macro: hello (eval (shell-command-to-string "touch /tmp/HELLO"))
> Hello. {{{hello}}}
>
> Then:
> M-x org-export-dispatch
> t A
>
> -> now /tmp/HELLO exist, with no prompting.
>
> This seems contrary to normal Emacs practice for risky local variables,
> and to the section "Code Evaluation and Security Issues" in the Org manual
> (which does not mention macros).
>
>

Re: What's up with ob-template.el? It seems heavily outdated

[Nicholas Savage]

Thanks for working on updating the template!

If the worg ob-template.el is broken, I feel like your updates should be 
replacing what is there, even if it isn't perfect yet. I can help you replace 
it if you would like to be contributing your version to improving the 
documentation.

On Wed, May 26, 2021, at 08:07, dalanicolai wrote:
> Ha! Well not too much response here...
> 
> Anyway @Pedro:
> So I do not have too much time to work on an updated template. But I have 
> added a somewhat updated template file to my emacs-lisp repo here 
>  along with some handy tips 
> .
> Then of course you can further just check out examples of other ob-el 
> files. Hope this is useful.

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Denis Maier]

Hi,

Am 26.05.2021 um 22:33 schrieb Nicolas Goaziou:

thanks for this!

I've just tried to test this, but I can't get it to work.

I've done
git pull
make

And I'm getting:
In toplevel form:
oc-csl.el:93:1:Error: Cannot open load file: No such file or directory, 
citeproc


Do you have an idea what's going wrong here?

Best,
Denis


Hello,

I just pushed a Citeproc-based citation processor. As such, Citeproc
library must be available in the load path. For a better experience,
your also need to download styles, and possibly locales definitions, as
pointed in the commentary section pasted below.

I called it `csl' instead of `citeproc'. It is a bit ambiguous, but it
is shorter, and "org-cite-csl" prefix sounds less redudant than
"org-cite-citeproc...". Also, I don't expect a different CSL-based
citation processor any time soon, so it should be fine. But I know this
is a weak argument, so if you think "citeproc" is still more
appropriate, I can revisit this.

As pointed out in the commentary section, this is, for a large part,
a port of András Simonyi's Citeproc Org library. Thanks!

There are some differences between the two libraries, however. For
example, Org Cite CSL does not support Org Ref links. It also provides
less customization options. OTOH, it supports ".bib", ".bibtex" and
".json" bibliography files. It also handles author suppression and
global affixes in citations.

This patch adds two files in a new "etc/csl/" directory. They are both
licensed under CC BY-SA 3.0 terms. So I assume this is fine to
distribute them with Org.

Here is the full commentary. Feedback welcome!

--8<---cut here---start->8---
This library registers the `csl' citation processor, which provides
the "export" capability for citations.  You may activate it globally with

(setq org-cite-export-processor '(csl))

or at the document level, with

#+cite_export: csl

The processor relies on the external Citeproc Emacs library, which must be
available prior to loading this library.

By default, citations are rendered in Chicago author-date CSL style.  You can
use another style file by specifying it in `org-cite-export-processor'

(setq org-cite-export-processor '(csl "/path/to/style-file.csl")

or from within the document by adding the file name to "cite_export" keyword

#+cite_export: csl /path/to/style-file.csl
#+cite_export: csl "/path/to/style-file.csl"

Styles can be downloaded, for instance, from the Zotero Style Repository
().  Dependent styles (which are not "unique"
in the Zotero Style Repository terminology) are not supported.

The processor uses the "en-US" CSL locale file shipped with Org for rendering
localized dates and terms in the references, independently of the language
settings of the Org document.  Additional CSL locales can be made available
by setting `org-cite-csl-locales-dir' to a directory containing the locale
files in question (see 
for such files).  The directory must contain at least the "en-US" CSL locale.

Bibliography is defined with the "bibliography" keyword.  It supports files
with ".bib", ".bibtex", and ".json" extensions.  References are exported using
the "print_bibliography" keyword.

The library supports the following citation styles:

- noauthor (na), including bare (b) variant,
- default style, including bare (b) variant.

CSL styles recognize "locator" in citation references' suffix.  For example,
in the citation

 [cite:see @Tarski-1965 chapter 1, for an example]

"chapter 1" is the locator.  The whole citation is rendered as

 (see Tarski 1965, chap. 1 for an example)

in the default CSL style.

The locator starts with a locator term, among "bk.", "bks.", "book", "chap.",
"chaps.", "chapter", "col.", "cols.", "column", "figure", "fig.", "figs.",
"folio", "fol.", "fols.", "number", "no.", "nos.", "line", "l.", "ll.",
"note", "n.", "nn.", "opus", "op.", "opp.", "page", "p.", "pp.", "paragraph",
"para.", "paras.", "¶", "¶¶", "§", "§§", "part", "pt.", "pts.", "section",
"sec.", "secs.", "sub verbo", "s.v.", "s.vv.", "verse", "v.", "vv.",
"volume", "vol.", and "vols.".  It ends with the last comma or digit in the
suffix, whichever comes last, or runs till the end of the suffix.

The part of the suffix before the locator is appended to reference's prefix.
If no locator term is used, but a number is present, then "page" is assumed.

This library was heavily inspired by and borrows from András Simonyi's
Citeproc Org () library.
Many thanks to him!
--8<---cut here---end--->8---

Regards,

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Denis Maier]

Am 27.05.2021 um 03:58 schrieb Bruce D'Arcus:

On Wed, May 26, 2021 at 8:47 PM Bruce D'Arcus  wrote:


BTW, I did get it all setup, and do seem to have run into a bug.

Input:

[cite/noauthor:@latexcompanion p23]

Output (not position of the locator label):

(p 1993, 23)


Hmm ... experimenting some more, these work correctly.

[cite/noauthor:@latexcompanion page 23]
[cite/noauthor:@latexcompanion p. 23]
[cite/noauthor:@latexcompanion p.23]

Still not sure why the above with the p at the front though.


I think a plain "p" in front of a number is not recognized as a locator 
prefix.
Nicolas's post mentions "page", "p.", "pp." as valid locator terms for 
page. So in your case this here seems to apply: "The part of the suffix 
before the locator is appended to reference's prefix."


Denis


Bruce

Re: [BUG] New error: (void-function org-url-p) when exporting to LaTeX [9.4.6 (9.4.6-gc5573b @ /Users/stanton/.emacs.d/straight/build/org/)]

[Tim Cross]

OK, think I've worked out what the problem is.

The function org-url-p is defined in org 9.5, but not org 9.4. Your
running org 9.4.6, which does not have that function. The fact something
in your install is trying to call org-url-p would indicate you have a
mixed or messed up installation of org (i.e. your setup is loading code
from 2 different versions).

It is very important when upgrading or installing org that no org
functionality is yet loaded to avoid this type of issue. Your best bet
is to remove all org related packages and then try installing org again.
If your using package.el to install org, make sure the call to install
it is early in your init file (before any functionality is loaded which
depends on org). I also find the use-pacakge macro very useful in this
regard as you can also setup things so that no org functionality is
loaded until you try to use something which depends on org. This means
you can typically start Emacs and immediately install/upgrade org
without any issues. Where people tend to come undone is when they have
been running Emacs for a while, have been using org and then to a
package update and the system tries to install a new version of org
(usually only an issue with new major versions rather than patch fix
version updates). 

Richard Stanton  writes:

> 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.
> 
>
> Everything worked fine until yesterday, but today when I try to export an org 
> file that contains the line
>
> #+SETUPFILE: 
> https://fniessen.github.io/org-html-themes/org/theme-readtheorg.setup
>
> I get the following error:
>
> Debugger entered--Lisp error: (void-function org-url-p)
>   org-url-p("https://fniessen.github.io/org-html-themes/org/the...;)
>   org--collect-keywords-1(("SETUPFILE" "FILETAGS" "TAGS" "ARCHIVE" "CATEGORY" 
> "COLUMNS" "CONSTANTS" "LINK" "OPTIONS" "PRIORITIES"
> "PROPERTY" "SEQ_TODO" "STARTUP" "TODO" "TYP_TODO") ("ARCHIVE" "CATEGORY" 
> "COLUMNS" "PRIORITIES") nil nil nil)
>   org-collect-keywords(("FILETAGS" "TAGS" "ARCHIVE" "CATEGORY" "COLUMNS" 
> "CONSTANTS" "LINK" "OPTIONS" "PRIORITIES" "PROPERTY" "SEQ_TODO"
> "STARTUP" "TODO" "TYP_TODO") ("ARCHIVE" "CATEGORY" "COLUMNS" "PRIORITIES"))
>   org-set-regexps-and-options()
>   org-mode()
>   org-export--prepare-file-contents("/Users/stanton/.org/setup" nil 0 1 1 
> #
> "/Users/stanton/teaching/MFE230I/mfe230i.org")
>   org-export-expand-include-keyword()
>   org-export-as(latex nil nil nil (:output-file "mfe230i.tex"))
>   org-export-to-file(latex "mfe230i.tex" nil nil nil nil nil 
> #f(compiled-function (file) #))
>   org-latex-export-to-pdf(nil nil nil nil)
>   org-export-dispatch(nil)
>   funcall-interactively(org-export-dispatch nil)
>   call-interactively(org-export-dispatch nil nil)
>   command-execute(org-export-dispatch)
>
> Thanks for any suggestions.
>
> Emacs  : GNU Emacs 27.2 (build 1, x86_64-apple-darwin20.3.0, Carbon Version 
> 164 AppKit 2022.3)
>  of 2021-04-06
> Package: Org mode version 9.4.6 (9.4.6-gc5573b @ 
> /Users/stanton/.emacs.d/straight/build/org/)


-- 
Tim Cross

Re: [BUG] New error: (void-function org-url-p) when exporting to LaTeX [9.4.6 (9.4.6-gc5573b @ /Users/stanton/.emacs.d/straight/build/org/)]

[Tim Cross]

Richard Stanton  writes:

> 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.
> 
>
> Everything worked fine until yesterday, but today when I try to export an org 
> file that contains the line
>
> #+SETUPFILE: 
> https://fniessen.github.io/org-html-themes/org/theme-readtheorg.setup
>
> I get the following error:
>
> Debugger entered--Lisp error: (void-function org-url-p)
>   org-url-p("https://fniessen.github.io/org-html-themes/org/the...;)
>   org--collect-keywords-1(("SETUPFILE" "FILETAGS" "TAGS" "ARCHIVE" "CATEGORY" 
> "COLUMNS" "CONSTANTS" "LINK" "OPTIONS" "PRIORITIES"
> "PROPERTY" "SEQ_TODO" "STARTUP" "TODO" "TYP_TODO") ("ARCHIVE" "CATEGORY" 
> "COLUMNS" "PRIORITIES") nil nil nil)
>   org-collect-keywords(("FILETAGS" "TAGS" "ARCHIVE" "CATEGORY" "COLUMNS" 
> "CONSTANTS" "LINK" "OPTIONS" "PRIORITIES" "PROPERTY" "SEQ_TODO"
> "STARTUP" "TODO" "TYP_TODO") ("ARCHIVE" "CATEGORY" "COLUMNS" "PRIORITIES"))
>   org-set-regexps-and-options()
>   org-mode()
>   org-export--prepare-file-contents("/Users/stanton/.org/setup" nil 0 1 1 
> #
> "/Users/stanton/teaching/MFE230I/mfe230i.org")
>   org-export-expand-include-keyword()
>   org-export-as(latex nil nil nil (:output-file "mfe230i.tex"))
>   org-export-to-file(latex "mfe230i.tex" nil nil nil nil nil 
> #f(compiled-function (file) #))
>   org-latex-export-to-pdf(nil nil nil nil)
>   org-export-dispatch(nil)
>   funcall-interactively(org-export-dispatch nil)
>   call-interactively(org-export-dispatch nil nil)
>   command-execute(org-export-dispatch)
>
> Thanks for any suggestions.
>
> Emacs  : GNU Emacs 27.2 (build 1, x86_64-apple-darwin20.3.0, Carbon Version 
> 164 AppKit 2022.3)
>  of 2021-04-06
> Package: Org mode version 9.4.6 (9.4.6-gc5573b @ 
> /Users/stanton/.emacs.d/straight/build/org/)

Doing a grep for org-url-p in the org-plus-contrib package *.el files
finds no reference to org-url-p (no calls, no definition). Could this
perhaps be from some add on package rather than part of org?


-- 
Tim Cross