[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/port
From: |
Visuwesh |
Subject: |
Re: FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)] |
Date: |
Tue, 20 Sep 2022 18:09:57 +0530 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
[செவ்வாய் செப்டம்பர் 20, 2022] Ihor Radchenko wrote:
>> 1. When you want to end a line with a link and continue text in the
>> next line. You don't care about the export since it will be
>> taken care of properly.
>> 2. When reflowing text with inline latex in them. You adjust the
>> line width so that it looks like 80 columns are present in a
>> single line. With hard-newlines, this becomes a very easy job
>> without with you have to isolate the line of interest into a
>> separate paragraph, then do the manual reflow, rinse and repeat.
>
> This sounds as a reasonable use case. However, the Emacs definition of
> hard newlines also involves re-defining paragraph breaks. I do not think
> that it is a good idea for Org to alter Org paragraph syntax depending
> on `use-hard-newlines' - it will create too much confusion when Org
> documents are opened outside Emacs.
I do not think it is necessary for org to recognise hard-newlines as a
paragraph break either since, after all, the presence of hard-newlines
is ephemeral.
>> 3. When writing a list, you give a short description at the top.
>> Then continue writing down below like this without the need to
>> insert a empty line after the first line.
>
> Note that _not_ having an empty line after the first line can be
> misleading. In Org syntax, absence of line will merge description and
> the text below into a single paragraph. It will, for example, affect
> export.
I do get your point, but sometimes there are situations where merging
does not cause confusion and I would like to have the ability to write
lists like no. 3. This is more true when you, like me, treat org-mode
as a major-mode which enhances plain text files. If i was exporting,
then I wouldn't rely on org-mode handling hard-newlines (kind of like
how HTML behaves wrt requiring <br>).
>> My point is that there are several instances where you need a solution
>> that is less aggressive than \\ and hard-newlines hit that sweet spot
>> perfectly.
>
> All in all, I feel that fully respecting `use-hard-newlines' in Org is
> not a good idea. We can do it partially (for filling), but I am afraid
> that it may create some confusion.
I am not sure what you mean by confusion here: those who have
`use-hard-newlines' turned on are explicitly asking for it. If
anything, I was confused when I found org-mode did not recognise
hard-newlines.
>> - (fill-region-as-paragraph c end justify)
>> + (fill-region c end justify)
>
> There are 3 calls to `fill-region-as-paragraph' inside
> `org-fill-element'. If we decide to support `use-hard-newlines'
> partially, all 3 calls should probably be replaced.
AFAICT, the rest two are comments (though I cannot tell the difference
between "comment" and "comment-block"). I replaced the one in paragraph
since that was where lack of hard-newlines support bit me.