Re: No-description <> links

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> Ihor Radchenko  writes:
>
>> I think that we may need to introduce a customization for default link
>> description. Some backends hard-code the default description to
>> something non-trivial and some just use arbitrary fallback like ???
>> (ox-ascii), "No description" (ox-html), or "" (ox-latex).
>
> I wonder, why not export [[link]] to <> as "link" by default, if
> no description is given, as is the case with URLs, Elisp, and the
> like?

Yes, something like that.

The main problem is how to properly design
this - the current approach is that individual backends decide. And we
have no control over third-party backends...

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

Re: the opposite of the noexport tag

[Ihor Radchenko]

Uwe Brauer  writes:

>> This is not a correct format. Please, review the manual section I linked
>> to.
>
> So it should be 
> #+options: SELECT_TAGS: ("noexport")
> #+options: EXCLUDE_TAGS: ("export")
>
> Right?

No.
#+SELECT_TAGS: tag1 tag2 ...
Same for #+EXCLUDE_TAGS.

> I am wondering why it worked anyhow

By default, SELECT_TAGS is set to "export" tag and EXCLUDE_TAGS is set
to "noexport" tag.

>> (side note: this is odd to set selected tags to "noexport")
>
> So what to you propose instead, in order to achieve my goal:
>
> «To  export only the sections  that have the export tag and leave the
> ignore the others»

#+SELECT_TAGS: export
And then
* This section will be exported :export:
* This - will not
* This - neither :some_other_tag:

And you do not even need #+SELECT_TAGS if you use "export" tag - it is
already set like this by default.

So, it is enough to just put :export: tag as needed:

* This section will be exported :export:
* This - will not
* This - neither :some_other_tag:

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

Re: Bug with "BEAMER_OPT: shrink" and links

[Guillaume MULLER]

Hi,

Thanks for the follow up.

I found a similar issue in Beamer's GitHub issue and added my comment:
https://github.com/josephwright/beamer/issues/100#issuecomment-1731863334

Unfortunately, thanks to your follow up I just realized this issue was closed, 
so I opened a brand new one:
https://github.com/josephwright/beamer/issues/863

Have a nice day :)

--
Guillaume MULLER


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [BUG] [PATCH] Add yank-media and DND handler [9.6.7 (9.6.7-g6eb773 @ /home/viz/lib/emacs/straight/build/org/)]

[Ihor Radchenko]

Visuwesh  writes:

>> Is there any particular reason why you insert a newline after the image
>> link?
>
> I think this can stay here until Po Lu writes the platform-agnostic code
> that you requested further down this thread?

Sure.

>> Also, we might want to add a subsection describing the new customization to
>> 17 Miscellaneous section of the manual. Otherwise, users might have
>> difficulties discovering relevant settings to customize dnd and yank
>> behavior.
>
> I have now added these to the manual with a few relevant concept
> indices.  Please check if they are understandable as I am terrible at
> writing documentation.  Thanks.

Thanks!
Upon reading the manual sections I have further comments on the code:

1. org-yank-image-save-type feels a bit inconsistent. What about
   org-yank-image-save-method? "Type" sounds more like extension (png,
   jpeg, etc)

2. org-dnd-method allows either attaching files/images or putting them
   into a dedicated directory. Same for yanked images. But it is not the
   case for yanked files - they are always attached, which is not
   consistent. May we also allow dedicated directory for yanked files?
   Or maybe simply merge the org-dnd-method customization for yank and
   dnd together.

I am attaching my further amendments on top of your patch.
For simpler review, I am also adding the manual section verbatim.

To other readers of this thread: Please help reviewing the manual
section - it should be as clear as possible for everyone.

--
** Drag and Drop & ~yank-media~
:PROPERTIES:
:DESCRIPTION: Dropping and pasting files and images
:END:

#+cindex: dropping files
#+cindex: dragging files
#+cindex: drag and drop
#+cindex: dnd
#+vindex: org-dnd-method
Org mode supports drag and drop (DnD) of files.  By default, Org asks
the user what must be done with the dropped file: attach it, insert
=file:= link, or open the file.  Customize ~org-dnd-method~ to set the
default DnD action.

When DnD method is "attach", Org mode first consults DnD metadata to
decide the attach method.  For example, when file/files are dragged
from a file manager, Org may attach by copying or by moving.

#+vindex: org-dnd-default-attach-method
If Org cannot figure out which attachment method to use from the
metadata, it defaults to ~org-dnd-default-attach-method~ [fn::By
default, ~org-dnd-default-attach-method~ is set to nil -- use the same
value as ~org-attach-method~ (~cp~ by default).]

#+cindex: pasting files, images from clipboard
Starting from Emacs 29, Org mode supports ~yank-media~ command to yank
images from the clipboard and files from a file manager.

#+vindex: org-yank-image-save-type
When yanking images from clipboard, Org saves the image on disk and
inserts the image link to Org buffer.  Images are either saved as
attachments to heading (default) or to a globally defined directory.
The save location is controlled by ~org-yank-image-save-type~.

#+vindex: org-yank-image-file-name-function
The yanked images are saved under automatically generated name.  You
can customize ~org-yank-image-file-name-function~ to make Org query
the image names or change the naming scheme.

When yanking files copied from a file manager, Org attaches them to
the current heading using the =mv= or the =cp= method if the files
were cut or copied in the file manager respectively.
---

>From 23a01dd32ed21061b52557b427b2dc39a656aa8b Mon Sep 17 00:00:00 2001
Message-ID: <23a01dd32ed21061b52557b427b2dc39a656aa8b.1698051344.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Mon, 23 Oct 2023 11:50:56 +0300
Subject: [PATCH] * doc/org-manual.org (Drag and Drop & ~yank-media~): Rewrite

---
 doc/org-manual.org | 54 +-
 1 file changed, 29 insertions(+), 25 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 5a17d1c1f..00eb6680b 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21101,39 +21101,43 @@ ** Drag and Drop & ~yank-media~
 :END:
 
 #+cindex: dropping files
+#+cindex: dragging files
+#+cindex: drag and drop
+#+cindex: dnd
 #+vindex: org-dnd-method
-Org can attach, insert =file:= links, or open files dropped onto an
-Emacs frame.  By default, Org asks the user what must be done with the
-dropped file but this can be changed by customizing the user option
-~org-dnd-method~.  Changing the variable can make Org do any of the
-above mentioned actions without prompting.
+Org mode supports drag and drop (DnD) of files.  By default, Org asks
+the user what must be done with the dropped file: attach it, insert
+=file:= link, or open the file.  Customize ~org-dnd-method~ to set the
+default DnD action.
+
+When DnD method is "attach", Org mode first consults DnD metadata to
+decide the attach method.  For example, when file/files are dragged
+from a file manager, Org may attach by copying or by moving.
 
 #+vindex: org-dnd-default-attach-method
-If Org cannot figure out which attachment method to use automatically,
-it defaults to

Re: [RFC][PATCH] Allow to export to ascii custom link types as notes

[Ihor Radchenko]

Max Nikulin  writes:

