Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

[Bastien]

Timothy  writes:

> Done :)

Thanks!

-- 
 Bastien

Re: IM dev discussions?

[Bastien]

Hi Timothy,

Timothy  writes:

> Both these things may not come together, or at the same time. For instance, 
> I’m
> currently talking to someone on the Doom discord who has a few potential
> improvement to Org in the works, and the main barrier to us hearing about them
> is their nervousness at sending an email in to the Org ML.

We probably can reassure them and teach them how not to be afraid to
go public and send an email to this list.

> Like it or not, I have the distinct impression that
>> to be fine with working by email, the old way.
> is a much greater ask than it used to be. Some people may come around with 
> time,
> but for getting started at least I think there’s quite a bit of value in 
> having
> less “alien” way of getting started. One could argue that by neglecting
> non-ML/IRC ways of interacting with the Org project we are accidentally 
> seceding
> territory to non-free services like reddit, stackexchange, and co.

Let's imagine we set up a Discourse instance on forum.orgmode.org.

It will probably attract users that don't really like/want to interact
through a mailing list, and maybe some of them will prefer this option
rather than posting to reddit, SO, etc.

It is a good outcome per se, and a way not to cede too much territory
to non-free services.

But then at some point we will have two problems: we will need to
spend energy encouraging these Discourse users send their patches to
the mailing list and people on this ML who are mostly here to help
others will have to split their time and attention between the ML and
forum.orgmode.org, because both will be official support channels
for the Org community.

To sum it up (1) I don't think we have the resources to compete with
non-free services like reddit (and should accept that they work as
users-to-users support channels) and (2) teaching users how to send a
patch to the mailing list is something we will have to do anyway at
some point if we want to help users become contributors.

So I really see why a Discourse instance might be tempting but this
will surely break something that works okay right now: this list as
the place where to keep track of Org's development and contribute
to it.

...

For french-speaking people, we have both a ML and a forum.

- the list: https://lists.sr.ht/~bzg/emacsfr
- the forum: https://emacs.gnu.re/public/

We advertize both equally on https://emacs-doctor.com.

It is okay to have both here because they are not competing with each
other, they are just places for discussing things.

Interestingly, the ML seems more active than the forum, but I would
not mind seeing the forum become more active than the list.  They are
just places to discuss Org topics in french.

The difference with considering list.orgmode.org + forum.orgmode.org
is that none of these places (FR-ML and FR-forum) is "the place were
we keep track of Org's development and where we encourage and teach
people how to contribute"... that's what matters in this discussion.

All best,

-- 
 Bastien

Re: IM dev discussions?

[Bastien]

Hi Timothy,

Timothy  writes:

> Yep, but I do think it’s good to have a few promoted places, ideally based on
> FOSS services. Not to start another tangent, but this is one of the reasons 
> why
> I think discourse could be a good idea — as a FOSS replacement for reddit,
> stackoverflow, etc.

If someone wants to set up a Discourse instance and maintain it, of
course (s)he can.  The question is: should this become an *official*
place for Org discussions, maintained by Org maintainers?  I don't
think this is desirable, given the resources we have*.

It is so easy to set up a Discourse instance and quite difficult
to maintain it in the long run -- also, how to explain to newcomers
when to send messages to Discourse and when to reach the list?  This
will probably end up as "a place for users" (Discourse) and "a place
for developers" (the ML), which I don't want.

* FWIW I would much prefer to have contributors commit to enhance
  Worg: it is a critical resource, seen by ~30K per month, and many
  pages are outdated.

>> I think I get your point about categorisation in general, but in this
>> case, there is the risk of excluding a category of people (lurkers,
>> occasional contributors, etc.) or more precisely: to incidently and
>> inadvertently encourage them to self-exclude themselves.
>
> I hear what you’re saying, I’m just not sure how much of an issue this 
> actually
> would be. My initial suspicion is with a this issue would be small to
> non-existent.

Perhaps -- or perhaps not.  What Ihor says in another email is that
people who post on e.g. reddit don't want to bother hardcore devs on
this list.  I'm quite sure if we setup an official #org-dev channel,
people from #org-mode will shy away from #org-dev.

>> Is it possible to lurk in a Matrix room without any login?
>
> With a matrix client you can peek in public rooms without joining them, and
>  currently 
> exists.

This link does not allow me to send an anonymous/pseudonymous message
to the Matrix room, right?  That's what I'm talking about, that IRC
permits.

All best,

-- 
 Bastien

Re: changing orgcard.tex (was: Dynamic keybindings in the manual)

[Timothy]

Hi Bastien,

> If we are to make changes against orgcard.tex we should be careful to
> stick to GNU conventions regarding creating refcards.

Might you have a link to those conventions on hand?

> Also, maybe some improvements can be shared upstream against the Emacs
> refcard?

Possibly, while keybindings /rarely/ change, occasionally they do, and so I
personally consider it a significant improvement having them dynamically
determined. After I finish with this we could ask emacs-devel what they think.

All the best,
Timothy

Re: Dynamic keybindings in the manual

[Bastien]

Hi Timothy,

Timothy  writes:

> In the recent discussion about potentially no longer generating `org-release' 
> in
> the Makefile, it was mentioned that `orgcard.tex' may be a bit of a blocker to
> that.

If we are to make changes against orgcard.tex we should be careful to
stick to GNU conventions regarding creating refcards.

Also, maybe some improvements can be shared upstream against the Emacs
refcard?

-- 
 Bastien

Re: [PATCH] Add .org suffixes to CONTRIBUTE and README

[Bastien]

"Christopher M. Miles"  writes:

> I agree this change too. This is more clear.

Applied on main as 52be6f0f4, thanks.

-- 
 Bastien

Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)

[Ihor Radchenko]

Russell Adams  writes:

