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

[Marcin Borkowski]

On 2021-11-29, at 19:27, 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.

This!

>> 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.
>
> 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. It
> suffices to use unstyled text, headings, code blocks, quotes, emphasis.
> That is it basically. org shines on documents where more is required --
> documentation, books, since recently scientific articles. Markdown’s
> common subset is not expressive enough for these documents, whereas for
> simple documents there is not much benefit in trading in Markdown for
> org. Thus, maybe it is more fruitful to try to market org(down) as a
> markup for complex documents, with the added benefit that it does
> incidentally also cover simple documents nicely on par with Markdown.

I agree.  When I type Markdown (and I often do, in a few places),
I mainly use `backticks` (single and triple ones) for code etc.,
_italics_,
- sometimes
- bulleted
- lists,

> quotations (not very often),

and a

# Heading

on rare occasions.  That's pretty much it.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Is it possible to add a "cumulative" column in column view?

[Marcin Borkowski]

Hi fellow Orgers,

I started using column view recently, and I would greatly appreciate it
if I could add a column with "cumulative sum".  In a less-than ideal
world it would be the sum of all the values of some property until the
current row.  In an ideal world, it could only count values of some
property A for rows in which property B is set to certain value.

I looked at the docstring of `org-columns-summary-types', and it is
obviously impossible to do it with it (the `summarize' function always
gets all the values and doesn't get the row number on anything like
it).  How difficult would it be to extend it?  (A cursory look at
`org-colview.el' suggests that there are quite a few layers of
abstraction, so it doesn't look like a 10-minute hack...)

TIA,

-- 
Marcin Borkowski
http://mbork.pl

Re: Subject: [PATCH] Fix DISPLAY error on exporting org with plantuml to html

[Sun Lin]

Hi Timothy,

Thank you! : ) 

I had signed the FSF, RT: 1718442. 

B.R.
 Lin

On Tuesday, November 30, 2021, 04:22:03 AM UTC, Timothy  
wrote: 
> Hi Sun,

> Thanks for not forgetting about this. As I commented before, I this looks
 sensible enough to apply, and so I’ve just pushed it as f9dcc3d with a tweaked
 commit message.

> You’ve also been added to the list of TINYCHANGE contributors on
 . If you submit more than 20
 cumulative lines of non-trivial code, you’ll need to get FSF assignment.

> Thanks for sharing the issue and making a patch for it  hopefully we’ll see
 you around in the future.

Re: Subject: [PATCH] Fix DISPLAY error on exporting org with plantuml to html

[Timothy]

Hi Sun,

> Can any help merge the patch? Or should I request Bastien to merge the patch? 

Thanks for not forgetting about this. As I commented before, I this looks
sensible enough to apply, and so I’ve just pushed it as f9dcc3d with a tweaked
commit message.

You’ve also been added to the list of TINYCHANGE contributors on
. If you submit more than 20
cumulative lines of non-trivial code, you’ll need to get FSF assignment.

Thanks for sharing the issue and making a patch for it  hopefully we’ll see
you around in the future.

All the best,
Timothy

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

[Tim Cross]

Richard Lawrence  writes:

> Tim Cross  writes:
>
>> I'm running Emacs 28 and cannot reproduce the issue you observe.
>
> Hmm, the plot thickens!
>
>> Running emacs -Q I find M-j is bound to
>>
>> M-j runs the command default-indent-new-line (found in global-map),
>> which is an interactive compiled Lisp function in ‘simple.el’.
>
> I definitely see the error in emacs -Q with
>
> GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo 
> version 1.16.0)
 o>
> which only contains Org 9.3, in my installation. So the problem has been
> around at least that long, but only surfaced for me because the binding
> of M-j changed between Emacs 26 and 27.
>
>> This binding is the same inside and outside of org mode.
>
> Yes, but inside Org mode, default-indent-new-line calls
> org-comment-line-break-function (because it is the value of
> comment-line-break-function), which is where the error originates.
>
> The last line of org-comment-line-break-function is:
>
>   (insert-before-markers-and-inherit fill-prefix)
>
> and fill-prefix is nil, at least in all the contexts where I've tried
> this.
>
> Since you're not seeing the error, could you please check in an Org
> buffer whether:
>
>   - comment-line-break-function is 'org-comment-line-break-function
>   - org-comment-line-break-function contains the line above (it should;
> it's still there in the master branch)
>   - fill-prefix is nil when you type M-j?
>   

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’
Local in buffer test.org; global value is 
comment-indent-new-line

Mode-specific function that line breaks and continues a comment.
This function is called during auto-filling when a comment syntax
is defined.
The function should take a single optional argument, which is a flag
indicating whether it should use soft newlines.

  This variable may be risky if used as a file-local variable.

and fill-prefix is

fill-prefix is a variable defined in ‘simple.el’.

Its value is nil

String for filling to insert at front of new line, or nil for none.

  Automatically becomes buffer-local when set.
  This variable is safe as a file local variable if its value
  satisfies the predicate ‘string-or-null-p’.
  You can customize this variable.
  Probably introduced at or before Emacs version 1.7.

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

Emacs is

GNU Emacs 28.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30,
cairo version 1.16.0) of 2021-11-30

and org version is

Org mode version 9.5.1 (release_9.5.1-11-g96d91b @
/usr/local/share/emacs/28.0.60/lisp/org/)

Looking at the git log, I can only find these messages relating to
default-indent-new-line

commit b41f31d2b60269bd0e7addd1081f3738f91e76bc
Author: Lars Ingebrigtsen 
Date:   Wed Aug 4 10:03:12 2021 +0200

Make `M-j' work reliably if `comment-auto-fill-only-comments' is set

* lisp/simple.el (default-indent-new-line): Force breaking the
line when called interactively (bug#49849).  (Perhaps the
interactive command should be rebound and call this function
instead...)

commit 8a11e430ec261c08cc928a7a5b05ee1027f50368
Author: Dmitry Gutov 
Date:   Thu Jun 27 16:57:47 2019 +0200

Use `default-indent-new-line' instead of `indent-new-comment-line'

* lisp/simple.el (default-indent-new-line): Doc string fix.

* lisp/textmodes/refill.el (refill-post-command-function): Make
default-indent-new-line work as indent-new-comment-line.

* lisp/textmodes/refill.el (refill-post-command-function): Bind
`M-C-j' and `M-j' to default-indent-new-line instead of
indent-new-comment-line to allow overriding via
`comment-line-break-function' (bug#12413).

commit 0b727f9d087d950c0d6614c9ec743a935d4e5fc7
Author: Richard M. Stallman 
Date:   Tue Aug 7 03:04:23 2007 +

(default-indent-new-line): New function.
It calls comment-line-break-function if there are comments.
(do-auto-fill): Use that.

which indicates the function was added in 2007 by RMS and made the
default for M-j in 2019. 

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.

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. It is
critically important to ensure Org has not been loaded before attempting
to do an upgrade. Unfortunately, it is very easy to not realise that
something in your init file is loading org. One of the advantages of
using use-package is that you can configure things so that org is not
loaded until you actually open an org file, 

Re: [org-cite] autoload oc processors?

[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.

Regards,
-- 
Nicolas Goaziou

[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]

:inherit-props seems to not consider global properties.

Testcase:

# Create a global property

#+PROPERTY: HOURLY_RATE 150

* Top 1
** Sub 1A
# here we should get the global property, but do not
   :LOGBOOK:
   CLOCK: [2021-09-26 Sun 12:25]--[2021-09-26 Sun 13:25] =>  1:00
   - I did some tasks
   :END:

** Sub 1B
* Top 2
  :PROPERTIES:
  :HOURLY_RATE: 110
  :END:
** Sub 2A
# successfully inherit from "Top 2"
   :LOGBOOK:
   CLOCK: [2021-09-26 Sun 21:26]--[2021-09-26 Sun 22:26] =>  1:00
   - I did some other tasks
   :END:

** Sub 2B
   :PROPERTIES:
   :HOURLY_RATE: 90
   :END:
# override Top 2
   :LOGBOOK:
   CLOCK: [2021-09-26 Sun 18:30]--[2021-09-26 Sun 19:00] =>  0:30
   - Attended a meeting
   :END:

#+BEGIN: clocktable :scope file :maxlevel 2 :properties ("HOURLY_RATE")
:inherit-props t
#+CAPTION: Clock summary at [2021-09-26 Sun 22:48]
| HOURLY_RATE | Headline |   Time |  |
|-+--++--|
| | *Total time* | *2:30* |  |
|-+--++--|
| | Top 1|   1:00 |  |
| | \_  Sub 1A   || 1:00 |
| 110 | Top 2|   1:30 |  |
| 110 | \_  Sub 2A   || 1:00 |
|  90 | \_  Sub 2B   || 0:30 |
#+END:

I expect that "Sub 1A" will show the global HOURLY_RATE of 150, but it is
empty.

Emacs  : GNU Emacs 27.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
2.24.32, cairo version 1.16.0)
 of 2020-09-01
Package: Org mode version 9.4.6 (9.4.6-12-gdcc3a8-elpa @
/home/jet/.config/emacs/elpa/org-20210823/)

current state:
==
(setq
 org-duration-format 'h:mm
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-latex-listings t
 org-link-shell-confirm-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-export-global-macros '((LASTMONTH .
 "(eval (format-time-string \"%B %Y\"
(encode-time (decoded-time-add (decode-time) (make-decoded-time :month
-1)")
(NET30 .
 "(eval (format-time-string \"%m/%d/%Y\"
(encode-time (decoded-time-add (decode-time) (make-decoded-time :day
30)")
(LASTOFLASTMONTH .
 "(eval (format-time-string \"%m/%d/%Y\"
(encode-time (let ((d (decode-time))) (setf (decoded-time-day d) 1)
(decoded-time-add d (make-decoded-time :day -1))")
(FIRSTOFLASTMONTH .
 "(eval (format-time-string \"%m/%d/%Y\"
(encode-time (let ((d (decoded-time-add (decode-time) (make-decoded-time
:month -1 (setf (decoded-time-day d) 1) d")
)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
 org-log-note-clock-out t
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-mode-hook '(#[0 "\301\211 \207" [imenu-create-index-function
org-imenu-get-tree] 2]
 org-bullets-mode org-tempo-setup (lambda nil
(electric-indent-local-mode -1))
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-all append
local] 5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-babel-pre-tangle-hook '(save-buffer)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-babel-load-languages '((emacs-lisp . t) (dot . t) (ditaa . t))
 org-export-backends '(ascii html icalendar latex md confluence re-reveal)
 org-ascii-format-drawer-function #[771 " \207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-ditaa-jar-path "/usr/share/ditaa/ditaa.jar"
 org-structure-template-alist '(("n" . "notes") ("a" . "export ascii") ("c"
. "center")
("C" . "comment") ("e" . "example") ("E" .
"export")
("h" . "export html") ("l" . "export
latex") ("q" . "quote")
("s" . "src") ("v" . "verse"))
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
 org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
 

Re: [org-cite] autoload oc processors?

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> I probably don't understand autoloading very well, but was thinking of
> something like this:
>
> ;;;###autoload
> (org-cite-register-processor 'oc-natbib ...

IIUC, this would register `natibib' processor for everyone whenever Org
is loaded. This may not be what you have in mind.

Regards,
-- 
Nicolas Goaziou

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

[Nicolas Goaziou]

Hello,

Sébastien Miquel  writes:

> Attached is a patch that applies the same fix where affected.

Thank you. It mostly looks good, but I have one nit.

> -  (lambda (file)
> - (run-hook-with-args 'org-icalendar-after-save-hook file) nil
> +  '(lambda (file)
> +  (run-hook-with-args 'org-icalendar-after-save-hook file) nil

This is not really the same fix. 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.

WDYT?

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] Fontification for inline src blocks

[Timothy]

Hi Ihor,

> That’s an option. Though you should also consider a paragraph ending at
> EOB. Searching for “” will fail with error then.

Don’t worry, that’s just a snippet. The full logic is as follows

┌
│ (min limit (or (save-excursion (and (search-forward "\n" limit t 2) (point)))
│(point-max)))
└

>> [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.

I’ve attached the latest version of the patch. At this point I consider it
fairly well-reviewed, so I’ll push it tomorrow if I don’t hear of any
last-minute issues.

All the best,
Timothy
>From 690718bd2a31f9293572aa7a583a31a0615d18c8 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Tue, 13 Jul 2021 02:43:29 +0800
Subject: [PATCH] org-src: Implement native inline src fontification

* lisp/org-src.el (org-fontify-inline-src-blocks,
org-fontify-inline-src-blocks-1): Create a function to search the buffer
up to a limit for inline src blocks.  Light fontification is applied to
matched inline src blocks.  When `org-src-fontify-natively' is
set, `org-src-font-lock-fontify-block' is applied to the content.

* lisp/org.el (org-set-font-lock-defaults): Add
`org-fontify-inline-src-blocks' to `org-font-lock-extra-keywords', which
is locally bound inside `org-set-font-lock-defaults'.

* lisp/org-faces.el: Introduce a new face `org-inline-src-block' which
inherits from `org-block' by default.
---
 lisp/org-faces.el |  4 
 lisp/org-src.el   | 44 
 lisp/org.el   |  1 +
 3 files changed, 49 insertions(+)

diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index b151045a9..272762789 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -459,6 +459,10 @@ (defface org-block-end-line '((t (:inherit org-block-begin-line)))
   "Face used for the line delimiting the end of source blocks."
   :group 'org-faces)
 
+(defface org-inline-src-block '((t (:inherit org-block)))
+  "Face used for inline source blocks as a whole."
+  :group 'org-faces)
+
 (defface org-verbatim '((t (:inherit (fixed-pitch shadow
   "Face for fixed-with text like code snippets."
   :group 'org-faces
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 51dde602d..639a447e8 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -654,6 +654,50 @@ (defun org-src-font-lock-fontify-block (lang start end)
 	 '(font-lock-fontified t fontified t font-lock-multiline t))
 	(set-buffer-modified-p modified)
 
+(defun org-fontify-inline-src-blocks (limit)
+  "Try to apply `org-fontify-inline-src-blocks-1'."
+  (condition-case nil
+  (org-fontify-inline-src-blocks-1 limit)
+(error (message "Org mode fontification error in %S at %d"
+(current-buffer)
+(line-number-at-pos)
+
+(defun org-fontify-inline-src-blocks-1 (limit)
+  "Fontify inline src_LANG blocks, from `point' up to LIMIT."
+  (let ((case-fold-search t)
+(initial-point (point)))
+(while (re-search-forward "\\_

Re: [org-cite] autoload oc processors?

[Timothy]

Hi Bruce,

> Primarily I am asking if there’s a way to load the processor as needed
> without a user explicitly having to do so.

This is actually a thought that occurred to me recently, and I’ve been
considering bringing up on the ML. Thanks for mentioning this.

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.

All the best,
Timothy

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi Tim,

> I’ll let you (/the ML) know when I’ve taken a look at stiky bits, and whether 
> I
> think I’m able to create something that works. My intuition is that if ls -l 
> can
> properly represent sticky bits (and my rudimentary understanding is that it 
> can)
> it should be fine for specifying them too. We’ll see.

I’ve gone away and had a look, then come back and had a think. This has resulted
in 9ce7802. Since we just have to worry about suid/sgid (as :tangle-mode is only
applied to the file produced [with the sticky bit being dir-specific]), not much
is required — we just allow the `s' in place of `x' for the user/group 
executable
flag.

This is pretty trivial as we’re still relying on `file-modes-symbolic-to-number'
for this, and in a very straight-forward way. So, I think we should be fine now 
.

All the best,
Timothy

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

[M . ‘quintus’ Gülker]

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 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.

> 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.

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. It
suffices to use unstyled text, headings, code blocks, quotes, emphasis.
That is it basically. org shines on documents where more is required --
documentation, books, since recently scientific articles. Markdown’s
common subset is not expressive enough for these documents, whereas for
simple documents there is not much benefit in trading in Markdown for
org. Thus, maybe it is more fruitful to try to market org(down) as a
markup for complex documents, with the added benefit that it does
incidentally also cover simple documents nicely on par with Markdown.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

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

[Richard Lawrence]

Tim Cross  writes:

> I think something is very wrong if your Emacs 28 has org 9.3. I'm pretty
> sure the earliest version which was bundled with Emacs 28 was 9.4 - it
> is certainly 9.5 now and that is the version that will be bundled with
> it when it is released.

Fair enough -- I did think that was weird. I installed Emacs 28 as
emacs-next via Guix, which I am new to; maybe it installed a very old
build, or maybe something is screwed up in the load-path. 

Still, I think this is not relevant to the problem. I see the same
problem on Emacs 27.2 (also installed via Guix) with the built-in Org
9.4.4. I also see it on both Emacs 27.2 and 28 when I load Org
from the latest bugfix branch in git ("Org mode version 9.5.1
(release_9.5.1-13-gc91271 @ /home/rwl/src/org-mode/lisp/)").

Several other people have confirmed that they see it too -- two in this
thread, one privately to me off-list.

So I don't think it's a problem with my setup. But I'm still trying to
get clear on where the problem could be. The functions involved
(default-indent-new-line, org-comment-line-break-function, and
insert-before-markers-and-inherit) mostly haven't been modified in a
long time. What *has* changed is that M-j now calls this stack of
functions, when it used to call comment-indent-new-line (in Emacs 26).

In fact, if I run M-x default-indent-new-line in an Org buffer in Emacs
26 with the built-in Org 9.1.9, I get the same error. I think this issue
has been lurking for a while -- it's just that the new binding brought
it to the surface.

-- 
Best,
Richard

Re: Re-installing org-mode packages due to annoying message

[Thomas S. Dye]

Aloha Alan,

Alan E. Davis  writes:


It is interesting that an old timer like yourself would reach 
for
Spacemacs.  I haven't, mostly because I don't think I need the 
modal model
of Vi.  The keybindings of Emacs or so convenient and 
intelligent I find
them to be enough.  Here's where I might have spent more time in 
the early
days learning the basics better.  One of the things I like about 
Emacs is
that I can dance around a page of text, in a manner that the 
commercially
produced text editors and word processors I know have not dared 
to
implement.  We are locked in to a dumbed down interface in all 
the software
we encounter.  I cannot think of one example just now, but maybe 
the way
one can move back and forth over characters and words.  I never 
learned Vi,

except to be able to edit a simple config file if need be.

I know I am over my head, and I have been so for the 30-ish 
years I have
been using Emacs and for the time I have used Org-mode.  It is 
more than I
can do to keep up with the newer complexities that are cropping 
up.  Yet,

just like the plain text files, and the LaTeX source for my one
publication, a lexicon of animal names, they live on while 
documents using
the high priced tools are not longer readable or editable.  And 
through all
the changes, my little utilities for editing things that only I 
could
probably care about, and I would not expect anyone to care to 
learn---they

still work today.  I love it!


FYI, from another old-timer in over his head, Spacemacs has a simple option to 
enable Emacs key bindings.  You don't need to use the modal bindings.

hth,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye

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

[Matt Price]

I don't have very thoughtful comments but I'll just say that I really do
also like the idea of a formal syntax; that a staged standard seems to make
sense to me, though I'm ignorant about how syntaxes are normally defined
and managed;  and am generally not super enthusiastic about the particular
name that's been chosen.

It seems like there are lots of people thinking in similar ways about
related issues -- that is, whenever it's possible, treating org files as
syntax trees rather than linear text trees.. The org-ml project comes to
mind; so does the recent work on tree-sitter in emacs; and Ihor's recent
thread on changing fontification.  I guess it would be nice if the
smarter-than-me people involved in all these projects are tracking each
other somewhat to make sure efforts converge as much as possible.

For me it would be really great to have better support for an org syntax in
VSCode & in Node; I'm sure other people have their own priority areas.  A
syntax definition would surely help?


On Mon, Nov 29, 2021 at 8:22 AM Karl Voit  wrote:

> Hi Tim,
>
> * Tim Cross  wrote:
> >
> > Hi Karl,
> >
> > while I can appreciate the point you are making, I'm doubtful your
> > suggestion will gain the traction necessary to work.
>
> You might be right. Only time will tell. ;-)
>
> > To me, it feels a little like the frequent posts from RMS in the
> > emacs-devel list where he gets upset when people refer to Linux
> > instead of GNU Linux.
>
> I disagree here.
>
> Linux vs. GNU/Linux are two different names for the same thing.
> Org-mode is an Elisp implementation and Orgdown is just a syntax
> definition. So they are completely different things.
>
> > To some extent, the distinction will be too subtle for many and
> > often, it isn't clear whether an issue is a syntax definition
> > (orgdown) or an implementation bug or just simply user
> > misunderstanding.
>
> 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).
>
> > Perhaps we just need a name for the markup syntax which doesn't actually
> > reference 'org' at all - it simply is the markup syntax which org
> > happens to use. A completely separate name might avoid confusion and
> > would make it very clear that the markup syntax is not org mode. Problem
> > is, naming is terribly difficult and I have no suggestions on what would
> > be a good name.
>
> 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.
>
> > I have not yet viewed your video, but will certainly be doing so. Again,
> > agree with the sentiment of what your trying to do, just not convinced
> > it is compatible with basic human nature.
>
> Maybe we need to differ between the Org-mode community with
> potential bias and the main target group of people who did use
> Markdown in the past and never have heard of Org-mode before?
>
> --
> get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
>> get Memacs from https://github.com/novoid/Memacs <
> Personal Information Management > http://Karl-Voit.at/tags/pim/
> Emacs-related > http://Karl-Voit.at/tags/emacs/
>
>
>

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

[Colin Baxter ]

> Richard Lawrence  writes:

> Tim Cross  writes:
>> I'm running Emacs 28 and cannot reproduce the issue you observe.

> Hmm, the plot thickens!

>> Running emacs -Q I find M-j is bound to
>> 
>> M-j runs the command default-indent-new-line (found in
>> global-map), which is an interactive compiled Lisp function in
>> ‘simple.el’.

> I definitely see the error in emacs -Q with

Indeed, so do I with emacs -Q. I get the error message with emacs-27.2,
emacs-28.0.50 and 29.0.50. 

I'm afraid the nuances of line indenting in org-mode have always been a
black art to me. I stick to C-j because I've found it works for me in
most cases.

Best wishes,

Colin Baxter.

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

[Tim Cross]

Richard Lawrence  writes:

> Tim Cross  writes:
>
>> I'm running Emacs 28 and cannot reproduce the issue you observe.
>
> Hmm, the plot thickens!
>
>> Running emacs -Q I find M-j is bound to
>>
>> M-j runs the command default-indent-new-line (found in global-map),
>> which is an interactive compiled Lisp function in ‘simple.el’.
>
> I definitely see the error in emacs -Q with
>
> GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo 
> version 1.16.0)
>
> which only contains Org 9.3, in my installation. So the problem has been
> around at least that long, but only surfaced for me because the binding
> of M-j changed between Emacs 26 and 27.
>

I think something is very wrong if your Emacs 28 has org 9.3. I'm pretty
sure the earliest version which was bundled with Emacs 28 was 9.4 - it
is certainly 9.5 now and that is the version that will be bundled with
it when it is released.

My suggestion would be to update Emacs to current version on the
emacs-28 branch of the git repo. This is at 'rc1' level and close to
what will be released. There is not much oint in trying to diagnose an
issue with both an old development version of Emacs and a version of org
which is two releases old. Update Emacs and ensure org is at least
version 9.5 (verison 9.5.1 was just released).

Re: [org-cite] autoload oc processors?

[Bruce D'Arcus]

On Sun, Nov 28, 2021 at 5:19 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > Is there any reason not to autoload the processors?
>
> I am not sure about what you mean. Could you elaborate?

Primarily I am asking if there's a way to load the processor as needed
without a user explicitly having to do so.

I probably don't understand autoloading very well, but was thinking of
something like this:

;;;###autoload
(org-cite-register-processor 'oc-natbib ...

Bruce

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

[Karl Voit]

Hi Tim,

* Tim Cross  wrote:
>
> Hi Karl,
>
> while I can appreciate the point you are making, I'm doubtful your
> suggestion will gain the traction necessary to work. 

You might be right. Only time will tell. ;-)

> To me, it feels a little like the frequent posts from RMS in the
> emacs-devel list where he gets upset when people refer to Linux
> instead of GNU Linux. 

I disagree here. 

Linux vs. GNU/Linux are two different names for the same thing.
Org-mode is an Elisp implementation and Orgdown is just a syntax
definition. So they are completely different things.

> To some extent, the distinction will be too subtle for many and
> often, it isn't clear whether an issue is a syntax definition
> (orgdown) or an implementation bug or just simply user
> misunderstanding.

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).

> Perhaps we just need a name for the markup syntax which doesn't actually
> reference 'org' at all - it simply is the markup syntax which org
> happens to use. A completely separate name might avoid confusion and
> would make it very clear that the markup syntax is not org mode. Problem
> is, naming is terribly difficult and I have no suggestions on what would
> be a good name.

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.

> I have not yet viewed your video, but will certainly be doing so. Again,
> agree with the sentiment of what your trying to do, just not convinced
> it is compatible with basic human nature. 

Maybe we need to differ between the Org-mode community with
potential bias and the main target group of people who did use
Markdown in the past and never have heard of Org-mode before?

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

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

[Christophe Schockaert]

On 2021-11-29 03:33, Michael Ashton wrote:

On Nov 28, 2021, at 6:22 PM, Jim Porter  wrote:

On 11/28/2021 11:46 AM, Karl Voit wrote:
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.


I agree that it's useful to distinguish the files/syntax from the 
*mode*, which contains many functions for doing things with those 
files.


For what it's worth (perhaps not much), I've always referred to the 
syntax/file format as simply "Org"; for example, "I put my notes into 
an Org file." This is by analogy with most of the other Emacs major 
modes for editing files. I write Python in `python-mode', I write C++ 
in `c++-mode', I write text files in `text-mode', and so on.


Maybe "Org" isn't distinct enough though. People unfamiliar with 
Org-Mode might confuse "Org" with "org charts" or some other use of 
the word. Still, if we look to other tools that can read the same 
files as Org-Mode, they tend to be called things like "Organice", not 
"Orgmodeanice". :)


Perhaps orgtext or org-text?

Hi Karl and Org fellows,


I do understand that it has always been a tricky topic, since Org Mode 
and its format are intrinsically linked.


I think what you are bringing is useful, I can feel how a syntax for a 
"standard" Org format subset would be useful (maybe we could keep open a 
way to customize it by exporting Lisp params values as part of a 
document annex, but that's beyond the current status, just to say I 
understand why you bring that :).


I have to say, however, that I am not very enthusiast with the name that 
you came by for this.
At first, because I feel Org format and Markdown are different beasts ; 
eventhough I do use Markdown, I prefer Org alot, so it sounds strange to 
have a reference to Markdown in Org format name.
But, really more because I feel like Org stands on its own, and it does 
not need to help itself as a comparison to Markdown to get its own 
renown, or to explain what it is.


In previous mails, "Org Syntax" and "Org Markup" sounded good to me.
However, I do like "org-text" or "Org Text" a lot, or why not even 
"OrgText", but I favor the first two, which refer to the way we write 
"org-mode" the Emacs Mode and "Org Mode" in documents.


After all, this is exactly what it is about, "Writing text in Org", and 
what it is essentially "text characters arranged according to Org 
format".



Have a good day,

Christophe


--
--->  https://www.citadels.earth
Once it's perfectly aimed, the flying arrow goes straight to its target.
Thus, don't worry when things go right.
There will be enough time to worry about if they go wrong.
Then, it's time to fire a new arrow towards another direction.
Don't sink.  Adapt yourself !  The archer has to shoot accurately and
quickly.
[Words of Erenthar, the bowman ranger] <---

Re: Stable 9.5: invalid function (date date)

[Tim Loderhose]

Hi Ihor,

I refactored my emacs config and it appears like the problem is gone now.
(I was just using use-package, but there may have been some bit loading org
early)

Thanks for the pointer in any case!
Best,
Tim

On Thu, Nov 25, 2021 at 11:09 AM Ihor Radchenko  wrote:

> 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.
>
> Best,
> Ihor
>
>

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

[Max Nikulin]

On 29/11/2021 09:33, Michael Ashton wrote:



On 11/28/2021 11:46 AM, Karl Voit wrote:

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)


Perhaps orgtext or org-text?


I like such variant even though "orgdown" sounds better. Another one:

"text/org" ("slash" may be omitted in speech) as file format for Org 
Mode (as application).


If you can not survive without a pun and funny formatting, then

- "orgless" to emphasize that it lacks power of Org Mode.
- "org<1" to denote compatibility levels.

JSON format is not really human-friendly (in comparison e.g. to YAML), 
but the following representation of compatibility data for web-related 
technologies is great:

https://github.com/mdn/browser-compat-data

Recently I have noticed a number of issues with Org renderer at GitHub. 
I have not checked bugtracker of the ruby project (feel free to forward 
this list to the developers). I am unsure concerning appropriate 
compatibility level but it is annoying that verbatim text inside link 
description is not recognized.


- =[[https://bugzilla.mozilla.org/show_bug.cgi?id=1621763][Bug 1621763: 
[flatpak] native messaging support missing]]=

  square brackets inside link description breaks parsing of whole link
  (outer brackets, target, and description are shown).
- Verbatim text as whole description is not recognized,
  markers are shown
  =[[https://orgmode.org][=org-capture=]]=, the same for =~code~=.
  ~[[help:org-refile][=C-u C-c C-w= ~org-refile~]]~.
  =\u200B= zero-width space inside brackets does not help.
- "info:" links are not converted to HTML ones.
- Footnotes and ~[fn:text]~ links are not supported.
- ~src_elisp{(server-start)}~ appears literally.
- =#+caption:= before =#+begin_example= block is not supported
  and absent in HTML output.
- =#+attr_html: :alt= for images is not supported.
- ~="* %(org-get-x-clipboard 'CLIPBOARD)"=~ ("=" and everything inside
  without outer "~") is not recognized as verbatim.

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

[Marcin Borkowski]

On 2021-11-29, at 13:18, Juan Manuel Macías  wrote:

> Marcin Borkowski writes:
>
>> Quite the contrary.  The amount of confusion between TeX (engine)/TeX
>> (language)/TeX (distro)/TeX-aware text editor/LaTeX (whatever) among
>> novice/casual users has always been terrible.
>
> It's natural when those novice/casual users approach something that is
> new to them, but nothing invincible when they want to learn. The "TeX"
> ecosystem is not trivial, but I think that all, or almost all of us,
> understand each other when things like 'TeX/LaTeX code', 'TeX engine',
> 'LaTeX format', etc. are said. If the TeX language were somewhat
> self-contained and widely used outside of TeX, I would see OK that the
> language had its own name. But, since the TeX language is something that
> almost only TeX understands (roughly said), I think the economy wins
> here (IMHO). I don't see how we could improve everything by having half
> a dozen more exotic names.

Agreed, I just wanted to say that the situation with TeX is more
complicated.  Especially that 92%* TeX users are novice/casual users.

* Number made up, but loosely based on anecdotal evidence;-).

-- 
Marcin Borkowski
http://mbork.pl

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

[Juan Manuel Macías]

Marcin Borkowski writes:

> Quite the contrary.  The amount of confusion between TeX (engine)/TeX
> (language)/TeX (distro)/TeX-aware text editor/LaTeX (whatever) among
> novice/casual users has always been terrible.

It's natural when those novice/casual users approach something that is
new to them, but nothing invincible when they want to learn. The "TeX"
ecosystem is not trivial, but I think that all, or almost all of us,
understand each other when things like 'TeX/LaTeX code', 'TeX engine',
'LaTeX format', etc. are said. If the TeX language were somewhat
self-contained and widely used outside of TeX, I would see OK that the
language had its own name. But, since the TeX language is something that
almost only TeX understands (roughly said), I think the economy wins
here (IMHO). I don't see how we could improve everything by having half
a dozen more exotic names.

Best regards,

Juan Manuel 

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

[Max Nikulin]

On 29/11/2021 07:23, Matt Huszagh wrote:

Max Nikulin writes:


My current variant:

":\\(?:[^\n]*?[[:blank:]]\\)?:width[[:blank:]]+\\(\\S-+\\)"

The regexp should not match e.g.

#+attr_html: :alt something
:width 600

P.S. I would prefer to use the same parser as ox does.


I can probably implement this if people want. But, let me know if I
should indeed use org-export-registered-backends. However, I'm starting
to feel like this should be separate patch (the goal for mine was just
to prioritize attr_org).


I am against regexps that have obvious flaws. I admit however that the 
regexp that appeared long time ago before your patch fails for some 
corner cases as well.


I will left decision to you and to Org developers and maintainers.

Additionally, I like that Timothy transformed a code fragment into 
`org-display-inline-image--width' function and, I suppose, it deserves 
some unit tests (see testing/README file).

[PATCH] [BUG] org.el: Fix first call of `org-paste-subtree'

[Max Nikulin]

An old bug is living in Org.

=C-c C-x C-y= ~org-paste-subtree~ fails just after Emacs start.
Maybe there are more similar issues.

- Start *new* instance of emacs.
- Copy some text that is Org subtree from some
  *external* application (not Emacs).
  I usually come across this issue when I copy capture
  from my Firefox extension. Alternative:
  #+begin_src elisp :results silent
(require 'ob-shell)
  #+end_src

  #+begin_src bash :results silent
printf '%b' '* Heading\n\nbody\n' |
  xclip -in -selection clipborad >/dev/null
  # xsel --input --clipboard
  #+end_src

- Try =C-c C-x C-y= or [[elisp:(org-paste-subtree)]]

  + Actual result is the following message:
: user-error: The kill is not a (set of) tree(s).  Use ‘C-y’ to 
yank anyway

  + Expected result is a heading pasted at the end of the buffer.
  + The result may be achieved by calling [[elisp:(org-paste-subtree)]] 
once more.


- The problem is ~(and kill-ring (current-kill 0))~ expression
  in the definition of ~org-paste-subtree~.
  Restart emacs and repeat steps above skipping ~org-paste-subtree~.
  Notice that ~(current-kill 0)~ call changes value of ~kill-ring~.
  #+begin_src elisp :results pp
(list (and kill-ring t) (current-kill 0) (and kill-ring t))
  #+end_src

  #+RESULTS:
  : (nil "* Heading\n\nbody\n" t)

I suppose, it is better to let the error from ~current-kill~ to 
propagate (in the case of empty `kill-ring' and clipboard). I do not 
have Windows machine available to test the change.


There is another occurence of ~(and (current-kill 0))~
in ~org-kill-is-subtree-p~. I would rather transform it
to ~org~subtree-p~ to avoid call of ~current-kill~ inside, but this 
patch does not include such change.
>From 04bbf6359f370bddb6ca5fff1d8c7737e7ac5ee7 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Mon, 29 Nov 2021 18:54:43 +0700
Subject: [PATCH] org.el: Fix first call of `org-paste-subtree'

* lisp/org.el (org-paste-subtree): Do not check `kill-ring' before
calling `current-kill' since the latter can pull content of clipboard.

First call of `org-paste-subtree' failed if nothing had been yanked
before since Emacs start but system clipboard had text with valid
subtree originating from other application.  The bug was where since
the commit adding `org-paste-subtree'.

If both `kill-ring' and system clipboard are empty then `current-kill'
generates meaningful error.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 025513e7a..55953e97b 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -7774,7 +7774,7 @@ the inserted text when done.
 
 When REMOVE is non-nil, remove the subtree from the clipboard."
   (interactive "P")
-  (setq tree (or tree (and kill-ring (current-kill 0
+  (setq tree (or tree (current-kill 0)))
   (unless (org-kill-is-subtree-p tree)
 (user-error
  (substitute-command-keys
-- 
2.25.1

Re: Re-installing org-mode packages due to annoying message

[Alan E. Davis]

Tim:

I appreciate your thoughtful response.  You went to a great deal of
trouble, and answered, I think, most of the important questions I have with
this issue.

I use Arch Linux, and have been installing the AUR emacs-git package.
Sure, I don't need to go beyond the current stable package.  For now, I
do.  I have a few org-mode ancillary packages installed, some I am still
uncertain of, and some of which are more essential.

I have indeed installed some packages and also some code into my init file,
without understanding what they do, because I want to test whether they
will work for my needs.  I plan to steal your initialization for use of
packages, because mine is out of date, and I think this may solve the
problem of the annoying message I refer to.  The message is to the effect
that one needs to install Org-mode from a different repo, because after
version 9.5 (I think) the existing elpa repo will not be updated.  I hope
your simple code will solve that. I may just follow your advice and declare
emac init bankruptcy (If I understand that correctly), and start by copying
over the functions I have written and the configurations I have found
essential.  I have actually done that in the past.

I appreciate that Emacs exists.  I cannot overstate my appreciation for the
work that Richard Stallman and the multitudes of programmers have put into
making this tool and making it better.  I see the need for cleaning out the
garage once in a while, and I understand that Org-mode will be better
served by consolidating the repositories.  I have just not been able to
understand the shop talk, I guess.  Your example is really helpful.

It is interesting that an old timer like yourself would reach for
Spacemacs.  I haven't, mostly because I don't think I need the modal model
of Vi.  The keybindings of Emacs or so convenient and intelligent I find
them to be enough.  Here's where I might have spent more time in the early
days learning the basics better.  One of the things I like about Emacs is
that I can dance around a page of text, in a manner that the commercially
produced text editors and word processors I know have not dared to
implement.  We are locked in to a dumbed down interface in all the software
we encounter.  I cannot think of one example just now, but maybe the way
one can move back and forth over characters and words.  I never learned Vi,
except to be able to edit a simple config file if need be.

I know I am over my head, and I have been so for the 30-ish years I have
been using Emacs and for the time I have used Org-mode.  It is more than I
can do to keep up with the newer complexities that are cropping up.  Yet,
just like the plain text files, and the LaTeX source for my one
publication, a lexicon of animal names, they live on while documents using
the high priced tools are not longer readable or editable.  And through all
the changes, my little utilities for editing things that only I could
probably care about, and I would not expect anyone to care to learn---they
still work today.  I love it!

I appreciate your help.

Alan Davis

On Sun, Nov 28, 2021 at 2:38 PM Tim Cross  wrote:

>
> "Alan E. Davis"  writes:
>
> > I have just spent an hour trying to figure out what's going on with
> ELPA, GNU ELPA, NONGNU ELPA packages.  I am lost.
> >
> > A plethora of methods exist for installing org-mode and other packages;
> it is unnecessary to list them, even if I could.
> >
> > I've been using Emacs and Org-mode for many years.  I am not interested
> in spending an hour of my time to learn a new way to install
> > something that has been working well for me.  I may not use org-mode
> with the facility of a programmer who can whip off a quick utility
> > in emacs lisp, but I have come to depend on the basic tools as a core of
> my work flow.
> >
> > I have tried "use package",  but I would prefer something
> straightforward, like just list-packages then install.  I don't understand
> how to
> > set up my init file (dot emacs) for various package repos.  It was
> working, that's all I needed.  Now I get a 5 second delay each time I use
> > org-mode.  I cannot seem to find the information I need to fix this.  On
> reddit, on emacs wiki, on this list, I cannot find the magic search
> > term.  I see advice like "the maintainer has written a very clear
> explanation of the issue" but,this very clear explanation does not help
> > me understand what I need to do.
> >
> > I guess I need a formula, but I have cut and pasted two or three
> different things into the top of my .init file.  Perhaps I need to start
> > again, but my .init file has been taking root for nearly 30 years; it's
> burned into my muscle memory.
> >
> > I hope I will never have to write another email like this to get help
> for something that should be simple.  Maybe I will now have to install
> > from git.  I think I am already too far out at sea to abandon the
> packages approach.  I guess it serves me right for stepping off the
> > beach.
> >
>

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

[Sébastien Miquel]

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.

Attached is a patch that applies the same fix where affected.

Regards,

--
Sébastien Miquel
From 35ae093113d9a04a99b55f0747848b373a7463f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Mon, 29 Nov 2021 09:54:33 +0100
Subject: [PATCH] ox: Fix async export with native compilation

* lisp/ox-beamer.el (org-beamer-export-to-pdf):
* lisp/ox-icalendar.el (org-icalendar-export-to-ics):
* lisp/ox-koma-letter.el (org-koma-letter-export-to-pdf):
* lisp/ox-man.el (org-man-export-to-pdf):
* lisp/ox-texinfo.el (org-texinfo-export-to-info): Quote lambda.

Quote or name lambdas to prevent their compilation into anonymous
functions which cannot be passed to the external async emacs process.
---
 lisp/ox-beamer.el  | 2 +-
 lisp/ox-icalendar.el   | 4 ++--
 lisp/ox-koma-letter.el | 2 +-
 lisp/ox-man.el | 2 +-
 lisp/ox-texinfo.el | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index c9a67f891..3bfcd01d4 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -1059,7 +1059,7 @@ Return PDF file's name."
   (let ((file (org-export-output-file-name ".tex" subtreep)))
 (org-export-to-file 'beamer file
   async subtreep visible-only body-only ext-plist
-  (lambda (file) (org-latex-compile file)
+  #'org-latex-compile)))
 
 ;;;###autoload
 (defun org-beamer-select-environment ()
diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el
index 0a682c7c8..68c5679ea 100644
--- a/lisp/ox-icalendar.el
+++ b/lisp/ox-icalendar.el
@@ -888,8 +888,8 @@ Return ICS file name."
 (org-export-to-file 'icalendar outfile
   async subtreep visible-only body-only
   '(:ascii-charset utf-8 :ascii-links-to-notes nil)
-  (lambda (file)
-	(run-hook-with-args 'org-icalendar-after-save-hook file) nil
+  '(lambda (file)
+	 (run-hook-with-args 'org-icalendar-after-save-hook file) nil
 
 ;;;###autoload
 (defun org-icalendar-export-agenda-files ( async)
diff --git a/lisp/ox-koma-letter.el b/lisp/ox-koma-letter.el
index 6a895a6a2..978e4e41f 100644
--- a/lisp/ox-koma-letter.el
+++ b/lisp/ox-koma-letter.el
@@ -982,7 +982,7 @@ Return PDF file's name."
 (org-koma-letter-special-contents))
 (org-export-to-file 'koma-letter file
   async subtreep visible-only body-only ext-plist
-  (lambda (file) (org-latex-compile file)
+  #'org-latex-compile)))
 
 
 (provide 'ox-koma-letter)
diff --git a/lisp/ox-man.el b/lisp/ox-man.el
index 6d3476cda..9a1f00f35 100644
--- a/lisp/ox-man.el
+++ b/lisp/ox-man.el
@@ -1117,7 +1117,7 @@ Return PDF file's name."
   (let ((outfile (org-export-output-file-name ".man" subtreep)))
 (org-export-to-file 'man outfile
   async subtreep visible-only body-only ext-plist
-  (lambda (file) (org-latex-compile file)
+  #'org-latex-compile)))
 
 (defun org-man-compile (file)
   "Compile a Groff file.
diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index b0125894a..734c8a4f3 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@ -1701,7 +1701,7 @@ Return INFO file's name."
 	(org-export-coding-system org-texinfo-coding-system))
 (org-export-to-file 'texinfo outfile
   async subtreep visible-only body-only ext-plist
-  (lambda (file) (org-texinfo-compile file)
+  #'org-texinfo-compile)))
 
 ;;;###autoload
 (defun org-texinfo-publish-to-texinfo (plist filename pub-dir)
-- 
2.34.1

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

[Richard Lawrence]

Sorry, forgot to reply to this:

Tim Cross  writes:

> Note that C-j in org mode is different from 'normal' C-j in that it is
> bound to org-return-and-maybe-indent. If you want M-j to act like C-j in
> org mode, you would need to rebind M-j to org-return-and-maybe-indent in
> an appropriate org mode startup hook. 

This is a good suggestion, thanks; maybe that will be the best solution
for me, if the answer is that the current behavior is not a bug. 

It now seems to me that it must be a bug, though, since Org sometimes
calls a built-in C function with an argument it cannot accept, and
several people have confirmed this. The main question for me at this
point is: does this happen because org-comment-line-break-function is
being called when it shouldn't be, or because fill-prefix is nil when it
shouldn't be, or something else?

-- 
Best,
Richard

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

[Richard Lawrence]

Tim Cross  writes:

> I'm running Emacs 28 and cannot reproduce the issue you observe.

Hmm, the plot thickens!

> Running emacs -Q I find M-j is bound to
>
> M-j runs the command default-indent-new-line (found in global-map),
> which is an interactive compiled Lisp function in ‘simple.el’.

I definitely see the error in emacs -Q with

GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo 
version 1.16.0)

which only contains Org 9.3, in my installation. So the problem has been
around at least that long, but only surfaced for me because the binding
of M-j changed between Emacs 26 and 27.

> This binding is the same inside and outside of org mode.

Yes, but inside Org mode, default-indent-new-line calls
org-comment-line-break-function (because it is the value of
comment-line-break-function), which is where the error originates.

The last line of org-comment-line-break-function is:

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

and fill-prefix is nil, at least in all the contexts where I've tried
this.

Since you're not seeing the error, could you please check in an Org
buffer whether:

  - comment-line-break-function is 'org-comment-line-break-function
  - org-comment-line-break-function contains the line above (it should;
it's still there in the master branch)
  - fill-prefix is nil when you type M-j?
  
Thanks!

-- 
Best,
Richard