Re: BUG Visibility Cycling with inline tasks

[Ihor Radchenko]

Michael Dauer  writes:

> Stating collapsed, pressing TAB on the heading 2 already shows the issue.

Could you describe what is the issue you observe and how it differs from
your expectations? I do not see any problem with visibility on my side.

Best,
Ihor

Re: Git repository status

[Bastien]

Hi Yasushi,

Yasushi SHOJI  writes:

> It seems like we are transitioning from code.orgmode.org to
> git.savannah.gnu.org, but still not synced?

they are sinced manually so far.

I just announced that the new repos are the official ones.

I will continue to sync the old ones until Org 9.6 is released and the
new publication process for orgmode.org is in place, which can take a
while.

> Which branch, gnu.org/main or orgmode.org/master, should I make
> patches against?

gnu.org/main

Thanks!

-- 
 Bastien

Switching to new Git repositories

[Bastien]

Hi all,

from now on, here are the official Org repositories:

- org-mode: https://git.savannah.gnu.org/cgit/emacs/org-mode.git
- worg: https://git.sr.ht/~bzg/worg
- orgweb: https://git.sr.ht/~bzg/orgweb

org-contrib will continue to be on https://git.sr.ht/~bzg/org-contrib
until it disappears, thanks to volunteers taking over maintainance of
the various packages.

You can forget code.orgmode.org.

If you commit to code.orgmode.org by mistake instead of using the new
repos, just merge the commit from the old repo that you can set up as
a remote branch: I won't delete code.orgmode.org until Org 9.6.

If you don't have write access to the new repos and think you should,
please send me an email.

I will work on merging orgweb+worg and setting up the HTML publication
process from sr.ht, which can take a while.

Have a nice week!

-- 
 Bastien

Heading toward Org 9.5

[Bastien]

Hi all,

I'll work on integrating small bug fixes and feature improvements
listed on https://updates.orgmode.org during this week, aiming at
releasing Org 9.5 over the next week-end.

If your patch does not appear on updates.orgmode.org and didn't 
receive an answer on the list, please send me an email pointing at
the reference on orgmode.org/list.

Thanks,

-- 
 Bastien

Re: Internal link broken when publishing (was org-id with ox-html)

[chris]

On Tuesday, 14 September 2021 18:33:43 CEST Max Nikulin wrote:
> As a kind of summary:
> 
> During publishing of a project
> - "id:" links to headings from the same file are exported as short
> generated anchors like #org032777e or as anchors to custom ids when the
> latter are available
> - "Search heading" links to other files are exported as short generated
> anchors or as custom ids.
> - "id:" links to headings in external files are exported as ID value
> with "ID-" prefix. These links are *broken* currently.

Thanks a lot.
Perfectly functional org-id links between two files are broken when published 
to HTML.
I suppose a bug should be opened about that?
(I can do that in a few weeks.)

CUSTOM_ID solution is not good because you have to specify what file the ID is 
in. With plain ID, you specifically do not have to specify in which file the ID 
is, and therefore you can freely move around entries with ID, even beyond the 
file boundary, without troubling yourself. Because there is some sort of 
database behind, taking care of it for you.

For the exporting, considering the "ID-db" must be queried, and a translation 
process must be applied, I don't think there should be any specifications about 
the way it is implemented.