>> AFAIU, this should be supported by the IRC server. Does irc.libera.chat
>> (where #org-mode channel is hosted) support logging?
>
> There is no log today.
>
> Also our parent channel #emacs prohibits logging.
>
> https://www.emacswiki.org/emacs/EmacsChannelLogging

Does #org-mode share such a strong stand?
If so, it may be problematic even to quote the discussions there in Org
commit messages.
IMHO, it makes #org-mode a lot less usable for the purposes of Org
development. Deliberately public and unencrypted matrix #org-mode room
is better in this regard.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: emacs really slow when inserting a new source code block

[Ihor Radchenko]

Luca Ferrari  writes:

> Hi all,
> I'm having issues in my org files whenever I insert a new source block
> (perl if that matters) with "#+begin_src perl" Emacs becomes really
> slow.
> I can move, paste, edit within the source block (in the same org
> buffer, not an external window) but at a very slow rate.
> In the messages I've only this:

Thanks for reporting!
May you
1. M-x profiler-start  cpu 
2. Move/paste/edit your source block
3. M-x profiler-report 
4. M-x profiler-report-write-profile and share the resulting file here
?

> Starting new Ispell process aspell with default dictionary...done
> Error enabling Flyspell mode:
> (No Ispell process to read output from!)

Did you try disabling flyspell?

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: The Org mode in the Org Git does not export

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> When I attach the profiler before exporting and then abort with C-g, the
> profiler reports that Org spends almost all of the time in
> 'org-export--generate-copy-script'.

Profiler reports after C-g are not reliable.

> Any ideas?

In addition to debug-on-quit, you can M-x debug-on-entry org-export-as
and try to identify which part of that function is lagging.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [BUG] Warning (org-element-cache): org-element--cache: Unregistered buffer modifications detected. Resetting. [9.6 (9.6-??-86c4635db @ /Users/timothyw/.emacs.doom/.local/straight/build-28.1/org/)]

[Ihor Radchenko]

Timothy Washington  writes:

> This seems to happen when I'm using Org Roam in my Doom Emacs config. I'm
> intermittently getting these errors popping.
>
> This is actually an accumulation of a single first one.
>
> Warning (org-element-cache): org-element--cache: Unregistered buffer
> modifications detected. Resetting.
> If this warning appears regularly, please report the warning text to Org
> mode mailing list (M-x org-submit-bug-report).
> The buffer is:  *temp*
>  Current command: vertico-exit

Thanks for reporting!
Can you please update Org mode to the latest development version and
then try to trigger the warning again?

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: IM dev discussions?

[Ihor Radchenko]

Bastien  writes:

>> Ideally, it would be nice to
>> have ML front-end that looks similar to GitHub issues. I recall the
>> latest versions of mailman had somewhat familiar look. Sourcehut is also
>> trying to implement a web-based front-end (though is it not familiar at
>> all, unfortunately).
>
> Note that if the GNU project moves to using its instance of sourcehut,
> then we will also benefit from such a web-based front-end.

Yes. However, despite being web-based, Sourhut's frontend is not
intuitive at all. I also heard that the frontend accessibility is not
something they plan to improve upon much. See 
https://cadence.moe/blog/2022-07-03-git-forge-opinions-github-gitlab-gitea-sourcehut

>> Note that the opposite to the above is not true. We should not prefer
>> familiar front-ends at the cost of sacrificing technical accessibility.
>
> Agreed again.
>
> Another parameter I put in the equation: what do we want?
>
> If our priority were to redirect reports made on r/org-mode and SO to
> the Org maintainers, then switching to GitHub would probably be a good
> move: users that feel comfortable sharing reports and ideas on these
> platforms would create more issues on GitHub than emails we currently
> receive on the list.

I did a little experiment over last month by directing reddit users to
Org ML. When asked, a substantial fraction of people actually did post
to Org ML. My impression is that people first reach out to "casual"
resources like reddit because they are afraid to bother "hardcore" Org
developers on the mailing list with they humble little issues.

Maybe we can nicely ask moderators/active users of reddit/SO to redirect
people to Org ML when appropriate? Similar to our current effort with
contributor stewards.

> I believe our priority should be to motivate more Elisp hackers to
> become Org maintainers.  I expect potential candidates to be okay with
> the GNU recommendation of trying to avoid GitHub for ethical reasons
> and to be fine with working by email, the old way.  Especially if we
> have maintainers for small files: they certainly don't want to follow
> everything in Org's development but agree to be cc'ed occasionally.

I think you are missing one important category of contributors --
maintainers of third-party packages. I've got involved into several
Org-related discussions on Github because I got @mentioned in some
threads. My impression is that a number of package maintainers on Github
actively cross-link issues between repos and try to resolve problems
together. However, they rarely reach out to Org ML.

Notably, I managed to communicate on GitHub simply using email.

May we set a single account on GitHub and link it to Org ML so that
people can @mention Org team on GitHub, and we automatically get the
email directly to Org ML? Note that I do not suggest maintaining Org
mirror with its issues page. Just a user.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Going back to the earlier :ATTR_BACKEND: issue as a property for
> headings, I've been doing some testing and scribbled down a possible
> function[1] whose code is almost entirely stolen from
> org-export-read-attribute, with some modifications. Evaluated at the
> headline, it returns the value of the ATTR_BACKEND property as a plist.
> And then that plist could be easily manipulated on each backend to
> format export_template conveniently. For example:
>
> * headline
> :PROPERTIES:
> :ATTR_LaTeX: :export_template \begin{myenv}\n%s\n\end{myenv}
> :ATTR_LaTeX+: blah blah blah
> :END:
>
> ==> (:export_template "\\begin{myenv}\\n%s\\n\\end{myenv} blah blah blah")
>
> I don't know if that would be the way to go...

What I have in mind is to modify `org-export-read-attribute' directly.
Then, we can call `org-export-read-attribute' in `org-export-data';
resolve the refs in the template (re-use code from
`org-babel-ref-resolve' and `org-babel-parse-multiple-vars'); do normal
export and pass it to the template. Before running the normal export, we
strip :export_template from the INFO to avoid issues with ox-html which
puts every single attr into the generated html.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Org Syntax Specification

[Rohit Patnaik]

I also want to chip in with a thank-you for the org syntax specification page. 
As someone who's working on a custom org exporter, this is a very useful 
resource for finding out how elements are structured within org-mode.

Thanks,
Rohit

Re: access to specific instance(s) of past recurring event(s)

[Tim Cross]

Mark Barton  writes:

> 
>
>> On Sep 25, 2022, at 5:44 AM, Saša Janiška  wrote:
>> 
>> When looking for some solution I've stumbled upon this (old) post
>> https://karl-voit.at/2017/01/15/org-clone-subtree-with-time-shift/ which 
>> utilizes
>> *org-clone-subtree-with-time-shift*.
>
> I also use this method for some of my reoccurring events. I usually create a 
> year's worth
> of clones and then a task to clone more for next year. It is nice to be able 
> to
> remove/adjust some of the subtree entries to accommodate holidays.
>
> When I don't use this method for a reoccurring event then I usually just 
> schedule a
> repeating task and then have my notes in that task to record what happened 
> each time.
>
> Mark

That is pretty much my work flow as well. Sometimes cloning is useful
because you actually want separate 'entries' and want to retain
them. Other times, you actually want all the notes associated with some
repeating 'thing' to be kept together. Having this flexibility is very
useful.

Re: [BUG] org-auto-repeat-maybe: error "Can’t expand minibuffer to full frame" and missing log note

[Bhavin Gandhi]

On Wed, 17 Aug 2022 at 15:14, Ihor Radchenko  wrote:
> >> Yikes! Then, can also check for window-minibuffer-p, but I feel that it
> >> will be a fight against all kinds of edge cases.
> >
> > I haven't been able to make much progress on this bug in the last two
> > weeks. Will try to send a patch in a few days, as the steps I gave above
> > feels like an edge case which we won't see happening hopefully.
>
> Your patch will be already an improvement.

I'm attaching the patch for the current approach we discussed in this
thread. I have tried basic operations like taking note on state change,
and have tried with recurring entries which need more than 10 cycles to
be marked as done (original bug report).

As I was changing the indentation of code from org-add-log-note, I converted
some tabs to spaces, is it okay to do so?

-- 
Bhavin Gandhi (bhavin192) | https://geeksocket.in
From afb1158d9a360020f093436228cdf4e689474db8 Mon Sep 17 00:00:00 2001
From: Bhavin Gandhi 
Date: Sun, 25 Sep 2022 22:06:53 +0530
Subject: [PATCH] org.el: Make sure `org-add-log-note' runs at the end of Org
 command
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org.el (org-add-log-setup): Save `this-command' and
`recursion-depth' before adding the `org-add-log-note'to
post-command-hook.
(org-add-log-note): Execute only if the current `(recursion-depth)'
and `this-command' are same as the ones we saved during the log-setup.

This change tries to make sure that we run the `org-add-log-note' only
after the current Org command has finished executing. Previously, the
post-command-hook was getting triggered if the Org command in turn
runs some other command.

Fixes the bug originally reported by Michael Powe.

Bhavin Gandhi. [BUG] org-auto-repeat-maybe: error "Can’t expand
minibuffer to full frame" and missing log note.
Sat, 18 Jun 2022 23:30:50 +0530.
https://list.orgmode.org/CAOn=hbcsoco++we0xgrhfoxxcexrocpygd1ncjzkyy-9lck...@mail.gmail.com/

Relevant discussion on bug-gnu-emacs: https://debbugs.gnu.org/56425
---
 lisp/org.el | 64 -
 1 file changed, 34 insertions(+), 30 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index b63aaed4f..ba20df59f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10355,6 +10355,8 @@ EXTRA is additional text that will be inserted into the notes buffer."
 	org-log-note-how how
 	org-log-note-extra extra
 	org-log-note-effective-time (org-current-effective-time)
+org-log-note-this-command this-command
+org-log-note-recursion-depth (recursion-depth)
 org-log-setup t)
   (add-hook 'post-command-hook 'org-add-log-note 'append))
 
@@ -10383,37 +10385,39 @@ EXTRA is additional text that will be inserted into the notes buffer."
 
 (defun org-add-log-note ( _purpose)
   "Pop up a window for taking a note, and add this note later."
-  (remove-hook 'post-command-hook 'org-add-log-note)
-  (setq org-log-setup nil)
-  (setq org-log-note-window-configuration (current-window-configuration))
-  (delete-other-windows)
-  (move-marker org-log-note-return-to (point))
-  (pop-to-buffer-same-window (marker-buffer org-log-note-marker))
-  (goto-char org-log-note-marker)
-  (org-switch-to-buffer-other-window "*Org Note*")
-  (erase-buffer)
-  (if (memq org-log-note-how '(time state))
-  (org-store-log-note)
-(let ((org-inhibit-startup t)) (org-mode))
-(insert (format "# Insert note for %s.
+  (when (and (equal org-log-note-this-command this-command)
+ (= org-log-note-recursion-depth (recursion-depth)))
+(remove-hook 'post-command-hook 'org-add-log-note)
+(setq org-log-setup nil)
+(setq org-log-note-window-configuration (current-window-configuration))
+(delete-other-windows)
+(move-marker org-log-note-return-to (point))
+(pop-to-buffer-same-window (marker-buffer org-log-note-marker))
+(goto-char org-log-note-marker)
+(org-switch-to-buffer-other-window "*Org Note*")
+(erase-buffer)
+(if (memq org-log-note-how '(time state))
+(org-store-log-note)
+  (let ((org-inhibit-startup t)) (org-mode))
+  (insert (format "# Insert note for %s.
 # Finish with C-c C-c, or cancel with C-c C-k.\n\n"
-		(cl-case org-log-note-purpose
-		  (clock-out "stopped clock")
-		  (done  "closed todo item")
-		  (reschedule "rescheduling")
-		  (delschedule "no longer scheduled")
-		  (redeadline "changing deadline")
-		  (deldeadline "removing deadline")
-		  (refile "refiling")
-		  (note "this entry")
-		  (state
-		   (format "state change from \"%s\" to \"%s\""
-			   (or org-log-note-previous-state "")
-			   (or org-log-note-state "")))
-		  (t (error "This should not happen")
-(when org-log-note-extra (insert org-log-note-extra))
-(setq-local org-finish-function 'org-store-log-note)
-(run-hooks 'org-log-buffer-setup-hook)))
+  (cl-case org-log-note-purpose
+

Re: access to specific instance(s) of past recurring event(s)

[Bob Newell]

Saša Janiška  writes:

> One useful feature of Taskwarrior is that if I have e.g recurring
> weekly task "upload meeting's recording" and, due to various reasons,
> I'm simply behind my schedule, I can access **any** of the missed
> events and not just the oldest one as it seems to be with org-mode.

Perhaps this is primitive and hackish, but I have the same
issue, especially with my "habits" like daily guitar practice
and language study. In my case these live in my "todo.org"
file.

When there is something I need to "fix" as you describe, I
just edit the properties (or content) in the entry in the
underlying file. This is very unsophisticated and can be a bit
error-prone, but it's straightforward and it works.

-- 
Bob Newell
Honolulu, Hawai`i

- Via GNU/Linux/Emacs/Gnus/BBDB

Re: Dynamic keybindings in the manual

[Juan Manuel Macías]

Hi, Timothy,

Timothy writes:

> This prompted me to take a look at `orgcard.tex' and I was surprised to 
> discover
> that it’s TeX TeX, not even LaTeX, and it has hard-coded keybindings.

Wow, it's in plainTeX... I've tried cleaning that document and removing
most of the code, as it's unnecessary. I've left just the sections in a
new LaTeX document, and redefined the \key command like so:

\newcommand\key[2]{%
  #1 \quad%
  \{\{\{kbd(#2)\}\}\}\par}

so that a line like this:

\key{rotate current subtree between states}{TAB}

produce in the PDF this, literally:

rotate current subtree between states {{{kbd(TAB)}}}

I don't know if this could help to copy the text from the PDF, create an
Org document and then manipulate those macros. In case this helps, I'm
attaching the new tex document here.

Best regards,

Juan Manuel

--
--
--
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com



orgcard-clean.tex
Description: TeX document

[BUG] org-create-file-search-functions and description [9.5.5 (release_9.5.5 @ /usr/share/emacs/29.0.50/lisp/org/)]

[Magnus Therning]

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


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

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


The documenation on org-create-file-search-functions contains this 
piece of text


 A function in this hook may also use setq to set the variable 
 description to provide a suggestion for the descriptive text to 
 be used for this link when it gets inserted into an Org buffer 
 with org-insert-link.


This doesn't seem to be true though. I really would love for there 
to be a way to influence the link description, but no matter what 
the documentation should be corrected.


For some more info look at 
https://www.reddit.com/r/orgmode/comments/xmvtsy/orgcreatefilesearchfunctions_and_description/


Emacs  : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ 
Version 3.24.34, cairo version 1.17.6)

of 2022-09-21
Package: Org mode version 9.5.5 (release_9.5.5 @ 
/usr/share/emacs/29.0.50/lisp/org/)


/M

--
Magnus Therning   OpenPGP: 0x927912051716CE39
email: mag...@therning.org
@magthe@mastodon.technology   http://magnus.therning.org/

You can't depend on your judgement when your imagination is out of 
focus.

— Mark Twain


signature.asc
Description: PGP signature

[BUG] Warning (org-element-cache): org-element--cache: Unregistered buffer modifications detected. Resetting. [9.6 (9.6-??-86c4635db @ /Users/timothyw/.emacs.doom/.local/straight/build-28.1/org/)]

[Timothy Washington]

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

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

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


This seems to happen when I'm using Org Roam in my Doom Emacs config. I'm
intermittently getting these errors popping.

This is actually an accumulation of a single first one.

Warning (org-element-cache): org-element--cache: Unregistered buffer
modifications detected. Resetting.
If this warning appears regularly, please report the warning text to Org
mode mailing list (M-x org-submit-bug-report).
The buffer is:  *temp*
 Current command: vertico-exit
 Backtrace:
nil Disable showing Disable logging
Warning (org-element-cache): org-element--cache: Unregistered buffer
modifications detected. Resetting.
If this warning appears regularly, please report the warning text to Org
mode mailing list (M-x org-submit-bug-report).
The buffer is:  *temp*
 Current command: nil
 Backtrace:
nil Disable showing Disable logging
Warning (org-element-cache): org-element--cache: Unregistered buffer
modifications detected. Resetting.
If this warning appears regularly, please report the warning text to Org
mode mailing list (M-x org-submit-bug-report).
The buffer is:  *temp*
 Current command: nil
 Backtrace:
nil Disable showing Disable logging


Emacs  : GNU Emacs 28.1 (build 1, aarch64-apple-darwin21.1.0, NS
appkit-2113.00 Version 12.0.1 (Build 21A559))
 of 2022-05-11
Package: Org mode version 9.6 (9.6-??-86c4635db @
/Users/timothyw/.emacs.doom/.local/straight/build-28.1/org/)

current state:
==
(setq
 org-roam-db-location "/Users/timothyw/.emacs.d/.local/etc/org-roam.db"
 org-link-elisp-confirm-function nil
 org-directory "~/org/"
 org-after-refile-insert-hook '(save-buffer)
 org-indirect-buffer-display 'current-window
 org-roam-db-gc-threshold 2305843009213693951
 org-crypt-key nil
 org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-load-hook '(+org-init-org-directory-h +org-init-appearance-h
+org-init-agenda-h +org-init-attachments-h +org-init-babel-h
 +org-init-babel-lazy-loader-h +org-init-capture-defaults-h
+org-init-capture-frame-h +org-init-custom-links-h
 +org-init-export-h +org-init-habit-h +org-init-hacks-h
+org-init-keybinds-h +org-init-popup-rules-h
 +org-init-smartparens-h +org-init-roam-maybe-h)
 org-roam-buffer-window-parameters '((no-delete-other-windows . t))
 org-startup-folded nil
 org-babel-after-execute-hook
'(+org-redisplay-inline-images-in-babel-result-h)
 org-link-abbrev-alist '(("doomdir" . "/Users/timothyw/.doom.d/%s")
("emacsdir" . "/Users/timothyw/.emacs.d/%s")
 ("doom-repo" . "
https://github.com/doomemacs/doomemacs/%s;)
 ("wolfram" . "https://wolframalpha.com/input/?i=%s;)
("wikipedia" . "https://en.wikipedia.org/wiki/%s;)
 ("duckduckgo" . "https://duckduckgo.com/?q=%s;)
("gmap" . "https://maps.google.com/maps?q=%s;)
 ("gimages" . "https://google.com/images?q=%s;)
("google" . "https://google.com/search?q=;)
 ("youtube" . "https://youtube.com/watch?v=%s;)
("github" . "https://github.com/%s;))
 org-agenda-files '("~/org/")
 org-capture-templates '(("t" "Personal todo" entry (file+headline
+org-capture-todo-file "Inbox") "* [ ] %?\n%i\n%a" :prepend t)
 ("n" "Personal notes" entry (file+headline
+org-capture-notes-file "Inbox") "* %u %?\n%i\n%a" :prepend t)
 ("j" "Journal" entry (file+olp+datetree
+org-capture-journal-file) "* %U %?\n%i\n%a" :prepend t)
 ("p" "Templates for projects")
 ("pt" "Project-local todo" entry (file+headline
+org-capture-project-todo-file "Inbox") "* TODO %?\n%i\n%a"
  :prepend t)
 ("pn" "Project-local notes" entry (file+headline
+org-capture-project-notes-file "Inbox") "* %U %?\n%i\n%a"
  :prepend t)
 ("pc" "Project-local changelog" entry
(file+headline +org-capture-project-changelog-file "Unreleased")
  "* %U %?\n%i\n%a" :prepend t)
 ("o" "Centralized templates for projects")
 ("ot" "Project todo" entry
#'+org-capture-central-project-todo-file "* TODO %?\n %i\n %a" :heading
"Tasks"
  :prepend nil)
 ("on" "Project notes" entry
#'+org-capture-central-project-notes-file "* %U %?\n %i\n %a" :heading
"Notes"
  :prepend t)
 ("oc" "Project changelog" entry
#'+org-capture-central-project-changelog-file "* %U %?\n %i\n %a" :heading
  "Changelog" :prepend t)
 

[BUG] org-fill-paragraph doesn't handle ^L correctly [9.5.4 (release_9.5.4-19-g4dff42 @ /home/matt/Code/emacs/lisp/org/)]

[Matt Beshara]

‘org-fill-paragraph’ does not correctly handle ^L characters 
(a.k.a. form feed, C-q C-l).  It should treat them as paragraph 
separating whitespace, but instead treats them as any other 
character which would appear in normal text.  Here is an example 
to demonstrate the current behaviour:


abc def
^L
ghi jkl

In org-mode, with point at the beginning or the end of the first 
or last line, doing ‘org-fill-paragraph’ (M-q) should do nothing, 
because the lines are already shorter than the fill-column.  What 
really happens is that I end up with one line which looks like:


abc def ^L def ghi

In text-mode, ‘fill-paragraph’ does handle ^L characters 
correctly, and pressing M-q anywhere in the first example results 
in no change being made to the buffer.


Emacs  : GNU Emacs 29.0.50 (build 2, x86_64-pc-linux-gnu, X 
toolkit, cairo version 1.17.6)

of 2022-08-27
Package: Org mode version 9.5.4 (release_9.5.4-19-g4dff42 @ 
/home/matt/Code/emacs/lisp/org/)

emacs really slow when inserting a new source code block

[Luca Ferrari]

Hi all,
I'm having issues in my org files whenever I insert a new source block
(perl if that matters) with "#+begin_src perl" Emacs becomes really
slow.
I can move, paste, edit within the source block (in the same org
buffer, not an external window) but at a very slow rate.
In the messages I've only this:

Starting new Ispell process aspell with default dictionary...done
Error enabling Flyspell mode:
(No Ispell process to read output from!)

This puzzles me because the language of my org document is set to
"it", but I never found such a big problem before.
I've tried other type of source blocks, and while they appear to
behave smoothier, whenever I edit "#+end_src" Emacs has a freeze, and
in fact in the screen I see only "#+end_s" and after a second the line
completes.

I'm running GNU Emacs 28.2 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0) with org-mode 9.5.5.

Anything I can inspect?

Thanks,
Luca

Re: The Org mode in the Org Git does not export

[Fraga, Eric]

On Sunday, 25 Sep 2022 at 18:40, Rudolf Adamkovič wrote:
> When I attach the profiler before exporting and then abort with C-g, the
> profiler reports that Org spends almost all of the time in
> 'org-export--generate-copy-script'.

Try M-x toggle-debug-on-quit RET and then export, hitting C-g when it
gets stuck.  That'll give you a backtrace which might help debug this.

-- 
: Eric S Fraga, with org release_9.5.5-815-gae2140 in Emacs 29.0.50

Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

[Timothy]

Hi Bastien,

> Please go ahead with what seems better to you (especially since it
> matches Ihor’s preferences too), but if Eduardo has some time to help,
> it be great to really stabilize what kind of info is expected on this
> banner.

Done :)

All the best,
Timothy

The Org mode in the Org Git does not export

[Rudolf Adamkovič]

Hello smart people!

The Org mode from Git does not export my notebook, while the Org mode
that comes with Emacs 29 does.  Is that normal?  My 1.6 MB notebook
contains 2078 headings and lots of prose, mathematics, code, citations,
tables, ... virtually everything.

The minimal configuration used for testing:

| (setq-default org-use-extra-keys t)
| (setq org-export-use-babel nil ; <--- NOTE no Babel execution
|   org-export-with-broken-links 'mark
|   org-cite-csl-styles-dir "~/"
|   org-cite-export-processors '((t csl)))
| (with-eval-after-load 'ox
|   (require 'oc-csl))

The Org mode in Emacs 29 (Emacs Git, e0565e3896) exports the notebook in
about 13 seconds, but the Org mode from Git (Org Git, ebbc2ffaa) keeps
exporting forever.  (FYI, the new Org announces that the buffer is
syntactically correct.)

When I attach the profiler before exporting and then abort with C-g, the
profiler reports that Org spends almost all of the time in
'org-export--generate-copy-script'.

P.S. A while ago, I tried to binary-search the problematic part in my
notebook, but I did not find it.  The export times got progressively
better as I cut the parts.  Worst-case, I can try this again.

Any ideas?

Rudy
-- 
"The whole science is nothing more than a refinement of everyday
thinking."
-- Albert Einstein, 1879-1955

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)

[zimoun]

Hi,

On Sun, 25 Sep 2022 at 11:36, Ihor Radchenko  wrote:

>> Look at this example from Guix IRC channel:
>> https://logs.guix.gnu.org/
>
> AFAIU, this should be supported by the IRC server. Does irc.libera.chat
> (where #org-mode channel is hosted) support logging?

These logs are done by custom Scheme code [1,2] run in some Guix
project’s server [3].


1: 

2: 

3: 



Cheers,
simon

Dynamic keybindings in the manual

[Timothy]

Hi All,

(skip to the rule if you’re not interested in a preamble)

In the recent discussion about potentially no longer generating `org-release' in
the Makefile, it was mentioned that `orgcard.tex' may be a bit of a blocker to
that.

This prompted me to take a look at `orgcard.tex' and I was surprised to discover
that it’s TeX TeX, not even LaTeX, and it has hard-coded keybindings.

Neither of those things seemed great to me, so I thought I’d try my hand at
whipping up an Org version. In doing so I made a macro that inserts the
appropriate keybinding.

┌
│ #+macro: key (eval (format "{{{kbd(%s%s)}}}" (if $2 (concat $1 " ") "") (or 
(org-string-nw-p (key-description (or (where-is-internal (intern (string-trim 
(or $2 $1))) nil t) ))) (format "M-x %s" (string-trim (or $2 $1))
└



Looking at the manual, I see that it too has hardcoded keybindings. Considering
that occasional changes can easily slip by (see
, just 
one
week ago), I think it would make sense to adopt a similar approach.

Instead of having
┌
│ {{{kbd(C-c C-r)}}} (~org-reveal~)
└


We could have
┌
│ {{{cmd(org-reveal)}}}
└


With the use of the earlier `key' macro and
┌
│ #+macro: cmd {{{key($1)}}} (~$1~)
└

While I think this could be a good idea, I don’t think I’m likely to get to this
any time soon, so I’m shooting this off to the ML in case other people are
interested.

All the best,
Timothy

Re: access to specific instance(s) of past recurring event(s)

[Saša Janiška]

On 25. 09. 2022. 16:25, Mark Barton wrote:

I also use this method for some of my reoccurring events. 


Good.


It is nice to be able to remove/adjust some of the subtree entries to 
accommodate holidays.


Indeed.

When I don't use this method for a reoccurring event then I usually just schedule a 


repeating task and then have my notes in that task to record what 
happened each time.


That's also interesting. Thanks!


Sincerely,
Saša

--
As fire is covered by smoke, as a mirror is covered by dust,
or as the embryo is covered by the womb, the living entity is
similarly covered by different degrees of this lust.

Re: access to specific instance(s) of past recurring event(s)

[Saša Janiška]

On 25. 09. 2022. 15:46, Fraga, Eric wrote:


I guess I'm not sure what you would like to do with previous (missed)
events?


Well, I want to mark them as completed, but not in consecutive order 
from oldest to newest - that's why I want to be able to 
access/modify/complete them in **any** order.



Sincerely,
Saša
--
In this endeavor there is no loss or diminution,
and a little advancement on this path can protect
one from the most dangerous type of fear.

Re: access to specific instance(s) of past recurring event(s)

[Mark Barton]



> On Sep 25, 2022, at 5:44 AM, Saša Janiška  wrote:
> 
> When looking for some solution I've stumbled upon this (old) post 
> https://karl-voit.at/2017/01/15/org-clone-subtree-with-time-shift/ which 
> utilizes *org-clone-subtree-with-time-shift*.

I also use this method for some of my reoccurring events. I usually create a 
year's worth of clones and then a task to clone more for next year. It is nice 
to be able to remove/adjust some of the subtree entries to accommodate 
holidays. 

When I don't use this method for a reoccurring event then I usually just 
schedule a repeating task and then have my notes in that task to record what 
happened each time. 

Mark

Re: [PATCH] ob-clojure.el: Add support for babashka and nbb backend

[Bastien]

Hi Christopher,

"Christopher M. Miles"  writes:

> Thanks, Bastien.

(I know you sent a patch and I'll review it, no worry!)

>> Would you consider taking over the maintainance of ob-clojure.el?
>
> Thanks for invitation, I already maintained many org-mode related
> libraries. Even though clojure is my favourite programming language, But
> I'm not familiar with CIDER and other Clojure tools interaction. So
> currently I'm not confident to maintain ob-clojure.el. But I think I
> might be able to do this in future someday. (If someone already
> maintained, I still can contribute)

Actually the invitation was for Daniel as I recalled you declined it
already (correct me if I'm wrong!).  Of course, we can have several
maintainers.

> BTW, I have a question, If someone maintain the ob-clojure.el, does this
> library need to be separated out org-mode repository?

No: we have many lisp/*el files with a specific maintainer.

These maintainers of Org's cor handle bug fixes against the files they
are maintaining and can be cc'ed on the list when discussing features.

The burden is general quite low, it's just a guarantee that someone is
in charge and can alleviate the workload of core maintainers.

All best,

-- 
 Bastien

Re: access to specific instance(s) of past recurring event(s)

[Fraga, Eric]

On Sunday, 25 Sep 2022 at 14:16, Saša Janiška wrote:
> Now I wonder if there is some other/better solution that has possibly
> popped up in the meantime?

I use subtree cloning to create most repeating events but, for those
that I simply have a repeating timestamp, I guess I've never had a
reason to "view/manage" a previous event.  I do use log notes to record
anything of import for individual instances of the repeating event.

I guess I'm not sure what you would like to do with previous (missed)
events?
-- 
: Eric S Fraga, with org release_9.5.5-815-gae2140 in Emacs 29.0.50

Re: [PATCH] ob-clojure.el: Add support for babashka and nbb backend

[Christopher M. Miles]

Bastien  writes:

> Hi Daniel,
>
> Daniel Kraus  writes:
>
>> Attached is the patch changed the logic to use a temp file with
>> org-babel-eval.
>
> Applied in main as 764642f5, thanks a lot and sorry for the delay.
>
> I also added you to https://orgmode.org/worg/contributors.html.
>
> Would you consider taking over the maintainance of ob-clojure.el?

Sorry, replied to wrong thread. Haha

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: [PATCH] ob-clojure.el: Add support for babashka and nbb backend

[Christopher M. Miles]

Bastien  writes:

> Hi Daniel,
>
> Daniel Kraus  writes:
>
>> Attached is the patch changed the logic to use a temp file with
>> org-babel-eval.
>
> Applied in main as 764642f5, thanks a lot and sorry for the delay.
>
> I also added you to https://orgmode.org/worg/contributors.html.
>

Thanks, Bastien.

> Would you consider taking over the maintainance of ob-clojure.el?

Thanks for invitation, I already maintained many org-mode related
libraries. Even though clojure is my favourite programming language, But
I'm not familiar with CIDER and other Clojure tools interaction. So
currently I'm not confident to maintain ob-clojure.el. But I think I
might be able to do this in future someday. (If someone already
maintained, I still can contribute)

BTW, I have a question, If someone maintain the ob-clojure.el, does this
library need to be separated out org-mode repository?

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)

[Russell Adams]

On Sun, Sep 25, 2022 at 11:36:46AM +0800, Ihor Radchenko wrote:
> Jean Louis  writes:
>
> > For IRC, there are ways to record history, and I am sure that
> > such history may be recorded with referencable hyperlinks.
> >
> > Look at this example from Guix IRC channel:
> > https://logs.guix.gnu.org/
>
> AFAIU, this should be supported by the IRC server. Does irc.libera.chat
> (where #org-mode channel is hosted) support logging?

There is no log today.

Also our parent channel #emacs prohibits logging.

https://www.emacswiki.org/emacs/EmacsChannelLogging

Logging sounds nice until anyone can datamine it. You're welcome to
log locally on your client for private use.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [PATCH] Add .org suffixes to CONTRIBUTE and README

[Christopher M. Miles]

Bastien  writes:

> I'm considering apply the patch below, renaming CONTRIBUTE to
> CONTRIBUTE.org and README to README.org.
>
> The main benefit is to enhance the rendering of the README on 
> GNU ELPA.
>
> I also do some minor reformatting and remove the warning about
> org-contrib.
>
> Any objection?
>
> [2. text/x-diff; 
> 0001-WIP-on-main-ebbc2ffaa-Merge-remote-tracking-branch-github-main.patch]...

I agree this change too. This is more clear.

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: org-assert-version considered harmful

[Bastien]

Ihor Radchenko  writes:

> One valid option is 9.6-pre

Let's go for this one.  I've add a note about our conventions for the
;; Version header in https://orgmode.org/worg/org-maintenance.html

-- 
 Bastien

Re: org-assert-version considered harmful

[Bastien]

Ihor Radchenko  writes:

> Also, they are used by Makefile to generate orgcard.tex
> We need to be careful in this area.

Yes...

> Note that in
> Org mode version 9.6 (release_9.5.5-830-g77f9e1 @ [load-path])
>
> release_9.5.5 while version is 9.6
> I feel like you missed this detail.

Yes I did :)

Still, "Org mode version 9.6-pre (...)" is more accurate IMO.

-- 
 Bastien

Re: org-assert-version considered harmful

[Ihor Radchenko]

Bastien  writes:

>> The code I quoted explicitly removes the "-dev" part. Would you prefer
>> to keep it?
>
> Yes, let's keep it, otherwise (org-release) reads like a lie.
>
> Why is it necessary to emit org-version.el?
>
> We could have (defun org-version ...) and (defun org-git-version ...)
> from within org.el, right?

org-version is already defined in org.el (using org-git-version and org-release)
org-git-version requires running git.
org-release could be defined in org.el

> Also, I don't think we need org-release: the info org-version provides
> is enough to know if you are loading Org from a stable (ELPA) release
> or from a local git repository.
>
> WDYT?

They are not the same. org-git-version uses tags + HEAD. org-release
uses lisp/org.el (after the patch).

Also, they are used by Makefile to generate orgcard.tex
We need to be careful in this area.

This Makefile + Elisp usage is what makes me uncomfortable changing
things in this area.

>> See the attached.
>
> Tested and works fine, modulo the -dev part that we should keep.

Note that in
Org mode version 9.6 (release_9.5.5-830-g77f9e1 @ [load-path])

release_9.5.5 while version is 9.6
I feel like you missed this detail.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

access to specific instance(s) of past recurring event(s)

[Saša Janiška]

Hello,

I do use org-mode for many things, but for the task management itself 
was still depending on Taskwarrior despite its poor support for 
recurring events.


However, after settling to more Emacs-powered packages, I'd like to 
replace Taskwarrior with org-mode...


One useful feature of Taskwarrior is that if I have e.g recurring weekly 
task "upload meeting's recording" and, due to various reasons, I'm 
simply behind my schedule, I can access **any** of the missed events and 
not just the oldest one as it seems to be with org-mode.


When looking for some solution I've stumbled upon this (old) post 
https://karl-voit.at/2017/01/15/org-clone-subtree-with-time-shift/ which 
utilizes *org-clone-subtree-with-time-shift*.


Now I wonder if there is some other/better solution that has possibly 
popped up in the meantime?



Sincerely,
Saša

--
A person is said to be elevated in yoga when, having renounced
all material desires, he neither acts for sense gratification
nor engages in fruitive activities.

Re: IM dev discussions?

[Fraga, Eric]

On Sunday, 25 Sep 2022 at 18:53, Timothy wrote:
>> It’s good to be able to connect to Matrix via Emacs: I will try this
>> myself soon.
>
> I haven’t tried this myself yet, but it sounds quite promising! I’d be
> interested to hear how you find it.

(ement.el) Working quite well.  Rapid development in progress by
@alphapapa but already very usable.  Much better than IRC in that you
don't miss anything if you drop your connection.

-- 
: Eric S Fraga, with org release_9.5.5-815-gae2140 in Emacs 29.0.50

Re: org-assert-version considered harmful

[Ihor Radchenko]

Bastien  writes:

>> The code I quoted explicitly removes the "-dev" part. Would you prefer
>> to keep it?
>
> Yes, let's keep it, otherwise (org-release) reads like a lie.

Note that 9.6-dev is not a valid package version string.
See `version-to-list'.

One valid option is 9.6-pre

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section

[Juan Manuel Macías]

Ihor Radchenko writes:

>>> #+ATTR_BACKEND: :export_template "can also work on non-headings"
>>> Paragraph.
>>
>> In this case I would not see it necessary, IMHO. For simple things (of
>> the begin/end style) there are the special blocks. And for more complex
>> pre- and/or post- code we have export blocks and export snippets. Since
>> there is no heading involved here, there would be no danger of the
>> pre-code leaving with the content of the previous header.
>
> I do not insist on this. I just see supporting this easier (it will work
> automatically) compared to explicitly limiting :export_template to
> headings/inlinetasks.
>
> Also, some people prefer to have such option (Pedro Andres Aranda
> Gutierrez in off-list reply to
> https://orgmode.org/list/87fsgmyyhw.fsf@localhost)

Well, it's evident that your idea of the export_template attribute is
very productive and can be consistently extended to more situations. One
scenario where I think it would be very useful is also in tables and
figures, but in this case to insert arbitrary code *inside* the table,
figure, etc. environments. This is something that gets asked on the list
from time to time and the solutions provided are usually a bit tricky.

Going back to the earlier :ATTR_BACKEND: issue as a property for
headings, I've been doing some testing and scribbled down a possible
function[1] whose code is almost entirely stolen from
org-export-read-attribute, with some modifications. Evaluated at the
headline, it returns the value of the ATTR_BACKEND property as a plist.
And then that plist could be easily manipulated on each backend to
format export_template conveniently. For example:

* headline
:PROPERTIES:
:ATTR_LaTeX: :export_template \begin{myenv}\n%s\n\end{myenv}
:ATTR_LaTeX+: blah blah blah
:END:

==> (:export_template "\\begin{myenv}\\n%s\\n\\end{myenv} blah blah blah")

I don't know if that would be the way to go...

Best regards,

Juan Manuel

[1]
(defun possible-function (attribute)
  "TODO"
  (let* ((prepare-value
  (lambda (str)
(save-match-data
  (cond ((member str '(nil "" "nil")) nil)
((string-match "^\"\\(\"+\\)?\"$" str)
 (or (match-string 1 str) ""))
(t str)
 (attributes
  (let ((value (org-entry-get nil attribute)))
(when value
  (let ((s value) result)
(while (string-match
"\\(?:^\\|[ \t]+\\)\\(:[-a-zA-Z0-9_]+\\)\\([ 
\t]+\\|$\\)"
s)
  (let ((value (substring s 0 (match-beginning 0
(push (funcall prepare-value value) result))
  (push (intern (match-string 1 s)) result)
  (setq s (substring s (match-end 0
;; Ignore any string before first property with `cdr'.
(cdr (nreverse (cons (funcall prepare-value s) result
attributes))


-- 
--
--
Juan Manuel Macías 

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: IM dev discussions?

[Timothy]

Hi Bastien,

Just one quick comment on a certain part of your email.

> I expect potential candidates to be okay with the GNU recommendation of trying
> to avoid GitHub for ethical reasons and to be fine with working by email, the
> old way.

Both these things may not come together, or at the same time. For instance, I’m
currently talking to someone on the Doom discord who has a few potential
improvement to Org in the works, and the main barrier to us hearing about them
is their nervousness at sending an email in to the Org ML.

Like it or not, I have the distinct impression that
> to be fine with working by email, the old way.
is a much greater ask than it used to be. Some people may come around with time,
but for getting started at least I think there’s quite a bit of value in having
less “alien” way of getting started. One could argue that by neglecting
non-ML/IRC ways of interacting with the Org project we are accidentally seceding
territory to non-free services like reddit, stackexchange, and co.

All the best,
Timothy

Re: org-assert-version considered harmful

[Bastien]

Ihor Radchenko  writes:

> I think that it will still be useful. In particular, consider major new
> feature development. We may take a longer delay between releases then.

Yes.

> The code I quoted explicitly removes the "-dev" part. Would you prefer
> to keep it?

Yes, let's keep it, otherwise (org-release) reads like a lie.

Why is it necessary to emit org-version.el?

We could have (defun org-version ...) and (defun org-git-version ...)
from within org.el, right?

Also, I don't think we need org-release: the info org-version provides
is enough to know if you are loading Org from a stable (ELPA) release
or from a local git repository.

WDYT?

> See the attached.

Tested and works fine, modulo the -dev part that we should keep.

Thanks!

-- 
 Bastien

Re: org-assert-version considered harmful

[Ihor Radchenko]

Bastien  writes:

> Ihor Radchenko  writes:
>
>> org-git-version is very useful when people report bugs.
>> M-x org-submit-bug-report supplies org-git-version output for bug
>> subject. Thus, we can easily check which git commit their build
>> corresponds to.
>
> Let's keep `org-git-version'.  If we manage to release Org more often
> (minor and major versions), I doubt keep `org-git-version' will remain
> that useful in practise, though.  Let's revisit the topic then.

I think that it will still be useful. In particular, consider major new
feature development. We may take a longer delay between releases then.

>> Note that we already have a way to parse Org version from lisp/org.el,
>> similar to what the commit you referenced does.
>> It is just that this code path is not used by default.
>
> I'd favor using it by default.
>
> When using Org from the main branch of the git repository,
> M-x org-version RET should return this:
>
> "Org mode version 9.6-dev (release_9.5.5-822-g0a6a56 @ [load-path])"

The code I quoted explicitly removes the "-dev" part. Would you prefer
to keep it?

> Can you provide a patch for the above suggestions?  I'll test and see
> if more fixes are needed, even though I'm also not that familiar with
> the code either.

See the attached.
After the patch, org-version returns
Org mode version 9.6 (release_9.5.5-830-g77f9e1 @ [load-path])

>From 77f9e16d7436ca629384e6574f2231e275ea8447 Mon Sep 17 00:00:00 2001
Message-Id: <77f9e16d7436ca629384e6574f2231e275ea8447.1664104208.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Sun, 25 Sep 2022 19:02:17 +0800
Subject: [PATCH] * mk/targets.mk (ORGVERSION): Prefer lisp/org.el version
 header

Do not use the latest Git tag.  Prefer the Version header in org.el.

The Git tag on main branch is only available for the latest release.
Before this commit, development Org version was indistinguishable from
the release version.

See https://orgmode.org/list/8735cfn44v@gnu.org
---
 mk/targets.mk | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/mk/targets.mk b/mk/targets.mk
index 5cba63e21..518635737 100644
--- a/mk/targets.mk
+++ b/mk/targets.mk
@@ -11,16 +11,10 @@ INSTSUB   = $(SUBDIRS:%=install-%)
 ORG_MAKE_DOC ?= info html pdf
 
 ifneq ($(wildcard .git),)
-  ORGVERSION ?= $(subst release_,,$(shell git describe --match release\* --abbrev=0 HEAD))
-  ifeq ($(ORGVERSION),)
-# In elpa.git, there are no tags available.  Fall back to using
-# the org.el header.
-ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 'lisp-mnt)" \
-  --visit lisp/org.el --eval '(princ (lm-header "version"))'))
-GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD)
-  else
-GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
-  endif
+  # Use the org.el header.
+  ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 'lisp-mnt)" \
+--visit lisp/org.el --eval '(princ (lm-header "version"))'))
+  GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
   GITSTATUS  ?= $(shell git status -uno --porcelain)
 else
  -include mk/version.mk
-- 
2.35.1


-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Opening of links

[Max Nikulin]

On 24/09/2022 18:49, Max Nikulin wrote:

On 23/09/2022 21:49, Guillaume MULLER wrote:


- My OS settings are configured so that PDFs are opened in Evince. I 
configured this with "xfce4-settings-manager > Default Applications" 
(which runs "xfce4-mime-settings" under the hood) and it can be 
verified with "xdg-open test.pdf" or by opening Thunar and clicking on 
"test.pdf".


I would name it desktop environment configuration since OS may have more 
settings and it is your issue.


These settings likely alters ~/.config/mimeapps.list
https://specifications.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.html 


"Association between MIME types and applications"

Unfortunately Emacs does not support this part of XDG specs, so there 
are no ready to use functions to work with .desktop files and MIME 
associations. You may add entries calling xdg-open for file types you 
wish to the `org-file-apps' custom variable.


Likely the following entry in `org-file-apps' to override maicap by 
xdg-open may allow to achieve what you expect:


(system . (lambda (file _link) (browse-url-xdg-open file

However links with page numbers (supported for "docview:" type out of 
the box) will not work with such generic handler.

Re: IM dev discussions?

[Bastien]

Ihor Radchenko  writes:

> Familiarity is important. 

I agree with all what you said.

> Ideally, it would be nice to
> have ML front-end that looks similar to GitHub issues. I recall the
> latest versions of mailman had somewhat familiar look. Sourcehut is also
> trying to implement a web-based front-end (though is it not familiar at
> all, unfortunately).

Note that if the GNU project moves to using its instance of sourcehut,
then we will also benefit from such a web-based front-end.

> Note that the opposite to the above is not true. We should not prefer
> familiar front-ends at the cost of sacrificing technical accessibility.

Agreed again.

Another parameter I put in the equation: what do we want?

If our priority were to redirect reports made on r/org-mode and SO to
the Org maintainers, then switching to GitHub would probably be a good
move: users that feel comfortable sharing reports and ideas on these
platforms would create more issues on GitHub than emails we currently
receive on the list.

I believe our priority should be to motivate more Elisp hackers to
become Org maintainers.  I expect potential candidates to be okay with
the GNU recommendation of trying to avoid GitHub for ethical reasons
and to be fine with working by email, the old way.  Especially if we
have maintainers for small files: they certainly don't want to follow
everything in Org's development but agree to be cc'ed occasionally.

2 cts,

-- 
 Bastien

Re: IM dev discussions?

[Timothy]

Hi Bastien,

> I’m all for places where people can freely discuss anything related to
> Org.  There are already many such places: #org-mode and #org-mode-fr
> on IRC, r/org-mode on reddit.com, stackoverflow.com, etc.

Yep, but I do think it’s good to have a few promoted places, ideally based on
FOSS services. Not to start another tangent, but this is one of the reasons why
I think discourse could be a good idea — as a FOSS replacement for reddit,
stackoverflow, etc.

> I don’t want development decisions to be taken in such places—that I
> think we all agree upon.

Sounds like we’re on the same page.

> Based on that, I don’t want a separated IRC channel or a Matrix room
> to be promoted (de facto, by its name) as the place for “contributing
> to Org’s development”: #org-dev or a dedicated Matrix room would sound
> like this to newcomers.  #orgmode is the IM complement of the mailing
> list: a place where Orgers discuss.  On top of that, the ML is the
> place where to suggest patches.

Mmm, it doesn’t have the same role or supplant the ML.

> I think I get your point about categorisation in general, but in this
> case, there is the risk of excluding a category of people (lurkers,
> occasional contributors, etc.) or more precisely: to incidently and
> inadvertently encourage them to self-exclude themselves.

I hear what you’re saying, I’m just not sure how much of an issue this actually
would be. My initial suspicion is with a this issue would be small to
non-existent.

>> With regards to accessibility, I think Matrix is also reaching a rather good
>> point.
>
> Is it possible to lurk in a Matrix room without any login?

With a matrix client you can peek in public rooms without joining them, and
 currently 
exists.

>> The current state of affairs includes an Emacs client, a host of
>> dedicated apps, in-browser web clients, and more. While the ability to peruse
>> archives has not yet been developed, it is also possible to copy a link to a
>> particular message, and so a conversation can be transferred from Matrix to 
>> the
>> ML with a link to the initial conversation, e.g.
>> 
>
> It’s good to be able to connect to Matrix via Emacs: I will try this
> myself soon.

I haven’t tried this myself yet, but it sounds quite promising! I’d be
interested to hear how you find it.

All the best,
Timothy

Re: IM dev discussions?

[Ihor Radchenko]

Bastien  writes:

> Tim Cross  writes:
>
>> FB is what their parents use and email is what their
>> grandparents use!
>
> So true, but quite painful to read on a mailing list ;)

Then how should Timothy feel? :)

Re: IM dev discussions?

[Bastien]

Hi Timothy,

Timothy  writes:

> Doing something similar for Org development is an interesting idea. Something
> similar probably could be set up with the Org room, or a dedicated Org-dev 
> room
> (I’m aware of Bastien’s thoughts on wanting development and help to not be
> separated, but while I like the idea of them living in the same space, I’m
> personally a big fan of categorisation. For instance, we could make an 
> org-mode
> space with a few different rooms: org-dev, org-help, org-showcase, org-chat,
> etc.).

I'm all for places where people can freely discuss anything related to
Org.  There are already many such places: #org-mode and #org-mode-fr
on IRC, r/org-mode on reddit.com, stackoverflow.com, etc.

I don't want development decisions to be taken in such places---that I
think we all agree upon.

Based on that, I don't want a separated IRC channel or a Matrix room
to be promoted (de facto, by its name) as the place for "contributing
to Org's development": #org-dev or a dedicated Matrix room would sound
like this to newcomers.  #orgmode is the IM complement of the mailing
list: a place where Orgers discuss.  On top of that, the ML is the
place where to suggest patches.

I think I get your point about categorisation in general, but in this
case, there is the risk of excluding a category of people (lurkers,
occasional contributors, etc.) or more precisely: to incidently and
inadvertently encourage them to self-exclude themselves.

> With regards to accessibility, I think Matrix is also reaching a rather good
> point. 

Is it possible to lurk in a Matrix room without any login?

The same way you can send an email to the mailing list without being a
subscriber (vs opening a GitHub issue without having a GitHub account)
you can lurk in #org-mode without having a registered account on the
IRC server, which is good.

> The current state of affairs includes an Emacs client, a host of
> dedicated apps, in-browser web clients, and more. While the ability to peruse
> archives has not yet been developed, it is also possible to copy a link to a
> particular message, and so a conversation can be transferred from Matrix to 
> the
> ML with a link to the initial conversation, e.g.
> 

It's good to be able to connect to Matrix via Emacs: I will try this
myself soon.  

All best,

-- 
 Bastien

Re: IM dev discussions?

[Bastien]

Tim Cross  writes:

> FB is what their parents use and email is what their
> grandparents use!

So true, but quite painful to read on a mailing list ;)

-- 
 Bastien

Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

[Bastien]

Ihor Radchenko  writes:

> So, we may create a badge with an icon representing src code (maybe
> " | source code"?) that will point to
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/

+1

-- 
 Bastien

Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

[Bastien]

Hi Timothy,

Timothy  writes:

>> IMHO if someone with UX/UI experience can/wants to interview real Org
>> newcomers, that will help us a lot for deciding about such tiny changes.
>
> Unfortunately, it can be quite hard to find such people on the ML etc. (funny
> about that ).

I'm copying Eduardo who volunteered in the past for this kind of work.

> For what it’s worth, when doing the original website re-design I went to some
> effort to get the thoughts of people who don’t use Org to make sure it did a
> decent job communicating the essentials.

Definitely an ingredient of why your work improved the situation a lot!

> With regards to the current banner, I’m inclined to remove the report bug 
> text:
> having that as well as the badge-link is simply confusing, and the badge-link 
> to
> the feedback page is better.

> We can also add a source code badge using the git icon and linking to
> , and I’d then be 
> inclined
> to remove the “Repository …” text for similar reasons.

I'd definitely love to get more feedback on this: I don't think the
current banner is *that* cluttered, and the info about the repo and
the way to send bug reports seems really useful - but perhaps that's
just me.

Please go ahead with what seems better to you (especially since it
matches Ihor's preferences too), but if Eduardo has some time to help,
it be great to really stabilize what kind of info is expected on this
banner.

Thanks!

-- 
 Bastien

Re: [PATCH] Add .org suffixes to CONTRIBUTE and README

[Timothy]

Hi Bastien,

> I’m considering apply the patch below, renaming CONTRIBUTE to
> CONTRIBUTE.org and README to README.org.

I’ve actually been thinking “why don’t we add .org?” for a while now, so I’d be
glad to see this changed.

The other changes you’ve made all look sensible to me .

All the best,
Timothy

Re: org-assert-version considered harmful

[Bastien]

Ihor Radchenko  writes:

> org-git-version is very useful when people report bugs.
> M-x org-submit-bug-report supplies org-git-version output for bug
> subject. Thus, we can easily check which git commit their build
> corresponds to.

Let's keep `org-git-version'.  If we manage to release Org more often
(minor and major versions), I doubt keep `org-git-version' will remain
that useful in practise, though.  Let's revisit the topic then.

> I am not very familiar with all the code paths our Makefile and
> autoloads take from setting ORG-VERSION to generating the appropriate
> Elisp constants.
>
> However, I do note that mk/targets.mk contains the following:
>
> ifneq ($(wildcard .git),)
>   ORGVERSION ?= $(subst release_,,$(shell git describe --match release\* 
> --abbrev=0 HEAD))
>   ifeq ($(ORGVERSION),)
> # In elpa.git, there are no tags available.  Fall back to using
> # the org.el header.
> ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 
> 'lisp-mnt)" \
>   --visit lisp/org.el --eval '(princ (lm-header "version"))'))
> GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD)
>   else
> GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
>   endif
>   GITSTATUS  ?= $(shell git status -uno --porcelain)
> else
>  -include mk/version.mk
>   GITVERSION ?= N/A
>   ORGVERSION ?= N/A
> endif
>
> Note that we already have a way to parse Org version from lisp/org.el,
> similar to what the commit you referenced does.
> It is just that this code path is not used by default.

I'd favor using it by default.

When using Org from the main branch of the git repository,
M-x org-version RET should return this:

"Org mode version 9.6-dev (release_9.5.5-822-g0a6a56 @ [load-path])"

> We can remove the current default and simply use
>
> ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 
> 'lisp-mnt)" \
>   --visit lisp/org.el --eval '(princ (lm-header "version"))'))
> GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD)
>
> all the time.
>
> I do not know if more involved fix is required (because I am not
> familiar enough with the relevant code).

Can you provide a patch for the above suggestions?  I'll test and see
if more fixes are needed, even though I'm also not that familiar with
the code either.

-- 
 Bastien

[PATCH] Add .org suffixes to CONTRIBUTE and README

[Bastien]

I'm considering apply the patch below, renaming CONTRIBUTE to
CONTRIBUTE.org and README to README.org.

The main benefit is to enhance the rendering of the README on 
GNU ELPA.

I also do some minor reformatting and remove the warning about
org-contrib.

Any objection?

diff --git a/CONTRIBUTE b/CONTRIBUTE.org
similarity index 89%
rename from CONTRIBUTE
rename to CONTRIBUTE.org
index f8a81515e..fbd1616f5 100644
--- a/CONTRIBUTE
+++ b/CONTRIBUTE.org
@@ -1,5 +1,3 @@
--*- mode: org; fill-column:70 -*-
-
 The text below explains the rules for participating in Org mode
 development.
 
@@ -66,9 +64,3 @@ Org maintenance is detailed on Worg: see [[https://orgmode.org/worg/org-maintena
  them and ask everyone to keep this in mind when posting changes.
 
 See [[https://orgmode.org/worg/org-contribute.html][worg/org-contribute]] for guidance on how to contribute effectively.
-
-* The =contrib/= directory
-
-The git repository used to contain a =contrib/= directory.  Files in
-this directory were moved to a new [[https://git.sr.ht/~bzg/org-contrib][org-contrib]] repository before Org
-9.5.  You can install the new =org-contrib= from [[https://elpa.nongnu.org/nongnu/][NonGNU ELPA]].
diff --git a/README b/README.org
similarity index 50%
rename from README
rename to README.org
index bb0a0c582..bf9301169 100644
--- a/README
+++ b/README.org
@@ -1,32 +1,16 @@
--*- mode: org; fill-column:70 -*-
+This is a distribution of Org Mode, a major mode for keeping notes,
+authoring documents, computational notebooks, literate programming,
+maintaining to-do lists, planning projects, and more — in a fast and
+effective plain text system.
 
-This is a distribution of Org, a plain text notes and project planning
-tool for Emacs.
+Check the [[https://orgmode.org][Org Mode website]] for more.
 
-Check the Org Mode website at https://orgmode.org and the installation
-instructions at https://orgmode.org/org.html#Installation.
+* Install Org
 
-* Contents of this distribution
+Org is part of GNU Emacs: you probably don't need to install it.
 
-- README :: This file.
-
-- COPYING :: The GNU General Public License.
-
-- Makefile :: The makefile to compile and install Org.  See the
-  installation instructions https://orgmode.org/org.html#Installation
-  or this more detailed procedure on Worg:
-  https://orgmode.org/worg/dev/org-build-system.html.
-  
-- mk/ :: Files needed for building Org.
-
-- lisp/ :: Directory with all the Emacs Lisp files that make up Org.
-
-- doc/ :: The documentation files.  org.texi is the source of the
-  documentation, org.html and org.pdf are formatted versions of it.
-
-- etc/ :: Files needed for the ODT exporter.
-
-- testing/ :: Testing suite for Org.
+To install a more recent version, please do it from [[https://elpa.gnu.org/packages/org.html][GNU ELPA]] by
+running this command: =M-x package-install RET org RET=
 
 * Join the GNU Project
 
@@ -36,19 +20,18 @@ System, developed by the GNU Project.
 If you are the author of an awesome program and want to join us in
 writing Free (libre) Software, please consider making it an official
 GNU program and become a GNU Maintainer.  Instructions on how to do
-this are here http://www.gnu.org/help/evaluation
+this are here http://www.gnu.org/help/evaluation.
 
 Don't have a program to contribute?  Look at all the other ways to
-help: https://www.gnu.org/help/help.html
+help: https://www.gnu.org/help/help.html.
 
 And to learn more about Free (libre) Software in general, please read
 and share this page: https://gnu.org/philosophy/free-sw.html
 
 * License
 
-Org-mode is published under the GNU GPLv3 license or any later
-version, the same as GNU Emacs:
-https://www.gnu.org/licenses/gpl-3.0.html
+Org-mode is published under the [[https://www.gnu.org/licenses/gpl-3.0.html][GNU GPLv3 license]] or any later
+version, the same as GNU Emacs.
 
 Org-mode is free software: you can redistribute it and/or modify it
 under the terms of the GNU General Public License as published by the

-- 
 Bastien

Re: org-assert-version considered harmful

[Ihor Radchenko]

Bastien  writes:

>> Should we use the next planned release version number on main branch as
>> a convention?
>
> I'd rather use the value set in the ";; Version:" header.
>
> It is "9.5.5" in the bugfix branch and "9.6-dev" on the main branch.

Makes sense.

> I'm not even sure we should keep `org-git-version' at all: if we need
> to distinguish between pre-release states, it seems easy enough to set
> the header as 9.6rc1, 9.6rc2, etc.
>
> WDYT?

org-git-version is very useful when people report bugs.
M-x org-submit-bug-report supplies org-git-version output for bug
subject. Thus, we can easily check which git commit their build
corresponds to.

> PS: I have a vague memory that Stefan suggested to look at how things
> are done on bbdb.el:
>
> https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/lisp/bbdb.el?h=externals/bbdb#n4750
>
> If we can remove the complex Make machinery we have right now, I'd be
> very happy.  One reason for this machinery was to avoid merge conflict
> (thanks to getting rid of the Version: header), but we do have these
> conflicts (now that the header is back) and they are easy to solve.

I am not very familiar with all the code paths our Makefile and
autoloads take from setting ORG-VERSION to generating the appropriate
Elisp constants.

However, I do note that mk/targets.mk contains the following:

ifneq ($(wildcard .git),)
  ORGVERSION ?= $(subst release_,,$(shell git describe --match release\* 
--abbrev=0 HEAD))
  ifeq ($(ORGVERSION),)
# In elpa.git, there are no tags available.  Fall back to using
# the org.el header.
ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 
'lisp-mnt)" \
  --visit lisp/org.el --eval '(princ (lm-header "version"))'))
GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD)
  else
GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
  endif
  GITSTATUS  ?= $(shell git status -uno --porcelain)
else
 -include mk/version.mk
  GITVERSION ?= N/A
  ORGVERSION ?= N/A
endif

Note that we already have a way to parse Org version from lisp/org.el,
similar to what the commit you referenced does.
It is just that this code path is not used by default.

We can remove the current default and simply use

ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 
'lisp-mnt)" \
  --visit lisp/org.el --eval '(princ (lm-header "version"))'))
GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD)

all the time.

I do not know if more involved fix is required (because I am not
familiar enough with the relevant code).

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: org-assert-version considered harmful

[Bastien]

Ihor Radchenko  writes:

> Currently, main and bugfix branches both have (org-version) ; => "9.5.5"
> As a result, the assertion will not catch the important case when users
> mix Org version installed via package.el and Org version installed from
> git.
>
> Should we use the next planned release version number on main branch as
> a convention?

I'd rather use the value set in the ";; Version:" header.

It is "9.5.5" in the bugfix branch and "9.6-dev" on the main branch.

I'm not even sure we should keep `org-git-version' at all: if we need
to distinguish between pre-release states, it seems easy enough to set
the header as 9.6rc1, 9.6rc2, etc.

WDYT?

PS: I have a vague memory that Stefan suggested to look at how things
are done on bbdb.el:

https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/lisp/bbdb.el?h=externals/bbdb#n4750

If we can remove the complex Make machinery we have right now, I'd be
very happy.  One reason for this machinery was to avoid merge conflict
(thanks to getting rid of the Version: header), but we do have these
conflicts (now that the header is back) and they are easy to solve.

-- 
 Bastien

Re: Org Syntax Specification

[Bastien]

Hi Timothy,

I'm late to the party, but *thanks* for these important improvements
on the https://orgmode.org/worg/dev/org-syntax.html page!

A few suggestions:

- Make it a description of the syntax of the latest stable Org.  (For
  now let's consider 9.6 to be the latest stable as we are working on
  releasing it soon.)  Perhaps this is already the case and I missed
  it?

- Remove the "draft" status ("DRAFT v2β"). Don't describe it as a
  draft in the org-manual.org if it accurately reflects the current
  syntax (current = latest stable).

- Remove all the inline notes (some suggest changes in Org's grammar,
  that might scare the readers a bit.)

- Promote the page to orgmode.org/worg/org-syntax.html: the /dev/ path
  in the current URL makes it read like it is the syntax for the "dev"
  version.

What do you think?

-- 
 Bastien

Re: [PATCH] ox-html.el: Fix DTD typo

[Ihor Radchenko]

Ihor Radchenko  writes:

> rapun...@disroot.org writes:
>
>> From: Giovanni Alfredo Garciliano Díaz 
>>
>> * lisp/ox-html.el (org-html-doctype-alist): Fix system identifier for XHTML 
>> 1.1 DTD
>>
>> Right DTDs are listed on https://www.w3.org/QA/2002/04/valid-dtd-list.html
>>
>> TINYCHANGE

Applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3e9f98c691f5505dbfdc4cb4b57a411c03bd69aa

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Numbered footnotes in the manual interfere with diff

[Bastien]

Ihor Radchenko  writes:

> Do you have any suggestion on how to deal with changing footnotes in the
> manual? When I delete this footnote, all the footnotes must be
> re-numbered creating a lot of garbage in the diff. Is it ok? Or should
> we prefer inline footnote definitions in the manual to avoid such
> situations?

I propose to use inline footnotes for notes of one paragraph and to
use regular footnotes for notes spanning over more than one paragraph.
This will enhance both diffs readability and that of the manual's .org
source.

WDYT?

-- 
 Bastien

Re: [BUG] Nitpick: https://liberapay.com/org-mode/ says "Org-mode" while our convention is to use "Org mode" [9.5.5 (release_9.5.5-827-g3b0c4a @ /home/yantar92/.emacs.d/straight/build/org/)]

[Bastien]

Ihor Radchenko  writes:

> s/Org-mode/Org mode

Done, thanks!

-- 
 Bastien

Numbered footnotes in the manual interfere with diff (was: Dates in headlines)

[Ihor Radchenko]

Ihor Radchenko  writes:

>> https://orgmode.org/manual/Handling-Links.html#FOOT28
>
> Unless I miss something, this footnote is plain wrong. The timestamps
> are not removed. At least not when I run M-x org-store-link on a
> headline with timestamp with emacs -Q.

I think we should just remove this footnote.

Bastien,
Do you have any suggestion on how to deal with changing footnotes in the
manual? When I delete this footnote, all the footnotes must be
re-numbered creating a lot of garbage in the diff. Is it ok? Or should
we prefer inline footnote definitions in the manual to avoid such
situations?

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [PATCH] Re: Org Publish HTML and PDF With GPG Files

[Ihor Radchenko]

Ihor Radchenko  writes:

> Subject: [PATCH] ox-publish: Allow linking to encrypted Org files
>

Applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f99902ecdfa4357035fb04f44b3baa8cec260530

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [BUG] org-html-mathjax-options docstring [9.5.1 (release_9.5.1-11-g96d91b @ /emacs-28.0.90/lisp/org/)]

[Ihor Radchenko]

Y. E. via "General discussions about Org-mode." 
writes:

> It seems the docstring of org-html-mathjax-options may need to be
> updated.

Thanks for reporting!

Fixed.
See https://list.orgmode.org/orgmode/87h71xuhdw.fsf@localhost/

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

[BUG] Nitpick: https://liberapay.com/org-mode/ says "Org-mode" while our convention is to use "Org mode" [9.5.5 (release_9.5.5-827-g3b0c4a @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Hi,

According to doc/Documentation_Standards.org

> - Prefer "Org mode" to "Org-mode" or "org-mode". This is simply because
>   it reflects an existing convention in [[info:emacs:Top][The Emacs
>   Manual]] which consistently documents mode names in this form - "Text
>   mode", "Outline mode", "Mail mode", etc.

However, https://liberapay.com/org-mode/ says
"Contributors to GNU Emacs Org-mode" and uses "Org-mode" across the
description.

s/Org-mode/Org mode

Best,
Ihor

Re: Babel C-mode corrupts double-quoted strings in output

[Ihor Radchenko]

tbanelwebmin  writes:

> This fix in ob-C.el passes all unit tests, as well as Martin's example, and 
> some other examples.
>
> If someone get a regression, please tell me!
> In a few days, I will commit.
>
> The fix: in ob-C.el line 185, change:
>   (org-babel-read results t)
> to:
>   results

Did you have a chance to push the commit?
I am not seeing anything in the git log.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [ANN] An Org parser for Julia

[Bastien]

Hi Timothy,

Timothy  writes:

> https://github.com/tecosaur/OrgMode.jl

Great!  I advertized this new parser on Worg:
https://orgmode.org/worg/org-tools/index.html

Thanks!

-- 
 Bastien

Re: svg file from tikz picture

[Ihor Radchenko]

Akira Kyle  writes:

> I've been using the attached patch for the last few years and I've meaning to 
> send it here/start a discussion about ob-latex.el since I used it pretty much 
> daily to write tikz figures in org mode. So I'm glad to see this discussion 
> has been started!
>
> I've found it to be incredibly productive to use babel to develop tikz 
> diagrams as I can make come changes and quickly `org-ctrl-c-ctrl-c` to render 
> them in the same buffer.
>
> I think when I made this patch I had been caught by some of the quirks of the 
> svg export. For example, sometimes I would have some latex equation which I 
> use ~org-latex-preview~ on as I was writing it, but then it would fail to 
> render as mathjax upon html export since I would use some latex package that 
> isn't available under mathjax. So by using ob-latex I could easily fix this 
> by using the ~:file .svg~ header and get a nice html export. However due to 
> the different way of assembling the ~.tex~ file sometimes ~org-latex-preview~ 
> would work but ob-latex wouldn't. I think my use case may be fairly common 
> and so I think ob-latex really should be updated so svg uses the 
> ~org-latex-preview~ code. o

Thanks a lot for the patch!
I am not very familiar with the code here, but I will try to cross-check
things as much as possible as an initial feedback.

> Also I think the ~.tikz~ extension doesn't really make any sense since one 
> really can but arbitrary tex code in such a block, and I think that's why I 
> renamed it in my patch. However I'm now realizing that this evaluation method 
> probably doesn't make much since `:tangle` will already do this, with the 
> added benefit of handling noweb references correctly. So perhaps this should 
> be removed and document using tangling in lieu of ~:file *.tikz~?

This sounds reasonable, but we must not remove it just yet. Instead, we
need to support .tex extension _and_ .tikz extension as backwards
compatibility. For .tikz extension we may also display a warning that it
is obsolete.

> -(defcustom org-babel-latex-htlatex-packages
> -  '("[usenames]{color}" "{tikz}" "{color}" "{listings}" "{amsmath}")
> -  "Packages to use for htlatex export."
> -  :group 'org-babel
> -  :type '(repeat (string)))

Removing this defcustom will be a regression. Maybe we can instead
append it to org-latex-packages-alist? Note that {color} and {tikz} are
not loaded by default in `org-format-latex-header'.

> +  (org-format-latex-header
> +   (concat org-format-latex-header
> +   (mapconcat #'identity (cdr (assq :headers params)) "\n")
> +   (if fit "\n\\usepackage[active, tightpage]{preview}\n" "")

(concat "a" nil "b") is perfectly acceptable. There is no need to supply
empty strings as `concat' arguments.
Can simply use (when fit ...)

> +(defun org-babel-latex-format-tex (tex-file body)
> +  "Generate a temporary tex file from execute params."
> +  (with-temp-file tex-file
> +(insert
> + (org-latex-make-preamble
> +  (org-export-get-environment (org-export-get-backend 'latex))
> +  org-format-latex-header)
> + (concat "\n\\begin{document}\n" body "\n\\end{document}\n"

I note that `org-export-get-environment' will be ran inside a temporary
file. It means that Org buffer LaTeX export settings for the source
buffer will not affect the return value. I assume that it is
intentional. If so, it is worth adding a comment about it into the code.

>  
> -(defun org-babel-latex-tex-to-pdf (file)
> -  "Generate a pdf file according to the contents FILE."
> -  (require 'ox-latex)
> -  (org-latex-compile file))
> -

This is removing a non-private function. Even though this function is
nothing but trivial, we still cannot remove it without notice.
The function should be moved to org-compat.el and marked obsolete.

Finally, please note that we follow certain commit message standards in
Org mode. See https://orgmode.org/worg/org-contribute.html#commit-messages

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: [Translation] Add Persian/Farsi to org-export

[Bastien]

Hi Sajad,

Sorry it took long to review and apply this.

Sajad Hosseini Balef  writes:

> lisp/ox.el: Add Persian/Farsi to org-export

Applied on the main branch as 36c27f11d.

I also added your name to https://orgmode.org/worg/contributors.html.

If you want to submit other patches, please fill the FSF copyright
assignment: https://orgmode.org/request-assign-future.txt

Thanks!

-- 
 Bastien

Re: [External] : Re: strange errors with org-element-cache-reset and jit-lock-function void-variable org-element-citation-prefix-re

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> I am leaning towards removing `this-command' check, unless there are
>> important reasons to keep it.
>
> Yes, please go ahead.

Done.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3b0c4ad20794ecfb6557900897179718cc812786

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92