Re: [BUG] clocktable :inherit-props does not respect global property setting [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/jet/.config/emacs/elpa/org-20210823/)]

[Colin Baxter 😺]

Hello Jeff

You clock table works for me, including your missing rate of 150. I
attach a screen shot.

By the way, you have a ":inherit-props t" which is not on the #+BEGIN:
clocktable line. I assume that has been corrupted in the email
formatting.

Best wishes

Re: [org-cite] autoload oc processors?

[Denis Maier]

Am 29.11.2021 um 23:48 schrieb Nicolas Goaziou:

Hello,

Timothy  writes:


A more sophisticated solution probably exists, but my thought was that if a cite
export keyword like this is seen:
┌
│ #+cite_export: FORMAT ...
└

and there is no known cite backend `FORMAT', then we could just try running
┌
│ (require 'oc-FORMAT nil t)
└

before complaining that there’s no cite backend FORMAT loaded.

This relies on consistent naming, but since that seems to hold pretty well so
far and failure to load just results in the current behaviour, I’m inclined to
think this would be a good change in terms of user experience.


OK. I implemented this on main branch. We'll see how it goes.



Thanks, that sounds like a good change!
Best,
Denis

Clocktable parameters

[Colin Baxter 😺]

Hello,

I find the differences between the variables

(1) org-clocktable-defaults
(2) org-agenda-clockreport-parameter-plist

hard to understand.

Ok, (1) seems reasonably clear. It's described in `info' (there's no
doc-string). The variable (2) confuses me. According to its doc string
(there's no `info' mention) it gives parameters for a clock table in
the daily and weekly agendas. How is that different from (1)?

Am I correct in thinking (1) is primarily for a clock table not
associated with the agenda? Quite how such a clocktable would arise is
unclear to me.

I would appreciate some pointers or a reference - thank you.


Best wishes,

Colin Baxter.

[Bug] incorrect indent of next heading after org-paste-subtree

[Max Nikulin]

Another old bug with org-paste-subtree.

It make indentation of next heading wrong.

Consider the following document and follow described steps:

 >8 
#+STARTUP: indent
Enable soft indent mode

Put to kill ring some text *without trailing newline*
that represents a subtree. In my case it is generated
by a browser extension.
#+begin_src elisp :results silent
  (kill-new "* Pasted Header\nPasted body")
#+end_src

Several levels of heading to make the problem apparent:
* H1
** H2
Ensure that the following "H3" heading is expanded,
put cursor to this line and try =C-c C-x C-y=
or [[elisp:(org-paste-subtree)]]
*** H3
:PROPERTIES:
:CUSTOM_ID: h3
:END:
Body
 8< 

Actual result:

 >8 
Several levels of heading to make the problem apparent:
* H1
*** H2
Ensure that the following "H3" heading is expanded,
put cursor to this line and try =C-c C-x C-y=
or elisp:(org-paste-subtree)
* Pasted Header
  Pasted body
* H3
  :PROPERTIES:
  :CUSTOM_ID: h3
  :END:
  Body
 8< 

Expected result

 >8 
Several levels of heading to make the problem apparent:
* H1
*** H2
Ensure that the following "H3" heading is expanded,
put cursor to this line and try =C-c C-x C-y=
or elisp:(org-paste-subtree)
* Pasted Header
  Pasted body
* H3
  :PROPERTIES:
  :CUSTOM_ID: h3
  :END:
  Body
 8< 