> Expected behavior is the same style of anchors for particular heading, e.g.
> - value of custom_id property is used even for "id:" links
> - either value of id property or short generated anchor is used for
> links to a heading having id property (maybe it should be possible to
> customize preferred style) but the same for search heading text fuzzy
> links and "id:" links, internal and external ones.
> 
> I do not mind to have both anchors with value of id and custom_id
> properties if they are defined for a header.
> 
> My opinion is that value of id property should be used for heading
> anchor when available to guarantee stable links from other sites. I
> admit that default behavior may be short (perhaps unstable) anchors.
> 
> On 07/09/2021 22:46, chris wrote:
> > On Tuesday, 24 August 2021 17:23:24 CEST Maxim Nikulin wrote:
> >> On 23/08/2021 03:42, inkbottle wrote:
> >>   From my point of view it looks like a bug.
> >> 
> >> https://code.orgmode.org/bzg/org-mode/src/master/lisp/ox.el#L4381
> 
> ...
> 
> > I believe it's a bug, plain and simple.
> 
> I am afraid that its fix would not be so simple.
> 
> > With a unique org file, the `:ID: e54113f9-2ad7-4a86-94be-68ffc696de0b`
> > are
> > resolved to `orgfa9c151` consistently.
> 
> My opinion (in contradiction to Nicolas) is that anchors should be as
> stable as possible even in the absence of cross-references withing the
> document. It allows links from other sites to particular sections. That
> is why value of ID property is better than random anchor despite the
> former is longer.
> 
> > There is a patch here:
> > https://gist.github.com/jethrokuan/d6f80caaec7f49dedffac7c4fe41d132
> > but, as I understand it, the workaround consists in treating `:ID:`
> > similarly as `:CUSTOM_ID:`, that is, exporting them "verbatim".
> 
> If it were a patch, it would be easier to spot the changed part. This
> approach may be implemented in a bit cleaner way but I do not think that
> it will allow to use custom_id value for "id:" link if a heading has
> both (see `org-html-link' and `org-export-resolve-id-link').
> 
> >> checks for ID property.
> >> https://code.orgmode.org/bzg/org-mode/src/master/lisp/ox-html.el#L1659
> >> queries CUSTOM_ID only. I suppose, ID should be here as well. A subtle
> >> point is which one (ID or CUSTOM_ID) should be used if both are defined
> >> for some headers.
> > 
> > Yes, "ID should be here as well" => No.
> > That is the point I'm advocating above.
> > `:CUSTOM_ID:` are meant to be treated in a so-called "stable" way. That is
> > to say, the `CUSTOM_ID` you see in your org-file, is what you get in your
> > HTML file (also I've done some tests with that method, and I recall it
> > wasn't working at all in a multiple org files setting).
> > On the other hand, `:ID:` are meant to be treated through a *translation
> > table*, and should result in some `orgfa9c151` thing, on the HTML side.
> > Weaving the two methods together doesn't seem like "road to success".
> 
> In a general case it is rather hard to get stable anchors, even having
> full history of changes. On the other hand I see no reason to avoid
> stable IDs where they exist. Looks like a reason for defcustom at least.
> I consider random anchors and the cache to make some of them stable as
> an unavoidable fallback when there is no better way (users avoid
> property drawers).
> 
> >> Maybe it is possible to create workaround as a custom config without
> >> touching of Org code. I guess, "nicer" ids may be replaced by values of
> >> ID property. Examples (I tried none of them):
> >> -
> >> https://tecosaur.github.io/emacs-config/config.html#nicer-generated-headi
> >> ng
> >> https://orgmode.org/list/e1jxajq-0004dk...@lists.gnu.org/ (TEC.
> >> 

Extending org-batch-agenda-csv to include location property

[JG]

Hi, I've been researching a way to extend the org-batch-agenda-csv
command to include a location property from the properties drawer. From
what I see in the source code, the fields it creates are all hard-coded:

https://github.com/tkf/org-mode/blob/master/lisp/org-agenda.el#L2984-L2985

and I don't see a straight-forward way to include things that are in the
properties drawer, namely the location property.

In doing some broader research, I came across the org-agenda-property
package which extracts information in the property drawer, by default
including the location property, and appends it to the full view of the
agenda. It appears this extraction occurs in the package in these lines:

https://github.com/Malabarba/org-agenda-property/blob/master/org-agenda-property.el#L165-L170

If someone could point me in the right direction about extending the
org-batch-agenda-csv function to include the location property from the
property drawer, perhaps by somehow incorporating the procedure in the
org-agenda-property package, I would appreciate it.

Re: DONE headlines take a different color

[Jim Porter]

On 9/19/2021 9:09 AM, Giovanni Gigante wrote:


As per the subject: TODO states mantain the headline color (as 
expected), but DONE states change it (not expected).


As shown in lines 2, 5, 8, 11, 14 of the following screenshot (emacs 
27.2 on MacOS launched with -q,  org mode 9.4.4):


I believe this is the result of `org-fontify-done-headline', which 
defaults to t as of e360cd8f3a from Feb 2020.


- Jim

Customizing the agenda item format

[Matt Huszagh]

I'm attempting to create a custom agenda, but having a bit of trouble
getting this to work in the way that I want. In particular, I'd like to
be able to specify the display format for each item.

Here's what I've got so far:

(setq org-agenda-custom-commands
  '(("c" "Custom agenda view"
 ((tags-todo "hardware|electronics|mechanical_engineering"
 ((org-agenda-skip-function '(org-agenda-skip-entry-if 
'todo '("HOLD")))
  (org-agenda-overriding-header "Hardware")
  (org-agenda-prefix-format "  ")
  (org-agenda-hide-tags-regexp ".*")))

This gives me something like

TODO some headline title

This is close to what I want. But, all my items are TODO so I don't want
to display this. In other words, I just want

some headline title

Then, I'd also like to display the title of the page, right-justified,
in parentheses.

So,

some headline title(some page title)

Another display I'm considering is to present the full outline path,
rather than just the title, so something like

some/headline/path (some page title)

I can provide functions to get this information, but I don't know how to
present it in the agenda.

Are displays like this possible? `org-agenda-prefix-format' gives a lot
of flexibility for the prefix format, but I wasn't able to find
something similar for the actual item. The "Presentation and Sorting"
part of the manual also didn't give me any leads.

Thanks
Matt

Re: publishing: no default publishing function, or symbol is not defined

[Yasushi SHOJI]

Hi,

I've also added a test case for the default translation function.
I'm not sure it's justified to add a new func `org-plist-delete-all`
just for this.
We can move the function to the test file if we don't need it in org-marcs.
-- 
yashi
From 2fdf67b4ddfac97acb2b685957b6e4ca26474fb4 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI 
Date: Sun, 19 Sep 2021 18:56:19 +0900
Subject: [PATCH 1/3] ox-publish: Set default transformation

As documented in Org Manual, we should have the default transformation
function set to org-html-publish-to-html.

Signed-off-by: Yasushi SHOJI 
---
 lisp/ox-publish.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-publish.el b/lisp/ox-publish.el
index c25dd5473..99b1dca81 100644
--- a/lisp/ox-publish.el
+++ b/lisp/ox-publish.el
@@ -617,7 +617,8 @@ files, when entire projects are published (see
 			  (abbreviate-file-name filename
 	 (project-plist (cdr project))
 	 (publishing-function
-	  (pcase (org-publish-property :publishing-function project)
+	  (pcase (org-publish-property :publishing-function project
+   'org-html-publish-to-html)
 	(`nil (user-error "No publishing function chosen"))
 	((and f (pred listp)) f)
 	(f (list f
-- 
2.33.0

From 4978f588443f0ac27c75676697c2cc1b8beae668 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI 
Date: Mon, 20 Sep 2021 02:09:29 +0900
Subject: [PATCH 2/3] org-macs: Introduce org-plist-delete-all

In some cases we want to remove multiple properties from a plist.
This function just for that.

Signed-off-by: Yasushi SHOJI 
---
 lisp/org-macs.el | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 18ae642c7..bd4bb5066 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -538,6 +538,11 @@ that may remove elements by altering the list structure."
 (setq list (delete (pop elts) list)))
   list)
 
+(defun org-plist-delete-all (plist props)
+  "Delete all elements in PROPS from PLIST"
+  (dolist (e props plist)
+(setq plist (org-plist-delete plist e
+
 (defun org-plist-delete (plist property)
   "Delete PROPERTY from PLIST.
 This is in contrast to merely setting it to 0."
-- 
2.33.0

From 83913a2b0becb8429e9cc4e5872a9c7557351d03 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI 
Date: Mon, 20 Sep 2021 02:10:26 +0900
Subject: [PATCH 3/3] testing: ox-publish: Add a test case for default trans
 func

We use `org-html-publish-to-html' as the default transformation
function.  This commit adds a test case to make sure that org-publish
produces exact same output when org-html-publish-to-html is given as
:publishing-function or without it.

Because `org-publish-property' checks the given property with
`plist-member', we can't pass nil with :publishing-function; This
causes ox-publish to error out with "No publishing function chosen".

Thus we are removing :publishing-function from the plist using
`org-plist-delete-all'.

Signed-off-by: Yasushi SHOJI 
---
 testing/lisp/test-ox-publish.el | 36 -
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/testing/lisp/test-ox-publish.el b/testing/lisp/test-ox-publish.el
index 35031742f..3bfb985ab 100644
--- a/testing/lisp/test-ox-publish.el
+++ b/testing/lisp/test-ox-publish.el
@@ -22,12 +22,16 @@
 
 ;;; Helper functions
 
-(defun org-test-publish (properties handler)
+(defun org-test-publish (properties handler  remove-prop)
   "Publish a project defined by PROPERTIES.
 Call HANDLER with the publishing directory as its sole argument.
 Unless set otherwise in PROPERTIES, `:base-directory' is set to
 \"examples/pub/\" sub-directory from test directory and
-`:publishing-function' is set to `org-publish-attachment'."
+`:publishing-function' is set to `org-publish-attachment'.
+Because `org-publish-property' uses `plist-member' to check the
+existance of a property, a property with a value nil is different
+from non-existitance.  Properties in REMOVE-PROP will be remove
+from the final plist."
   (declare (indent 1))
   (let* ((org-publish-use-timestamps-flag nil)
 	 (org-publish-cache nil)
@@ -35,13 +39,15 @@ Unless set otherwise in PROPERTIES, `:base-directory' is set to
 	 (pub-dir (make-temp-file "org-test" t))
 	 (org-publish-timestamp-directory
 	  (expand-file-name ".org-timestamps/" pub-dir))
+ (props (org-plist-delete-all
+ (org-combine-plists
+  `(:base-directory ,base-dir
+:publishing-function org-publish-attachment)
+  properties
+  `(:publishing-directory ,pub-dir))
+ remove-prop))
 	 (project
-	  `("test" ,@(org-combine-plists
-		  `(:base-directory
-			,base-dir
-			:publishing-function org-publish-attachment)
-		  properties
-		  `(:publishing-directory ,pub-dir)
+	  `("test" ,@props)))
 (unwind-protect
 	(progn
 	  (org-publish-projects (list project))
@@ -92,7 +98,19 @@ Unless set 

Re: Emacs-orgmode Digest, Vol 187, Issue 19

[Ypo]

Thanks Max Nikulin

Then I think I will behave like grown people and use LaTeX syntax, previewing 
it on HTML exports, cause it gives no errors compared to the problematic PDF 
exports.

Thanks again, best regards

Sep 19, 2021 14:12:15 emacs-orgmode-requ...@gnu.org:

> Message: 20
> Date: Sun, 19 Sep 2021 19:05:01 +0700
> From: Max Nikulin 
> To: emacs-orgmode@gnu.org
> Subject: Re: Overlining troubles
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> On 19/09/2021 00:51, Ypo wrote:
> 
> 
> I use orgmode to read and study directly but I am not able to set up
> LaTeX preview. So I need something "direct", but I can't renounce to
> exporting it.
> 
> 
> For some letters accented characters exist: "ā".
> 
> Inline LaTeX preview just works for me (Linux), so I can suggest nothing
> besides to check "*Org Preview LaTeX Output*" buffer for errors.
> 
> 
> El 18/09/2021 a las 19:32, Timothy escribió:
> 
> 
> If you’re thinking of maths, why not just write inline LaTeX, e.g.
> \(\bar{x}\) ?
> 
> 
> 
> I think, you should follow this recomendations. Typography rules for
> math expressions substantially differ from ones for prose (italic font
> for variables, LaTeX cares concerning proper spaces, etc.).
> 
> When I was writing docs containing math, I had PDF (earlier DVI or PS)
> viewer window open along with LaTeX sources, so I could read formatted
> text. Anyway that time math in WYSIWYG was rather ugly (maybe besides
> texmacs), required heavy mouse work, and such editors had various
> problems with more or less complex documents that were easier for me to
> solve in LaTeX. That is why I never had expectation that source document
> should look like formatted one. Editing of sufficiently complex
> equations in LaTeX is not always convenient though

Re: [PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil

[Timothy]

Hi  Morgan,

Thanks for clarifying this. That makes sense to me, and so I’ve just pushed your
patch as 3a77e59 , with a slightly tweaked commit message. Thanks for going to
the effort of pinpointing and fixing this issue, and your patience in seeing
this accepted.

Morgan Willcock  writes:

> It seems to default to spaces everywhere else. If you export an actual
> document through the ascii exporter instead of just a document header
> you will get a mix of tabs and spaces. This is how it was brought to my
> attention, I was distributing a file that was batch exported and someone
> pointed out that the indentation was inconsistent.
>
> If it is handled as an export preference or defaults to the global
> indentation preference then that would be fine but I don’t believe
> either of those are the case.
>
> Thanks for continuing to look,
> Morgan

All the best,
Timothy

[PATCH] ox.el: add smart quotes for Greek

[Juan Manuel Macías]

Hi,

I attach here a tiny patch to add Greek smart quotes. Finally, I apply
the second level quotation marks that Protesilaos Stavrou proposed in this
previous thread:
https://orgmode.org/list/87o89yv1mz@cnu407c2zx.nsn-intra.net/#r

So the quotation marks setting for Greek is exactly the same as in the
case of quotation marks for Spanish.

Thanks a lot to Protesilaos, Michalis and Maxim Nikulin for their suggestions on
that thread (Maxim, sorry I did not reply to your message in the thread,
but and I didn't see it until a few days ago :-()

Best regards,

Juan Manuel

-
https://juanmanuelmacias.com

>From 3deb65be3d59e2ae35bd6dc9bb38b138dee926f8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Sun, 19 Sep 2021 17:58:51 +0200
Subject: [PATCH] ox.el: add smart quotes for greek

* lisp/ox.el (org-export-smart-quotes-alist): The correct quotes for Greek have been established with the help of Protesilaos Stavrou
---
 lisp/ox.el | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 5fe894569..a8014d401 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -524,7 +524,7 @@ e.g. \"H:2\"."
   "The default language for export and clocktable translations, as a string.
 This may have an association in
 `org-clock-clocktable-language-setup',
-`org-export-smart-quotes-alist' and `org-export-dictionary'.
+`org-export-smart-quotes-' and `org-export-dictionary'.
 This option can also be set with the LANGUAGE keyword."
   :group 'org-export-general
   :type '(string :tag "Language")
@@ -5437,6 +5437,16 @@ transcoding it."
  (secondary-closing
   :utf-8 "‘" :html "" :latex "\\grq{}" :texinfo "@quoteleft{}")
  (apostrophe :utf-8 "’" :html ""))
+("el"
+ (primary-opening
+  :utf-8 "«" :html "" :latex "\\guillemotleft{}"
+  :texinfo "@guillemetleft{}")
+ (primary-closing
+  :utf-8 "»" :html "" :latex "\\guillemotright{}"
+  :texinfo "@guillemetright{}")
+ (secondary-opening :utf-8 "“" :html "" :latex "``" :texinfo "``")
+ (secondary-closing :utf-8 "”" :html "" :latex "''" :texinfo "''")
+ (apostrophe :utf-8 "’" :html ""))
 ("en"
  (primary-opening :utf-8 "“" :html "" :latex "``" :texinfo "``")
  (primary-closing :utf-8 "”" :html "" :latex "''" :texinfo "''")
-- 
2.32.0

DONE headlines take a different color

[Giovanni Gigante]

  
  

As per the subject: TODO states mantain the headline color (as
expected), but DONE states change it (not expected).

As shown in lines 2, 5, 8, 11, 14 of the following screenshot (emacs
27.2 on MacOS launched with -q,  org mode 9.4.4):



In the past this did not happen; I have verified this with an
ancient installation.


Giovanni Gigante

  

Re: [PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil

[Morgan Willcock]

Timothy  writes:

> Hi  Morgan,
>
> I’ve just taken a look at your patch (it `git am's just fine), since nobody 
> else
> seems to have had the time to look at your patch as of late. There’s one thing
> which I now realise completely slipped by me last time — why are tabs bad?
> Maybe I’m missing something obvious, but exporting with tabs and 
> viewing/`cat'ing
> the file everything looks fine to me in terms of alignment.

Hi Timothy,

It seems to default to spaces everywhere else. If you export an actual
document through the ascii exporter instead of just a document header
you will get a mix of tabs and spaces. This is how it was brought to my
attention, I was distributing a file that was batch exported and someone
pointed out that the indentation was inconsistent.

If it is handled as an export preference or defaults to the global
indentation preference then that would be fine but I don't believe
either of those are the case.

Thanks for continuing to look,
Morgan

Re: [PATCH] manual: How to refer to tables in other files

[Timothy]

Hi  William,

Thanks for sending in this patch. Documentation improvements are always great to
see. I’ve just applied your patch with minor tweaks to the commit message, and
the “Nu HTML” bit removed as d700c03 .

William Denton  writes:

> Attached is a very small update to the docs about how to refer to tables in
> other files.  Probably there’s something wrong with the formatting, but git
> send-email didn’t work, and I hope the Changelog entry gets through.
>
> Bill

All the best,
Timothy

Re: [PATCH] Add faces to improve contextuality of agenda views

[Timothy]

Hi  Protesilaos,

Thanks for sending this patch in, and sorry it’s taken a while for you to hear
anything back. I see the utility of org-imminent-deadline, but am fairly
indifferent about the rest.

Hopefully bumping this might prompt some others to give their thoughts on your
patch.

All the best,
Timothy

Re: [PATCH] org-cite: define \citeprocitem for LaTeX export

[Timothy]

Looks like I forgot to mark this patch as applied on updates.orgmode.org.
Let’s just quickly fix that…

Re: [PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil

[Timothy]

Hi  Morgan,

I’ve just taken a look at your patch (it `git am's just fine), since nobody else
seems to have had the time to look at your patch as of late. There’s one thing
which I now realise completely slipped by me last time — why are tabs bad?
Maybe I’m missing something obvious, but exporting with tabs and 
viewing/`cat'ing
the file everything looks fine to me in terms of alignment.

Morgan Willcock  writes:

> I’ve attached a patch to fix an issue where tab characters are generated by
> the ASCII exporter when `indent-tabs-mode’ has its default value of t.

All the best,
Timothy

Re: [PATCH] Fixed lstset where language= wipes out previous definitions

[Timothy]

Hi  Karl,

Thanks for sending in this patch, and sorry it’s taken so long for someone to
get back to you. Would you mind explaining the issue here a bit more? I can’t
see at a glance how preceding definitions are wiped in the current
code.

Karl Stump  writes:

> * ox-latex.el (org-latex-src-block): moved ((“language” ,lst-lang)) to the 
> head of the list.
> This fixes wiping out preceding definitions given in 
> `org-latex-listings-options’.
> TINYCHANGE
> —
>  lisp/ox-latex.el | 4 ++–
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff –git a/lisp/ox-latex.el b/lisp/ox-latex.el
> index b9ecf070a..f956c851e 100644
> — a/lisp/ox-latex.el
> +++ b/lisp/ox-latex.el
> @@ -3075,13 +3075,13 @@ contextual information.“
>   (concat
>(org-latex–make-option-string
> (append
> -lst-opt
> +   `((”language“ ,lst-lang))
> +   lst-opt
>  (cond
>   ((and (not float) (plist-member attributes :float)) nil)
>   ((string= ”multicolumn“ float) ’((”float“ ”*“)))
>   ((and float (not (assoc ”float“ lst-opt)))
>`((”float“ ,(plist-get info :latex-default-figure-position)
> -`((”language“ ,lst-lang))
>  (if label
>  `((”label“ ,(org-latex–label src-block info)))
>’((”label“ ” “)))

All the best,
Timothy

Re: [PATCH] Various minor docfixes found by checkdoc

[Timothy]

Just marking as applied for  .

Re: [PATCH] ob-tangle.el: Fix error in org-tangle from org-src edit buffer

[Timothy]

Hi Mark,

Many thanks for not only tracking down this problem but making a fix and
submitting it . I've just pushed this as 986341b with minor tweaks to the
commit message.

Mark Dawson  writes:

> [PATCH] ob-tangle.el: Fix error in org-tangle from org-src edit
>  buffer
>
> (org-babel-tangle) : Fix stringp error which happens when confirming
> successful tangle when `org-babel-tangle` is called from an org-src edit
> buffer.
>
> TINYCHANGE
> ---
>  lisp/ob-tangle.el | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
> index 2f60ef9a4..0768c8588 100644
> --- a/lisp/ob-tangle.el
> +++ b/lisp/ob-tangle.el
> @@ -281,7 +281,10 @@ matching a regular expression."
>   (if (= block-counter 1) "" "s")
>   (file-name-nondirectory
>(buffer-file-name
> -   (or (buffer-base-buffer) (current-buffer)
> +   (or (buffer-base-buffer)
> +   (current-buffer)
> +   (and (org-src-edit-buffer-p)
> +(org-src-source-buffer))
>   ;; run `org-babel-post-tangle-hook' in all tangled files
>   (when org-babel-post-tangle-hook
>(mapc

--
Timothy

Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Ihor Radchenko]

Timothy  writes:
> Ah, I’ve already got a few patches on Org that I’m preparing for sharing on 
> the
> ML, so this may make it a bit harder for me. I’ll let you know how I find it 
> if
> I do give it a go though.

My repo is up-to-date with latest master. You should be able to merge
without too much trouble. I think you can even add my repo to git
remotes, fetch feature/org-fold-universal-core branch, and merge it with
your local testing branch.

Best,
Ihor

Re: [PATCH] minor typo fix in org-tutorials/org-protocol-custom-handler.org

[Timothy]

Marking as applied on updates.orgmode.org.

Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Timothy]

Hi  Ihor,

Thanks for clearing up the nature of your patch-y feature request.

>> p.s. I’m marking this as a patch on the tracker, since it is one :P
>
> This is not a real patch. I just separated changes I made in
> org-element.el. Other changes include cache support across Org code and
> tests. In total it looks roughly like:
>
> 12 files changed, 2584 insertions(+), 1140 deletions(-)
>
> However, I did not directly base the patch on master, but rather on
> (hopefully-to-be-merged-at-some-point org-fold branch :’/). I am not too
> interested in porting the patch onto master. At least not until I get
> feedback on parser and API changes.

Righteo, I’ll un-mark this as a patch then .

>> As someone who tangles massive literate config this sounds like it could make
>> quite a noticeable improvement. To test this, do I need to do anything more 
>> than
>> just apply your patch?
>
> Applying the patch will not work. As I said, it is mostly for reference
> to show the changes to parser and API. If you want to test it, you can
> use . That repo includes the org-fold
> branch and the new cache implementation.

Ah, I’ve already got a few patches on Org that I’m preparing for sharing on the
ML, so this may make it a bit harder for me. I’ll let you know how I find it if
I do give it a go though.

All the best,
Timothy

Re: Bug: PDF Export of Link fails (emphasis ends inside link target)

[Max Nikulin]

On 03/09/2021 21:57, Maxim Nikulin wrote:

On 03/09/2021 21:33, Timothy wrote:


Perhaps a “fix” could be auto-escaping problematic characters in urls 
when

entering links via `org-insert-link'.

[/query/] 


`org-insert-link' still may detect emphasis markers around the point and 
add extra marks. Unfortunately heuristics to detect start marker only 
(while typing text when no end marker yet) will be prone to false 
positives.


Maybe additional undo step while adding link is enough to alleviate the 
issue with false positives (similar to autoreplace patterns in text 
processors). If a user notices that additional markers are added 
incorrectly, she can remove them through undo. Next undo removes the 
inserted link completely.

Re: Overlining troubles

[Max Nikulin]

On 19/09/2021 00:51, Ypo wrote:


I use orgmode to read and study directly but I am not able to set up 
LaTeX preview. So I need something "direct", but I can't renounce to 
exporting it.


For some letters accented characters exist: "ā".

Inline LaTeX preview just works for me (Linux), so I can suggest nothing 
besides to check "*Org Preview LaTeX Output*" buffer for errors.



El 18/09/2021 a las 19:32, Timothy escribió:


If you’re thinking of maths, why not just write inline LaTeX, e.g. 
\(\bar{x}\) ?


I think, you should follow this recomendations. Typography rules for 
math expressions substantially differ from ones for prose (italic font 
for variables, LaTeX cares concerning proper spaces, etc.).


When I was writing docs containing math, I had PDF (earlier DVI or PS) 
viewer window open along with LaTeX sources, so I could read formatted 
text. Anyway that time math in WYSIWYG was rather ugly (maybe besides 
texmacs), required heavy mouse work, and such editors had various 
problems with more or less complex documents that were easier for me to 
solve in LaTeX. That is why I never had expectation that source document 
should look like formatted one. Editing of sufficiently complex 
equations in LaTeX is not always convenient though.

Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Ihor Radchenko]

Timothy  writes:

> p.s. I’m marking this as a patch on the tracker, since it is one :P

This is not a real patch. I just separated changes I made in
org-element.el. Other changes include cache support across Org code and
tests. In total it looks roughly like:

12 files changed, 2584 insertions(+), 1140 deletions(-)

However, I did not directly base the patch on master, but rather on
(hopefully-to-be-merged-at-some-point org-fold branch :'/). I am not too
interested in porting the patch onto master. At least not until I get
feedback on parser and API changes.

> As someone who tangles massive literate config this sounds like it could make
> quite a noticeable improvement. To test this, do I need to do anything more 
> than
> just apply your patch?

Applying the patch will not work. As I said, it is mostly for reference
to show the changes to parser and API. If you want to test it, you can
use https://github.com/yantar92/org. That repo includes the org-fold
branch and the new cache implementation.

Best,
Ihor

Re: [PATCH] Rename headline to heading

[Timothy]

Hi  André,

Sorry that you haven’t heard anything in a while. I’ve been hoping that Bastien
or Nicolas might have been able to take a look at this and give their thoughts,
but unfortunately judging from their recent activity they both seem to be quite
busy as of late. I dream of the day when Org could actually employ a full-time
maintainer via opencollective (or similar).

In the meantime, I’ve flagged this message in my own mail client, and it appears
on  so you can at least be sure that this won’t be
forgotten about.

> I’m still waiting for the FSF to send me back my form signed.  I’ve sent
> it on the 31st of July.

Could you let us know if the FSF have got back to you on this?

All the best,
Timothy

Re: [feature proposal] Headline caching via org-element-cache = up to 2.5x performance boost

[Timothy]

Hi  Ihor,

I’ve just read through your description, and this sounds very promising! Many
thanks for going to the effort of tracking down this performance issue and
/actually making a patch to address it/.

As someone who tangles massive literate config this sounds like it could make
quite a noticeable improvement. To test this, do I need to do anything more than
just apply your patch?

> I would like to propose adding support of storing headlines in
> org-element-cache.
>
> Currently, org-element-cache only stores elements within individual
> sections. Storing headlines in cache would open various possibilities to
> improve Org performance: tag inheritance, property inheritance, category
> queries, id lookup, refile targets, agenda views, etc could all make use
> of cache.
>
> I am not proposing a mere idea, but have an actual working (WIP) code
> in: . Also, I am attaching a reference
> patch for org-element.el (the actual branch contains more changes).

All the best,
Timothy

p.s. I’m marking this as a patch on the tracker, since it is one :P

Re: publishing: no default publishing function, or symbol is not defined

[Yasushi SHOJI]

Hi Chris,

On Sun, Jun 20, 2021 at 3:30 AM Christopher W. Ryan via General
discussions about Org-mode.  wrote:
> But is there not a default publishing action, that requires no explicit
> :publishing-function statement? This part of the documentation says
> there is:
>
> https://orgmode.org/manual/Publishing-action.html#Publishing-action

I just encountered the exact problem.  The attached patch fixed it for
me.  Would you mind testing it?

ps. I've dug a bit in the commit history but I couldn't find any evidence that
we've ever supported this default behaviour at least with the current exporter.

Nicolas, if that's true, should we change the documentation instead?

Best,
-- 
   yashi
From 2fdf67b4ddfac97acb2b685957b6e4ca26474fb4 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI 
Date: Sun, 19 Sep 2021 18:56:19 +0900
Subject: [PATCH] ox-publish: Set default transformation

As documented in Org Manual, we should have the default transformation
function set to org-html-publish-to-html.

Signed-off-by: Yasushi SHOJI 
---
 lisp/ox-publish.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-publish.el b/lisp/ox-publish.el
index c25dd5473..99b1dca81 100644
--- a/lisp/ox-publish.el
+++ b/lisp/ox-publish.el
@@ -617,7 +617,8 @@ files, when entire projects are published (see
 			  (abbreviate-file-name filename
 	 (project-plist (cdr project))
 	 (publishing-function
-	  (pcase (org-publish-property :publishing-function project)
+	  (pcase (org-publish-property :publishing-function project
+   'org-html-publish-to-html)
 	(`nil (user-error "No publishing function chosen"))
 	((and f (pred listp)) f)
 	(f (list f
-- 
2.33.0

Git repository status

[Yasushi SHOJI]

Hi,

It seems like we are transitioning from code.orgmode.org to
git.savannah.gnu.org, but still not synced?

Which branch, gnu.org/main or orgmode.org/master, should I make patches against?

Best,
--
yashi