>>> For ascii backend :export function from `org-link-parameters' may return
>>> (PATH . DESCRIPTION) `cons' instead of string.
>> 
>> This is non-standard. We should document it somewhere in the manual.
>
> Currently the question is whether it is acceptable or it should be 
> changed to e.g. plist or even to use a callback.

I see no problem with special return value of the link :export function.
In fact, I thought of similar approach globally, allowing :export
function to return AST data that will be further processed.

WRT cons vs. plist, I am mostly neutral. Slightly in favour of plist for
future extensibility.

I am not sure what you mean by callback.

>>> I believe that parenthesis should be skipped in the case of angle
>>> brackets "()", but I do not change this behavior. There is some
>>> inconsistency in respect to brackets for description of inline links,
>>> but it is preserved as well.
>> 
>> May you elaborate?
>
> I believe, parenthesis are not necessary when angle brackets are added 
> around URI. Anyway currently behavior is not consistent and angle 
> brackets are not added in some cases. I would prefer to stick to angle 
> brackets and to drop parenthesis when <> are present.

May you provide an example when the angle brackets are not added?

>>> I do not like that :export functions are called twice: for text and for
>>> note. In my opinion it is better to collect links in a property of INFO
>>> to later format notes at the end of the heading. I would consider more
>>> dense style of notes with list markers instead of empty line as separator.
>> 
>> Again, may you elaborate?
>
> List of links is added by `org-ascii--describe-links' that iterates over 
> links earlier handled by `org-ascii-link', so :export function is called 
> twice for each link having this property. I would consider collecting 
> links in some property of the INFO argument instead. As a result 
> `org-ascii--describe-link' would reuse results of formatters called by 
> `org-ascii-link'.

It is already the case. `org-export-data' maintains export cache under
:exported-data hash table in INFO plist. So, the second call to
`org-export-data` will be cached.

> Currently list of links is formatted as
>
> [Description 1] 
>
> [Description 2] 
>
>  From my point of view it would not harm to have more dense formatting
>
> - [Description 1] 
> - [Description 2] 

I see no reason to change the existing behaviour here. Yes, I do not see
much harm, but changing the defaults is something we should only do when
there is a clear benefit. Harm may not always be anticipated by us in
advance.

>>> +   (if (string-match-p "\\`\u200b*\\[.*\\]\u200b*\\'" anchor)
>>> +   anchor
>>> +(format "[%s]" anchor))
>> 
>> This is out of scope of the patch, isn't it?
>
> Not really.

Do you mean "this is out of scope"?

>> I can see the motivation, but we should probably move this change to a
>> separate patch and discussion thread.
>
> In the case of inline links brackets are sometimes added around 
> description, sometimes not. To keep current behavior I have decided that 
> it is better to suppress duplicated brackets implicitly than to add an 
> extra argument that controls adding [] explicitly.

May you show an example?

