emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Merging paragraphs separated by comment lines during export (was: About 'inline special blocks')
Date: Thu, 26 May 2022 10:54:34 +0800	[thread overview]
Message-ID: <875ylt6m1h.fsf@localhost> (raw)
In-Reply-To: <t6lnl9$123b$1@ciao.gmane.io>

Max Nikulin <manikulin@gmail.com> writes:

>> First line
>> # comment
>> Second line
>> 
>> Should we consider a comment as inline object? I suspect that such
>> change will cause unpredictable breakages all around Org and third-party
>> packages.
>
> I believed that comments are stripped before passing to export backend, 
> so I did not expect any problem with inline comments.

You are right. After examining org-export--skip-p and
org-export--prune-tree, I see that all the comments are removed
unconditionally. But then, all we need to do is simply merging
paragraphs separated by a comment with :post-blank = 0 and the first
paragraph having :post-blank = 0. As long as export is concerned it is
simply a question of writing an export filter (Timothy, did you have
anything other than export in mind?)

>>> ---- >8 ----
>>> #+macro: nofollow [[attr:(:html (:rel "nofollow noopener"))]]
>>>
>>> An {{{nofollow}}[[attr:(:html (:title "be
>>> careful!"))]][[http://unsafe.com][unsafe link]].
>>> ---- 8< ----
>> 
>> I am not sure if I like this idea. It seems fine, but I afraid that it
>> will complicate parser at some point. We may want to assign such inline
>> properties to the following object, which is already a pain for
>> affiliated keywords.
>
> Certainly parser should recognize inline attributes, but I do not expect 
> real complications here. Assigning attributes may be performed when AST 
> is ready. Just collect attributes and put them to the following 
> non-attribute object during breadth-first tree transversal. Attributes 
> as the last child is a reason for a warning.

I was mostly thinking about element cache. Dealing with affiliated
keywords caused a lot of pain when I was working on cache. On the other
hand, inline objects are currently parsed together - org-element-context
always parses everything starting from the parent object
:contents-begin. So, maybe it is not going to be as much problem as I
thought.

Another concern about inline attributes is plain-text objects. Consider
the following paragraph:

Some text *bold* plain text. _Underline {{{attribute}}} more text
/italics/ end of underline_.

The object structure will be:
(paragraph
  (plain-text "Some text ")
  (bold
    (plain-text "bold"))
  (plain-text " plain text. ")
  (underline
    (plain-text "Underline ")
    (attribute)
    (plain-text " more text ")
    (italics
      (plain-text "italics"))
    (plain-text " end of underline"))
  (plain-text ".\n"))

So, should the attribute be assigned to " more text "? Just the next
word? What if we have something like

Text {{{attribute to be assigned to "two words"}}}two words but
plain-text element still continues.

Best,
Ihor


  reply	other threads:[~2022-05-26  2:54 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-23 14:30 About 'inline special blocks' Juan Manuel Macías
2022-05-23 15:20 ` Kaushal Modi
2022-05-23 21:06   ` Juan Manuel Macías
2022-05-24  2:36     ` Tim Cross
2022-05-24  2:51       ` Timothy
2022-05-24  6:54         ` Eric S Fraga
2022-05-26  7:30           ` Christian Moe
2022-05-24 15:09         ` Max Nikulin
2022-05-25  7:22           ` Ihor Radchenko
2022-05-25 17:05             ` Max Nikulin
2022-05-26  2:54               ` Ihor Radchenko [this message]
2022-05-24  3:56       ` Ihor Radchenko
2022-05-24 14:05         ` João Pedro
2022-05-26  4:56           ` Ihor Radchenko
2022-05-26 11:30             ` João Pedro
2022-05-26 12:20               ` Ihor Radchenko
2022-05-26 17:35                 ` João Pedro
2022-05-26 21:22                   ` About opening issues vs email [Was: About 'inline special blocks'] Kaushal Modi
2022-05-27  4:24                     ` Ihor Radchenko
2022-05-27  4:36                     ` João Pedro
2022-05-25 13:55         ` About 'inline special blocks' Juan Manuel Macías
2022-06-17  6:28         ` Ihor Radchenko
2022-06-17 19:49           ` Juan Manuel Macías
2022-06-19 12:47   ` Juan Manuel Macías
2022-06-19 19:30     ` Christian Moe
2022-06-19 20:15       ` Juan Manuel Macías
2022-06-19 22:18     ` Tim Cross
2022-06-20 16:57     ` Max Nikulin
2022-06-20 19:06       ` Juan Manuel Macías
2022-06-21 16:39         ` Max Nikulin
2022-06-21 18:19           ` Juan Manuel Macías
2022-06-20 22:46       ` Tim Cross
2022-06-26  4:07         ` Org mode export accessibility (was: About 'inline special blocks') Ihor Radchenko
2022-06-26  6:29           ` Tim Cross
2022-06-26 10:46             ` Org mode export accessibility Juan Manuel Macías
2022-06-26 10:54               ` Ihor Radchenko
2022-06-27 14:40                 ` T.V Raman
2022-06-30  7:53                   ` Ihor Radchenko
2022-07-07 14:18                     ` briangpowell
2022-07-07 14:42                       ` T.V Raman
2022-07-08  4:38                         ` Ihor Radchenko
2022-07-08 13:55                           ` T.V Raman
2022-07-09  3:39                             ` Ihor Radchenko
2022-07-09 13:20                               ` T.V Raman
2022-09-30 11:07                         ` Max Nikulin
2022-09-30 13:29                           ` T.V Raman
2022-09-30 16:43                             ` Max Nikulin
2022-09-30 16:55                               ` T.V Raman
2022-10-01  4:36                             ` Ihor Radchenko
2022-10-01 14:59                               ` T.V Raman
2022-10-02  2:54                               ` Org source in PDF (Re: Org mode export accessibility) Max Nikulin
2022-10-02  3:50                                 ` Timothy
2022-07-07 14:43                       ` Org mode export accessibility T.V Raman
2022-07-07 15:37                       ` T.V Raman
2022-07-08  4:33                       ` Ihor Radchenko
2022-07-08 13:54                         ` T.V Raman

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=875ylt6m1h.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \
    /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).