Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Ihor Radchenko]

Bastien Guerry  writes:

> Until Org maintainers get an email confirmation for when a copyright
> assignment process is done, we can simply suggest contributors to wait
> a month before pinging the copyright clerk and to CC Org maintainers
> when doing so.  WDYT?

Sounds reasonable.
It is a longer period compared to 5 business days mentioned in
https://www.gnu.org/prep/maintain/maintain.html, but the copyright clerk
is just a single guy taking care about all the requests...

When the contributor emails the form to the FSF, the FSF sends per an
electronic (usually PDF) copy of the assignment. This, or whatever
response is required, should happen within five business days of the
initial request. If no reply from the FSF comes after that time, please
send a reminder. If there is still no response after an additional week,
please write to maintain...@gnu.org about it.

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

Re: Presenting Hyperorg version 0.1.0: The Org to HTML Converter

[Ihor Radchenko]

 writes:

> I will consider your points and take them into account.

Thanks!

> On 2024-03-24 14:40 Ihor Radchenko  wrote:
>> If it is an option, it would be nice if you upstreamed your additions
>> to orgparse. This way, we can get a better Python-based Org parser for
>> everyone's benefit.
>
> The code is free. The orgparse maintainer is free to re-use it of
> course. On the other hand in the long run I will consider to separate
> my parsing code into an extra package. But currently it is to unstable
> and do support only a small subset of all org(roam) features.

It would help if you notify orgparse maintainer once your code gets more
stable ;)

>> I see. FYI, it is a bug to throw an error when parsing Org document.
>> Any kind of text file is a valid Org document. There is no notion of
>> invalid syntax in Org markup.
>
> You mean throw an error is a bug because it is not possible to
> write invalid org documents?

Yup.

> I am not convinced yet. But I am open to it and willing to learn.
>
> Even org-html-export* itself do throw errors and stop processing when
> there are unknown orgids.

This has nothing to do with the parser.
Erring on unknown ids/paths is a special _feature_ of Org exporter
controlled by `org-export-with-broken-links' variable.
`org-export-with-broken-links' is nil by default simply because (1) Org
export has no sensible way to export links that point to nowhere; (2)
Such links are generally unwanted and need to be corrected by the user
in many use cases.

> What is about an inconsistent block?
>
> #begin_src
> foobar
> #end_example

With your example, the following AST will be produced by Org parser
(`org-element-parse-buffer'):

(org-data
 (section
  (paragraph
   "#+begin" (subscript "src")
   "\nfoobar\n#+end" (subscript "example")
   "\n"))

>> > Other things are "invalid" links, e.g. unknown orgids, unknown roam 
>> > links, unsupported "link kinds" ("protocols" in org syntax?; e.g. 
>> > "inkscape:").
>> 
>> In Org terminology, we call these "broken" links.
>> "link kinds" are link "types".
>
> The term "types" is to broad and conflicts with Pythons in build
> functions. ;) That is the main reason why I used "kind". On the other
> hand the org syntax reference IMHO also use the term "protocol".

Syntax reference says the following:

PROTOCOL
A string which is one of the link type strings in org-link-parameters
 ^

We also always say "link type" in the manual.

I just made things more explicit, replacing PROTOCOL with LINKTYPE:
https://git.sr.ht/~bzg/worg/commit/0634eed3

>> Generally, part of the "Benefits" section is a bit hand-wavy. I
>> recommend using more clear statements. Otherwise, it is not clear what
>> exactly the benefits are.
>
> Again. It is also not "clear" for me. There are benefits just for
> myself as an low-level-Emacs-and-org-user, someone who get headaches
> reading Lisp code and feeling very comfortable using Python. In short:
> My opinion is very subjective. And I don't have enough experience to
> compare my tool to others.
> I tried to make this point clear in my benefits section. And this is
> also the reason why there was no benefits section in the first place
> because I wasn't clear enough about what to write in there.
>
> Maybe I should rephrase the section to "Benefits and design goals".

Maybe something like "Motivation"; to emphasize that the listed points
are your subjective reasons to write the exporter.

Still, it would be useful to have an objective comparison; if you want
to get others to use your package. Having a clear list of reasons why
your package is better is important then. (I implicitly assumed that you
are interested to attract users after you announced the package in
public)

>> 1. Drop "Fairly resilient when dealing with parser issues."
>
> Why? The "design goal" is to process all nodes no matter how
> bad/invalid they are.

Simply because Org mode has no notion of invalid nodes.
So, this kind of goal sounds very strange for me.

>> 2. Reword "Fairly resilient managing dead and problematic links which
>> are a common phenomenon when working with a constantly evolving
>> Zettelkasten or personal wiki." And instead clearly explain how broken
>> links are exported.
>
> I don't want to blow up the text. Not sure what you expect here. The
> node is exported as HTML but the link is colorful highlighted and a
> tooltip explaining the problem is added.

Is it something akin when `org-export-with-broken-links' is set to 'mark?

>> 4. Drop "Adhers to World Wide Web Consortium (W3C) standards for HTML5
>>and CSS ()." Most other blog exporters for Org mode
>>adhere to standards. And those that are not are probably out of
>>interest for the purposes of comparison.
>
> Why?

If Org export does not adhere to standards, it is a bug, it should, and
it will be fixed. And some other blog generators that do not use Org
export (like Hugo) do conform to the standards, AFAIK.

> Btw: Even code generated 

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Bastien Guerry]

