How to export to the simplest possible HTML?

[Marcin Borkowski]

Hello everyone,

I'd like to export an Org buffer (or portion of it) to the simplest HTML
possible, prgrammatically.  For example, I only want the body, I don't
want any generated IDs, and I don't want the ToC.  I tried this:

(org-html-export-as-html nil nil nil t '(org-export-with-toc nil))

but the ToC still appears in the output.  Also, I'd prefer to do it
a bit "less interactively" - for example, setting the current buffer to
the one with export results is unnecessary for me, since I'm going to
call my exporting function in a loop over many elements.  I tried

(org-export-with-backend 'html (org-element-at-point (point)))

but it errored out:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  org-html-headline((headline (:raw-value ...)) ...)
  org-export-with-backend(html (headline (:raw-value ...)))

I also want to supply my custom formatting for italics & friends, so
that

This is /italic/.

can become e.g.

This is italic.

I'm considering writing a custom (derived) export backend, but maybe
that is an overkill?  Any ideas?

TIA,

-- 
Marcin Borkowski
http://mbork.pl

Re: HTML export meta tag

[Scott Randby]

On 5/29/23 16:37, Timothy wrote:

Hi Scott,


Just to give some support to my request, the HTML standard
() says this:
“Then, if the element is one of the void elements, or if the element is a
foreign element, then there may be a single U+002F SOLIDUS character (/), which
on foreign elements marks the start tag as self-closing. On void elements, it
does not mark the start tag as self-closing but instead is unnecessary and has
no effect of any kind. For such void elements, it should be used only with
caution — especially since, if directly preceded by an unquoted attribute value,
it becomes part of the attribute value rather than being discarded by the
parser.”


The things is the ox-html exporter currently tries to (mostly) support XHTML,
which as I understand requires the self-closing slash.

I think what’s really needed is an HTML export implementation that can more
easily support different “modes” of export, but somebody needs to work on that
.


Okay, but when I try to validate my page as XHTML, I get numerous errors that 
would be inconvenient to fix especially since I'm only interested in obtaining 
valid HTML. What I think I'll do is to edit the org-html--build-meta-entry 
function in my ox-html.el file to eliminate the trailing slash. I'll just have 
to remember to do that every time I upgrade Org.

Scott

Re: HTML export meta tag

[Timothy]

Hi Scott,

> Just to give some support to my request, the HTML standard
> () says this:
> “Then, if the element is one of the void elements, or if the element is a
> foreign element, then there may be a single U+002F SOLIDUS character (/), 
> which
> on foreign elements marks the start tag as self-closing. On void elements, it
> does not mark the start tag as self-closing but instead is unnecessary and has
> no effect of any kind. For such void elements, it should be used only with
> caution — especially since, if directly preceded by an unquoted attribute 
> value,
> it becomes part of the attribute value rather than being discarded by the
> parser.”

The things is the ox-html exporter currently tries to (mostly) support XHTML,
which as I understand requires the self-closing slash.

I think what’s really needed is an HTML export implementation that can more
easily support different “modes” of export, but somebody needs to work on that
.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: HTML export meta tag

[Scott Randby]

On 5/29/23 14:07, Ihor Radchenko wrote:

Scott Randby  writes:




This did not happen when I used Org 9.4.6:



I wouldn't care about this change, but when I validate the page code 
(https://validator.w3.org/) I get the following: "Info: Trailing slash on void 
elements has no effect and interacts badly with unquoted attribute values."


Timothy, may you take a look?


Just to give some support to my request, the HTML standard 
(https://html.spec.whatwg.org/multipage/syntax.html#start-tags) says this: "Then, if 
the element is one of the void elements, or if the element is a foreign element, then 
there may be a single U+002F SOLIDUS character (/), which on foreign elements marks the 
start tag as self-closing. On void elements, it does not mark the start tag as 
self-closing but instead is unnecessary and has no effect of any kind. For such void 
elements, it should be used only with caution — especially since, if directly preceded by 
an unquoted attribute value, it becomes part of the attribute value rather than being 
discarded by the parser."

Scott

Re: HTML export meta tag

[Ihor Radchenko]

Scott Randby  writes:

> 
>
> This did not happen when I used Org 9.4.6:
>
> 
>
> I wouldn't care about this change, but when I validate the page code 
> (https://validator.w3.org/) I get the following: "Info: Trailing slash on 
> void elements has no effect and interacts badly with unquoted attribute 
> values."

Timothy, may you take a look?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

HTML export meta tag

[Scott Randby]

Hello,

When I export to HTML using Org 9.6.6, there is a /> closing the meta tag:



This did not happen when I used Org 9.4.6:



I wouldn't care about this change, but when I validate the page code 
(https://validator.w3.org/) I get the following: "Info: Trailing slash on void 
elements has no effect and interacts badly with unquoted attribute values."

The documentation I've seen states that the code without the trailing slash is 
the proper code. I request that the org-html--build-meta-entry function in 
ox-html.el be changed to eliminate the trailing slash.

Scott Randby

Re: [BUG] wrong-type-argument syntax-table-p "Syntax table including \"@\" and \"_\" as word constituents.

[Daniel Clemente]

It works now. Thanks!

On Mon, 29 May 2023 at 08:34, Ihor Radchenko  wrote:

> Daniel Clemente  writes:
>
> >   there was a recent change to how the tags table is initialized. I think
> > that as a side effect, some tag functions like org-tags-expand don't work
> > unless you open an org-mode buffer first. I have a small bash script that
> > exports my agenda; right in the beginning (before opening any org-mode
> > file) it collects some data by calling org-map-entries. org-map-entries
> > needs org-tags-expand, which now fails because the syntax table hasn't
> been
> > initialized yet.
> >
> > Minimal case to reproduce this:
>
> Thanks for reporting!
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=24ed8b204
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [BUG] lisp/org-eldoc.el: Eldoc does not work in org source blocks

[Bruno Cardoso]

Sure, fair enough. I am aware this is just a workaround, not an actual 
solution. Thanks!

Bruno.


On 2023-05-29, 07:42 +, Ihor Radchenko  wrote:

> Bruno Cardoso  writes:
>
>> The Eldoc interface `eldoc-print-current-symbol-info' works everywhere just 
>> fine for me (Emacs
>> 28.2), but it does not work inside org source blocks for elisp code. Yet, 
>> reverting to the
>> obsolete `elisp-eldoc-documentation-function' in org-eldoc's
>> `org-eldoc-documentation-function' works (see below). I tested it both in my 
>> own config and
>> "emacs -Q" with same results.
>
> Note that org-eldoc is not a part of Org. We only provide a minimal
> maintenance until someone takes over it. See
> https://orgmode.org/worg/org-orphanage.html
>
> Your change to obsolete function is questionable. So, this change is at
> least non-trivial. Unfortunately, this falls beyond the level of
> maintenance we can offer here.
>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: Unable to install from elpa

[Max Nikulin]

On 26/05/2023 15:23, Ihor Radchenko wrote:

Max Nikulin writes:


I have realized that the command is specified in the README.org file, so
it is mentioned twice on https://elpa.gnu.org/packages/org.html



However prior to Emacs-29.1 built-in packages are filtered-out from
completion list and ignored by non-interactive command
...
Should `list-packages' recipe be used in the README.org file instead?


The first instance of M-x package-install  org  comes from
ELPA itself. Considering that ELPA is targeting various Emacs versions,
it should probably be corrected there first.


Generally agree, but I am skeptical concerning changes in ELPA since 
only minority of packages are affected.



The second instance in README.org may then be altered according to what
ELPA devs do.


Users may open README.org outside of ELPA. "To install a more recent 
version..." is is not enough even for coming Emacs-29 since the default 
value for `package-install-upgrade-built-in' is nil.


Another pitfall with install instruction in an .org file is that if the 
file is opened in Emacs < 29 then package.el generates mixed-versions 
.elc files. A precaution is necessary that `list-packages' should be run 
in a clean emacs session, not the one with README.org.

Re: [PATCH] org-id: implement arbitrary cross-file references

[Ihor Radchenko]

Sergei Kosyrev  writes:

> Fair enough -- I'm open to sign the FSF copyright assignment.

Thanks for your interest to contribute to Org mode!
See https://orgmode.org/worg/org-contribute.html#copyright for the
details how to get started with FSF copyright assignment.

FSF generally replies within 5 working days. If not, let us know.

> +#+BEGIN_src org
> +#+TBLFM: $2='(identity remote(file:./org-wile-with-tables.org,@@#$Value))
> +#+END_src

Would it not be more reasonable to allow generic file links here? Like
in 4.4 External Links section of the manual:

 ‘file:projects.org’
 ‘file:projects.org::some words’ (text search)(1)
 ‘file:projects.org::*task title’ (headline search)
 ‘file:projects.org::#custom-id’ (headline search)

> +(defun org-id-parse-remote-table-ref (refstr)
> +  (save-match-data
> +(when-let* ((match (string-match "^file:\\([^:]+\\)\\(\\|:.+\\)$" 
> refstr))
> +(m1 (match-string 1 refstr))
> +(m2 (match-string 2 refstr))
> +(filename (cl-remove-if (lambda (c) (member c '(40 41)))
> +(org-table-formula-substitute-names 
> m1)))
> +(table-name (org-table-formula-substitute-names m2)))
> +  (list filename table-name

The format of file:... has nothing at all to do with org-id.el library.
You should instead modify how org-table.el parses remote references
instead of abusing ID resolution mechanisms.

> + (let* ((ident (cl-subseq table-id 1))
> +(id-match (search-forward (concat 
> "#+NAME: " ident) nil t)))
> +   (unless id-match
> + (error "org-id-find-remote: file \"%s\" has 
> no table with NAME \"%s\"." file ident))

Be aware that not all the things with #+NAME in Org files are tables.
You can use `org-element-at-point' to check element type you are looking at.

> -   org-table-column-names org-table-column-name-regexp
> +  org-table-column-names (org-table-column-name-regexp 
> org-table-column-name-regexp)

I fail to see the reason behind this change. May you explain why you had
to protect the global value here?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] wrong-type-argument syntax-table-p "Syntax table including \"@\" and \"_\" as word constituents.

[Ihor Radchenko]

Daniel Clemente  writes:

>   there was a recent change to how the tags table is initialized. I think
> that as a side effect, some tag functions like org-tags-expand don't work
> unless you open an org-mode buffer first. I have a small bash script that
> exports my agenda; right in the beginning (before opening any org-mode
> file) it collects some data by calling org-map-entries. org-map-entries
> needs org-tags-expand, which now fails because the syntax table hasn't been
> initialized yet.
>
> Minimal case to reproduce this:

Thanks for reporting!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=24ed8b204

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-mode for package documentation

[Ihor Radchenko]

Philip Kaludercic  writes:

>> We discussed possible syntax of inline custom markup to be added. See
>> https://orgmode.org/list/87bkqx4jyg.fsf@localhost Someone is to go ahead
>> and try to implement it. It might be me in future, but I am prioritizing
>> working on some other new features in Org for now.
>
> My general question is what advantage this would provide over just using
> TeXinfo in the first place, if the required complexity of the markup has
> to be the same as for TeXinfo in the first place?

Check out the original thread where RMS officially suggested that Org
can be used instead of texinfo.

In short, Org provides much more configurable export output. You can
customize it using Elisp or within Org document itself. You can generate
parts of documentation using output of src blocks. You can fine-tune
specific export output formats using inline export blocks. etc ...

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Preserving leading zeros

[Ihor Radchenko]

William Denton  writes:

> I'm thinking about moving a personal library catalogue system into Org.  This 
> would involve ISBNs, and when ISBNs had 10 digits some would have leading 
> zeros. 
> It turns out leading zeros are removed when something looks like a number.
>
> #+name:isbn
> | 0006145396 |
>
> #+begin_src shell :results output :var string=isbn
> echo $string
> #+end_src
>
> #+RESULTS:
> : 6145396

Try 
#+name:isbn
| "0006145396" |

Currently, Org unconditionally converts everything that looks like a
number into numbers using `read'.

We could, in theory, allow passing ;L flags or similar when reading
table reference (see 3.5.2 Formula syntax for Calc). Feel free to write
a feature request if you think that it might be useful.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-mode for package documentation

[Philip Kaludercic]

Ihor Radchenko  writes:

> Payas Relekar  writes:
>
>> IIRC, Richard Stallman said he'd be amenable to it, _provided that_ Org
>> fulfilled all the requisite functionality from Texinfo.
>
> Correct. We need to add more flexible markup. The idea was to add
> something similar to special blocks, but inline. Currently, ox-texinfo
> is approaching the extended markup with macros. See doc/doc-setup.org.
>
>> Ihor (org maintainer) was also receptive, but I don't remember if/how
>> much progress happened towards the goal.
>
> We discussed possible syntax of inline custom markup to be added. See
> https://orgmode.org/list/87bkqx4jyg.fsf@localhost Someone is to go ahead
> and try to implement it. It might be me in future, but I am prioritizing
> working on some other new features in Org for now.

My general question is what advantage this would provide over just using
TeXinfo in the first place, if the required complexity of the markup has
to be the same as for TeXinfo in the first place?

Re: org-mode for package documentation

[Ihor Radchenko]

Payas Relekar  writes:

> IIRC, Richard Stallman said he'd be amenable to it, _provided that_ Org
> fulfilled all the requisite functionality from Texinfo.

Correct. We need to add more flexible markup. The idea was to add
something similar to special blocks, but inline. Currently, ox-texinfo
is approaching the extended markup with macros. See doc/doc-setup.org.

> Ihor (org maintainer) was also receptive, but I don't remember if/how
> much progress happened towards the goal.

We discussed possible syntax of inline custom markup to be added. See
https://orgmode.org/list/87bkqx4jyg.fsf@localhost Someone is to go ahead
and try to implement it. It might be me in future, but I am prioritizing
working on some other new features in Org for now.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Editing begin_verse using edit special

[Ihor Radchenko]

Bernt Hansen  writes:

> I use #+begin_verse
> For certain blocks in my org files 
>
> Is there a way to allow C-c ‘ to edit this block in fundamental mode?

Patches for `org-edit-special' are welcome!

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] lisp/org-eldoc.el: Eldoc does not work in org source blocks

[Ihor Radchenko]

Bruno Cardoso  writes:

> The Eldoc interface `eldoc-print-current-symbol-info' works everywhere just 
> fine for me (Emacs
> 28.2), but it does not work inside org source blocks for elisp code. Yet, 
> reverting to the
> obsolete `elisp-eldoc-documentation-function' in org-eldoc's
> `org-eldoc-documentation-function' works (see below). I tested it both in my 
> own config and
> "emacs -Q" with same results.

Note that org-eldoc is not a part of Org. We only provide a minimal
maintenance until someone takes over it. See
https://orgmode.org/worg/org-orphanage.html

Your change to obsolete function is questionable. So, this change is at
least non-trivial. Unfortunately, this falls beyond the level of
maintenance we can offer here.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-fold-core-region error: missing SPEC

[Ihor Radchenko]

420actionun...@gmail.com writes:

> I set a breakpoint at the beginning of function
> ORG-FOLD-CORE-GET-FOLDING-SPEC-FROM-ALIAS. It runs quite a few times
> successfully. Every time the input argument SPEC-OR-ALIAS has one of
> these values: 'ORG-FOLD-VISIBLE or 'ORG-FOLD-HIDDEN. But at some point
> the function runs with a value of 'DRAWER, and that's when it returns
> NIL and the error is thrown higher up in ORG-FOLD-CORE-REGION when it
> explicitly tests for a NIL result.
>
> ORG-FOLD-CORE--SPEC-SYMBOLS has the value:
>
> ((HIDDEN . ORG-FOLD-HIDDEN) (:ALIAS . ORG-FOLD-HIDDEN)
> (ORG-FOLD-HIDDEN . ORG-FOLD-HIDDEN) (VISIBLE . ORG-FOLD-VISIBLE)
> (:ALIAS . ORG-FOLD-VISIBLE) (ORG-FOLD-VISIBLE . ORG-FOLD-VISIBLE))
>
> But when a drawer wants to be added we call ORG-FOLD-REGION like this:
>
> (ORG-FOLD-REGION (LINE-END-POSITION 0) (POINT) T (IF (EQ
> ORG-FOLD-CORE-STYLE 'TEXT-PROPERTIES) 'DRAWER 'OUTLINE))

This implies that the buffer where `org-fold-region' is called is not in
Org mode or did not have Org property initialized.
`org-insert-property-drawer' expects the buffer to be in Org mode.

> I'm still unclear on how ORG-FOLD-CORE--SPEC-SYMBOLS gets set with
> this alist. Is there is an opportunity for callers to customize it?
> What would be appropriate values to add for 'DRAWER and 'OUTLINE?

The answer to this question is described in the top commentary of
org-fold-core.el. Also, see `org-fold-initialize'.

However, the problem is not just with folding. As I said,
`org-insert-property-drawer' expect the major mode to be Org mode. Your
backtrace implies that either the buffer is not in Org mode or something
strange was done when initializing Org. Either way, random failures may
happen - Org mode APIS, unless explicitly stated, expect major mode to
be Org.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at