From: Max Nikulin <firstname.lastname@example.org>
Cc: Matt Beshara <email@example.com>
Subject: Re: Should page break (^L) work as paragraph element separator and be included into Org syntax? (was: [BUG] org-fill-paragraph doesn't handle ^L correctly)
Date: Tue, 27 Sep 2022 17:48:13 +0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 27/09/2022 03:13, Tim Cross wrote:
> Max Nikulin writes:
>> On 26/09/2022 18:39, Ihor Radchenko wrote:
>>> Should we add page break (^L) to our syntax? It sounds like a reasonable
>>> addition for a text-based markup.
>> I do not have strong opinion. It is a control character while I prefer explicit markup and
>> printable characters or commands in such case. On the other hand the character is widely
>> used in .el files.
>> Users may expect \newline when ^L is exported to LaTeX.
> I think I'm with you as well. I don't have a strong opinion and while
> personally, I don't like control characters used as part of the syntax,
> ^L is often used in elisp files, so ......
Matt, could you, please, provide some details concerning your use case
for ^L in Org files? Even if nothing will change this time, it may
affect later decisions.
On 27/09/2022 13:21, Robert Klein wrote:
> On Tue, 27 Sep 2022 01:10:49 +1000
> Matt Beshara wrote:
>> Fair enough. If the consensus from others is that ^L should be
>> recognised as a paragraph separator and the code is eventually
>> written to make that work, that would be nice, but as it stands I
>> can just start adding newlines after ^L.
> Actually ^L is a *page* separator (to be exact “FORM FEED”).
I have realized that page separator for plain text is not necessary
paragraph separator. The same paragraph may continue on the next page.
It makes things more tricky. ^L should be kept on its own line while
text around should be wrapped.
However from a discussion happened a year ago I concluded that it may be
not so trivial to tune `org-fill-element' for special cases.
Timothy. Re: [PATCH] Don't fill displayed equations. Sun, 03 Oct 2021
16:50:54 +0800. https://email@example.com
next prev parent reply other threads:[~2022-09-27 10:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-24 23:39 [BUG] org-fill-paragraph doesn't handle ^L correctly [9.5.4 (release_9.5.4-19-g4dff42 @ /home/matt/Code/emacs/lisp/org/)] Matt Beshara
2022-09-26 11:39 ` Should page break (^L) work as paragraph element separator and be included into Org syntax? (was: [BUG] org-fill-paragraph doesn't handle ^L correctly [9.5.4 (release_9.5.4-19-g4dff42 @ /home/matt/Code/emacs/lisp/org/)]) Ihor Radchenko
2022-09-26 15:10 ` Matt Beshara
2022-09-27 6:21 ` Robert Klein
2022-09-26 16:13 ` Max Nikulin
2022-09-26 20:13 ` Tim Cross
2022-09-27 10:48 ` Max Nikulin [this message]
2022-09-28 1:00 ` Should page break (^L) work as paragraph element separator and be included into Org syntax? (was: [BUG] org-fill-paragraph doesn't handle ^L correctly) Ihor Radchenko
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).