emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About 'inline special blocks'


From: Max Nikulin
Subject: Re: About 'inline special blocks'
Date: Tue, 24 May 2022 22:09:33 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1

On 24/05/2022 09:51, Timothy wrote:

To me, this is another reason for comment and #+attr_X lines not to break
paragraphs, as then we can just re-use #+attr_X lines.

I like the idea that comments and attribute lines should not be paragraph separators. I expect, it should alleviate the issue that LaTeX and Org paragraphs may significantly differ. Do somebody has examples when such change will cause negative effects (besides broken compatibility, of course)?

┌────
│ Hi there look at
│ #+attr_X: :prop val
│ inline_mark{some content}
│ and now continuing the paragraph...
└────

However I am afraid that using the same construct for block-level elements and inline object will cause confusion. Consider a paragraph starting from a link. Which attributes belongs to the whole paragraph and which ones should affect the starting link only?

I consider attributes specific to an inline object as a great feature, but I am unsure if it requires special inline object. Would not it be enough to allow attributes for already existing objects (emphasis, links, citations)? It is feasible to require from external tools such as pandoc to support special blocks (likely implemented in lisp code)?

Concerning fear that complicated attributes makes text hardly readable, macros might be a rescue, but it would depend on implementation.

I had an idea to implement proof-of-concept for inline attributes using a special link type and a parse tree filter that transfers attributes to the next object. Unfortunately time related bugs in Emacs appeared to be rather time consuming.

---- >8 ----
#+macro: nofollow [[attr:(:html (:rel "nofollow noopener"))]]

An {{{nofollow}}[[attr:(:html (:title "be careful!"))]][[http://unsafe.com][unsafe link]].
---- 8< ----

Such implementation would allow to test if it convenient enough and whether special blocks are really necessary.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]