Org mode version 9.5 (release_9.5-225-g494c20

Re: [PATCH] Fontification for inline src blocks

[Timothy]

Pushed 🙂.

All the best,
Timothy

Re: [patch] fix ox-latex async export bug

[Sébastien Miquel]

Hi,

Nicolas Goaziou writes:

This is not really the same fix.


Indeed, but I tested it and it does work.


You're quoting a lambda, which should
not be required if the problem disappeared. IOW, the true fix probably
belong in the `org-export-async-start' function.


What happens is as follows
 1. This lambda is passed as the =post-process= variable of
    =org-export-to-file=.
 2. Which converts it to code using =`(funcall ',post-process)=
 3. Which =org-export-async-start= writes to a file, to be executed by
    the external emacs process.

I think native compilation compiles the lamdba in
=org-latex-export-to-pdf= and that there is no way to get back this
original lambda (the code) from within =org-export-to-file= or
=org-export-async-start=. Quoting the lambda prevents this
compilation.

My understanding of elisp and the native compilation business is quite
superficial, so this may be wrong.

Regards,

--
Sébastien Miquel

Re: [BUG] C-c C-* causes "org-element--cache: Unregistered buffer modifications detected."

[Max Nikulin]

On 21/11/2021 15:35, Ihor Radchenko wrote:

Max Nikulin writes:


C-\ russian-computer RET
A
C-*

Latin "A" to type Cyrillic "Ф"


Apparently, C-* on

Ф Put cursor on this line and hit =C-c C-*= to make it a heading

and just

Ф

are producing different buffer-chars-modified-tick/buffer-modified-tick
signatures. I have added this kind of edit and the one from your other
report [1] to the exception list. The commit is 28d47cfb8 (main).


Ihor, thank you for your work related to such issues. I had a hope to 
thank you for the fix, but I faced a warning again in a bit modified 
scenario. This time it is soft indent mode.


 >8 
#+startup: indent
Do not forget to activate settings above by =C-c C-c=

* H
Try =C-c C-*= on this line
 8< 

Warning (org-element-cache): org-element--cache: Unregistered buffer 
modifications detected. Resetting.
If this warning appears regularly, please report it to Org mode mailing 
list (M-x org-submit-bug-report).

The buffer is: new.org
 Current command: (nil 312 320)
 Chars modified: 312
 Buffer modified: 320
 Backtrace:
nil

First letter of new heading must be a capital one, though it can be 
Latin. Converting top-level "H" heading by C-c C-* does not cause such 
warning.



Given the growing number of such "special" cases, I also changed to code
to reset cache all the time but for "self-insert-command" in
russian-computer. Just to be safe. The warning will not be shown though.

[1] https://orgmode.org/list/sn5uaa$ehd$1...@ciao.gmane.io


I am not an active user of main branch (I was merely hunting for another 
bug), so I can not estimate performance penalty for large files due to 
continuous cache resetting. I do not follow emacs-devel mail list last 
weeks. Have you managed to negotiate with Eli concerning changes 
required in Emacs code? I mean some followups of


https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51766
#51766 29.0.50; Return value of buffer-chars-modified-tick changes when 
buffer text is not yet changed before inserting a character for 
non-latin input methods

Re: Unintended consequences of removing org-speed-commands-user

[Shankar Rao]

Thank you for the tip. I didn't realize that `member' could be used in
this way to insert an element at a particular point in a list. But
this doesn't address the main issue in my post, that the user has two
different approaches for adding commands to `org-speed-commands'
depending on whether it is a brand new command or overwriting an old
one.

After thinking about it over the weekend, I believe I've come up with
a simple solution that will achieve easy addition to/ modification of
`org-speed-commands' without bringing reverting back to
`org-speed-commands-user'. I'll submit a patch for this soon

Shankar

On Sun, Nov 28, 2021 at 1:15 PM  wrote:
>
>
> Hi,
>
> If you want to insert a new element in the list after a particular
> element, you could do :
>
> #+begin_src emacs-lisp
> (let ((bk (cdr (member '("Agenda Views etc") org-speed-commands
>   (setf (cdr (member '("Agenda Views etc") org-speed-commands))
> (cons '("@" . my-foobarized-speed-command) bk)))
> #+end_src
>
> Use append to insert a list of new elements instead of one.
>
> Also simply add a new list at the end, use append :
>
> #+begin_src emacs-lisp :results code
> (setq org-speed-commands
>   (append org-speed-commands '(("my foo commands!")
>("@" . my-foobarized-speed-command)
>("&" . my-barfooized-speed-command
> #+end_src
>
> However if you define many new commands, simply redefining the whole
> list is simpler ;)

Re: [PATCH] Fontification for inline src blocks

[Ihor Radchenko]

Timothy  writes:

>>> [use org-element]
>
> Ah right. We now also have the new thread about using org-element. I think 
> that
> sounds like a great change overall, but am still keen for this patch to go
> through for the moment — just as a stop gap till org-element exposes all the
> necessary information and there are some nice examples of using it for
> fontification.

Agree. I plan to do some work on org-element-based fontification, but
probably not in near future.

Also, note that your patch has unused let-binding:

In org-fontify-inline-src-blocks-1:
org-src.el:669:70: Warning: Unused lexical variable `initial-point'

Best,
Ihor

Question about using `org-add-note' programmatically

[Tor Kringeland]

I'm trying to write a function that adds a note to the current
`org-mode' heading.  Naively I write it as

  (defun my/add-note ()
(interactive)
(org-add-note)
(insert "some text")
(org-ctrl-c-ctrl-c))

but this does not work.  Calling the function (on a recent build of
Emacs 29) inserts the string "some text" into the current buffer and
then opens up the note from `org-add-note'.  (IIRC this used to work
earlier this year (in September) but I don't know why (nor is it
relevant).)  Currently my solution has been to define the function as a
keyboard macro (using `fset'), which works perfectly, but I do hanker
for a cleaner solution.

Maybe what I want isn't the intended behavior of these `org' functions,
but does someone know how I can achieve what I want in a cleaner way,
than using keyboard macros?

Re: [PATCH] Fontification for inline src blocks

[Sébastien Miquel]

Hi,

Timothy writes:

Pushed 🙂.


Sorry for the late reply, but isn't there a =message= call leftover from 
debugging ?


Regards,

--
Sébastien Miquel

[ANN] ox-pandoc, revived

[Alex Fenton]

Hello,

ox-pandoc is an exporter for Org Mode that uses pandoc 
(https://pandoc.org/) to export to a very wide variety of text markup 
(e.g. markdown variants), document (ODT, docx) and presentation (e.g. 
html, .pdf) formats. It is available via MELPA and at: 
https://github.com/emacsorphanage/ox-pandoc


pandoc handles almost all org text-markup features and offers many 
options for controlling output. With ox-pandoc, it can also be used with 
Org Mode's code evaluation.


ox-pandoc was originally created by kawabata, but had fallen out of step 
over the past few years with recent pandoc and Org Mode versions. As a 
result, it had a number of serious bugs. Current releases roll up a 
dozen or so fixes and enhancements and with the kind help of the MELPA 
team, the package is now distributed from a maintained repo.


The current version includes initial support for org citations in Org 
9.5. This feature is experimental and I welcome feedback and reports on 
this or any other aspect of the package.


best

alex

Re: [PATCH] Fontification for inline src blocks

[Timothy]

Hi Sebastien,

> Sorry for the late reply, but isn’t there a `message' call leftover from
> debugging ?

Ooops! Time for a clean-up patch to fix the things you and Ihor’s just noticed.

Thanks for mentioning this.

All the best,
Timothy

Re: [BUG] C-c C-* causes "org-element--cache: Unregistered buffer modifications detected."

[Ihor Radchenko]

Max Nikulin  writes:

> Ihor, thank you for your work related to such issues. I had a hope to 
> thank you for the fix, but I faced a warning again in a bit modified 
> scenario. This time it is soft indent mode.
> ...
> First letter of new heading must be a capital one, though it can be 
> Latin. Converting top-level "H" heading by C-c C-* does not cause such 
> warning.

Well... I added yet another exception on main. Note that this special
case is also just in older Emacs versions.

> I am not an active user of main branch (I was merely hunting for another 
> bug), so I can not estimate performance penalty for large files due to 
> continuous cache resetting. I do not follow emacs-devel mail list last 
> weeks. Have you managed to negotiate with Eli concerning changes 
> required in Emacs code? I mean some followups of ...

The conclusion from that discussion is that someone needs to prepare
upstream patch for Emacs. I may do it in future, but it does not feel
like high priority because fixes for Emacs master will not solve the
problem in older Emacs versions. (and I secretly hope that this kind of
patch will be implemented by someone else as a part of tree-sitter
integration).

As for the performance, the last series of special cases you reported
(thanks again for doing this!) should not happen too frequently. I
cannot imagine users spamming C-c C-* all the time. The most problematic
is the case triggered by self-insert-command, but it will not trigger
cache reset. The worst impact we can see with C-c C-* issue is ~1.5-2x
slower agenda (or other full-text search queries) if cache is reset
between agenda updates. It is still much better than not using cache.

Actually, growing cache too much makes Emacs garbage collector perform
pretty poorly (at least when you have a file so large that cache has
300-400k elements). Reducing cache size from time to time may be even
beneficial for performance. I do not know the realistic cutoff values
though. We may want to implement access frequency-based cache element
removal.

Best,
Ihor

Re: [ANN] ox-pandoc, revived

[Timothy]

Hi Alex,

Great to hear that someone is taking care of ox-pandoc again!

Thanks for stepping up, and I wish you all the best 🙂.

Timothy

Re: [ANN] ox-pandoc, revived

[Bruce D'Arcus]

On Tue, Nov 30, 2021 at 7:50 AM Alex Fenton  wrote:

> The current version includes initial support for org citations in Org 9.5. 
> This feature is experimental and I welcome feedback and reports on this or 
> any other aspect of the package.

Did pandoc get support for org-cite?

There's been basically zero activity on this issue I created awhile back:

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

Or are you somehow massaging these citations into the "draft" format
already implemented in pandoc?

Bruce

Re: [ANN] ox-pandoc, revived

[Denis Maier]

Am 30.11.2021 um 09:40 schrieb Alex Fenton:

Hello,

ox-pandoc is an exporter for Org Mode that uses pandoc 
(https://pandoc.org/) to export to a very wide variety of text markup 
(e.g. markdown variants), document (ODT, docx) and presentation (e.g. 
html, .pdf) formats. It is available via MELPA and at: 
https://github.com/emacsorphanage/ox-pandoc


pandoc handles almost all org text-markup features and offers many 
options for controlling output. With ox-pandoc, it can also be used with 
Org Mode's code evaluation.


ox-pandoc was originally created by kawabata, but had fallen out of step 
over the past few years with recent pandoc and Org Mode versions. As a 
result, it had a number of serious bugs. Current releases roll up a 
dozen or so fixes and enhancements and with the kind help of the MELPA 
team, the package is now distributed from a maintained repo.


The current version includes initial support for org citations in Org 
9.5. This feature is experimental and I welcome feedback and reports on 
this or any other aspect of the package.


best

alex



That's great. Thank you.


Regarding citations and 
https://github.com/emacsorphanage/ox-pandoc#alternative-using-pandoc-citation-syntax: 
There are also plans to support the new org cite citation syntax on the 
pandoc side of things. This might make some things easier in the future.


Denis

[PATCH] New function org-speed-command-add for adding/modifying speed commands

[Shankar Rao]

Over the weekend I thought about this issue of configuring
`org-speed-commands' more easily, and I believe I have come up with a
simpler solution that I have provided in the attached patch.

This patch creates a new function `org-speed-command-add' that can be
used to add new speed command shortcuts to `org-speed-commands', as
well as modify existing shortcuts. This function takes as argument an
alist in the same format as `org-speed-commands'. For each command for
which the shortcut key is already present in `org-speed-commands', the
old command is replaced with the new command at the same position.
Commands with brand new shortcut keys are added to the user section of
`org-speed-commands'.

I believe this patch strikes a balance between power users, who can
still directly customize `org-speed-commands', and non-experts, who
may want to add/modify some speed commands without having to
understand the structure and organization of `org-speed-commands'.

Shankar

On Wed, Nov 24, 2021 at 10:36 AM Shankar Rao  wrote:
>
> Hello all,
>
> I discovered that upgrading to 9.5 broke my configuration because the
> variable `org-speed-commands-user' was removed. I read the thread
> (https://list.orgmode.org/87v9hzzhrn@gmail.com/) where this change
> was proposed and I completely agree that exposing the whole set of
> `org-speeds-commands' to the user for customization is an improvement
> over the previous state of affairs. However, I believe there were some
> unintended consequences of this change that can make it difficult to
> customize `org-speed-commands' for users that are not elisp gurus.
>
> The main problem is that `org-speed-commands' serves two purposes
> simultaneously:
>
> 1.) It contains all the mappings between speed keys and commands
> 2.) It contains headlines for command categories.
>
> Because of this second purpose, both the contents and order of entries
> in `org-speed-commands' are important. For example, suppose I want to
> replace the usual "n" command with my own. According to the usual
> conventions for alists
> (https://www.gnu.org/software/emacs/manual/html_node/elisp/Association-Lists.html),
> new associations such as this are added to the front of the list. But
> if I do so, by doing something like:
>
>   (setq org-speed-commands (cons '("n" . #'my-org-next-heading)
> org-speed-commands))
>
> Then the speed key "n" will show up twice when
> `org-speed-command-help' is invoked. I could first delete the old
> association by replacing `org-speed-commands' in the above with
> `(assoc-delete-all "n" org-speed-commands)', but then my modified
> command will no longer appear in the "Outline Navigation" section of
> the speed command help. Alternatively, I could replace the association
> for "n" using `alist-get':
>
>   (setf (alist-get "n" org-speed-commands nil nil #'equal)
> #'my-org-next-heading)
>
> However, this solution won't work for new speed commands (e.g., if I
> want to bind `my-org-next-heading' to "N" instead), because in that
> case `alist-get' will return `nil'.
>
> Below is the relevant portion of my config file where I customize
> `org-speed-commands':
> -
>   (defun alist-set (key value alist-symbol &optional testfn)
> "Set KEY to VALUE in alist referenced by ALIST-SYMBOL.
>
>   If KEY is not present in the alist, then add (KEY. VALUE) to the
>   front of the alist. Compare keys with TESTFN. Defaults to equal."
> (if-let ((keyval (assoc key (eval alist-symbol) testfn)))
> (setf (cdr keyval) value)
>   (set alist-symbol (cons (cons key value) (eval alist-symbol)
>
>
>   (defvar sbr-org-speed-commands-user '(("User Custom Speed Commands")
> ("N" . 
> ded-org-show-next-heading-tidily)
> ("P" .
> ded-org-show-previous-heading-tidily)
> ("h" . 
> sbr-org-speed-insert-subheading)
> ("u" . org-up-heading-or-item)
> ("b" . org-backward-heading-or-item)
> ("f" . org-forward-heading-or-item)
> ("p" . org-prev-heading-or-item)
> ("n" . org-next-heading-or-item))
> "My custom Org speed commands")
>
>   (dolist (keyval (reverse sbr-org-speed-commands-user))
> (alist-set (car keyval) (cdr keyval) 'org-speed-commands))
> -
>
> As you can see, I defined my own function `alist-set', which modifies
> an association in an alist if the key is already present, or adds the
> new association to the front of the list otherwise. In my opinion,
> functionality like `alist-set' should be built into Emacs itself. My
> code then constructs my own list of custom speed commands with its own
> section header and uses `alist-set' to add/modify speed commands.
> While this code works, it's a bit unsatisfying because
>
> 1.) It relies on my custom `alist-se

Re: [ANN] ox-pandoc, revived

[Alex Fenton]

On 30/11/2021 15:09, Bruce D'Arcus wrote:


Did pandoc get support for org-cite?

There's been basically zero activity on this issue I created awhile back:

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


AFAIK pandoc still doesn't support the official Org Mode syntax.

ox-pandoc relies on the fact that it first exports to an intermediate 
org file before handing off to pandoc. SRC blocks and citations are 
already resolved by the time pandoc is called.


If exporting with oc-natbib or oc-biblatex, citations are replaced by 
LaTeX commands, which pandoc passes through to the compiler. If 
exporting with oc-csl, citations and bibliographies are "just" formatted 
text by the time pandoc sees it.


I may add an oc-pandoc to massage org citations into pandoc format if 
there is a need to have citations be resolved by pandoc rather than Org 
Mode.


best
alex

Re: [ANN] ox-pandoc, revived

[Bruce D'Arcus]

On Tue, Nov 30, 2021 at 9:27 AM Alex Fenton  wrote:
>
> On 30/11/2021 15:09, Bruce D'Arcus wrote:

> AFAIK pandoc still doesn't support the official Org Mode syntax.
>
> ox-pandoc relies on the fact that it first exports to an intermediate
> org file before handing off to pandoc. SRC blocks and citations are
> already resolved by the time pandoc is called.

...

> I may add an oc-pandoc to massage org citations into pandoc format if
> there is a need to have citations be resolved by pandoc rather than Org
> Mode.

I'm not sure that's necessary; it probably doesn't really matter in practice.

Perhaps you can reassess once pandoc itself is updated, so you don't
have to worry about writing and maintaining special code to do this?

FWIW, org-cite seems partially inspired by the pandoc citation model
and syntax, but is a superset of it (pandoc has no global affixes;
also doesn't have styles, though does have sort of boolean feature
flags). I'm not sure how pandoc itself will handle that difference.

Bruce

how to export red colored TeX to latex

[Uwe Brauer]

Hi

I want to obtain a latex file that contains

\textcolor{red}{$\delta \phi = \frac{2 m}{R}$}


However when I add 
\textcolor{red}{$\delta \phi = \frac{2 m}{R}$}

To an org file and export it as Latex, the construct ends up like this


\textcolor{red}\{\(\delta \phi = \frac{2 m}{R}\)\}

Which is wrong.

Any ideas how to obtain the correctly exported expression?

Thanks

Uwe Brauer 

Re: how to export red colored TeX to latex

[John Kitchin]

maybe @@latex:\textcolor{red}{$\delta \phi = \frac{2 m}{R}$}@@ will do.

John

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



On Tue, Nov 30, 2021 at 11:29 AM Uwe Brauer  wrote:

>
>
> Hi
>
> I want to obtain a latex file that contains
>
> \textcolor{red}{$\delta \phi = \frac{2 m}{R}$}
>
>
> However when I add
> \textcolor{red}{$\delta \phi = \frac{2 m}{R}$}
>
> To an org file and export it as Latex, the construct ends up like this
>
>
> \textcolor{red}\{\(\delta \phi = \frac{2 m}{R}\)\}
>
> Which is wrong.
>
> Any ideas how to obtain the correctly exported expression?
>
> Thanks
>
> Uwe Brauer
>
>
>

Re: how to export red colored TeX to latex

[Uwe Brauer]

>>> "JK" == John Kitchin  writes:

> maybe @@latex:\textcolor{red}{$\delta \phi = \frac{2 m}{R}$}@@ will do.
> John

Thanks! That worked!


smime.p7s
Description: S/MIME cryptographic signature

Re: how to export red colored TeX to latex

[Juan Manuel Macías]

Hi,

Uwe Brauer writes:

> Hi
>
> I want to obtain a latex file that contains
>
> \textcolor{red}{$\delta \phi = \frac{2 m}{R}$}
>
>
> However when I add 
> \textcolor{red}{$\delta \phi = \frac{2 m}{R}$}
>
> To an org file and export it as Latex, the construct ends up like this
>
>
> \textcolor{red}\{\(\delta \phi = \frac{2 m}{R}\)\}
>
> Which is wrong.
>
> Any ideas how to obtain the correctly exported expression?

Not exactly related, but if it helps, I have defined this custom link
for colored text segments:

(NB: I apply two colors for `:face', because normally I use two themes,
one clear for the day and another dark for the night hours: when my dark
theme is active, apply a background color. But you can simplify that part to
your liking):

(org-link-set-parameters "color"
  ;; :display 'full
   :face (lambda (path) (when path
  (if (string= (face-attribute 
'default :background) "#282c34")
  `(:foreground ,path 
:background "#F5f5f5")
`(:foreground ,path
   :export (lambda (path desc format)
 (cond
  ((eq format 'latex)
   (concat
"\\textcolor{"
path
"}{" desc "}"))
  ((eq format 'html)
   (format "%s"
   path desc)

The link would then look like this, adapting John's solution using a
LaTeX export snippet:

[[color:red][@@latex:$\delta \phi = \frac{2 m}{R}$@@]]

Best regards,

Juan Manuel 

[PATCH] Fix org-comment-line-break-function (was: Is M-j broken for you in Org on Emacs 27 and 28?)

[Richard Lawrence]

Hi Tim and all,

Thanks for sticking with me here...

Tim Cross  writes:

> I just checked this when running emacs -Q and get the following
>
> comment-line-break-function is a variable defined in ‘simple.el’.
>
> Its value is ‘org-comment-line-break-function’
>
> and fill-prefix is
>
> fill-prefix is a variable defined in ‘simple.el’.
>
> Its value is nil

OK, those are the values I have too...

> and I don't get any error with M-j and cannot reproduce the issue you
> are encountering. .

Do you see an error if you explicitly call

(insert-before-markers-and-inherit nil)

?

Because that is what org-comment-line-break-function does when
fill-prefix is nil. That is the source of the error on all the versions
where I have reproduced it. If you don't see the error then, it would
indicate to me that something in your setup is suppressing it.

> Looking at the git log, I can only find these messages relating to
> default-indent-new-line
> ...
> which indicates the function was added in 2007 by RMS and made the
> default for M-j in 2019. 

Right, which is why I don't see it with M-j in Emacs 26, presumably.
Emacs 26.1, the version installed on my Debian system, was released May
28, 2018.

> my suspicion is that your org version is too old for the current Emacs
> versions... The other possibility is that you have a broken "mixed"
> installation of org.

I'm aware of the difficulties of a mixed installation and have been
careful to avoid them. I run Org from git, usually a recent pull of the
bugfix branch, which I load via use-package from my init file. But I
have also tested it with the built-in Org for various versions of Emacs
with emacs -Q. I do not have Org installed via ELPA.

Just to be extra, super sure, I built Emacs this afternoon from a
checkout of the repo, and the error is *still* there, with the same
cause. In that build, with emacs -Q, I have:

(org-version)
"9.5"

(emacs-version)
"GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo 
version 1.16.0)
 of 2021-11-30"

At this point I've replicated the bug on my machine in four different
builds of Emacs (version 26.1 from Debian, 27.2 and "emacs-next" from
Guix, and version 29.0.50 I built myself from source) with several
versions of Org (the built-in ones in these Emacsen and a recent build
of the bugfix branch). It is robustly reproducible for me, and the cause
is clear: default-indent-new-line calls org-comment-line-break-function,
which calls

(insert-before-markers-and-inherit nil)

which is a type error. I'm looking for help figuring out what the right
fix is. I attach a patch for the simplest fix I can think of; please let
me know if something else would be better.

-- 
Best,
Richard

diff --git a/lisp/org.el b/lisp/org.el
index 1a1375461..fdeec0d67 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19695,7 +19695,8 @@ non-nil."
   (save-excursion (forward-char -1) (delete-horizontal-space))
   (delete-horizontal-space)
   (indent-to-left-margin)
-  (insert-before-markers-and-inherit fill-prefix))
+  (when fill-prefix
+(insert-before-markers-and-inherit fill-prefix)))
 
 
 ;;; Fixed Width Areas

Re: Merging ox-texinfo+ into ox-texinfo

[Jonas Bernoulli]

Sorry for the delay, I got side-tracked with many other things.

Nicolas Goaziou  writes:

>>> It is possible to mix the two styles;
>>
>> Well... it turned out not to be true, but I should be able to get it
>> to work.
>
> Then I suggest to use "attr_texinfo" keyword, for example:
>
>#+attr_texinfo: :shorthand t
>- item...
>
> This way, we ensure the change is local. `org-texinfo-item' already
> checks :sep attribute.

I am sure I can get it to work just fine without a need for that.
It just turns out that I haven't done so yet, because I only used the
ox-texinfo+ style in manuals that use that style exclusively.  Now
that you have signaled that there is a good change that this would be
included in Org, putting in the work to use both styles in parallel is
actually justified.

But it likely will be a few weeks until I get to work because I looked
at the current implementation again and decided that it would be better
to start over and do the work using org-element instead of at the latest
possible moment when strings are being concatenated as ox-texinfo+
currently does.

> I see no reason to change the prefix, since these functions are part of
> ox-texinfo. I didn't look closely at your code, tho, so I may be wide of
> the mark.

I haven't started working on the org-element based implementation yet,
but I expect that won't actually need any new function definitions so,
the question is moot anyway.  (But just in case: I agree.)

 Cheers,
 Jonas

citeproc-org and org-ref 3

[Joseph Vidal-Rosset]

Dear John, and dear Andras,

Having updated my org-ref to the last version, I see that the html
export of bibliography does not work any longer for my blog.

Reading Andras's note here
https://github.com/andras-simonyi/citeproc-org
I confess that I am lost.

What have I to do to not waste too much time with this problem?

Best wishes,

Jo.

Re: how to export red colored TeX to latex

[Uwe Brauer]

> Hi,
> Uwe Brauer writes:


> Not exactly related, but if it helps, I have defined this custom link
> for colored text segments:

> (NB: I apply two colors for `:face', because normally I use two themes,
> one clear for the day and another dark for the night hours: when my dark
> theme is active, apply a background color. But you can simplify that part to
> your liking):

> (org-link-set-parameters "color"
> ;; :display 'full
>  :face (lambda (path) (when path
> (if (string= (face-attribute 
> 'default :background) "#282c34")
> `(:foreground ,path 
> :background "#F5f5f5")
>   `(:foreground ,path
>  :export (lambda (path desc format)
>(cond
> ((eq format 'latex)
>  (concat
>   "\\textcolor{"
>   path
>   "}{" desc "}"))
> ((eq format 'html)
>  (format "style=\"color:%s;\">%s"
>path desc)

> The link would then look like this, adapting John's solution using a
> LaTeX export snippet:

> [[color:red][@@latex:$\delta \phi = \frac{2 m}{R}$@@]]

Thanks, right now, I don't need links but it is good to know that there is a 
way to use them.


smime.p7s
Description: S/MIME cryptographic signature

Re: citeproc-org and org-ref 3

[András Simonyi]

Dear Joseph,

unfortunately, my note on the `citeproc-org` page has become kind of
misleading and has to be updated because org-ref didn't switch to the
new org-cite citation syntax after all, although this was the plan for
a while. I think if you wish to use org-ref 3 then you should simply
remove citeproc-org entirely -- if I understand correctly the latest
version of org-ref supports the old syntax as well and is capable of
CSL-based export (among others) on its own.

best regards,
András

On Tue, 30 Nov 2021 at 18:00, Joseph Vidal-Rosset
 wrote:
>
>
> Dear John, and dear Andras,
>
> Having updated my org-ref to the last version, I see that the html
> export of bibliography does not work any longer for my blog.
>
> Reading Andras's note here
> https://github.com/andras-simonyi/citeproc-org
> I confess that I am lost.
>
> What have I to do to not waste too much time with this problem?
>
> Best wishes,
>
> Jo.
>

Re: Is M-j broken for you in Org on Emacs 27 and 28?

[Morgan Willcock]

Tim Cross  writes:

> Based on your report of having org 9.3, my suspicion is that your org
> version is too old for the current Emacs versions (since the change in
> 2019 to use default-indent-new-line for C-M-j and M-j. I don't think
> this is a bug in current Org or Emacs.

Just for reference, I see the same problem on Emacs 27.2 using the
default and latest versions of Org-mode.

i.e.

 - using `emacs -Q` the Org version is listed as 9.4.4 and I see error

 - running emacs normally the Org version is listed as 9.5.1 and I see
   the error

> The other possibility is that you have a broken "mixed" installation of
> org. This can easily occur if org is upgraded when it has already been
> loaded into the Emacs instance when the upgrade is performed.

I upgraded the package using `emacs -Q` and I only use GNU ELPA as a
package source. I think that in my case the package installation was
clean.

Thanks,
Morgan

Re: citeproc-org and org-ref 3

[Joseph Vidal-Rosset]

Many thanks Andras for this first clarification. There is no hurry and
after John's advice, I will take the most convenient decision.

Many thanks to both of you for your very helpful works.

Best wishes,

Jo.

Le 30/11/2021 à 18:16, András Simonyi a écrit :
> Dear Joseph,
>
> unfortunately, my note on the `citeproc-org` page has become kind of
> misleading and has to be updated because org-ref didn't switch to the
> new org-cite citation syntax after all, although this was the plan for
> a while. I think if you wish to use org-ref 3 then you should simply
> remove citeproc-org entirely -- if I understand correctly the latest
> version of org-ref supports the old syntax as well and is capable of
> CSL-based export (among others) on its own.
>
> best regards,
> András
>
> On Tue, 30 Nov 2021 at 18:00, Joseph Vidal-Rosset
>  wrote:
>>
>>
>> Dear John, and dear Andras,
>>
>> Having updated my org-ref to the last version, I see that the html
>> export of bibliography does not work any longer for my blog.
>>
>> Reading Andras's note here
>> https://github.com/andras-simonyi/citeproc-org
>> I confess that I am lost.
>>
>> What have I to do to not waste too much time with this problem?
>>
>> Best wishes,
>>
>> Jo.
>>

Formal syntax for org-cite

[Timothy]

Hi All (and Nicolas in particular),

There's recently been a little bit of progress on the Pandoc issue for
org-cite support
(https://github.com/jgm/pandoc/issues/7329#issuecomment-982805313), and
the maintainers are now asking if there is any specification for
org-cite syntax.

Looking at https://orgmode.org/worg/dev/org-syntax.html, there isn't,
and so I've tried to come up with a draft. Most of it was worked out
from what I know of the syntax combined with looking at org-element.el,
however I'm not sure what character class applies to the global and key
prefix/suffix components.

The draft:


Citation syntax is currently not documented, but from the implementation
it looks something like this:
#+begin_example
[cite CITESTYLE: GLOBALPREFIX KEYCITES GLOBALSUFFIX]
#+end_example

The only mandatory component, =KEYCITES= consists of one or more
instances of the pattern, separated by semicolons.
#+begin_example
KEYPREFIX @KEY KEYSUFFIX
#+end_example

=KEY= can be made of any word-constituent character, =-=, =.=, =:=, =?=,
=!=, =`=, ='=, =/=, =*=, =@=, =+=, =|=, =(=, =)=, ={=, =}=, =<=, =>=,
=&=, =_=, =^=, =$=, =#=, =%=, =%=, or =~=.

I have not yet confirmed what =KEYPREFIX= and =KEYSUFFIX= may contain,
but as a starting point, any of the characters allowed in =KEY= except
=@= plus whitespace would seem fairly safe. =KEYSUFFIX= must start with
a whitespace character to be able to be differentiated from =KEY=.

=CITESTYLE= consists of a main =STYLE= and any number of =VARIANT=​s
(including zero), prefixed by forwards slashes in the following pattern
#+begin_example
/STYLE/VARIANT/VARIANT/VARIANT
#+end_example

=STYLE= and =VARIANT= can be made of any alphanumeric character, =_=, or =-=.

=GLOBALPREFIX= and =GLOBALSUFFIX= can contain the same characters as
=KEYPREFIX= and =KEYSUFFIX=, however =GLOBALPREFIX= must end with a
semicolon, and =GLOBALSUFFIX= must start with a semicolon.

"cite" and =CITESTYLE=, =KEYCITES= and =GLOBALSUFFIX= are /not/
separated by whitespace. Neither are =KEYPREFIX=, =@KEY=, or =KEYSUFFIX=
separated by whitespace.


Do let me know what you think :)

Timothy.

Re: citeproc-org and org-ref 3

[John Kitchin]

See https://www.youtube.com/watch?v=rRR-5NSpKyE for an overview of what to
do. basically you need a csl file that provides the style you want, and you
specify it like this in the org file or in default settings. You may also
need a locale file if you are not blogging in english.

#+csl-style: apa-5th-edition.csl

#+csl-locale: en-US

You can find a basic example org file for html export with CSL at
https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org

Here is a minimal way to export your blog file I suppose.

(let ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
  (org-open-file (org-html-export-to-html)))


John

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



On Tue, Nov 30, 2021 at 12:16 PM András Simonyi 
wrote:

> Dear Joseph,
>
> unfortunately, my note on the `citeproc-org` page has become kind of
> misleading and has to be updated because org-ref didn't switch to the
> new org-cite citation syntax after all, although this was the plan for
> a while. I think if you wish to use org-ref 3 then you should simply
> remove citeproc-org entirely -- if I understand correctly the latest
> version of org-ref supports the old syntax as well and is capable of
> CSL-based export (among others) on its own.
>
> best regards,
> András
>
> On Tue, 30 Nov 2021 at 18:00, Joseph Vidal-Rosset
>  wrote:
> >
> >
> > Dear John, and dear Andras,
> >
> > Having updated my org-ref to the last version, I see that the html
> > export of bibliography does not work any longer for my blog.
> >
> > Reading Andras's note here
> > https://github.com/andras-simonyi/citeproc-org
> > I confess that I am lost.
> >
> > What have I to do to not waste too much time with this problem?
> >
> > Best wishes,
> >
> > Jo.
> >
>

Re: how to export red colored TeX to latex

[Juan Manuel Macías]

Uwe Brauer writes:

> Thanks, right now, I don't need links but it is good to know that there is a 
> way to use them.

It's just a way of using links to produce different strings, depending
on the export format (LaTeX, HTML...). I use them quite a bit for text
segments as \foreignlanguage{}{}, \textcolor{}{}, etc. Anyway, that
specific link does not have any associated link action.

Best regards,

Juan Manuel 

Re: citeproc-org and org-ref 3

[Joseph Vidal-Rosset]

Many thanks John !  I will try and I will inform all of you.

Best wishes,

Jo.

Le 30/11/2021 à 18:31, John Kitchin a écrit :
> See https://www.youtube.com/watch?v=rRR-5NSpKyE
>  for an overview of what to
> do. basically you need a csl file that provides the style you want, and
> you specify it like this in the org file or in default settings. You may
> also need a locale file if you are not blogging in english.
>
> #+csl-style: apa-5th-edition.csl
>
> #+csl-locale: en-US
>
>
> You can find a basic example org file for html export with CSL at
> https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org
> 
>
> Here is a minimal way to export your blog file I suppose.
>
> (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
>(org-open-file  (org-html-export-to-html)))
>
>
> John
>
> ---
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu 
>
>
>
> On Tue, Nov 30, 2021 at 12:16 PM András Simonyi
> mailto:andras.simo...@gmail.com>> wrote:
>
> Dear Joseph,
>
> unfortunately, my note on the `citeproc-org` page has become kind of
> misleading and has to be updated because org-ref didn't switch to the
> new org-cite citation syntax after all, although this was the plan for
> a while. I think if you wish to use org-ref 3 then you should simply
> remove citeproc-org entirely -- if I understand correctly the latest
> version of org-ref supports the old syntax as well and is capable of
> CSL-based export (among others) on its own.
>
> best regards,
> András
>
> On Tue, 30 Nov 2021 at 18:00, Joseph Vidal-Rosset
> mailto:jos...@vidal-rosset.net>> wrote:
>  >
>  >
>  > Dear John, and dear Andras,
>  >
>  > Having updated my org-ref to the last version, I see that the html
>  > export of bibliography does not work any longer for my blog.
>  >
>  > Reading Andras's note here
>  > https://github.com/andras-simonyi/citeproc-org
> 
>  > I confess that I am lost.
>  >
>  > What have I to do to not waste too much time with this problem?
>  >
>  > Best wishes,
>  >
>  > Jo.
>  >
>

Re: [patch] fix ox-latex async export bug

[Rasmus Pank Roulund]

Sébastien Miquel  writes:

> Hi,
>
> Nicolas Goaziou writes:
>>> I don’t really understand why this bug happens to be honest.
>> The patch is already an improvement, but the beast is still lurking,
>> indeed.
> This is most likely due to native compilation which compiles the
> unquoted lambda. Once compiled, it (presumably) fails to be passed to
> the external emacs process.

Ah, interesting.  Is this a bug or a feature?

FWIW, I definitely use native compilation on my private laptop and almost
certainly on my work (Windows) laptop as well.

Thanks,
Rasmus

-- 
If you can mix business and politics wonderful things can happen!

Re: smart quotes and languages like en-gb

[Rasmus]

Nicolas Goaziou  writes:

> Hello,
>
> Rasmus  writes:
>
>> I have noticed that smart quotes are not picked up for “long” languages,
>> like “en-gb”, since smart quotes are defined for “short” languages, like
>> “en”, in org-export-smart-quotes-alist.
>>
>> The attached patch is an attempt at remedying this.  Not sure if it is the
>> best fix, though...
>
> IMO, this is a bit of a kludge. 
>
> "oc.el" parses language-region tags already, although it has not been
> factored out as an independent function yet. See
> `org-cite--get-note-rule'. Maybe moving this part to "org-macs.el" would
> be a better solution.

The patch is definitely dodgy. E.g. if I have rules for both en-gb and en
the smart quote would depend on the order of ‘org-export-smart-quotes-alist’.

So a better patch is needed, indeed.

Thanks for the reference to the oc function.  I will check it ASAP.

Thanks,
Rasmus

-- 
I feel emotional landscapes they puzzle me

Re: oc-biblatex too aggressive in replacing styles

[Rasmus]

Nicolas Goaziou  writes:

> Hello,
>
> Rasmus  writes:
>
>> However, I think it is currently too aggressive in overwriting styles.
>
> Ah?
>
>> Could it perhaps accept any style that is given in
>> ‘org-cite-biblatex-options’ / ‘org-latex-packages-alist’ and only
>> overwrite it if another style is explicitly specified in the file to be
>> exported?
>
> Isn't it the case already?

For me it is not. But maybe I used the latest release and not the latest git 
version.  Let me recheck and get pack. 

>> Currently, the only way I have found that I can specify that I want to use
>> biblatex-chicago is by issuing
>>
>> #+cite_export: biblatex chicago-authordate
>
> If you need chicago-authordate style globally, you can set
> `org-cite-export-processors' instead, e.g., to
>
>   ((t biblatex "chicago-authordate"))

I see. I had missed that you could supply a third argument, but it seems to 
work perfectly! Thanks! 
(And sorry about the noise.)

Maybe I will try to write a patch for the manual.

Kind regards,
Rasmus

-- 
A clever person solves a problem. A wise person avoids it

Re: [patch] fix ox-latex async export bug

[Rasmus]

Timothy  writes:

> Hi Tim,
>
>> I’m wondering if this could be a problem when exporting to latex if the
>>underlying latex process encounters errors and is waiting for user
>> input before
>>it can continue (which happens if there are problems in the tex
>> source latex is
>>trying to process)?
>>
>> It might be worth checking next time you encounter an error if you can
>> run latex on the generated *.tex file and see if it waits for user
>> input?
>
> If you look at the default value of `org-latex-pdf-process', it has the flag
> `-interaction=nonstopmode' which should mean the process never pauses
> and waits
> for user input.

Indeed.  I run LaTeX in noninteractive mode. (And by now I rarely make 
mistakes... ;)

Rasmus

-- 
However beautiful the theory, one should occasionally look at the evidence

Re: [PATCH] Fix org-comment-line-break-function

[Marco Wahl]

Hi Richard and all,

[...]

> Just to be extra, super sure, I built Emacs this afternoon from a
> checkout of the repo, and the error is *still* there, with the same
> cause. In that build, with emacs -Q, I have:
>
> (org-version)
> "9.5"
>
> (emacs-version)
> "GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo 
> version 1.16.0)
>  of 2021-11-30"
>
> At this point I've replicated the bug on my machine in four different
> builds of Emacs (version 26.1 from Debian, 27.2 and "emacs-next" from
> Guix, and version 29.0.50 I built myself from source) with several
> versions of Org (the built-in ones in these Emacsen and a recent build
> of the bugfix branch). It is robustly reproducible for me, and the cause
> is clear: default-indent-new-line calls org-comment-line-break-function,
> which calls
>
> (insert-before-markers-and-inherit nil)
>
> which is a type error. I'm looking for help figuring out what the right
> fix is. I attach a patch for the simplest fix I can think of; please let
> me know if something else would be better.

diff --git a/lisp/org.el b/lisp/org.el
index 1a1375461..fdeec0d67 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19695,7 +19695,8 @@ non-nil."
   (save-excursion (forward-char -1) (delete-horizontal-space))
   (delete-horizontal-space)
   (indent-to-left-margin)
-  (insert-before-markers-and-inherit fill-prefix))
+  (when fill-prefix
+(insert-before-markers-and-inherit fill-prefix)))
 
I don't have anything better.  I think this is a good patch.  It makes
M-j work again.

Possible refinements and improvements can follow.

+1 for applying of your patch.


Ciao,
-- 
Marco

Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)

[Karl Voit]

Hi,

* M  ‘quintus’ Gülker  wrote:
>
> Am Montag, dem 29. November 2021 schrieb Karl Voit:
>> It seems to be the case that the name "Orgdown" is the reason why
>> the Org-mode community does not support the idea of an
>> implementation-agnostic definition of the syntax. Which is ... kinda
>> funny if you think about it.
>>
>> Well if the project is not working out, at least I made my point and
>> we continue to have all those misunderstandings and lack of Orgdown
>> support in 3rd party tools (because Org-mode is way too big).
>
> I think the project has value; better tooling outside of Emacs is
> something org can only profit from in my opinion. One point that has not
> been raised yet are scenarios of collaborative work; I would enjoy it
> quite a bit if I could work on documents together with people who do not
> like Emacs as an editor for whatever reason. Currently, org as a file
> format is pretty much excluded if collaboration is intended with someone
> who does not use Emacs. The natural choice in these cases is Markdown.

I agree.

One of the next things I do have on my list is to try out crdt as
I've learned at EmacsConf21 that it is mature enough to be used in
practice. 

If that holds true, we can start dreaming of having a Etherpad-like
session from our GNU/Emacs while peers are connected to the same
session via some web-based tool/service.

> I agree that the name is kind of odd as it seems as if it is necessary
> to invoke some association to Markdown. Other markup languages also do
> not need that -- Textile, Asciidoc, etc. Perhaps it is best to simply
> ignore the naming issue and focus on the actual work instead. It is far
> more important to get the compatibility levels defined. After that you
> can still reconsider the naming.

The dominant feedback of
https://www.reddit.com/r/emacs/comments/r4cq3o/orgdown_the_new_name_for_the_syntax_of_orgmode/
was negative comments on the name and nothing else. Even here,
although due to a much more civilized style, the name choice was the
dominant topic and not the idea. I have to take this as a strong
signal here and I'm very close in giving up on Orgdown as a project.

I did underestimate the power of the name choice as I clearly was
impatient because I was looking forward to interesting discussions
on the idea itself like in this sub-thread.

There were two possible generic approaches for me: start from zero
with an open process, involving peers in all choices such as naming,
Orgdown1 syntax elements, ...

While this approach offers maximum community involvement, my fear
was to get into too many long discussions about details before I
could express my vision to anybody in a concise way.

Second approach: define everything myself up to Orgdown7 (as an
example) and publish with a big bang. The downsides here are
obvious.

I chose an in-between approach: defining only a minimal set (name,
common structure/idea/documentation, Orgdown1, providing a
collaborative home on GitLab) and hope for a project community that
will take over (or at least support) from there, discussing syntax
elements for Orgdown2 and taking the project to its next logical
steps.

In hindsight, this decision was wrong.

Quite frankly, I don't have the energy to throw away everything and
start from zero with a different name.

People do not seem to realize what it took to get there - which is
partly understandingly because I had to learn by doing what it takes
to get the idea into a coherent and consistent form. 

Simply switching to a different name is not just search&replace. It
would reset the project almost to its very start again, losing the
go-live effect of previous weekend (whose effect might be
questionable considering the name discussion), its project URL that
is now out there, the motivation video which aims to explain the
motivation to users of Emacs, the EmacsConf21 talk publicity, and it
would require much effort to reach the status where Orgdown is now.

>> Oh, there is a very large danger here of getting something that is
>> not compatible with Org-mode any more. I don't think that this would
>> be a good thing. At least the different flavors killed the fun of
>> Markdown for me.
>
> The astonishing thing is that most people manage to get along despite of
> the incompatibilities of the different Markdown flavours. Otherwise
> Markdown would not be such a success. Why is this? What can be learned
> from this for creating org tools outside of Emacs? Actually surveying
> this might be of interest.

I agree and I have thought about it myself already.

My guess is that most people do not suffer much from different
Markdown flavors because they rarely mix them in their workflows. I
guess most people are using Markdown only in their text editor OR
only in GitHub/GitLab org files OR only within any other
Markdown-tool.

I might be in an unusual situation where I do have to work with
GitHub/GitLab flavored Markdown README files AND with DIY company
solutions that work with pp

Re: Stable 9.5: invalid function (date date)

[Simon Butler]

Ihor Radchenko  writes:

> Tim Loderhose  writes:
>
>> Hi,
>>
>> I am also getting this error. It's fixable only by re-installing org from a
>> emacs -q, I assumed because files on the agenda file list are visited
>> before org is fully installed?
>> Unfortunately, this also occurs with a fresh install of Emacs
>> (re-installing all packages), but I'm not sure why. I'd assumed it's
>> because of the agenda file list, but that doesn't exist at that point.
>> I will try these days to get a minimal config to reproduce the issue, and
>> will respond again.
>
> This is a known problem for users loading Org early in their config and
> using non-standard package managers (like straight.el). See
> https://list.orgmode.org/m25ytopjg9@blind-drunk.fritz.box/
>
> In the linked thread we are also discussing some ways to address this on
> Org side, but no good solution yet. Patches are welcome.
>

What follows seems a little silly to me, but maybe it points to a clear
reason for someone with greater knowledge.

I've just updated two computers from org 9.4.4 to 9.5.1. Both are
running fedora 35 with emacs 27.2

One of the installations had this problem. There are minor differences
in the .emacs files between the two installations in terms of packages and the
order in which they appear in the file. I also use use-package.

seeing the above advice I revised the order of packages on the machine
with the problem so they were close to the order on the other machine -
mostly before (use-package org ...). Restarted emacs, and the problem was
still present.

I had noticed that the statement

(prefer-coding-system 'utf-8)

appeared in both .emacs files, early in one and towards the end of the
on where the (date date) was seen after M-x org-agenda

after moving (prefer-coding-system 'utf-8) to before the first use of
use-package the problem is gone

best
Simon

> Best,
> Ihor

Re: [BUG] clocktable :inherit-props does not respect global property setting [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/jet/.config/emacs/elpa/org-20210823/)]

[Jeff Trull]

Confirmed, after updating org it now works! Thanks for your help.

On Tue, Nov 30, 2021 at 1:07 AM Colin Baxter 😺  wrote:

> Hello Jeff
>
> You clock table works for me, including your missing rate of 150. I
> attach a screen shot.
>
> By the way, you have a ":inherit-props t" which is not on the #+BEGIN:
> clocktable line. I assume that has been corrupted in the email
> formatting.
>
> Best wishes
>
>

[PATCH] org.el: Fix the filling of regions containing lists

[Sébastien Miquel]

Hi,

The attached patch fixes the following issues with the functions
=fill-region= and =fill-paragraph=, when called with an active region
containing a list.

In the examples, replace 'long line' by long lines to be filled.

 + Calling =fill-region= on a region which contains a list with single
   line items (such as the one below) breaks the list structure.
   - long line
   - long line
 + Calling =fill-region= on a region with a list such as the one below
   doesn't fill the list
   - short line
 short line
   - short line
 short line
 + Calling =fill-paragraph= on a region containing a list such as the
   one below doesn't fill the first item
   - long line
   - long line
   - long line
 + Calling =fill-paragraph= on a region containing a list such as the
   one below doesn't fill the list
   - long line
   - long line
   - short line

Regards,

--
Sébastien Miquel
From 6c60e8e43e39074fa87da2f0ed272a69a6793862 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Sat, 6 Nov 2021 22:41:20 +0100
Subject: [PATCH] org.el: Fix the filling of regions containing lists

* lisp/org.el (org-setup-filling): Set fill-forward-paragraph-function.
(org--single-lines-list-is-paragraph): New internal variable. Whether
a list with single lines items should be considered a single
paragraph.
(org--paragraph-at-point): use org--single-lines-list-is-paragraph.
(org-fill-paragraph): When an active region contains a list ensure
every item get filled.
* testing/lisp/test-org.el (test-org/fill-paragraph):
(test-org/fill-region): Test behaviour of fill-paragraph and
fill-region with an active region containing a list.

When filling paragraphs in a region, do not treat a list with single
lines items as a single paragraph.
---
 lisp/org.el  | 19 +++
 testing/lisp/test-org.el | 41 
 2 files changed, 56 insertions(+), 4 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 025513e7a..17046f391 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19629,6 +19629,8 @@ assumed to be significant there."
 ;; `org-setup-filling' installs filling and auto-filling related
 ;; variables during `org-mode' initialization.
 
+(defvar org--single-lines-list-is-paragraph) ; defined later
+
 (defun org-setup-filling ()
   (require 'org-element)
   ;; Prevent auto-fill from inserting unwanted new items.
@@ -19644,6 +19646,10 @@ assumed to be significant there."
 (setq-local paragraph-start paragraph-ending)
 (setq-local paragraph-separate paragraph-ending))
   (setq-local fill-paragraph-function 'org-fill-paragraph)
+  (setq-local fill-forward-paragraph-function
+  (lambda (&optional arg)
+(let ((org--single-lines-list-is-paragraph nil))
+  (org-forward-paragraph arg
   (setq-local auto-fill-inhibit-regexp nil)
   (setq-local adaptive-fill-function 'org-adaptive-fill-function)
   (setq-local normal-auto-fill-function 'org-auto-fill-function)
@@ -19873,9 +19879,11 @@ filling the current element."
 	(progn
 	  (goto-char (region-end))
 	  (skip-chars-backward " \t\n")
-	  (while (> (point) start)
-		(org-fill-element justify)
-		(org-backward-paragraph)))
+	  (let ((org--single-lines-list-is-paragraph nil))
+(while (> (point) start)
+		  (org-fill-element justify)
+		  (org-backward-paragraph)
+  (skip-chars-backward " \t\n"
 	  (goto-char origin)
 	  (set-marker origin nil
  (t
@@ -21218,6 +21226,9 @@ It also provides the following special moves for convenience:
 ;; Return moves left.
 arg))
 
+(defvar org--single-lines-list-is-paragraph t
+  "Treat plain lists with an item every line as a whole paragraph")
+
 (defun org--paragraph-at-point ()
   "Return paragraph, or equivalent, element at point.
 
@@ -21279,7 +21290,7 @@ Function may return a real element, or a pseudo-element with type
 	  (while (memq (org-element-type (org-element-property :parent l))
 			   '(item plain-list))
 		(setq l (org-element-property :parent l)))
-	  (and l
+	  (and l org--single-lines-list-is-paragraph
 		   (org-with-point-at (org-element-property :post-affiliated l)
 		 (forward-line (length (org-element-property :structure l)))
 		 (= (point) (org-element-property :contents-end l)))
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 056ea7d87..4375456da 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -765,8 +765,49 @@
 	  (push-mark (point) t t)
 	  (goto-char (point-max))
 	  (call-interactively #'org-fill-paragraph)
+	  (buffer-string)
+  ;; Fill every list item in a region
+  (should
+   (equal "\n- 2345678\n  9\n- 2345678\n  9"
+	  (org-test-with-temp-text "\n- 2345678 9\n- 2345678 9"
+	(let ((fill-column 10))
+	  (transient-mark-mode 1)
+	  (push-mark (point-min) t t)
+	  (goto-char (point-max))
+	  (call-interactively #'org-fill-paragraph

Re: [PATCH] Fix org-comment-line-break-function

[Kaushal Modi]

On Tue, Nov 30, 2021 at 3:20 PM Marco Wahl  wrote:

>
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 1a1375461..fdeec0d67 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -19695,7 +19695,8 @@ non-nil."
>(save-excursion (forward-char -1) (delete-horizontal-space))
>(delete-horizontal-space)
>(indent-to-left-margin)
> -  (insert-before-markers-and-inherit fill-prefix))
> +  (when fill-prefix
> +(insert-before-markers-and-inherit fill-prefix)))
>
> I don't have anything better.  I think this is a good patch.  It makes
> M-j work again.
>
> Possible refinements and improvements can follow.
>
> +1 for applying of your patch.
>

I am able to reproduce that M-j issue (using Emacs version: GNU Emacs
28.0.60 (build 9, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, cairo version
1.15.12)
 of 2021-11-29, built using commit
c4daff9cf844ec85930bdcd2064787c92c260861, and Org mode version 9.5
(release_9.5-292-g5e35de)).

And this patch fixes that for me as well.

+1 for applying this patch.

=

Before this patch, M-j gave this backtrace with debug enabled:

Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
  insert-before-markers-and-inherit(nil)
  org-comment-line-break-function(nil)
  default-indent-new-line(nil t)
  funcall-interactively(default-indent-new-line nil t)
  call-interactively(default-indent-new-line nil nil)
  command-execute(default-indent-new-line)


Output of C-h k M-j:

M-j runs the command default-indent-new-line (found in global-map),
which is an interactive compiled Lisp function in ‘simple.el’.

It is bound to C-M-j, M-j.

(default-indent-new-line &optional SOFT FORCE)

Break line at point and indent.
If a comment syntax is defined, call ‘comment-line-break-function’.

The inserted newline is marked hard if variable ‘use-hard-newlines’ is true,
unless optional argument SOFT is non-nil.

Re: [PATCH] Fix org-comment-line-break-function

[Tim Cross]

Marco Wahl  writes:

> Hi Richard and all,
>
> [...]
>
>> Just to be extra, super sure, I built Emacs this afternoon from a
>> checkout of the repo, and the error is *still* there, with the same
>> cause. In that build, with emacs -Q, I have:
>>
>> (org-version)
>> "9.5"
>>
>> (emacs-version)
>> "GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo 
>> version 1.16.0)
>>  of 2021-11-30"
>>
>> At this point I've replicated the bug on my machine in four different
>> builds of Emacs (version 26.1 from Debian, 27.2 and "emacs-next" from
>> Guix, and version 29.0.50 I built myself from source) with several
>> versions of Org (the built-in ones in these Emacsen and a recent build
>> of the bugfix branch). It is robustly reproducible for me, and the cause
>> is clear: default-indent-new-line calls org-comment-line-break-function,
>> which calls
>>
>> (insert-before-markers-and-inherit nil)
>>
>> which is a type error. I'm looking for help figuring out what the right
>> fix is. I attach a patch for the simplest fix I can think of; please let
>> me know if something else would be better.
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 1a1375461..fdeec0d67 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -19695,7 +19695,8 @@ non-nil."
>(save-excursion (forward-char -1) (delete-horizontal-space))
>(delete-horizontal-space)
>(indent-to-left-margin)
> -  (insert-before-markers-and-inherit fill-prefix))
> +  (when fill-prefix
> +(insert-before-markers-and-inherit fill-prefix)))
>  
> I don't have anything better.  I think this is a good patch.  It makes
> M-j work again.
>
> Possible refinements and improvements can follow.
>
> +1 for applying of your patch.
>
>

I was finally able to reproduce the error. It depends to some degree on
the text in the buffer and where the cursor is when you hit M-j. Adding
some additional text and moving the cursor to different locations
enabled me to reproduce the error and I now agree it is a bug in
org-comment-line-break-function.

I don't know if your patch is the right fix or not because I don't
understand what the purpose of insert-before-marks-and-inherit is - in
fact, the doc string for that function doesn't even state what the @rest
args argument is for, so I don't understand why it is passing in
fill-prefix. For example, is it safe to assume
insert-before-merks-and-inherit does not need to be called if
fill-prefix is nil? Why is that function even called with the
fill-prefix as an argument? 

Re: Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)

[Dr. Arne Babenhauserheide]

Karl Voit  writes:
> * M  ‘quintus’ Gülker  wrote:
>> Am Montag, dem 29. November 2021 schrieb Karl Voit:
>>> It seems to be the case that the name "Orgdown" is the reason why
>>> the Org-mode community does not support the idea of an
>>> implementation-agnostic definition of the syntax. Which is ... kinda
>>> funny if you think about it.

This does not represent my answer correctly.

I explicitly said that org is implementation-defined, so *full*
compatibility cannot easily be achieved outside Emacs. That does not
prevent partial compatibility.

>>> Well if the project is not working out, at least I made my point and
>>> we continue to have all those misunderstandings and lack of Orgdown
>>> support in 3rd party tools (because Org-mode is way too big).
>>
>> I think the project has value; better tooling outside of Emacs is
>> something org can only profit from in my opinion. One point that has not
>> been raised yet are scenarios of collaborative work; I would enjoy it
>> quite a bit if I could work on documents together with people who do not
>> like Emacs as an editor for whatever reason. Currently, org as a file
>> format is pretty much excluded if collaboration is intended with someone
>> who does not use Emacs. The natural choice in these cases is Markdown.
>
> I agree.
>
> One of the next things I do have on my list is to try out crdt as
> I've learned at EmacsConf21 that it is mature enough to be used in
> practice. 
>
> If that holds true, we can start dreaming of having a Etherpad-like
> session from our GNU/Emacs while peers are connected to the same
> session via some web-based tool/service.

That would be pretty nice. You might also want to look at orgzly[1],
org-js[2], or markup-rocks[3].

[1]: http://www.orgzly.com/help
[2]: https://github.com/mooz/org-js
[3]: https://markup.rocks/

All of these call org-mode syntax simply "org".

> There were two possible generic approaches for me: start from zero
> with an open process, involving peers in all choices such as naming,
> Orgdown1 syntax elements, ...

You can also just take up the already given arguments, form a decision,
and then move forward.

> Simply switching to a different name is not just search&replace. It
> would reset the project almost to its very start again, losing the
> go-live effect of previous weekend (whose effect might be
> questionable considering the name discussion), its project URL that
> is now out there, the motivation video which aims to explain the
> motivation to users of Emacs, the EmacsConf21 talk publicity, and it
> would require much effort to reach the status where Orgdown is now.

Why is that?

From the technical side a simple entry in NEWS „Orgdown now uses the
name Org Syntax as alias“ and a second domain should suffice.

It’s the emotional side that no one but you could solve.

> My guess is that most people do not suffer much from different
> Markdown flavors because they rarely mix them in their workflows. I
> guess most people are using Markdown only in their text editor OR
> only in GitHub/GitLab org files OR only within any other
> Markdown-tool.

Or they just don’t use 90% of markdown features. Titles, quoted, bold,
emphasis, links, inline-source, source-blocks. Which is a big difference
compared to Org mode.

Even with that, source-blocks tend to break between implementations.

>> Maybe most documents are very simple files. README files for FLOSS
>> projects, forum posts, blog posts. For such content the features where
>> the Markdown implementations differ are usually not required. 
>
> This sounds also a plausible explanation and is also boosted by
> another posting as an answer to yours.

And markdown has inline HTML: Anything missing (like tables) is just
exported from org-mode as HTML.

> I don't think that users of LaTeX/ConTeXt are part of the target
> group. They would actually lose a bit of having control, I think.
> And Overleaf might be too hard to beat I guess although I personally
> don't like to use cloud-based services but meanwhile that's the
> opinion of a tiny minority.

Switching from LaTeX to Org-Mode was a very empowering step for me,
because it simpified most documents a lot, enabled quick restructuring,
allowed for easy tracking of TODO-states and using executed inline-code
via babel — and I gained HTML export for free.

It’s not the tool for a single paper to one journal that only has to fit
one format and is never edited after final submission, but for any
larger writing, org-mode is quite a boost in productivity.

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


signature.asc
Description: PGP signature

Re: Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)

[Eduardo Ochs]

On Tue, 30 Nov 2021 at 17:46, Karl Voit  wrote:
>
> I chose an in-between approach: defining only a minimal set (name,
> common structure/idea/documentation, Orgdown1, providing a
> collaborative home on GitLab) and hope for a project community that
> will take over (or at least support) from there, discussing syntax
> elements for Orgdown2 and taking the project to its next logical
> steps.
>
> In hindsight, this decision was wrong.
>
> Quite frankly, I don't have the energy to throw away everything and
> start from zero with a different name.
>
> People do not seem to realize what it took to get there - which is
> partly understandingly because I had to learn by doing what it takes
> to get the idea into a coherent and consistent form.
>
> Simply switching to a different name is not just search&replace. It
> would reset the project almost to its very start again, losing the
> go-live effect of previous weekend (whose effect might be
> questionable considering the name discussion), its project URL that
> is now out there, the motivation video which aims to explain the
> motivation to users of Emacs, the EmacsConf21 talk publicity, and it
> would require much effort to reach the status where Orgdown is now.


Hi Karl,

I was at the EmacsConf2021, but I was totally exhausted due to other
chores and spoke to very few people there...

I think that your work is VERY important. I am one of the people who
have tried to learn Org lots of times and got stuck the same number of
times, and any initiative that splits the features - either syntactic
or semantics - into layers of different complexity and importance
will help me very much.

My suggestion about the name is: it's your project, changing its name
is not a trivial task, and the people who complained about the name
did not offer help. If I were you would simply put "find a better name
for the project and change its name to it" in my TODO list as a
low-priority task.

  Cheers =),
Eduardo Ochs
http://angg.twu.net/#eev
https://emacsconf.org/2021/talks/test/

Re: noweb and shell heredocs

[Dr. Arne Babenhauserheide]

Immanuel Litzroth  writes:

> You can set the delimiters used for noweb code.
> org-babel-noweb-wrap-end and org-babel-noweb-wrap-end.
>
> I think I set them to @@ in shell code.

I almost always use {{{...}}} via a footer in my org-files:

# Local Variables:
# org-babel-noweb-wrap-start: "{{{"
# org-babel-noweb-wrap-end: "}}}"
# End:

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


signature.asc
Description: PGP signature

Re: Formal syntax for org-cite

[Tom Gillespie]

Hi Timothy,
Thanks for putting this together. Comments in line. Best!
Tom

For reference here is the tokenizer pattern I use in laundry at the moment.
There are a number of issues with it ...
https://github.com/tgbugs/laundry/blob/5a396bef98d9a3cd9ee929f21cd47612dd6cb1ac/laundry/lex-abbrev.rkt#L896-L913

> Citation syntax is currently not documented, but from the implementation
> it looks something like this:
> #+begin_example
> [cite CITESTYLE: GLOBALPREFIX KEYCITES GLOBALSUFFIX]
> #+end_example

There is potential confusion here because =[cite= does not have to be
followed by a space (rather, cannot be).

The top level syntax is =[cite= terminating at the first occurrence of =]=.
I think we may also need to include a note that no whitespace is allowed either?
It will only be recognized within paragraph context (e.g. headings, paragraphs,
and other places where org objects can appear). Stating that up front would
clarify that the rest of the syntax described here is how to determine whether
the citation is well formed/how to parse it.

> =KEY= can be made of any word-constituent character, =-=, =.=, =:=, =?=,
> =!=, =`=, ='=, =/=, =*=, =@=, =+=, =|=, =(=, =)=, ={=, =}=, =<=, =>=,
> =&=, =_=, =^=, =$=, =#=, =%=, =%=, or =~=.

You have a duplicated =%= here.

> I have not yet confirmed what =KEYPREFIX= and =KEYSUFFIX= may contain,
> but as a starting point, any of the characters allowed in =KEY= except
> =@= plus whitespace would seem fairly safe. =KEYSUFFIX= must start with
> a whitespace character to be able to be differentiated from =KEY=.

I don't think we can allow whitespace here?

> =CITESTYLE= consists of a main =STYLE= and any number of =VARIANT=s
> (including zero), prefixed by forwards slashes in the following pattern
> #+begin_example
> /STYLE/VARIANT/VARIANT/VARIANT
> #+end_example

Need clarification on empty syles e.g. [cite//:]

> "cite" and =CITESTYLE=, =KEYCITES= and =GLOBALSUFFIX= are /not/
> separated by whitespace. Neither are =KEYPREFIX=, =@KEY=, or =KEYSUFFIX=
> separated by whitespace.

I may be missing something, but this is confusing with respect to the
statement about =KEYSUFFIX= and whitespace made above.

Re: noweb and shell heredocs

[Tom Gillespie]

Hi Łukasz,
One workaround that is fairly reliable is to prefix the names
of the blocks to be nowebbed with an &. So #+name: block-name
becomes #+name: &block-name. Then you reference it as
<<&block-name>> and the heredoc syntax is broken. Best,
Tom

Re: [PATCH] Fix org-comment-line-break-function

[Tim Cross]

Kaushal Modi  writes:

> On Tue, Nov 30, 2021 at 3:20 PM Marco Wahl  wrote:
>
>  diff --git a/lisp/org.el b/lisp/org.el
>  index 1a1375461..fdeec0d67 100644
>  --- a/lisp/org.el
>  +++ b/lisp/org.el
>  @@ -19695,7 +19695,8 @@ non-nil."
> (save-excursion (forward-char -1) (delete-horizontal-space))
> (delete-horizontal-space)
> (indent-to-left-margin)
>  -  (insert-before-markers-and-inherit fill-prefix))
>  +  (when fill-prefix
>  +(insert-before-markers-and-inherit fill-prefix)))
>
>  I don't have anything better.  I think this is a good patch.  It makes
>  M-j work again.
>
>  Possible refinements and improvements can follow.
>
>  +1 for applying of your patch.
>
> I am able to reproduce that M-j issue (using Emacs version: GNU Emacs 28.0.60 
> (build 9, x86_64-pc-linux-gnu, GTK+ Version 3.22.30,
> cairo version 1.15.12)
>  of 2021-11-29, built using commit c4daff9cf844ec85930bdcd2064787c92c260861, 
> and Org mode version 9.5
> (release_9.5-292-g5e35de)).
>
> And this patch fixes that for me as well.
>
> +1 for applying this patch.
>
> =
>
> Before this patch, M-j gave this backtrace with debug enabled:
>
> Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
>   insert-before-markers-and-inherit(nil)
>   org-comment-line-break-function(nil)
>   default-indent-new-line(nil t)
>   funcall-interactively(default-indent-new-line nil t)
>   call-interactively(default-indent-new-line nil nil)
>   command-execute(default-indent-new-line)
>
> Output of C-h k M-j:
>
> M-j runs the command default-indent-new-line (found in global-map),
> which is an interactive compiled Lisp function in ‘simple.el’.
>
> It is bound to C-M-j, M-j.
>
> (default-indent-new-line &optional SOFT FORCE)
>
> Break line at point and indent.
> If a comment syntax is defined, call ‘comment-line-break-function’.
>
> The inserted newline is marked hard if variable ‘use-hard-newlines’ is true,
> unless optional argument SOFT is non-nil.

I'm not sure this is the right patch to apply. While it does fix the
immediate error, it really does so by just avoiding the call to
insert-before-markers-and-inherit when fill-prefix is nil. It does not
address the question of what that function is supposed to do or whether
the correct fix is either to call the function without the fill-prefix
argument (which also works in that it avoids the error) or if instead,
the patch should be

(if fill-prefix
  (insert-before-markers-and-inherit fill-prefix)
 (insert-before-markers-and-inherit))

I note also that with or without the patch, the function does not appear
to work correctly anyway. If you hit M-j while in a comment, the new
line should be indented appropriately and have the comment character
prefix i.e. start a new comment line. It does not do that. This is
supposed to be the key difference between C-j and M-j.

Regardless, I think that unless we understand the purpose of
insert-before-markers-and-inherit, we should make the patch such that it
still calls that function. Even if fill-prefix is nil there is
probably a good reason why the markers and properties need to be
modified for some situations. 

It would be good to get Nicholas' input here as I think he wrote the
original function back in 2012. 

Re: "Orgdown", the new name for the syntax of Org-mode

[Samuel Wales]

if you will forgive one more bikeshed answer, what about this?

- reduced org
- reduced org, version 1

and maybe

- .rorg extension [if and only if needed to guarantee reduction]

as for why you got bikeshed answers, maybe the subject header of this
thread might have been part of it?

idk.

===

as for [other thread], i don't think you are doing this because
reduced org is an interesting idea but:

> "Does "assuming too much on other people's world because on my own small 
> world" have a scientific name?"

"epistemic tresspassing" has been used for something a bit similar.
also i would use the term "drive-by paper" for e.g. making claims
about a disease that the authors do not understand at all but think
they do, wanting to try their ideology, measurement tool, or intuition
regardless so they can get a paper out of it, but that does not apply
here.  more generally are things like fiefdom/chauvanism, ideological
bias, and professional bias, which are different.  maybe there should
be a "small world bias" or an "if you have a hammer everything looks
like a nail bias"?  and a "common belief bias" and "cultural belief
bias"?  and a "my favorite language bias"?  you might also consider
the availability heuristic, saliency bias, epistemic injustice, and
omission bias, but those are different too.

i think it is a good idea to be interested in the possibility of
reduced org as a generic markup language.

On 11/28/21, Karl Voit  wrote:
> Hi Org-mode community,
>
> At this year's EmascsConf, I had a 12 minute video where I explain why
> we do need a different name for the syntax of Org-mode in contrast to
> the Elisp implementation of GNU/Emacs Org-mode.
>
> I would like you to read my rationale and motivate you to use the term
> "Orgdown" for the syntax and "Orgdown1" for the first (very basic)
> level of Orgdown syntax elements.
>
> - The EmacsConf21 talk: https://emacsconf.org/2021/talks/org-outside
> - Orgdown site: https://gitlab.com/publicvoit/orgdown (please contribute!)
> - My motivation article: https://karl-voit.at/2021/11/27/orgdown/
>   - This is the longer version of my 12 minute EmacsConf21 video.
> - My personal copy of the video:
> https://tube.graz.social/w/bgJVfjPLQAoJwLJQZoo3Hu
>
>
> Just as a sneak preview (not as a replacement for my motivation article):
>
> Orgdown is and will be defined in a set of levels, starting with very
> basic Orgdown1 (or OD1 or O↓1 or ⧬1 - depending on your coolness
> factor of choice :-) )
>
> - OD1 →
> https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Orgdown-Levels.org
> - OD2 → will be defined in future
> - OD3 → will be defined in future
> - ...
> - OD∞ = Org-mode (by definition)
>
> Any OD-level needs to be compatible with Org-mode as implemented in
> Elisp for GNU/Emacs Org-mode according to https://orgmode.org. Any ODx
> is a sub-set of the syntax elements of ODy (with y>x).
>
> With introducing a new term specific for the syntax, we do get the
> benefit of getting a better way to handle Org-mode support in
> 3rd-party tools such as listed on
> https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Tool-Support.org
> (please extend!).
>
> Having a well-defined sub-set of Org-mode, I also do think that formal
> definitions of the Org-mode syntax will be easier to develop, starting
> with the very simple OD1 level.
>
> It would be awesome if we start referring to syntax support in
> 3rd-party tools with the corresponding OD levels.
>
> I want to emphasize that the goal of Orgdown is NOT and will never be
> something that is an alternative to our golden standard Org-mode. We
> will try hard not to get into the Markdown situation where you need to
> know the exact flavor of the markup in order to produce text.
>
> So far, the response was great at the conference and I do hope that
> this idea will get a life of its own, developing the standard further,
> bringing this magnificent lightweight markup to the digital world.
> This also eases some pain for users of GNU/Emacs when it comes to
> exchanging text-based data.
>
> Thanks for your support here!
>
>
> --
> Personal Information Management > http://Karl-Voit.at/tags/pim/
> Emacs-related > http://Karl-Voit.at/tags/emacs/
>
>
>


-- 
The Kafka Pandemic

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

Re: [PATCH] Fix org-comment-line-break-function

[Kaushal Modi]

On Tue, Nov 30, 2021, 6:29 PM Tim Cross  wrote:

>
> Regardless, I think that unless we understand the purpose of
> insert-before-markers-and-inherit, we should make the patch such that it
> still calls that function. Even if fill-prefix is nil there is
> probably a good reason why the markers and properties need to be
> modified for some situations.
>

Oops! You're right; I did not verify that binding within a comment. I just
checked that it prevented the error.

It would be good to understand the purpose of that function call and have a
proper fix.

>

Re: "Orgdown", the new name for the syntax of Org-mode

[Samuel Wales]

um, or just "assuming too much bias"?  :]

again i don't think you are really doing these things by just
proposing a bunch of ideas about markup languages.  not everybody
knows all languages and you'll get substantive corrective feedback.

On 11/30/21, Samuel Wales  wrote:
> if you will forgive one more bikeshed answer, what about this?
>
> - reduced org
> - reduced org, version 1
>
> and maybe
>
> - .rorg extension [if and only if needed to guarantee reduction]
>
> as for why you got bikeshed answers, maybe the subject header of this
> thread might have been part of it?
>
> idk.
>
> ===
>
> as for [other thread], i don't think you are doing this because
> reduced org is an interesting idea but:
>
>> "Does "assuming too much on other people's world because on my own small
>> world" have a scientific name?"
>
> "epistemic tresspassing" has been used for something a bit similar.
> also i would use the term "drive-by paper" for e.g. making claims
> about a disease that the authors do not understand at all but think
> they do, wanting to try their ideology, measurement tool, or intuition
> regardless so they can get a paper out of it, but that does not apply
> here.  more generally are things like fiefdom/chauvanism, ideological
> bias, and professional bias, which are different.  maybe there should
> be a "small world bias" or an "if you have a hammer everything looks
> like a nail bias"?  and a "common belief bias" and "cultural belief
> bias"?  and a "my favorite language bias"?  you might also consider
> the availability heuristic, saliency bias, epistemic injustice, and
> omission bias, but those are different too.
>
> i think it is a good idea to be interested in the possibility of
> reduced org as a generic markup language.
>
> On 11/28/21, Karl Voit  wrote:
>> Hi Org-mode community,
>>
>> At this year's EmascsConf, I had a 12 minute video where I explain why
>> we do need a different name for the syntax of Org-mode in contrast to
>> the Elisp implementation of GNU/Emacs Org-mode.
>>
>> I would like you to read my rationale and motivate you to use the term
>> "Orgdown" for the syntax and "Orgdown1" for the first (very basic)
>> level of Orgdown syntax elements.
>>
>> - The EmacsConf21 talk: https://emacsconf.org/2021/talks/org-outside
>> - Orgdown site: https://gitlab.com/publicvoit/orgdown (please
>> contribute!)
>> - My motivation article: https://karl-voit.at/2021/11/27/orgdown/
>>   - This is the longer version of my 12 minute EmacsConf21 video.
>> - My personal copy of the video:
>> https://tube.graz.social/w/bgJVfjPLQAoJwLJQZoo3Hu
>>
>>
>> Just as a sneak preview (not as a replacement for my motivation article):
>>
>> Orgdown is and will be defined in a set of levels, starting with very
>> basic Orgdown1 (or OD1 or O↓1 or ⧬1 - depending on your coolness
>> factor of choice :-) )
>>
>> - OD1 →
>> https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Orgdown-Levels.org
>> - OD2 → will be defined in future
>> - OD3 → will be defined in future
>> - ...
>> - OD∞ = Org-mode (by definition)
>>
>> Any OD-level needs to be compatible with Org-mode as implemented in
>> Elisp for GNU/Emacs Org-mode according to https://orgmode.org. Any ODx
>> is a sub-set of the syntax elements of ODy (with y>x).
>>
>> With introducing a new term specific for the syntax, we do get the
>> benefit of getting a better way to handle Org-mode support in
>> 3rd-party tools such as listed on
>> https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Tool-Support.org
>> (please extend!).
>>
>> Having a well-defined sub-set of Org-mode, I also do think that formal
>> definitions of the Org-mode syntax will be easier to develop, starting
>> with the very simple OD1 level.
>>
>> It would be awesome if we start referring to syntax support in
>> 3rd-party tools with the corresponding OD levels.
>>
>> I want to emphasize that the goal of Orgdown is NOT and will never be
>> something that is an alternative to our golden standard Org-mode. We
>> will try hard not to get into the Markdown situation where you need to
>> know the exact flavor of the markup in order to produce text.
>>
>> So far, the response was great at the conference and I do hope that
>> this idea will get a life of its own, developing the standard further,
>> bringing this magnificent lightweight markup to the digital world.
>> This also eases some pain for users of GNU/Emacs when it comes to
>> exchanging text-based data.
>>
>> Thanks for your support here!
>>
>>
>> --
>> Personal Information Management > http://Karl-Voit.at/tags/pim/
>> Emacs-related > http://Karl-Voit.at/tags/emacs/
>>
>>
>>
>
>
> --
> The Kafka Pandemic
>
> Please learn what misopathy is.
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>


-- 
The Kafka Pandemic

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

Re: [PATCH] org.el: Fix the filling of regions containing lists

[Samuel Wales]

wow thank you i look forward to this.

On 11/30/21, Sébastien Miquel  wrote:
> Hi,
>
> The attached patch fixes the following issues with the functions
> =fill-region= and =fill-paragraph=, when called with an active region
> containing a list.
>
> In the examples, replace 'long line' by long lines to be filled.
>
>   + Calling =fill-region= on a region which contains a list with single
>     line items (such as the one below) breaks the list structure.
>     - long line
>     - long line
>   + Calling =fill-region= on a region with a list such as the one below
>     doesn't fill the list
>     - short line
>   short line
>     - short line
>   short line
>   + Calling =fill-paragraph= on a region containing a list such as the
>     one below doesn't fill the first item
>     - long line
>     - long line
>     - long line
>   + Calling =fill-paragraph= on a region containing a list such as the
>     one below doesn't fill the list
>     - long line
>     - long line
>     - short line
>
> Regards,
>
> --
> Sébastien Miquel
>


-- 
The Kafka Pandemic

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

Re: Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)

[Tom Gillespie]

Karl,
   The exact naming of a thing is nearly always the most contentious
step in trying to promulgate it. In my own field we can easily get all
parties to agree on a definition, but they refuse to budge on a name.
As others have said, I wouldn't worry about kibitizing over the name.

I would however worry about the larger negative reaction. From my
perspective I think the issue is that there are many efforts working
toward a formalized specification for Org syntax and Org mode
functionality, and some of those stakeholders who have invested
significant effort may feel blindsided by a public declaration
announcing Orgdown because they were not consulted and not
made aware that you were working on it.

I appreciate the amount of work that you have put in, I have devoted
hundreds of hours to working on an alternate implementation of org
in Racket that uses a formal ebfn in hopes that others will be able
to use it as a guide and as a way to talk formally about how Org
parsers and implementations should behave.

It would thus be easy for me to say that your approach has put the
cart before the horse, because there are countless nuances in the
specification for Org syntax which must be addressed before any
levels of org compliance can be specified, otherwise the behavior
between levels will be inconsistent.

If I were to say this, it would not be fair to you at all. The ideas
and motivation for Orgdown are vital and important. You have put
in enormous thought and effort, all because you care about Org
and want to see it succeed.

The issue is that any shared specification for Org syntax is
fundamentally about how to coordinate as a community.
The way that Orgdown was presented to the community feels
(to me) like it is being imposed top down or coming from an
individual source, not from an open and visible community
process (the subject of your original email reads as a declaration
in english, and thus can be quite off putting, though I know that
was not the intention).

I personally haven't bothered with promulgation because I think
that we are not technically ready as a community to approach
outreach to other developers in a way that we can succeed.

The good news is that all of this can co-exist if we want it to,
but we need to be clear about our objectives as a community.

To me these objectives are as follows (and I would love
to hear from others about additional or alternate objectives).

1. To never fracture Org syntax so as to avoid the nightmare
of markdown flavors. (This means being able to say clearly
as a community that a parser is out of compliance and that
it is up to the user to fix their files. The ruby org parser used
by Github is a major issue here.)
2. To provide a clear specification for what graceful degradation
looks like when parsing Org syntax if a parser does not support
some portion of that syntax (e.g. should property drawer lines
be excluded or rendered as plain text?).
3. Provide a solid basis on which further formal specification
can be built. (My interests in particular are around providing
consistent semantics for org-babel blocks across languages
so that babel implementations can clearly communicate what
runtime features they support.)

The approach for Orgdown can absolutely meet all three of
these objectives, however in its current form Orgdown1 is not
sufficiently well specified to avoid fracturing the syntax.
This is because Org syntax is extremely complex (even the
elisp implementation of Org mode is internally inconsistent)
and there are edge cases where behavior will diverge if parsing
of even the simplest elements is not fully specified.

There are many ways to remedy this, however they require
a more formal approach. A number of us are working to build
technical foundations for such a formal approach, but I do not
think that any of those projects are ready to be used to
specify discrete levels of Org syntax parsing compliance.

If I may, I would suggest that an Orgdown0 is something that
could be well specified, but it would avoid parsing of markup
altogether and only deal with the major element types. Parsing
paragraphs and all the org objects is not something that can
be done piecemeal. There are too many interactions between
different parts of the syntax, and in some cases the existing
specification desperately needs to be revisited due to the
complexity that it induces or because it is underspecified.
Of course this would make Orgdown0 fairly useless as a
replacement for markdown, but at least it would be a start.

Best,
Tom

Re: Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)

[Tim Cross]

Tom Gillespie  writes:

> Karl,
>The exact naming of a thing is nearly always the most contentious
> step in trying to promulgate it. In my own field we can easily get all
> parties to agree on a definition, but they refuse to budge on a name.
> As others have said, I wouldn't worry about kibitizing over the name.
>
> I would however worry about the larger negative reaction. From my
> perspective I think the issue is that there are many efforts working
> toward a formalized specification for Org syntax and Org mode
> functionality, and some of those stakeholders who have invested
> significant effort may feel blindsided by a public declaration
> announcing Orgdown because they were not consulted and not
> made aware that you were working on it.
>
> I appreciate the amount of work that you have put in, I have devoted
> hundreds of hours to working on an alternate implementation of org
> in Racket that uses a formal ebfn in hopes that others will be able
> to use it as a guide and as a way to talk formally about how Org
> parsers and implementations should behave.
>
> It would thus be easy for me to say that your approach has put the
> cart before the horse, because there are countless nuances in the
> specification for Org syntax which must be addressed before any
> levels of org compliance can be specified, otherwise the behavior
> between levels will be inconsistent.
>
> If I were to say this, it would not be fair to you at all. The ideas
> and motivation for Orgdown are vital and important. You have put
> in enormous thought and effort, all because you care about Org
> and want to see it succeed.
>
> The issue is that any shared specification for Org syntax is
> fundamentally about how to coordinate as a community.
> The way that Orgdown was presented to the community feels
> (to me) like it is being imposed top down or coming from an
> individual source, not from an open and visible community
> process (the subject of your original email reads as a declaration
> in english, and thus can be quite off putting, though I know that
> was not the intention).
>
> I personally haven't bothered with promulgation because I think
> that we are not technically ready as a community to approach
> outreach to other developers in a way that we can succeed.
>
> The good news is that all of this can co-exist if we want it to,
> but we need to be clear about our objectives as a community.
>
> To me these objectives are as follows (and I would love
> to hear from others about additional or alternate objectives).
>
> 1. To never fracture Org syntax so as to avoid the nightmare
> of markdown flavors. (This means being able to say clearly
> as a community that a parser is out of compliance and that
> it is up to the user to fix their files. The ruby org parser used
> by Github is a major issue here.)
> 2. To provide a clear specification for what graceful degradation
> looks like when parsing Org syntax if a parser does not support
> some portion of that syntax (e.g. should property drawer lines
> be excluded or rendered as plain text?).
> 3. Provide a solid basis on which further formal specification
> can be built. (My interests in particular are around providing
> consistent semantics for org-babel blocks across languages
> so that babel implementations can clearly communicate what
> runtime features they support.)
>
> The approach for Orgdown can absolutely meet all three of
> these objectives, however in its current form Orgdown1 is not
> sufficiently well specified to avoid fracturing the syntax.
> This is because Org syntax is extremely complex (even the
> elisp implementation of Org mode is internally inconsistent)
> and there are edge cases where behavior will diverge if parsing
> of even the simplest elements is not fully specified.
>
> There are many ways to remedy this, however they require
> a more formal approach. A number of us are working to build
> technical foundations for such a formal approach, but I do not
> think that any of those projects are ready to be used to
> specify discrete levels of Org syntax parsing compliance.
>
> If I may, I would suggest that an Orgdown0 is something that
> could be well specified, but it would avoid parsing of markup
> altogether and only deal with the major element types. Parsing
> paragraphs and all the org objects is not something that can
> be done piecemeal. There are too many interactions between
> different parts of the syntax, and in some cases the existing
> specification desperately needs to be revisited due to the
> complexity that it induces or because it is underspecified.
> Of course this would make Orgdown0 fairly useless as a
> replacement for markdown, but at least it would be a start.
>

Hi Tom,

I pretty much agree with everything you wrote. I also feel it is
unfortunate that Karl received so much negative focus on the name and
not on the underlying idea - but I'm not surprised. As you say, naming
is extremely hard and getting consensus is even har

Re: [PATCH] Fix org-comment-line-break-function

[Kaushal Modi]

On Tue, Nov 30, 2021 at 6:29 PM Tim Cross  wrote:

>
> It would be good to get Nicholas' input here as I think he wrote the
> original function back in 2012.
>

Just to see what happens, I tried this:

M-: (setq-local comment-line-break-function #'comment-indent-new-line)

.. and then M-j started working perfectly! It worked fine both: in Org
comment lines and out of comment lines.

I see that comment-indent-new-line was added to emacs in newcomment.el back
in 2000. So I don't know why org-comment-line-break-function was added. May
be Nicolas can comment more on that.

So would this patch work?

=

>From 1a9187b82ed8d4e8d54ddd369a44d34295281fc3 Mon Sep 17 00:00:00 2001
From: Kaushal Modi 
Date: Tue, 30 Nov 2021 20:37:10 -0500
Subject: [PATCH] org: Remove `org-comment-line-break-function'

* lisp/org.el: Remove `org-comment-line-break-function' and let
`comment-line-break-function' be the default value.

This fixes the `M-j' binding issue reported by Richard Lawrence in
.
---
 lisp/org.el | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index ec59ddf44..ee8ca1f03 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19624,8 +19624,7 @@ assumed to be significant there."

 ;; `org-auto-fill-function' takes care of auto-filling.  It calls
 ;; `do-auto-fill' only on valid areas with `fill-prefix' shadowed with
-;; `org-adaptive-fill-function' value.  Internally,
-;; `org-comment-line-break-function' breaks the line.
+;; `org-adaptive-fill-function' value.

 ;; `org-setup-filling' installs filling and auto-filling related
 ;; variables during `org-mode' initialization.
@@ -19647,8 +19646,7 @@ assumed to be significant there."
   (setq-local fill-paragraph-function 'org-fill-paragraph)
   (setq-local auto-fill-inhibit-regexp nil)
   (setq-local adaptive-fill-function 'org-adaptive-fill-function)
-  (setq-local normal-auto-fill-function 'org-auto-fill-function)
-  (setq-local comment-line-break-function
'org-comment-line-break-function))
+  (setq-local normal-auto-fill-function 'org-auto-fill-function))

 (defun org-fill-line-break-nobreak-p ()
   "Non-nil when a new line at point would create an Org line break."
@@ -19903,17 +19901,6 @@ filling the current element."
  (adaptive-fill-mode (not (equal fill-prefix ""
  (when fill-prefix (do-auto-fill))

-(defun org-comment-line-break-function (&optional soft)
-  "Break line at point and indent, continuing comment if within one.
-The inserted newline is marked hard if variable
-`use-hard-newlines' is true, unless optional argument SOFT is
-non-nil."
-  (if soft (insert-and-inherit ?\n) (newline 1))
-  (save-excursion (forward-char -1) (delete-horizontal-space))
-  (delete-horizontal-space)
-  (indent-to-left-margin)
-  (insert-before-markers-and-inherit fill-prefix))
-

 ;;; Fixed Width Areas

-- 
2.34.0

=

Re: [PATCH] Fix regex for determining image width from attribute

[Matt Huszagh]

Timothy  writes:

> What would be a more sensible interpretation in your mind? The “true” value
> depends on the number of columns, and fetching that information seems a bit
> unreasonable. Since this isn’t just used if nothing else if given, I see a 
> 120%
> interpretation as fairly reasonable.

I think there are several different questions/considerations here, which
I'll address in a second. But first, I think the essential disagreement
is whether org should take an action if not explicitly told to do so. I
think org should only perform some action if given a clear directive. In
this context, I feel that org is guessing what the user wants and taking
an action based on that guess.

Ok, back to the fact that there are multiple considerations here. The
first issue is whether specifying a width for a backend reflects an
intention to have that same width in the org buffer. As I previously
stated, I don't agree that one implies the other. But, as also
previously discussed, this was a decision that was made almost 10 years
ago, so changing it would be a breaking change, etc. Because of that,
I'm not totally sure what org should do, and I expect a lot of people
won't want to change this.

The other consideration is if we take the first point as a given (that
org should use width directives for other backends), should it also
attempt to interpret directives that are ambiguous? In this case, do we
interpret 1.2\somemacro as 1.2? If \somemacro could only be \linewidth,
I'd be inclined to agree that this is logical. I also understand the
case for \columnwidth, though this is slightly less clear. But, what if
someone used 1.2\columnsep? Seems a bit unusual I know, but maybe
someone would want this. Again, I don't think we should guess if there's
a chance we could be wrong.

I totally agree with you that we don't want to implement a pseudo latex
parser here. But I feel like all this complexity is easily resolved by
just requiring that people be explicit about their intentions (i.e.,
specify #+attr_org: :width). That would avoid all the complex behavior
and surprises that could result from making intelligent guesses about
what the user wants.

Anyway, let me know what you want in terms of the patch. I still think
prioritizing attr_org should be its own patch and changing the regex and
all the other behavior should be a separate issue. But, if you'd like me
to perform the change I mentioned in my last email, I can take the time
to write that up and include it in the same patch.

Thanks
Matt

Re: Orgdown: negative feedback & attempt of a root-cause analysis

[Juan Manuel Macías]

Tom Gillespie writes:

> Karl,
>The exact naming of a thing is nearly always the most contentious
> step in trying to promulgate it. In my own field we can easily get all
> parties to agree on a definition, but they refuse to budge on a name.
> As others have said, I wouldn't worry about kibitizing over the name.
>
> I would however worry about the larger negative reaction. From my
> perspective I think the issue is that there are many efforts working
> toward a formalized specification for Org syntax and Org mode
> functionality, and some of those stakeholders who have invested
> significant effort may feel blindsided by a public declaration
> announcing Orgdown because they were not consulted and not
> made aware that you were working on it.
>
> I appreciate the amount of work that you have put in, I have devoted
> hundreds of hours to working on an alternate implementation of org
> in Racket that uses a formal ebfn in hopes that others will be able
> to use it as a guide and as a way to talk formally about how Org
> parsers and implementations should behave.
>
> It would thus be easy for me to say that your approach has put the
> cart before the horse, because there are countless nuances in the
> specification for Org syntax which must be addressed before any
> levels of org compliance can be specified, otherwise the behavior
> between levels will be inconsistent.
>
> If I were to say this, it would not be fair to you at all. The ideas
> and motivation for Orgdown are vital and important. You have put
> in enormous thought and effort, all because you care about Org
> and want to see it succeed.
>
> The issue is that any shared specification for Org syntax is
> fundamentally about how to coordinate as a community.
> The way that Orgdown was presented to the community feels
> (to me) like it is being imposed top down or coming from an
> individual source, not from an open and visible community
> process (the subject of your original email reads as a declaration
> in english, and thus can be quite off putting, though I know that
> was not the intention).
>
> I personally haven't bothered with promulgation because I think
> that we are not technically ready as a community to approach
> outreach to other developers in a way that we can succeed.
>
> The good news is that all of this can co-exist if we want it to,
> but we need to be clear about our objectives as a community.
>
> To me these objectives are as follows (and I would love
> to hear from others about additional or alternate objectives).
>
> 1. To never fracture Org syntax so as to avoid the nightmare
> of markdown flavors. (This means being able to say clearly
> as a community that a parser is out of compliance and that
> it is up to the user to fix their files. The ruby org parser used
> by Github is a major issue here.)
> 2. To provide a clear specification for what graceful degradation
> looks like when parsing Org syntax if a parser does not support
> some portion of that syntax (e.g. should property drawer lines
> be excluded or rendered as plain text?).
> 3. Provide a solid basis on which further formal specification
> can be built. (My interests in particular are around providing
> consistent semantics for org-babel blocks across languages
> so that babel implementations can clearly communicate what
> runtime features they support.)
>
> The approach for Orgdown can absolutely meet all three of
> these objectives, however in its current form Orgdown1 is not
> sufficiently well specified to avoid fracturing the syntax.
> This is because Org syntax is extremely complex (even the
> elisp implementation of Org mode is internally inconsistent)
> and there are edge cases where behavior will diverge if parsing
> of even the simplest elements is not fully specified.
>
> There are many ways to remedy this, however they require
> a more formal approach. A number of us are working to build
> technical foundations for such a formal approach, but I do not
> think that any of those projects are ready to be used to
> specify discrete levels of Org syntax parsing compliance.
>
> If I may, I would suggest that an Orgdown0 is something that
> could be well specified, but it would avoid parsing of markup
> altogether and only deal with the major element types. Parsing
> paragraphs and all the org objects is not something that can
> be done piecemeal. There are too many interactions between
> different parts of the syntax, and in some cases the existing
> specification desperately needs to be revisited due to the
> complexity that it induces or because it is underspecified.
> Of course this would make Orgdown0 fairly useless as a
> replacement for markdown, but at least it would be a start.

Everything you comment here seems very sensible to me.

Anyway I have to say that, in my case, the name 'orgdown' is not the
issue, but the underlying idea under the naming, whatever the name is.
IMHO, reduce Org to a markup language or, to put it somewhat
metaphorically

Re: Timestamps

[David Masterson]

Jude DaShiell  writes:

> I think the new standard is better since it allows for work or an agenda
> item to cross one or more Midnights.

If so, then the Org commands should be updated to follow the standard.

-- 
David Masterson

Re: Timestamps

[Jude DaShiell]

Not to mention the documentation.


On Tue, 30 Nov 2021, David Masterson wrote:

> Jude DaShiell  writes:
>
> > I think the new standard is better since it allows for work or an agenda
> > item to cross one or more Midnights.
>
> If so, then the Org commands should be updated to follow the standard.
>
>

Re: Timestamps

[David Masterson]

My mistake -- it is in the (latest?) documentation of "Plain Timestamp"
under "Dates and Times".  Eyes are getting old.  ;-)

Jude DaShiell  writes:

> Not to mention the documentation.
>
>
> On Tue, 30 Nov 2021, David Masterson wrote:
>
>> Jude DaShiell  writes:
>>
>> > I think the new standard is better since it allows for work or an agenda
>> > item to cross one or more Midnights.
>>
>> If so, then the Org commands should be updated to follow the standard.
>>
>>

-- 
David Masterson

Re: Timestamps

[David Masterson]

Nicolas Goaziou  writes:

> Hello,
>
> David Masterson  writes:
>
>> Has the format for timestamps covering (say) a few hours changed?  The
>> following is still possible with "C-c .", but (I think) it is not
>> documented in the Org-Mode manual:
>>
>>   <2021-11-27 Sat 10:30-12:30>
>>
>> This seems to be the new standard:
>>   <2021-11-27 Sat 10:30>--<2021-11-27 Sat 12:30>
>
> Both are valid. Maybe the manual needs some clarification. Would you
> want to tackle it?

My mistake, I missed it.  Thanks

-- 
David Masterson

Re: [PATCH] Fix regex for determining image width from attribute

[Timothy]

Hi Matt,

Thanks for your thoughtful deliberation on this.

> I think the essential disagreement is whether org should take an action if not
> explicitly told to do so. I think org should only perform some action if given
> a clear directive. In this context, I feel that org is guessing what the user
> wants and taking an action based on that guess.

I broadly agree with this, but I think this is provided by the four forms that
`org-image-actual-width' can take:
⁃ `t', in which case the actual image width is always used
⁃ an integer, in which case that will always be used as the width
⁃ `nil', which produces the guessing behaviour we’re discussing
⁃ `(val)', which guesses, falling back on `val'

> Ok, back to the fact that there are multiple considerations here. The
> first issue is whether specifying a width for a backend reflects an
> intention to have that same width in the org buffer. As I previously
> stated, I don’t agree that one implies the other. But, as also
> previously discussed, this was a decision that was made almost 10 years
> ago, so changing it would be a breaking change, etc. Because of that,
> I’m not totally sure what org should do, and I expect a lot of people
> won’t want to change this.

I’m not opposed to /expanding/ the behaviour (with due consideration), which 
could
resolve some of your concerns, but I don’t think it would be good to prevent the
current behaviour, which at this point seems well-established.

> The other consideration is if we take the first point as a given (that
> org should use width directives for other backends), should it also
> attempt to interpret directives that are ambiguous? In this case, do we
> interpret 1.2 as 1.2? If  could only be ,
> I’d be inclined to agree that this is logical. I also understand the
> case for , though this is slightly less clear. But, what if
> someone used 1.2? Seems a bit unusual I know, but maybe
> someone would want this. Again, I don’t think we should guess if there’s
> a chance we could be wrong.

I feel this very much depends on how bad “guessing wrong” is, and as previously
discussed, since it’s rather easy to correct or set `org-image-actual-width' to
prevent this, I’m not sure it warrants being terribly concerned about.

> I totally agree with you that we don’t want to implement a pseudo latex
> parser here. But I feel like all this complexity is easily resolved by
> just requiring that people be explicit about their intentions (i.e.,
> specify #+attr_org: :width). That would avoid all the complex behavior
> and surprises that could result from making intelligent guesses about
> what the user wants.

I think prioritising `#+attr_org: :width' makes a lot of sense, but I feel quite
reluctant to /require/ it.

> Anyway, let me know what you want in terms of the patch. I still think
> prioritizing attr_org should be its own patch and changing the regex and
> all the other behavior should be a separate issue. But, if you’d like me
> to perform the change I mentioned in my last email, I can take the time
> to write that up and include it in the same patch.

Thanks for continuing with this. Moving forward, I think it would be best to:
⁃ Make a patch just for prioritising `#+attr_org'
⁃ Make a patch just improving the regex (before or after the `#+attr_org' patch)
⁃ Discuss changing the behaviour of image previews separately later / in another
  thread, linking to this thread when doing so.

How does that sound?

Lastly, a comment on your documentation patch from earlier. I like the changes
to `org-image-actual-width', however I think you’ve been over-eager with 
scrapping
the current docstring for `org-display-inline-image--width'. Since the behaviour
is implemented there, I think it should at a minimum be documented there.
The docstring for a function referring to a variable’s documentation for how 
it’s
handled by the function seems a bit weird.

All the best,
Timothy

Re: [PATCH] Fix org-comment-line-break-function

[Tim Cross]

Kaushal Modi  writes:

> On Tue, Nov 30, 2021 at 6:29 PM Tim Cross  wrote:
>
>  It would be good to get Nicholas' input here as I think he wrote the
>  original function back in 2012. 
>
> Just to see what happens, I tried this:
>
> M-: (setq-local comment-line-break-function #'comment-indent-new-line)
>
> .. and then M-j started working perfectly! It worked fine both: in Org 
> comment lines and out of comment lines.
>
> I see that comment-indent-new-line was added to emacs in newcomment.el back 
> in 2000. So I don't know why
> org-comment-line-break-function was added. May be Nicolas can comment more on 
> that.
>
> So would this patch work?
>

Well, that is the big question - why was org-comment-line-break-function
added instead of just using the default comment-indent-new-line? My
only thoughts are there must be some subtle difference in org which the
default function was not sophisticated enough to work with. Problem is,
not knowing what that might be makes it hard to test and verify the real
impact of making the change.

Until this is determined, I think the only 'safe' approach would be to
just advise those who are impacted by the M-j issue to set
comment-line-break-function to comment-indent-new-line and then wait to
see if someone who has more historical context to comment. If nothing or
nobody says anything after a couple of months, then maybe apply your
patch.

Re: [patch] fix ox-latex async export bug

[Sébastien Miquel]

Hi,

Rasmus Pank Roulund writes:

This is most likely due to native compilation which compiles the
unquoted lambda. Once compiled, it (presumably) fails to be passed to
the external emacs process.

Ah, interesting.  Is this a bug or a feature?


I think the bug's with org-mode. As I explain elsewhere in the thread,
this lambda is to be treated as data, and written to a file to be
executed by the external emacs instance. It should always have been
quoted (naming it happens to work also).

Regards,

--
Sébastien Miquel

Re: how to export red colored TeX to latex

[Eric S Fraga]

Very nice Juan!  I would find this use of links quite useful.

-- 
: Eric S Fraga, with org release_9.5-230-g2bbac4 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096