From: "Gustav Wikström" <gustav@whil.se>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: Bastien Guerry <bzg@gnu.org>,
"emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: RE: attachment: link type export to HTML invalid attach dir
Date: Fri, 14 Feb 2020 07:23:34 +0000 [thread overview]
Message-ID: <HE1PR02MB30338B5559DCD5CAB39E686EDA150@HE1PR02MB3033.eurprd02.prod.outlook.com> (raw)
In-Reply-To: <87imkat451.fsf@nicolasgoaziou.fr>
Hi,
> -----Original Message-----
> From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
> Sent: den 14 februari 2020 01:16
> To: Gustav Wikström <gustav@whil.se>
> Cc: emacs-orgmode@gnu.org; Bastien Guerry <bzg@gnu.org>
> Subject: Re: attachment: link type export to HTML invalid attach dir
>
> Gustav Wikström <gustav@whil.se> writes:
>
> > What makes attachment links not be a core link type?
>
> 1. Org Attach is not loaded by default
> 2. Implementing Org syntax doesn't require to implement attachments
>
> Attachment links are in the same category as Docview links, for
> example.
> There is no "docview" occurrence in "org-element.el". We have been
> there already.
>
> > As I see it we have two categories here: Core = those inside Org
> mode.
> > Not core = those in external libraries. No other distinction needs to
> > be made. If a link type is inside Org mode, let it then use the
> > special properties that Org mode provides.
>
> Sure thing, but you use the wrong ones!
I meant that Core = inside the Org mode repository of source code files. Both Docview and Attachment is, both are mentioned in the manual as part of the system. Both should be able to use :search-option inside the Org element parser.
> > Attachment links need to be treated just as file links in most
> > regards. Since file-links have special logic which attachment links
> > also needs. Thus a reference to attachment in org-element.el. Nothing
> > strange here, nothing breaking and the parser is still self-
> contained.
>
> Attachement links should live only in "org-attach.el": like 99% of
> other links do live in their own library. They do not require a special
> treatment.
>
> Again, the parser is not self-contained if it references org-attach.el.
It doesn't referencen org-attach.el any longer. That reference is removed. What remains is a reference to the string "attachment". You may argue that even that is to much. And I can only agree with that vision if you also state that org-element shouldn't reference the string "file" either. Anything else is a subjective design that puts a sentiment on "more" or "less" importance of link types and how to regard if they're "important" enough to be mentioned. I don't think you want that in org-element any more than I do.
> > Maybe time for Bastien to step in. Because I can't remove the
> > reference to attachment in org-element.el without breaking it's
> > functionality. Which, btw, was broken before adding the reference in
> > org-element.el. The thing that started this discussion in the first
> > place. We're in a better place now.
>
> We're not. The way it is implemented is not correct.
Functionally we are - we have working attachment links that are treated in the same way as file links through out Org mode. Since there is special treatment for file links in Org, attachment links needs the same special treatment to get the same behavior. You might see it as a regression in the design of org-element.el. To which I've already given arguments about why it's not really - and different ways it can be solved - by removing special file-related properties from org-element.el. The added string-reference to attachment links is there because special string-references to file links are there. If special file link references are removed, then clearly attachment links will/should be removed as well.
> For opening link, attachment links should use the :follow link
> parameter. The "following" function can extract the search option, if
> any, and the file name, then call `org-open-file' appropriately. You're
> doing it backwards and modify `org-open-file' instead. Additional links
> are not supposed to modify "ol.el".
Sure, that's a principle I can agree to. And have already mentioned that I will try to refactor that part by giving the :follow function the same abilities as org-open-file currently has. But that won't be completed quite yet.
> For exporting link, it should use the :export link parameter. The
> "exporting" function can extract the search option, if any, and the
> file name. It can then re-create a file link object, and call `org-
> export-data' on it. You're also doing it backwards here and prefer to
> modify each export back-end instead.
Which I've argued about already, saying it will be difficult without having file already being treated the same way. I'm not opposed to doing it that way in the long run. But let it be done for file links first, then attachment links can follow. I don't have the capacity to dig into this on my own.
> > Attachment links works as intended. It would be a pity to have to
> > change that because of your argument that attachment links aren't
> > "core" enough to be mentioned in org-element.el.
>
> I strongly insist that it should be removed. I gave you ways to solve
> the issue. If you need anything else, let me know, but please consider
> implementing them.
In the end, I don't think I can roll back that change without breaking attachment links. For the reasons I've given below. I'm not trying to strong-arm anything here.
/G
next prev parent reply other threads:[~2020-02-14 7:23 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
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 [this message]
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=HE1PR02MB30338B5559DCD5CAB39E686EDA150@HE1PR02MB3033.eurprd02.prod.outlook.com \
--to=gustav@whil.se \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/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).