Until Org maintainers get an email confirmation for when a copyright
assignment process is done, we can simply suggest contributors to wait
a month before pinging the copyright clerk and to CC Org maintainers
when doing so.  WDYT?

-- 
 Bastien Guerry

Re: [ANN] Emergency bugfix release: Org mode 9.6.23

[Bastien Guerry]

Thanks a lot for your work on this!

-- 
 Bastien Guerry

[ANN] Emergency bugfix release: Org mode 9.6.23

[Ihor Radchenko]

Dear all,

I just released Org mode 9.6.23 that fixes several critical
vulnerabilities. The release is coordinated with emergency Emacs 29.3
release
(https://lists.gnu.org/archive/html/info-gnu/2024-03/msg5.html).

Please upgrade your Org mode *and* Emacs ASAP.

The vulnerabilities involve arbitrary Elisp and LaTeX evaluation when
previewing attachments in Emacs or when opening third-party Org files.

The arbitrary Elisp evaluation is fixed by this release.

The fix for LaTeX evaluation requires Emacs 29.3 and will not work for
the earlier Emacs versions. If upgrading Emacs is not viable, as a
workaround, you can set `org-preview-latex-default-process' to 'verbatim
- this will disable LaTeX previews and avoid the vulnerability.

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

Re: Presenting Hyperorg version 0.1.0: The Org to HTML Converter

[c.buhtz]

Dear Ihor,

I will consider your points and take them into account.

On 2024-03-24 14:40 Ihor Radchenko  wrote:
> If it is an option, it would be nice if you upstreamed your additions
> to orgparse. This way, we can get a better Python-based Org parser for
> everyone's benefit.

The code is free. The orgparse maintainer is free to re-use it of
course. On the other hand in the long run I will consider to separate
my parsing code into an extra package. But currently it is to unstable
and do support only a small subset of all org(roam) features.

> > Orgparse do throw exceptions e.g. UnicodeDecodeError or when
> > timestamps are invalid. Hyperorg catch that exceptions and go on
> > with the next node without interrupting the whole process.
> 
> I see. FYI, it is a bug to throw an error when parsing Org document.
> Any kind of text file is a valid Org document. There is no notion of
> invalid syntax in Org markup.

You mean throw an error is a bug because it is not possible to
write invalid org documents?

I am not convinced yet. But I am open to it and willing to learn.

Even org-html-export* itself do throw errors and stop processing when
there are unknown orgids.

What is about an inconsistent block?

#begin_src
foobar
#end_example

> > Other things are "invalid" links, e.g. unknown orgids, unknown roam 
> > links, unsupported "link kinds" ("protocols" in org syntax?; e.g. 
> > "inkscape:").
> 
> In Org terminology, we call these "broken" links.
> "link kinds" are link "types".

The term "types" is to broad and conflicts with Pythons in build
functions. ;) That is the main reason why I used "kind". On the other
hand the org syntax reference IMHO also use the term "protocol".

> Do you mean that orgparse throws an error when encountering tables?

No. I was referring to Hyperorg. OrgParse do not parse any org content
except headings and properties. Nearly everything else is unparsed and
given raw to my.

> Generally, part of the "Benefits" section is a bit hand-wavy. I
> recommend using more clear statements. Otherwise, it is not clear what
> exactly the benefits are.

Again. It is also not "clear" for me. There are benefits just for
myself as an low-level-Emacs-and-org-user, someone who get headaches
reading Lisp code and feeling very comfortable using Python. In short:
My opinion is very subjective. And I don't have enough experience to
compare my tool to others.
I tried to make this point clear in my benefits section. And this is
also the reason why there was no benefits section in the first place
because I wasn't clear enough about what to write in there.

Maybe I should rephrase the section to "Benefits and design goals".

> 1. Drop "Fairly resilient when dealing with parser issues."

Why? The "design goal" is to process all nodes no matter how
bad/invalid they are.

> 2. Reword "Fairly resilient managing dead and problematic links which
> are a common phenomenon when working with a constantly evolving
> Zettelkasten or personal wiki." And instead clearly explain how broken
> links are exported.

I don't want to blow up the text. Not sure what you expect here. The
node is exported as HTML but the link is colorful highlighted and a
tooltip explaining the problem is added.

> 4. Drop "Adhers to World Wide Web Consortium (W3C) standards for HTML5
>and CSS ()." Most other blog exporters for Org mode
>adhere to standards. And those that are not are probably out of
>interest for the purposes of comparison.

Why?

Btw: Even code generated by org-html-export* (XHTML 1.0 Strict) give
errors on W3C. e.g. "type" attribute is missing in 

Re: Presenting Hyperorg version 0.1.0: The Org to HTML Converter

[Ihor Radchenko]

c.bu...@posteo.jp writes:

> Am 24.03.2024 14:31 schrieb Ihor Radchenko:
>> Hmm. I thought that you implemented Org parser in python from scratch.
>> Now, I see that you are using orgparse.
>
> The orgparse package do not parse much of on org file. IT does parse the 
> meta infos (property drawers, etc) but not the content of an orgfile. In 
> the long run I might replay orgparse to reduce dependencies.
>
> Beside orgparse yes I implement an org parser.

Thanks for the  clarification.
If it is an option, it would be nice if you upstreamed your additions to
orgparse. This way, we can get a better Python-based Org parser for
everyone's benefit.

>> Wondering what you are referring to when mentioning "resilient when
>> dealing with parser issues".
>
> Orgparse do throw exceptions e.g. UnicodeDecodeError or when timestamps 
> are invalid. Hyperorg catch that exceptions and go on with the next node 
> without interrupting the whole process.

I see. FYI, it is a bug to throw an error when parsing Org document. Any
kind of text file is a valid Org document. There is no notion of invalid
syntax in Org markup.

> Other things are "invalid" links, e.g. unknown orgids, unknown roam 
> links, unsupported "link kinds" ("protocols" in org syntax?; e.g. 
> "inkscape:").

In Org terminology, we call these "broken" links.
"link kinds" are link "types".

> Additionally there are multiple fancy but not supported org features 
> (e.g. tables) currently not supported. Hyperorg shouldn't stop or crash 
> at this point.

Do you mean that orgparse throws an error when encountering tables?
If so, it is slightly odd to see this implementation detail listed in
"Benefits".

Generally, part of the "Benefits" section is a bit hand-wavy. I
recommend using more clear statements. Otherwise, it is not clear what
exactly the benefits are.

I'd suggest the following:

1. Drop "Fairly resilient when dealing with parser issues."
2. Reword "Fairly resilient managing dead and problematic links which
are a common phenomenon when working with a constantly evolving
Zettelkasten or personal wiki." And instead clearly explain how broken
links are exported.
3. Supply "Generates a comprehensive index of all nodes." with a
   screenshot
4. Drop "Adhers to World Wide Web Consortium (W3C) standards for HTML5
   and CSS ()." Most other blog exporters for Org mode
   adhere to standards. And those that are not are probably out of
   interest for the purposes of comparison.
5. Maybe mention the "tag cloud" visible in the example screenshot (btw,
   the screenshot is not very sexy; compare it with something like
   https://one.tonyaldon.com/).

>> index can be produced with minimal configuration via ox-publish.
>
> "minimal" is a subjective term here. Again I don't blame the tools or 
> the Emacs universe.
> But for me it is not even minimal to get ox-publish run in the first 
> place. Not speaking about further modifications, e.g. an index.

Clear.

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

Re: Presenting Hyperorg version 0.1.0: The Org to HTML Converter

[c . buhtz]

Dear Ihor,

thanks for your reply.

Am 24.03.2024 14:31 schrieb Ihor Radchenko:

Hmm. I thought that you implemented Org parser in python from scratch.
Now, I see that you are using orgparse.


The orgparse package do not parse much of on org file. IT does parse the 
meta infos (property drawers, etc) but not the content of an orgfile. In 
the long run I might replay orgparse to reduce dependencies.


Beside orgparse yes I implement an org parser.


Wondering what you are referring to when mentioning "resilient when
dealing with parser issues".


Orgparse do throw exceptions e.g. UnicodeDecodeError or when timestamps 
are invalid. Hyperorg catch that exceptions and go on with the next node 
without interrupting the whole process.
Other things are "invalid" links, e.g. unknown orgids, unknown roam 
links, unsupported "link kinds" ("protocols" in org syntax?; e.g. 
"inkscape:").
Additionally there are multiple fancy but not supported org features 
(e.g. tables) currently not supported. Hyperorg shouldn't stop or crash 
at this point.



index can be produced with minimal configuration via ox-publish.


"minimal" is a subjective term here. Again I don't blame the tools or 
the Emacs universe.
But for me it is not even minimal to get ox-publish run in the first 
place. Not speaking about further modifications, e.g. an index.


Emacs, Lisp and its "documentation" is a special thing not everybody can 
or want to handle. I would have to invest so much resources into basics 
like Lisp just to understand the documentation in a way that I would be 
able to modify the publishing feature in a (for me) satisfying way. I am 
the problem not Emacs and Co. ;)


Kind
Christian Buhtz

Re: Presenting Hyperorg version 0.1.0: The Org to HTML Converter

[Ihor Radchenko]

 writes:

> On 2024-03-23 13:58 Ihor Radchenko  wrote:
>> Although I am actually more interested in other questions -
>> why custom parser and what is tailored for zettelkasten.
>
> What do you mean by "custom parser"?

Hmm. I thought that you implemented Org parser in python from scratch.
Now, I see that you are using orgparse.

Wondering what you are referring to when mentioning "resilient when
dealing with parser issues".

> Zettelkasten? Hyperorg handles the links between nodes out of the box
> including the backlinks. It also creates an index (nodes sorted by
> title, tags, etc pp).
>
> Of course with Emacs is everything possible even Coffee making. But the
> difference are the resources you have to invest into configure it. This
> is much even if you know Lisp.

index can be produced with minimal configuration via ox-publish.
Backlinks are certainly a novelty. I do not recall Org publishing
systems that produce backlinks automatically (not via dynamic block).

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

Re: [BUG] Prompt appears in async shell results

[Matt]

  On Sat, 23 Mar 2024 15:16:37 +0100  Ihor Radchenko  wrote --- 
 
 > Yup. Tests are passing on my side as well, and I had no comments.
 > So, we are waiting for other interested users to test.
 > For at least a week, so that people who check the mailing list on
 > weekend have a chance to see the request.

Cool.

--
Matt Trzcinski
Emacs Org contributor (ob-shell)
Learn more about Org mode at https://orgmode.org
Support Org development at https://liberapay.com/org-mode

Re: [BUG] org-clock-sum: Wrong type argument: fixnump, nil [9.7-pre (release_9.6.22-1309-g8507ef @ /home/grfz/src/org-mode/lisp/)]

[Ihor Radchenko]

Gregor Zattler  writes:

> with point on the following frame for a clock table:
>
> #+BEGIN: clocktable :scope ("/home/absolute/path/file.org_archive")
> #+END:
> ...
> If instead I use a very fresh org-mode from main, specifically
>
> Org mode version 9.7-pre (release_9.6.22-1309-g8507ef @ 
> /home//src/org-mode/lisp/)
>
> like so:
>
> emacs -L ~/src/org-mode/lisp -L ~/src/org-mode/contrib/lisp -Q
>
> org-clock-report
>
> with point on said frame of a clock table produces
>
> Updating dynamic block ‘clocktable’ at line 13...
> org-clock-sum: Wrong type argument: fixnump, nil

What if you do the same starting from "make repro" in ~/src/org-mode ?
The backtrace should then appear rather than just an error line.
I would like to see that backtrace to understand what went wrong.

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

Re: [WORG] 2680e65 * org-maintenance.org (Copyright assignments): Minor improvements

[Ihor Radchenko]

Dear Adam, Bastien,

> +New contributors need to submit the 
> [[https://orgmode.org/request-assign-future.txt][form]] to the FSF.
> +#+begin_center
> ...
> +TODO: Get updated version of form from Emacs maintainers that includes the 
> line asking the secretary to send confirmation to interested parties (i.e. 
> the Org maintainers).
> +#+end_center

I think that we are not very accurate here.
According to
https://www.gnu.org/prep/maintain/maintain.html#Copyright-Papers:

   Once the conversation is under way and the contributor is ready for more
   details, you should send one of the templates that are found in the
   directory /gd/gnuorg/Copyright/; they are also available from the
   doc/Copyright/ directory of the gnulib project at
   https://savannah.gnu.org/projects/gnulib. This section explains which
   templates you should use in which circumstances. Please don’t use any of
   the templates except for those listed here, and please don’t change the
   wording.

We must use a specific form from a specific URL.

Also, about the changes to the FSF form that Stefan mentioned in
https://yhetil.org/emacs-devel/jwvh6hne6nv.fsf-monnier+em...@gnu.org/
It does not look like they are official yet. See
https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00060.html

> +The assignment process does not always go quickly; occasionally it may
> +get stuck or overlooked at the FSF.  The contact at the FSF for this
> +is: =copyright-clerk AT fsf DOT org=.  In rare cases, an inquiry from an
> +Org maintainer gets the process moving again.

I may be missing something, but the last sentence now reads like our
(Org maintainer's) inquiry rarely works.

The previous version is very different, IMHO:

> -Emails from the paper submitter have been ignored in the past, but an
> -email from the maintainers of Org mode has usually fixed such cases
> -within a few days.

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

Re: [bug] Smart quotes: confusion of apostrophe with second level quotes

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Anyway, I think a) your patch could be a major improvement;

Applied, onto main, after fixing another edge case with quotes spanning
across multiple markup objects.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=33503445e

> ... b) perhaps a
> brief note in the manual (I can send a tiny patch) should be added to
> warn of possible ambiguities, and possible solutions.

Yes, a patch clarifying what to do to force apostrophe would be welcome.

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

Re: [Worg] CSS improvements

[Dr. Arne Babenhauserheide]

Ihor Radchenko  writes:

> Adam Porter  writes:
>
>>> I am not sure if centered text should stand out.
>>> AFAIU, you want to add this style for the sole purpose of highlighting
>>
>> What is the purpose of centering text if not to make it stand out?
>
> To align text. I am not sure why anything more is necessary - it
> is certainly counter-intuitive for me that "center" means something more
> than just alignment.
>
> If you need extra highlighting, we may introduce a dedicated style and
> apply it via special block.

I defined a "kasten" block for my own page, maybe you can re-use that:

# ELISP
(add-to-list 'org-structure-template-alist '("k" 
"#+begin_kasten\n?\n#+end_kasten" "?"))

# ORG-MODE
# kasten-Environment for full-width boxed text.
#+latex_header: \definecolor{cream}{rgb}{1.0, 0.99, 0.82}
#+latex_header: \provideenvironment{kasten}% level0
#+latex_header: {\begin{tcolorbox}[colback=cream, sharp corners]%
#+latex_header: \medskip%
#+latex_header: }
#+latex_header: {\medskip\end{tcolorbox}%
#+latex_header: }

# CSS:
/* full-width boxed text */
.kasten {
color: #111;
text-align: justify;
clear: both;
border-top: 1px solid gray !important;
border-right: 0px none gray !important;
border-left: 0px none gray !important;
border-bottom: 1px solid gray !important;
background-color: #f6efca;
border-top: thin solid gray;
border-bottom: thin solid gray;
float: left;
width: 100%;
z-index: 1;
margin-top:20px;
margin-bottom:20px;
}

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


signature.asc
Description: PGP signature

Re: [PATCH] Run latex more than once for LaTeX src block evaluation

[Ihor Radchenko]

Max Nikulin  writes:

> On 22/03/2024 05:55, Michael wrote:
>> I have a small patch for `org-preview-latex-process-alist' making
>> the default setting for LaTeX source block evaluation be running
>> latex three times (instead of the current one).
>
> I suspect it may make the LaTeX preview feature unacceptably slow for 
> documents heavily loaded with math snippets. There was a proposal to use 
> LuaLaTeX instead of PdfLaTeX to provide better Unicode coverage, but it 
> was discarded due to significant slowdown.
>
> If it is true then it should not be active by default. It makes sense as 
> a user option, but I am unsure concerning required efforts.

Then, we may instead use latexmk - it will run latex as many times as
necessary.

Also, performance will be less problematic after Timothy and Karthik
merge their latex preview branch. (they may want to do measurements
though).

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

Re: [Worg] CSS improvements

[Ihor Radchenko]

Adam Porter  writes:

>> I am not sure if centered text should stand out.
>> AFAIU, you want to add this style for the sole purpose of highlighting
>
> What is the purpose of centering text if not to make it stand out?

To align text. I am not sure why anything more is necessary - it
is certainly counter-intuitive for me that "center" means something more
than just alignment.

If you need extra highlighting, we may introduce a dedicated style and
apply it via special block.

>> FYI, we usually do
>> 
>> : "Should I use one big Org file or many small ones?"
>> 
>> to make text stand out.
>
> Yes, but that makes it source code, which makes it monospaced, which is 
> not appropriate except for source code.

Agree.
Having some kind of style equivalent to beamer "alert" will be useful.

> Besides, the .org-center class is not even styled right now, so it isn't 
> even given a unique appearance on Worg right now.  So why not use it 
> this way?

Mostly because it is unexpected, as I described above.
I'd prefer to stick closer to the semantics and just apply alignment to
center blocks.

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

Re: [PATCH] Run latex more than once for LaTeX src block evaluation

[Max Nikulin]

On 22/03/2024 05:55, Michael wrote:

I have a small patch for `org-preview-latex-process-alist' making
the default setting for LaTeX source block evaluation be running
latex three times (instead of the current one).


I suspect it may make the LaTeX preview feature unacceptably slow for 
documents heavily loaded with math snippets. There was a proposal to use 
LuaLaTeX instead of PdfLaTeX to provide better Unicode coverage, but it 
was discarded due to significant slowdown.


If it is true then it should not be active by default. It makes sense as 
a user option, but I am unsure concerning required efforts.

Re: [Worg] CSS improvements

[Adam Porter]

On 3/23/24 09:49, Ihor Radchenko wrote:

Adam Porter  writes:


(@media all .org-center): Actually style this so that "#+begin_center"
blocks are centered and fit with the rest of the theme, allowing these
blocks to be used to make certain text stand out.


I am not sure if centered text should stand out.
AFAIU, you want to add this style for the sole purpose of highlighting


What is the purpose of centering text if not to make it stand out?


FYI, we usually do

: "Should I use one big Org file or many small ones?"

to make text stand out.


Yes, but that makes it source code, which makes it monospaced, which is 
not appropriate except for source code.


Besides, the .org-center class is not even styled right now, so it isn't 
even given a unique appearance on Worg right now.  So why not use it 
this way?