emacs-orgmode
[Top][All Lists]
Advanced

[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.



reply via email to

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