From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: "Gustav Wikström" <gustav@whil.se>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: attachment: link type export to HTML invalid attach dir
Date: Wed, 05 Feb 2020 17:54:00 +0100 [thread overview]
Message-ID: <87y2th0yc7.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <HE1PR02MB303324C053A518999533F379DA090@HE1PR02MB3033.eurprd02.prod.outlook.com> ("Gustav Wikström"'s message of "Sat, 25 Jan 2020 11:34:35 +0000")
Hello,
Gustav Wikström <gustav@whil.se> writes:
> That was kind of what I was trying to do, by allowing subtyping, so
> that the parser would be more knowledgeable about particular types of
> links, by allowing extended attributes. Maybe not implemented in the
> most extensible way though I'll admit.
Just to be clear, I firmly believe Element library should be as
low-level as possible. Ideally (we're not there yet), it should not
depend on any other part of Org. It should be the step (largely) above
"re-search-forward".
So, extending the parser to include knowledge to some other library in
Org is not an option. Element is expected to dumbly stick to Org syntax,
without knowing what it means.
> My suggestion to the link parser would be to have the following properties as the catch-all properties for links:
> - type :: Which type of link protocol applies. E.g. file, http, ftp, attachment, duckduckgo (ex. for a custom link abbreviation to search ddg)
> - raw-path :: The path to use for the particular protocol. Would contain everything in the link following "protocol:"
> - format :: Which format the link has. Plain, bracket or angular bracket
Barring custom link abbreviations, this is already the case.
> - description :: The description part of the link ([[protocol:path][description]])
Description is not meaningful here. This is parsed content.
> - begin, end, post-blank :: The default properties used for all elements. Not sure if contents-begin and contents-end are a part here as well.
They are when the link has contents, i.e., a description.
> As you've stated previously, from a performance perspective maybe it
> will be best to not expand the specific properties and instead let the
> expansion of those be handled in code by the link type owner (e.g.
> org-attach.el for attachment links).
More than performance, this is a design issue.
> Ah yes. Just briefly looking at the docview code. Docview doesn't seem
> to use the parser when extracting information about that "go to page"
> information from the link. Which means docview links doesn't really
> care how the link information is encoded in the parser anyways.
Indeed. However, higher level functions, e.g., org-open-link, do care
about it and ensure that "ol-docview.el" really processes a link.
> Maybe if docview were allowed to encode custom docview information
> into the parsed link in the parser it and others could reused that
> encoded information later? Docview would be able to add
> a ":go-to-page" option, for example. Just a thought.
I'm quite sure this is a wrong way to go.
> Most link types probably won't need custom link properties anyways.
> But could maybe let the parser know stuff by use of higher order
> functions? Or push for being important enough to be included into Org
> and allowed to be known by the parser.
Only syntax changes can go into the parser. Attachment links are regular
links, not something that requires extending Org's syntax. Note that
this is not the case of file links, which have a special syntax, e.g.,
[[./cat.jpg]].
> Ok, got it. Thanks for explaining. I'll admit it hasn't been totally
> clear to me what the best way forward is. After refreshing my
> understanding on links the conclusion I came to was that link
> abbreviations in its current form was not a fitting concept for
> attachment links. Attachments are pretty much similar to file links
> though, so even if my intention isn't to blur the meaning they will
> and should be treated very similar, since functionality is so similar.
Functionality may be familiar, but their syntax is not the same,
therefore, the differences should be handled elsewhere.
> Speaking from the perspective of attachment links, if there were
> a file link type exporter function available that could be used by
> attachment links without code duplication.
Where would live that function? ox.el is not an option since every
exporter treats file links differently.
As suggested already (I think) we could add a phase in ox.el that would
expand attachment links into their file link counterpart automatically.
This would avoid adding specific code in every export back-end. However,
export back-end would miss the opportunity to handle attachment links
specifically. This is one way or the other.
> Yes, and the function that implements that would also need the user
> argument as input. In addition to the link path.
Patch welcome. I see no objection to extending :follow link parameter in
"ol.el".
> Anyways, patch attached that makes org-element not know about
> attachments any longer, and moves most of the responsibility to
> org-attach.el. The exporters still needs to know to use the new
> function inside org-attach.el though.
Thank you. Please apply it.
Now we can try improving the situation for exporters.
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2020-02-05 16:54 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-21 7:53 FW: [RFC] Link-type for attachments, more attach options Gustav Wikström
2018-11-01 1:45 ` tumashu
2018-11-02 22:40 ` Gustav Wikström
2018-11-01 16:00 ` Marco Wahl
2018-11-02 23:07 ` Gustav Wikström
2018-11-03 3:37 ` Ihor Radchenko
2018-11-17 12:13 ` Gustav Wikström
2018-11-18 0:42 ` Ihor Radchenko
2018-11-18 8:57 ` Gustav Wikström
2018-11-20 14:00 ` Ihor Radchenko
2018-11-24 13:56 ` Gustav Wikström
2018-12-14 2:16 ` Ihor Radchenko
2019-05-26 22:24 ` Gustav Wikström
2018-11-04 22:37 ` Nicolas Goaziou
2018-11-17 11:58 ` Gustav Wikström
[not found] ` <PR1PR02MB47322711B7F7B7142D156F54DADE0@PR1PR02MB4732.eurprd02.prod.outlook.com>
2018-11-19 23:52 ` Nicolas Goaziou
2018-11-25 21:13 ` Gustav Wikström
2018-11-27 9:39 ` Nicolas Goaziou
2019-05-26 23:05 ` Gustav Wikström
2019-06-15 13:29 ` Nicolas Goaziou
2019-06-15 15:38 ` Bastien
2019-06-30 6:03 ` Gustav Wikström
2019-07-06 21:46 ` Nicolas Goaziou
2019-07-07 18:38 ` Gustav Wikström
2019-07-08 10:47 ` Marco Wahl
2019-07-09 10:16 ` Nicolas Goaziou
2019-07-27 14:56 ` Ihor Radchenko
2019-07-28 20:39 ` Gustav Wikström
2019-07-28 23:20 ` Ihor Radchenko
2019-01-04 12:21 ` FW: " Feng Shu
2019-05-26 23:15 ` Gustav Wikström
2019-12-12 5:21 ` stardiviner
2019-12-12 6:12 ` Gustav Wikström
2019-12-12 9:52 ` stardiviner
2019-12-12 19:42 ` Gustav Wikström
2019-12-13 13:38 ` stardiviner
2019-12-13 21:37 ` Gustav Wikström
2019-12-13 22:15 ` Gustav Wikström
2019-12-15 4:14 ` stardiviner
2019-12-15 9:29 ` stardiviner
2019-12-15 10:06 ` Gustav Wikström
2019-12-15 14:26 ` stardiviner
2019-12-15 20:41 ` Gustav Wikström
2019-12-16 3:38 ` stardiviner
2019-12-16 11:21 ` stardiviner
2019-12-17 4:27 ` stardiviner
2020-01-13 12:24 ` attachment: link type export to HTML invalid attach dir stardiviner
2020-01-14 3:27 ` Gustav Wikström
2020-01-14 5:04 ` stardiviner
2020-01-14 20:58 ` Gustav Wikström
2020-01-15 5:53 ` stardiviner
2020-01-15 19:48 ` Gustav Wikström
2020-01-16 11:06 ` stardiviner
2020-01-16 13:18 ` Nicolas Goaziou
2020-01-16 21:42 ` Gustav Wikström
2020-01-16 23:07 ` Gustav Wikström
2020-01-17 0:39 ` Nicolas Goaziou
2020-01-17 14:29 ` Gustav Wikström
2020-01-17 18:36 ` Gustav Wikström
2020-01-18 1:13 ` Gustav Wikström
2020-01-18 11:34 ` Nicolas Goaziou
2020-01-18 15:14 ` Gustav Wikström
2020-01-19 21:12 ` Nicolas Goaziou
2020-01-19 23:29 ` Gustav Wikström
2020-01-20 1:25 ` Nicolas Goaziou
2020-01-25 11:34 ` Gustav Wikström
2020-02-05 16:54 ` Nicolas Goaziou [this message]
2020-02-06 20:55 ` Gustav Wikström
2020-02-07 14:28 ` Nicolas Goaziou
2020-02-08 15:39 ` Gustav Wikström
2020-02-13 20:41 ` Nicolas Goaziou
2020-02-13 21:11 ` Gustav Wikström
2020-02-13 21:37 ` Nicolas Goaziou
2020-02-13 22:07 ` Gustav Wikström
2020-02-14 0:16 ` Nicolas Goaziou
2020-02-14 7:23 ` Gustav Wikström
2020-02-14 2:42 ` Kyle Meyer
2020-02-14 7:35 ` Gustav Wikström
2020-02-14 7:41 ` Gustav Wikström
2020-02-14 11:06 ` Bastien
2020-02-14 17:12 ` Nicolas Goaziou
2020-02-14 20:33 ` Bastien
2020-02-15 18:08 ` Nicolas Goaziou
2020-02-15 23:04 ` Kyle Meyer
2020-02-16 8:51 ` Nicolas Goaziou
2020-02-16 23:59 ` Bastien
2020-02-17 9:37 ` Nicolas Goaziou
2020-02-17 10:25 ` Bastien
2020-02-16 23:58 ` Bastien
2020-02-17 10:32 ` Nicolas Goaziou
2020-02-17 10:53 ` Bastien
2020-02-20 9:20 ` Nicolas Goaziou
2020-02-20 10:20 ` Bastien
2020-02-22 12:58 ` Nicolas Goaziou
2020-02-22 13:32 ` Bastien
2020-02-25 23:36 ` Gustav Wikström
2020-02-26 15:22 ` Nicolas Goaziou
2020-02-27 19:02 ` Gustav Wikström
2020-02-28 0:37 ` Nicolas Goaziou
2020-02-13 21:57 ` Gustav Wikström
2020-02-14 10:02 ` Bastien
2020-01-13 13:41 ` FW: [RFC] Link-type for attachments, more attach options stardiviner
2020-01-14 21:17 ` Gustav Wikström
2020-01-15 6:20 ` stardiviner
2020-01-15 22:42 ` Gustav Wikström
2020-01-16 11:15 ` stardiviner
2020-01-18 14:56 ` stardiviner
2020-01-18 15:30 ` Gustav Wikström
2020-01-19 4:28 ` stardiviner
2020-01-19 9:53 ` Gustav Wikström
2020-01-17 7:39 ` Missing `org-attach-set-inherit' function stardiviner
2020-01-17 16:31 ` Gustav Wikström
2020-01-18 14:54 ` stardiviner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y2th0yc7.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=emacs-orgmode@gnu.org \
--cc=gustav@whil.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).