> ... I do not insist on 
> "\u200b*" that allows to handle duplication due to brackets in Org 
> documents [[https://orgmode.org][\u200b[Org]\u200b]]. However I would 
> prefer to keep the regexp for the case of brackets added by link formatters.

I do not think that we need to handle zero-width spaces on backend
level. If we want to deal with them, it should be done globally, in
ox.el.

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

Re: Are 'placement' and 'float' "obsolete terms" in inline images export

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> So, the difference between :environment and :float is that :float also
>> encapsulates \caption in addition to the actual environment (like
>> tabularx or includegraphics) used for transcoded exported element.
>
>> I can see how :float+:placement can be imprecise and that the existing
>> :environment indeed serves a different purpose. (It might be worth
>> clarifying this distinction in the manual - it seems arbitrary from
>> the first glance).
>
>> But what would be the better name then?
>
> I think the problem is limited to images, where there is no "double"
> environment as in the case of tables (float environment that encloses an
> environment to generate the table, and :placement points to the correct
> environment).

IMHO, an equivalent of :environment for images is
\includegraphics or \includesvg.

> ... In the case of images, I am afraid that the new features
> have advanced the meaning of the old ones. Previously, :float only
> supported t/nil ("figure" by default, in case of t) along with a few
> explicit "float" environments, such as sidewaysfigure or wrapfigure.
> Since :float now can accept any string as an environment name, Pandora's
> box has been opened and the meaning of the old :float has been left
> behind: for example, we can put :float minipage, and minipage is not a
> float environment. Something similar has happened to :placement.
>
> My suggestion is to add a :environment attribute next to another
> :environment-options attr (or something like that, to introduce any
> arbitrary LaTeX code). A LaTeX image can be enclosed in many environment
> types, float or non-float.

As I said above, I feel that :environment term will be overloaded then.
What about :wrap?

> ... However, :float can still be useful for
> certain combinations. For example, a minipage environment cannot include
> a caption (it produces an error of the type "LaTeX Error: \caption
> outside float").

Do we know in advance which environments support \caption and which not?
I feel that we may handle this programmatically without creating an array
of almost-identical attributes.

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

Re: [BUG] [PATCH] Add yank-media and DND handler [9.6.7 (9.6.7-g6eb773 @ /home/viz/lib/emacs/straight/build/org/)]

[Visuwesh]

[திங்கள் அக்டோபர் 23, 2023] Ihor Radchenko wrote:

>>> Also, we might want to add a subsection describing the new customization to
>>> 17 Miscellaneous section of the manual. Otherwise, users might have
>>> difficulties discovering relevant settings to customize dnd and yank
>>> behavior.
>>
>> I have now added these to the manual with a few relevant concept
>> indices.  Please check if they are understandable as I am terrible at
>> writing documentation.  Thanks.
>
> Thanks!
> Upon reading the manual sections I have further comments on the code:
>
> 1. org-yank-image-save-type feels a bit inconsistent. What about
>org-yank-image-save-method? "Type" sounds more like extension (png,
>jpeg, etc)

You're right, I have now changed the name to say method instead.

> 2. org-dnd-method allows either attaching files/images or putting them
>into a dedicated directory. Same for yanked images. But it is not the
>case for yanked files - they are always attached, which is not
>consistent. May we also allow dedicated directory for yanked files?
>Or maybe simply merge the org-dnd-method customization for yank and
>dnd together.

Hmm... yes, I now made yank-media also respect the value of
org-dnd-method.  I changed the name of org-dnd-method to
org-yank-dnd-method and similarly for the rest of the common user
options.

Here's the new patch:

>From c7492fc2adb72a45691124929527798bf9482c2b Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Fri, 22 Sep 2023 20:11:41 +0530
Subject: [PATCH] Add support for yank-media and DND

* lisp/org.el (org-mode): Call the setup function for yank-media and
DND.
(org-setup-yank-dnd-handlers): Register yank-media-handler and DND
handler.
(org-yank-image-save-method, org-yank-image-file-name-function)
(org-yank-dnd-method, org-yank-dnd-default-attach-method): New
defcustoms.
(org--image-yank-media-handler, org--copied-files-yank-media-handler)
(org--dnd-rmc, org--dnd-attach-file, org--dnd-local-file-handler)
(org--dnd-xds-method, org--dnd-xds-function): Add yank-media and DND
handlers.

* doc/org-manual.org: (Drag and Drop & ~yank-media~): Describe the new
feature in the manual.

* etc/ORG-NEWS: Advertise the new features.
---
 doc/org-manual.org |  45 +
 etc/ORG-NEWS   |  24 +
 lisp/org.el| 231 -
 3 files changed, 299 insertions(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 3e9d42f55..7b14eb937 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -21095,6 +21095,51 @@ most recent since the mobile application searches files that were last
 pulled.  To get an updated agenda view with changes since the last
 pull, pull again.
 
+** Drag and Drop & ~yank-media~
+:PROPERTIES:
+:DESCRIPTION: Dropping and pasting files and images
+:END:
+
+#+cindex: dropping files
+#+cindex: dragging files
+#+cindex: drag and drop
+#+cindex: dnd
+#+vindex: org-yank-dnd-method
+Org mode supports drag and drop (DnD) of files.  By default, Org asks
+the user what must be done with the dropped file: attach it, insert
+=file:= link, or open the file.  Customize ~org-yank-dnd-method~ to
+set the default DnD action.
+
+When DnD method is "attach", Org mode first consults DnD metadata to
+decide the attach method.  For example, when file/files are dragged
+from a file manager, Org may attach by copying or by moving.
+
+#+vindex: org-yank-dnd-default-attach-method
+If Org cannot figure out which attachment method to use from the
+metadata, it defaults to ~org-yank-dnd-default-attach-method~ [fn::By
+default, ~org-yank-dnd-default-attach-method~ is set to nil -- use the same
+value as ~org-attach-method~ (~cp~ by default).]
+
+#+cindex: pasting files, images from clipboard
+Starting from Emacs 29, Org mode supports ~yank-media~ command to yank
+images from the clipboard and files from a file manager.
+
+#+vindex: org-yank-image-save-method
+When yanking images from clipboard, Org saves the image on disk and
+inserts the image link to Org buffer.  Images are either saved as
+attachments to heading (default) or to a globally defined directory.
+The save location is controlled by ~org-yank-image-save-method~.
+
+#+vindex: org-yank-image-file-name-function
+The yanked images are saved under automatically generated name.  You
+can customize ~org-yank-image-file-name-function~ to make Org query
+the image names or change the naming scheme.
+
+When yanking files copied from a file manager, Org respects the value
+of ~org-yank-dnd-method~.  Image files pasted this way also respect
+the value of ~org-yank-image-save-method~ when the action to perform
+is =attach=.
+
 * Hacking
 :PROPERTIES:
 :DESCRIPTION: How to hack your way around.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 252c5a9f9..7c40ec0fe 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -596,6 +596,30 @@ return a matplotlib Figure object to plot. For output results, the
 current figure (as returned by =pyplot.gcf()=) is cleared before
 evaluati

Re: Feature request: export form feed as page break

[Max Nikulin]

On 22/10/2023 16:00, Ihor Radchenko wrote:

Max Nikulin writes:


P.S. I am against using non-printable characters for markup. It might be
an \... entity for page break inside a paragraph, "#+...:" keyword
between block-level elements, etc.


What about all the above? We may provide entity, keyword, and also ^L.


I have not changed my opinion. Control characters should not be used for 
plain text markup.


^L might be inconvenient for users of browser-based tools (organice, 
etc.). Firefox displays it as a square with 0c code inside  
and as some space in regular tags. In Chromium it is invisible similar 
to zero-width space. Fortunately browsers allows to copy a paste it, it 
is exemption from control characters that are stripped on copy to 
protect users from unexpected effects of paste.


However e.g. konsole (terminal application) shows a warning popup on 
attempt to paste text containing ^L.


My vote is for portability, so usage of ^L should be discouraged.

Re: [RFC][PATCH] Allow to export to ascii custom link types as notes

[Max Nikulin]

On 23/10/2023 16:17, Ihor Radchenko wrote:

Max Nikulin writes:

WRT cons vs. plist, I am mostly neutral. Slightly in favour of plist for
future extensibility.

I am not sure what you mean by callback.


Originally I had an idea that :export should call some function that 
adds a note to info. Now I have another proposal. Instead of returning a 
cons, :export function should return result of some new function, e.g. 
(org-ascii-make-link-with-note NOTE DESCRIPTION), so a `cons' or a plist 
becomes an implementation detail that may be changed any time. The only 
inconvenience is necessity to declare this function to allow lazy 
loading of ox-ascii and perhaps to avoid circular dependencies.



May you provide an example when the angle brackets are not added?


angle and square brackets inconsistency

--- 8< ---
# (require 'ol-man)
# (setq org-ascii-links-to-notes nil)

- web :: [[http://orgmode.org][Org mode]]
- man :: [[man:man][man]]
- internal :: [[Heading][heading]]

* Heading
--- >8 ---
--- 8< ---
web
  [Org mode] ()
man
  man (http://man.he.net/?topic=man§ion=all)
internal
  heading (See section 1)


1 Heading
═
--- >8 ---


+   (if (string-match-p "\\`\u200b*\\[.*\\]\u200b*\\'" anchor)
+   anchor
+(format "[%s]" anchor))


This is out of scope of the patch, isn't it?


Not really.


Do you mean "this is out of scope"?


I mean, it is a related change. E.g. ox-html and ox-latex do not add 
square brackets around link descriptions, it is specifics of ox-ascii. 
Square brackets are sometimes added for inline links, sometimes they are 
not. Square brackets are always added for links as notes. I would avoid 
duplicated square brackets when links are formatted as notes and for 
inline links when description is formatted with brackets.

Re: org-ditaa woes

[Florin Boariu]

On Sat, Oct 21, 2023 at 10:50:08AM +0700, Max Nikulin wrote:


Does it work when executed from Emacs shell or eshell buffers?

Could you, please, provide complete sequence of commands to generate a 
graphics file from a ditaa source for a shell running in Emacs?


"M-x shell" and then:


sh-5.1$ echo -e "+-+\n| moo |\n+-+\n" > /tmp/foo.txt
sh-5.1$ cat /tmp/foo.txt 
+-+

| moo |
+-+

sh-5.1$ flatpak-spawn --host toolbox run /usr/bin/ditaa /tmp/foo.txt -o 
/tmp/foo.png

ditaa version 0.9, Copyright (C) 2004--2009  Efstathios (Stathis) Sideris

Running with options:
overwrite
Reading file: /tmp/foo.txt
Rendering to file: /tmp/foo.png
Done in 0sec
sh-5.1$ 


...gives pretty much the expected result, which is a PNG image of the
word "moo" embedded in a square. Is this what you hoped for?

Flatpack is a means to prevent accessing system files by applications 
that may have less degree of trust. I expect that a package should be 
carefully prepared to allow `man' and `info' access docs installed 
system-wide, files from /usr/share/doc should be available for 
doc-view, compiler toolchains should be available if Emacs is used for 
development. It sounds like rather broad permissions for isolated 
applications.


...I'm not an expert of Flatpak, but it is my understanding that it
uses something they call "portals" for defined access to your file
system. Apparently it's a bit more sphisticated than "just" broad
access.

For instance, once you have an application that requires to process a
file, you're presented with a dialog window by the OS (*not* by the
application) with which you can select your file. The file is then
opened for you, and your application only has the option to write to
that specific file -- and nowhere else. (Please don't fact-check me on
this, I really am just parroting concepts here... :-p)

This doesn't sound a lot like Emacs, and in fact I'm not sure how the
Emacs Flatpak works. Given that it's an "editor" designed to "edit"
everything, maybe it is indeed opening up most/all of the whole
host filesystem (?), has very little in the way of actual isolation
(??), and just uses Flatpak as a "package manager on steroids"
only to keep its own dependencies private (???).

But even this broad access to the host system isn't of any help to
me. This is because of the way the Fedora Silverblue distribution
works: the "bare linux" you boot into doesn't contain anything
beyond bare Wayland/Gnome desktop shell and essential system tools
(systemd, networking, DNS resolving, user management...). This is a
read-only ("immutable") image, like a perpetual, bare-bones "live
ISO" (courtesy of "libostree", https://ostreedev.github.io/ostree/ if
you're interested).

Any other applications -- gcc, python, additional libraries,
development tools, ditaa etc -- are being installed in a kind of
mutable container technology ("toolboxes", see
https://containertoolbx.org/ ). Those are pretty strongly isolated
from the host file system, and essentially only share the $HOME folder
and some state (/var, /proc, /dev, ...) with the host.

(This is a simplified view of things, but that's the gist of it.)

This means that even if the Emacs Flatpak was to give broad access to
the host, I still wouldn't be able to call "java -jar ...", simply
because the host system isn't meant to, and generally doesn't, even
have Java runtime to begin with, a ditaa.jar, or a /usr/bin/ditaa.
Those are meant to exist in toolboxes.

The command line above ("flatpak-spawn --host toolbox run [...]") is
designed to cross two namespacing boundaries:

  - "flatpak-spawn --host [...]" breaks out from the Flatpak,

  - "toolbox run [...]" then executes a command inside a toolbox
(e.g. "/usr/bin/ditaa").

The way they share data is worth some thought, but we incidentally get
lucky here: Emacs writes the code into "/tmp/...", which is shared
and accessible across all namespaces; and /usr/bin/ditaa read that,
and writes the PNG in the current project folder (in $HOME), which, in
this case, is also shared by emacs.

Hope this helps a bit to see the context of my request :-)

I really _need_ to generically execute a command.


Menu: Org → Documentation → Show version, Help → About Emacs
or M-x org-version


"9.6.6 (release_9.6.6 @ /app/share/emacs/29.1/lisp/org)"


M-x emacs-version.


"GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
cairo version 1.16.0), of 2023-08-06"

Cheers,
Florin.

--
   "Socks come in pairs. If you put a sock on your left foot, the other
sock of the pair instantly becomes the “right sock,” no matter where
it is located in the universe."
 -- quantum entanglement explained on /.

Re: [FR] Should we preserve point when calling `org-open-at-point' (C-c C-o) on a heading (was: [BUG] Point position with org-open-at-point on a heading [9.6.6 (release_9.6.6 @ /usr/local/share/emacs/

[Ihor Radchenko]

Ihor Radchenko  writes:

 Perhaps there's some reason why
 point is not preserved in this case. But for me at least, this is not
 what I'd expect, and I find it somewhat disrupting, especially when
 I'm working on a folded tree (defeats speed keys, etc.).
>>> 
>>> I see no particular reason.
>>
>> Maybe the following is a false alarm. I hope `save-excursion' will not 
>> break the "RET to open all" option, `org-open-at-point' is called 
>> recursively this case.
>
> "Open all" is broken now.
>
> That said, your concern is valid - if we open internal link, it will be
> expected the point jumps to that link rather than staying on the
> heading.

I believe that I now addressed all the concerns:
1. Point position is not preserved by default.
2. When a link being open moved point in current buffer, we do allow
   changing the position.
3. When multiple links are open, things should not be broken.
4. When multiple links are open and some of them (more than 1) also move
   point, we move point to the position defined by the last of such
   links.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=098f08159

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

Re: [RFC][PATCH] Allow to export to ascii custom link types as notes

[Ihor Radchenko]

Max Nikulin  writes:

>> I am not sure what you mean by callback.
>
> Originally I had an idea that :export should call some function that 
> adds a note to info. Now I have another proposal. Instead of returning a 
> cons, :export function should return result of some new function, e.g. 
> (org-ascii-make-link-with-note NOTE DESCRIPTION), so a `cons' or a plist 
> becomes an implementation detail that may be changed any time.

Then, `org-ascii-make-link-with-note' may as well receive and modify
INFO plist. This way, ((org-export-custom-protocol-maybe link desc 'ascii 
info)) 
cond form will work without changes as `org-ascii-make-link-with-note`
will do all the necessary processing.

> ... The only 
> inconvenience is necessity to declare this function to allow lazy 
> loading of ox-ascii and perhaps to avoid circular dependencies.

This is not a problem.
If lazy loading is desired, one may simply use (require 'ox-ascii)
inside :export function to trigger loading when necessary.

>> May you provide an example when the angle brackets are not added?
>
> angle and square brackets inconsistency
>
> --- 8< ---
> # (require 'ol-man)
> # (setq org-ascii-links-to-notes nil)
>
> - web :: [[http://orgmode.org][Org mode]]
> - man :: [[man:man][man]]
> - internal :: [[Heading][heading]]
>
> * Heading
> --- >8 ---
> --- 8< ---
> web
>[Org mode] ()
> man
>man (http://man.he.net/?topic=man§ion=all)

This is probably a bug in ol-man.

> internal
>heading (See section 1)

I see no problem here - internal links are special, and it makes sense to
drop angle brackets, unlike external web links that are often marked
with angle brackets in the wild.

> 1 Heading
> ═
> --- >8 ---
>
> +   (if (string-match-p "\\`\u200b*\\[.*\\]\u200b*\\'" anchor)
> +   anchor
> +  (format "[%s]" anchor))

 This is out of scope of the patch, isn't it?
>>>
>>> Not really.
>> 
>> Do you mean "this is out of scope"?
>
> I mean, it is a related change. E.g. ox-html and ox-latex do not add 
> square brackets around link descriptions, it is specifics of ox-ascii. 
> Square brackets are sometimes added for inline links, sometimes they are 
> not. Square brackets are always added for links as notes. I would avoid 
> duplicated square brackets when links are formatted as notes and for 
> inline links when description is formatted with brackets.

I did not mean unrelated to ox-ascii. I meant unrelated to "add new
feature allowing more flexibility for :export property of links when
exporting to ASCII".

I see handling anchors as a bugfix that should be discussed and
committed separately.

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

Re: the opposite of the noexport tag

[Uwe Brauer]

>>> "IR" == Ihor Radchenko  writes:

> Uwe Brauer  writes:
>>> This is not a correct format. Please, review the manual section I linked
>>> to.
>> 
>> So it should be 
>> #+options: SELECT_TAGS: ("noexport")
>> #+options: EXCLUDE_TAGS: ("export")
>> 
>> Right?

> No.
> #+SELECT_TAGS: tag1 tag2 ...
> Same for #+EXCLUDE_TAGS.

I recommend then to clarify this is in the manual: the expression in the manual 
is 
`("export")'

And at least for me it is not clear that this translate to 

#+SELECT_TAGS: export

>> I am wondering why it worked anyhow

> By default, SELECT_TAGS is set to "export" tag and EXCLUDE_TAGS is set
> to "noexport" tag.

>>> (side note: this is odd to set selected tags to "noexport")
>> 
>> So what to you propose instead, in order to achieve my goal:
>> 
>> «To  export only the sections  that have the export tag and leave the
>> ignore the others»

> #+SELECT_TAGS: export
> And then
> * This section will be exported :export:
> * This - will not
> * This - neither :some_other_tag:

> And you do not even need #+SELECT_TAGS if you use "export" tag - it is
> already set like this by default.


Ok, thanks! I figured that out now and it is, again, confusing.

- If I don't add any tag

* This section will be exported 
* This - will 
* This - will :some_other_tag:



- But if I just add *one* export tag to one of the sections the rest is 
ignored.

Couldn't that be clarified in the manual, please.

Regards

Uwe Brauer 


-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Hamas bestialic terroristic attack on Israel, especially the 
despicable pogroms.
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of Ukraine.
I support the EU membership of Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/


smime.p7s
Description: S/MIME cryptographic signature

Re: org-ditaa woes

[Florin Boariu]

I heard everybody referencing "org-plantuml" several times here :-)

I gave it a try, and, for reference, this is how my "org-plantuml" is
being set up in my case:


(org-babel-do-load-languages 'org-babel-load-languages '(
   [...]
   (plantuml . t)
   [...]
 ))

(setq org-plantuml-exec-mode 'plantuml)
(setq org-plantuml-executable-path "flatpak-spawn --host toolbox run 
/usr/bin/plantuml")



And with this as a document:


#+begin_src plantuml :file kmc3net.png
  bob -> alice: moo
#+end_src


it works as expected 🤷 (i.e. provides a [[file::kmc3net.png]] link,
which actually leads to a newly created file with the correct
contents).

Cheers,
F.

--
   "Socks come in pairs. If you put a sock on your left foot, the other
sock of the pair instantly becomes the “right sock,” no matter where
it is located in the universe."
 -- quantum entanglement explained on /.

Re: the opposite of the noexport tag

[Ihor Radchenko]

Uwe Brauer  writes:

> I recommend then to clarify this is in the manual: the expression in the 
> manual is 
> `("export")'

What about the attached patch?

>From f94d0c8dfa875983332dfe9432e6ec896c62bf59 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Mon, 23 Oct 2023 15:30:42 +0300
Subject: [PATCH] * doc/org-manual.org: Improve documentation for #+SELECT_TAGS
 and #+EXCLUDE_TAGS

(Export Settings): Clarify how to define multiple tags per-document.  Reword.

Link: https://orgmode.org/list/87y1ftilf3@mat.ucm.es
---
 doc/org-manual.org | 31 ---
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index c0e9c8d7e..29845f309 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12053,22 +12053,31 @@ ** Export Settings
 
   #+cindex: @samp{SELECT_TAGS}, keyword
   #+vindex: org-export-select-tags
-  The default value is =("export")=.  When a tree is tagged with
-  =export= (~org-export-select-tags~), Org selects that tree and its
-  subtrees for export.  Org excludes trees with =noexport= tags, see
-  below.  When selectively exporting files with =export= tags set, Org
-  does not export any text that appears before the first headline.
+  List of tags that will *only* be selected for export.  The default
+  value is ~org-export-select-tags~ =("export")=.  When a tree is
+  tagged with =export=, Org selects that tree and its subtrees for
+  export.  When selectively exporting files with =export= tags set,
+  Org does not export any text that appears before the first headline.
+
+  To select non-default tags for export, customize
+  ~org-export-select-tags~ (globally) or add
+  =#+SELECT_TAGS: tag1 tag2= to the document.
 
 - =EXCLUDE_TAGS= ::
 
   #+cindex: @samp{EXCLUDE_TAGS}, keyword
   #+vindex: org-export-exclude-tags
-  The default value is =("noexport")=.  When a tree is tagged with
-  =noexport= (~org-export-exclude-tags~), Org excludes that tree and
-  its subtrees from export.  Entries tagged with =noexport= are
-  unconditionally excluded from the export, even if they have an
-  =export= tag.  Even if a subtree is not exported, Org executes any
-  code blocks contained there.
+  List o tags that will be excluded from export.  The default value is
+  ~org-export-exclude-tags~ =("noexport")=.  When a tree is tagged
+  with =noexport=, Org excludes that tree and its subtrees from
+  export.  Entries tagged with =noexport= are unconditionally excluded
+  from the export, even if they have an =export= tag.  Even if a
+  subtree is not exported, Org executes any code blocks contained
+  there.
+
+  To select non-default tags for the exclusion, customize
+  ~org-export-exclude-tags~ (globally) or add =#+EXCLUDE_TAGS: tag1
+  tag2= to the document.
 
 - =TITLE= ::
 
-- 
2.42.0


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

Re: the opposite of the noexport tag

[Uwe Brauer]

>>> "IR" == Ihor Radchenko  writes:

> Uwe Brauer  writes:
>> I recommend then to clarify this is in the manual: the expression in the 
>> manual is 
>> `("export")'

> What about the attached patch?

> From f94d0c8dfa875983332dfe9432e6ec896c62bf59 Mon Sep 17 00:00:00 2001
> Message-ID: 
> 
> From: Ihor Radchenko 
> Date: Mon, 23 Oct 2023 15:30:42 +0300
> Subject: [PATCH] * doc/org-manual.org: Improve documentation for #+SELECT_TAGS
>  and #+EXCLUDE_TAGS

> (Export Settings): Clarify how to define multiple tags per-document.  Reword.


Thanks, this is better, but please  give me some minutes and I will try to add 
my suggestions.



> Link: https://orgmode.org/list/87y1ftilf3@mat.ucm.es
> ---
>  doc/org-manual.org | 31 ---
>  1 file changed, 20 insertions(+), 11 deletions(-)

> diff --git a/doc/org-manual.org b/doc/org-manual.org
> index c0e9c8d7e..29845f309 100644
> --- a/doc/org-manual.org
> +++ b/doc/org-manual.org
> @@ -12053,22 +12053,31 @@ ** Export Settings
 
>#+cindex: @samp{SELECT_TAGS}, keyword
>#+vindex: org-export-select-tags
> -  The default value is =("export")=.  When a tree is tagged with
> -  =export= (~org-export-select-tags~), Org selects that tree and its
> -  subtrees for export.  Org excludes trees with =noexport= tags, see
> -  below.  When selectively exporting files with =export= tags set, Org
> -  does not export any text that appears before the first headline.
> +  List of tags that will *only* be selected for export.  The default
> +  value is ~org-export-select-tags~ =("export")=.  When a tree is
> +  tagged with =export=, Org selects that tree and its subtrees for
> +  export.  When selectively exporting files with =export= tags set,
> +  Org does not export any text that appears before the first headline.
> +
> +  To select non-default tags for export, customize
> +  ~org-export-select-tags~ (globally) or add
> +  =#+SELECT_TAGS: tag1 tag2= to the document.
 
>  - =EXCLUDE_TAGS= ::
 
>#+cindex: @samp{EXCLUDE_TAGS}, keyword
>#+vindex: org-export-exclude-tags
> -  The default value is =("noexport")=.  When a tree is tagged with
> -  =noexport= (~org-export-exclude-tags~), Org excludes that tree and
> -  its subtrees from export.  Entries tagged with =noexport= are
> -  unconditionally excluded from the export, even if they have an
> -  =export= tag.  Even if a subtree is not exported, Org executes any
> -  code blocks contained there.
> +  List o tags that will be excluded from export.  The default value is
> +  ~org-export-exclude-tags~ =("noexport")=.  When a tree is tagged
> +  with =noexport=, Org excludes that tree and its subtrees from
> +  export.  Entries tagged with =noexport= are unconditionally excluded
> +  from the export, even if they have an =export= tag.  Even if a
> +  subtree is not exported, Org executes any code blocks contained
> +  there.
> +
> +  To select non-default tags for the exclusion, customize
> +  ~org-export-exclude-tags~ (globally) or add =#+EXCLUDE_TAGS: tag1
> +  tag2= to the document.
 
>  - =TITLE= ::
 
> -- 
> 2.42.0

-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Hamas bestialic terroristic attack on Israel, especially the 
despicable pogroms.
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of Ukraine.
I support the EU membership of Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/


smime.p7s
Description: S/MIME cryptographic signature

Re: the opposite of the noexport tag

[Uwe Brauer]

>>> "IR" == Ihor Radchenko  writes:

> Uwe Brauer  writes:
>> I recommend then to clarify this is in the manual: the expression in the 
>> manual is 
>> `("export")'

> What about the attached patch?

I added some lines, and run rediff and I hoper therefore the modified patch is 
ok.


Feel free to use it


-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Hamas bestialic terroristic attack on Israel, especially the 
despicable pogroms.
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of Ukraine.
I support the EU membership of Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
From f94d0c8dfa875983332dfe9432e6ec896c62bf59 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Mon, 23 Oct 2023 15:30:42 +0300
Subject: [PATCH] * doc/org-manual.org: Improve documentation for #+SELECT_TAGS
 and #+EXCLUDE_TAGS

(Export Settings): Clarify how to define multiple tags per-document.  Reword.

Link: https://orgmode.org/list/87y1ftilf3@mat.ucm.es
---
 doc/org-manual.org | 31 ---
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index c0e9c8d7e..29845f309 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12053,23 +12053,37 @@ ** Export Settings
 
   #+cindex: @samp{SELECT_TAGS}, keyword
   #+vindex: org-export-select-tags
-  The default value is =("export")=.  When a tree is tagged with
-  =export= (~org-export-select-tags~), Org selects that tree and its
-  subtrees for export.  Org excludes trees with =noexport= tags, see
-  below.  When selectively exporting files with =export= tags set, Org
-  does not export any text that appears before the first headline.
+  List of tags that will *only* be selected for export.  The default
+  value is ~org-export-select-tags~ =("export")=.  When a tree is
+  tagged with =export=, Org selects that tree and its subtrees for
+  export, ignoring all the other sections, that do not possess the
+  =export= tag.
+  Please recall, that a file without the =export= or the  =noexport=
+  tag will export all its sections.
+  When selectively exporting files with =export= tags set,
+  Org does not export any text that appears before the first headline.
+
+  To select non-default tags for export, customize
+  ~org-export-select-tags~ (globally) or add
+  =#+SELECT_TAGS: tag1 tag2= to the document.
 
 - =EXCLUDE_TAGS= ::
 
   #+cindex: @samp{EXCLUDE_TAGS}, keyword
   #+vindex: org-export-exclude-tags
-  The default value is =("noexport")=.  When a tree is tagged with
-  =noexport= (~org-export-exclude-tags~), Org excludes that tree and
-  its subtrees from export.  Entries tagged with =noexport= are
-  unconditionally excluded from the export, even if they have an
-  =export= tag.  Even if a subtree is not exported, Org executes any
-  code blocks contained there.
+  List o tags that will be excluded from export.  The default value is
+  ~org-export-exclude-tags~ =("noexport")=.
+  This tag is useful, if the =export= tag is not used on other sections.
+  When a tree is tagged
+  with =noexport=, Org excludes that tree and its subtrees from
+  export.  Entries tagged with =noexport= are unconditionally excluded
+  from the export, even if they have an =export= tag.  Even if a
+  subtree is not exported, Org executes any code blocks contained
+  there.
+
+  To select non-default tags for the exclusion, customize
+  ~org-export-exclude-tags~ (globally) or add =#+EXCLUDE_TAGS: tag1
+  tag2= to the document.
 
 - =TITLE= ::
 
-- 
2.42.0



smime.p7s
Description: S/MIME cryptographic signature

Re: the opposite of the noexport tag

[Loris Bennett]

Hi,

Below are some minor comma niggles.

Cheers,

Loris

Uwe Brauer  writes:

 "IR" == Ihor Radchenko  writes:
>
>> Uwe Brauer  writes:
>>> I recommend then to clarify this is in the manual: the expression in the 
>>> manual is 
>>> `("export")'
>
>> What about the attached patch?
>
> I added some lines, and run rediff and I hoper therefore the modified patch 
> is ok.
>
>
> Feel free to use it
>
>
> -- 
> Warning: Content may be disturbing to some audiences
> I strongly condemn Hamas bestialic terroristic attack on Israel, especially 
> the despicable pogroms.
> I strongly condemn Putin's war of aggression against Ukraine.
> I support to deliver weapons to Ukraine's military. 
> I support the NATO membership of Ukraine.
> I support the EU membership of Ukraine. 
> https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
>
> From f94d0c8dfa875983332dfe9432e6ec896c62bf59 Mon Sep 17 00:00:00 2001
> Message-ID: 
> 
> From: Ihor Radchenko 
> Date: Mon, 23 Oct 2023 15:30:42 +0300
> Subject: [PATCH] * doc/org-manual.org: Improve documentation for #+SELECT_TAGS
>  and #+EXCLUDE_TAGS
>
> (Export Settings): Clarify how to define multiple tags per-document.  Reword.
>
> Link: https://orgmode.org/list/87y1ftilf3@mat.ucm.es
> ---
>  doc/org-manual.org | 31 ---
>  1 file changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/doc/org-manual.org b/doc/org-manual.org
> index c0e9c8d7e..29845f309 100644
> --- a/doc/org-manual.org
> +++ b/doc/org-manual.org
> @@ -12053,23 +12053,37 @@ ** Export Settings
>  
>#+cindex: @samp{SELECT_TAGS}, keyword
>#+vindex: org-export-select-tags
> -  The default value is =("export")=.  When a tree is tagged with
> -  =export= (~org-export-select-tags~), Org selects that tree and its
> -  subtrees for export.  Org excludes trees with =noexport= tags, see
> -  below.  When selectively exporting files with =export= tags set, Org
> -  does not export any text that appears before the first headline.
> +  List of tags that will *only* be selected for export.  The default
> +  value is ~org-export-select-tags~ =("export")=.  When a tree is
> +  tagged with =export=, Org selects that tree and its subtrees for
> +  export, ignoring all the other sections, that do not possess the

No comma between 'sections' and 'that'.  English does not have a comma
before a restrictive relative pronoun.

> +  =export= tag.
> +  Please recall, that a file without the =export= or the  =noexport=

No comma between 'recall' and 'that'.  English does not have comma after
'that' used as a conjunction.

> +  tag will export all its sections.
> +  When selectively exporting files with =export= tags set,
> +  Org does not export any text that appears before the first headline.
> +
> +  To select non-default tags for export, customize
> +  ~org-export-select-tags~ (globally) or add
> +  =#+SELECT_TAGS: tag1 tag2= to the document.
>  
>  - =EXCLUDE_TAGS= ::
>  
>#+cindex: @samp{EXCLUDE_TAGS}, keyword
>#+vindex: org-export-exclude-tags
> -  The default value is =("noexport")=.  When a tree is tagged with
> -  =noexport= (~org-export-exclude-tags~), Org excludes that tree and
> -  its subtrees from export.  Entries tagged with =noexport= are
> -  unconditionally excluded from the export, even if they have an
> -  =export= tag.  Even if a subtree is not exported, Org executes any
> -  code blocks contained there.
> +  List o tags that will be excluded from export.  The default value is
> +  ~org-export-exclude-tags~ =("noexport")=.
> +  This tag is useful, if the =export= tag is not used on other sections.

No comma between 'useful' and 'if.  The comma is usually only placed
between the clauses when the if-clause precedes the main clause.

> +  When a tree is tagged
> +  with =noexport=, Org excludes that tree and its subtrees from
> +  export.  Entries tagged with =noexport= are unconditionally excluded
> +  from the export, even if they have an =export= tag.  Even if a
> +  subtree is not exported, Org executes any code blocks contained
> +  there.
> +
> +  To select non-default tags for the exclusion, customize
> +  ~org-export-exclude-tags~ (globally) or add =#+EXCLUDE_TAGS: tag1
> +  tag2= to the document.
>  
>  - =TITLE= ::

-- 
This signature is currently under constuction.

[BUG] code block side effects differences between "results: none" and "results: silent" [9.6.9 ( @ /home/jet/.config/emacs/elpa/org-9.6.9/)]

[Jeff Trull]

In the following code block, a propertized (inverse video) before-string
overlay appears when "results: none" is used, but the property is absent
(the overlay text appears normal) when "results:silent" is used:

# with ":results none" it works as expected - inverse video Foo appears
# with ":results silent" the string appears normally
#+begin_src emacs-lisp :results none
  (let ((buf (generate-new-buffer "side-effect-demo")))
  (with-current-buffer buf
(let ((ov (make-overlay 0 (point
  (overlay-put ov 'before-string (propertize "Foo" 'face
'(:inverse-video t))
#+end_src

It's my understanding that "none" vs. "silent" behavior should not change
side effects.

Thanks,
Jeff

Emacs  : GNU Emacs 29.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.16.0)
 of 2023-07-30
Package: Org mode version 9.6.9 ( @ /home/jet/.config/emacs/elpa/org-9.6.9/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-ditaa-jar-path "/usr/share/ditaa/ditaa.jar"
 org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-re-reveal-root "https://cdn.jsdelivr.net/npm/reveal.js@3.6.0";
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-ascii-format-drawer-function #[771 " \207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
 org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines org-cycle-optimize-window-after-visibility-change
  org-cycle-display-inline-images)
 org-latex-listings-options '(("basicstyle" "\\footnotesize\\ttfamily")
("showstringspaces" "false") ("breaklines" "true"))
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-mode-hook '(#[0 "\301\211 \207" [imenu-create-index-function
org-imenu-get-tree] 2] org-superstar-mode org-tempo-setup
 (lambda nil (electric-indent-local-mode -1))
 #[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-fold-show-all append local] 5]
 #[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec
 org-babel-hide-all-hashes org-eldoc-load)
 org-babel-load-languages '((emacs-lisp . t) (dot . t) (ditaa . t) (shell .
t))
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-latex-format-headline-function
'org-latex-format-headline-default-function
 org-confirm-shell-link-function 'yes-or-no-p
 org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-latex-classes '(("beamer"
  "\\documentclass[11pt,aspectratio=169]{beamer}\n
 \\usenavigationsymbolstemplate{} % no navigation bar\n
 \\beamertemplateballitem % items have little balls"
  ("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}") ("\\subsubsection{%s}" .
"\\subsubsection*{%s}"))
 ("article" "\\documentclass[11pt]{article}"
("\\section{%s}" . "\\section*{%s}") ("\\subsection{%s}" .
"\\subsection*{%s}")
  ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
  ("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
 ("report" "\\documentclass[11pt]{report}"
("\\part{%s}" . "\\part*{%s}") ("\\chapter{%s}" . "\\chapter*{%s}")
  ("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}") ("\\subsubsection{%s}" .
"\\subsubsection*{%s}"))
 ("book" "\\documentclass[11pt]{book}" ("\\part{%s}" .
"\\part*{%s}") ("\\chapter{%s}" . "\\chapter*{%s}")
  ("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}") ("\\subsubsection{%s}" .
"\\subsubsection*{%s}"))
 )
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-latex-packages-alist '(("" "moresize") ("" "fancyvrb") (""
"inconsolata") ("" "tikz") ("" "color") ("" "listings"))
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-latex-src-block-backend t
 org-ditaa-eps-jar-path
"/home/jet/.config/emacs/elpa/contrib/scripts/DitaaEps.jar"
 org-structure-template-alist '(("n" . "notes") ("a" . "export ascii") ("c"
. "center") ("C" . "comment") ("e" . "example") ("E" . "export")
("h" . "export html") ("l" . "export
latex") ("q" . "quote") ("s" . "src") ("v" . "verse"))
 org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
 org-html-format-inlinetask-function
'org

Re: Are 'placement' and 'float' "obsolete terms" in inline images export

[Juan Manuel Macías]

Ihor Radchenko writes:

>> My suggestion is to add a :environment attribute next to another
>> :environment-options attr (or something like that, to introduce any
>> arbitrary LaTeX code). A LaTeX image can be enclosed in many environment
>> types, float or non-float.
>
> As I said above, I feel that :environment term will be overloaded then.
> What about :wrap?

I like :wrap. What's more, remembering that old thread where
some questions about code before/after the image were discussed,
what if the expected value of :wrap were a kind of template? This would
allow code to be placed before and/or after (not just an environment)
the image, always within the float environment, if it exists. Something
like this:

#+ATTR_LaTeX: :float nil :wrap 
\begin{minipage}[b]{10pc}\small\n%s\n\end{minipage} 
#+CAPTION: caption
[[file:foo.png]]

Thus :caption with value nil does not add any higher float environment
and would enclose (always within the template) the value of #+CAPTION as
\captionof{figure}{caption}. Of course, with a float environment
declared, :wrap can still be used. An internal environment is unlikely
(I can't think of any use case right now), but you can add arbitrary
code like \captionsetup{} or \ContinuedFloat, which should always go
inside the float environment.

The result of the previous example could also be obtained with:

#+ATTR_LaTeX: :float minipage :placement [b]{10pc} :caption 
\captionof{figure}{caption} 
[[file:foo.png]]

I don't know if it would be appropriate to explain in the Manual that
doing so would not be... "correct"? I don't know if there is any term in
programming to designate these situations which, without being bugs, are
functionalities not consciously sought...

>> ... However, :float can still be useful for
>> certain combinations. For example, a minipage environment cannot include
>> a caption (it produces an error of the type "LaTeX Error: \caption
>> outside float").
>
> Do we know in advance which environments support \caption and which not?
> I feel that we may handle this programmatically without creating an array
> of almost-identical attributes.

I like the idea, but unfortunately, apart from the known float
environments, there are those that a user can define using the \newfloat
command from the float package.

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

[BUG] org-element--cache Cached element is incorrect (ox-hugo) [9.6.10 (release_9.6.10 @ /home/gk/.emacs.d/lib/org/lisp/)]

[George Kettleborough]

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.


I've been having a problem where some of my exports get truncated
randomly at the end. I haven't been able to figure out the exact
problem, but by bisecting org-mode I found the problem appears in
072ddbc9 which sets `org-element--cache-self-verify' to t. By setting
this back to nil manually the truncation goes away, but the warning then
appears.

Interestingly I can only reproduce this when running emacs in batch
mode, not in regular mode.

I know ox-hugo and caching has come up before, but I don't think this
was the same problem as before.


Warning (org-element-cache): org-element--cache: (nil) Cached element is 
incorrect in *Ox-hugo Pre-processed programming.org *. (Cache tic up to 
date: "yes") Resetting.
If this warning appears regularly, please report the warning text to Org 
mode mailing list (M-x org-submit-bug-report).
The element is: "(headline (:raw-value \"Working on Multiple Web 
Projects with Docker Compose and Traefik\" :begin 85 :end 10406 
:pre-blank 0 :contents-begin 201 :contents-end 10405 :robust-begin 344 
:robust-end 10403 :level 1 :priority nil :tags (\"networking\" \"web\" 
\"development\" \"traefik\" \"docker\") :todo-keyword \"DONE\" 
:todo-type done :post-blank 1 :footnote-section-p nil :archivedp nil 
:commentedp nil :post-affiliated 85 :closed (timestamp (:type inactive 
:raw-value \"[2023-10-02 Mon 09:00]\" :year-start 2023 :month-start 10 
:day-start 2 :hour-start 9 :minute-start 0 :year-end 2023 :month-end 10 
:day-end 2 :hour-end 9 :minute-end 0 :begin 209 :end 231 :post-blank 0)) 
:EXPORT_FILE_NAME \"multiple-web-projects-traefik\" :EXPORT_HUGO_LASTMOD 
\"<2023-10-19 Thu 21:24>\" :title \"Working on Multiple Web Projects 
with Docker Compose and Traefik\" :mode nil :granularity element :cached 
t ...))"
The real element is: "(headline (:raw-value \"Working on Multiple Web 
Projects with Docker Compose and Traefik\" :begin 85 :end 10620 
:pre-blank 0 :contents-begin 201 :contents-end 10619 :robust-begin 344 
:robust-end 10617 :level 1 :priority nil :tags (\"networking\" \"web\" 
\"development\" \"traefik\" \"docker\") :todo-keyword \"DONE\" 
:todo-type done :post-blank 1 :footnote-section-p nil :archivedp nil 
:commentedp nil :post-affiliated 85 :closed (timestamp (:type inactive 
:raw-value \"[2023-10-02 Mon 09:00]\" :year-start 2023 :month-start 10 
:day-start 2 :hour-start 9 :minute-start 0 :year-end 2023 :month-end 10 
:day-end 2 :hour-end 9 :minute-end 0 :begin 209 :end 231 :post-blank 0)) 
:EXPORT_FILE_NAME \"multiple-web-projects-traefik\" :EXPORT_HUGO_LASTMOD 
\"<2023-10-19 Thu 21:24>\" :title \"Working on Multiple Web Projects 
with Docker Compose and Traefik\" :mode nil :granularity element :parent 
(org-data (:begin 1 :contents-begin 1 :contents-end 26390 :end 26390 
:robust-begin 3 :robust-end 26388 :post-blank 0 :post-affiliated 1 :path 
\"/home/gk/blog/content-org/programming.org\" :mode org-data :CATEGORY 
\"programming\""

Cache around :begin:
(keyword (:key "HUGO_CATEGORIES" :value "programming" :begin 53 :end 85 
:post-blank 1 :post-affiliated 53 :mode nil :granularity element :cached 
t :parent (section (:begin 1 :end 85 :contents-begin 1 :contents-end 84 
:robust-begin 1 :robust-end 82 :post-blank 1 :post-affiliated 1 :mode 
first-section :granularity element :cached t :parent (org-data (:begin 1 
:contents-begin 1 :contents-end 26390 :end 26390 :robust-begin 3 
:robust-end 26388 :post-blank 0 :post-affiliated 1 :path 
"/home/gk/blog/content-org/programming.org" :mode org-data :CATEGORY 
"programming" :cached t))
(keyword (:key "HUGO_CATEGORIES" :value "programming" :begin 53 :end 85 
:post-blank 1 :post-affiliated 53 :mode nil :granularity element :cached 
t :parent (section (:begin 1 :end 85 :contents-begin 1 :contents-end 84 
:robust-begin 1 :robust-end 82 :post-blank 1 :post-affiliated 1 :mode 
first-section :granularity element :cached t :parent (org-data (:begin 1 
:contents-begin 1 :contents-end 26390 :end 26390 :robust-begin 3 
:robust-end 26388 :post-blank 0 :post-affiliated 1 :path 
"/home/gk/blog/content-org/programming.org" :mode org-data :CATEGORY 
"programming" :cached t))

nil

Emacs : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.38, cairo version 1.17.8)

of 2023-10-02
Package: Org mode version 9.6.10 (release_9.6.10 @ 
/home/gk/.emacs.d/lib/org/lisp/)

Re: Feature request: export form feed as page break

[Marvin Gülker]

Am Sonntag, dem 22. Oktober 2023 schrieb Jambunathan K:
> I am the original author of ox-odt.el.
>
> The page break feature is available as part of
> https://github.com/kjambunathan/org-mode-ox-odt

I took a look at 
https://github.com/kjambunathan/org-mode-ox-odt/blob/master/notes/SNIPPETS.org#improve-support-for-pagebreaks
and indeed, there is a page break feature, but it seems to be exclusive
to this backend. I would prefer it if the page break feature was part of
org’s actual markup and thus work with all backends, including LaTeX,
without backend-specific markup.

> This is a fork of the ODT exporter in Emacs Orgmode.

I heard of it before; for now I think I want to stick with upstream org.
I do keep an eye on this fork in case I need one of its exclusive
features. Since from a technical point, I am mostly writing pretty
boring pure text documents, it worked out until now mostly.

  -MG

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