FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)]

FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Visuwesh]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

     https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.
------------------------------------------------------------------------

Hard-newlines [1] are an excellent way to inform Emacs to stop refilling
lines.  In a way, this serves a similar purpose to org's \\ but with a
major difference being that hard-newlines are not saved to file.  There
are several cases where this is the desired behaviour:
    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.
    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.

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.
I currently don't have a git checkout of org-mode handy so cannot
produce a patch wrt master branch but changing
`fill-region-as-paragraph' to `fill-region' does the job, as in

diff --git a/lisp/org/org.el b/lisp/org/org.el
index 6f92cdeab5..d53c8c0243 100644
--- a/lisp/org/org.el
+++ b/lisp/org/org.el
@@ -19580,7 +19580,7 @@ org-fill-element
 					      (org-element-context))))
 		     (push (point) cuts)))
 		 (dolist (c (delq end cuts))
-		   (fill-region-as-paragraph c end justify)
+		   (fill-region c end justify)
 		   (setq end c))))
 	     t)))
 	;; Contents of `comment-block' type elements should be

       
1. See C-h f use-hard-newlines RET

Emacs  : GNU Emacs 29.0.50 (build 12, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
 of 2022-09-17
Package: Org mode version 9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)

Re: FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Ihor Radchenko]

Visuwesh <visuweshm@gmail.com> writes:

> Hard-newlines [1] are an excellent way to inform Emacs to stop refilling
> lines.  In a way, this serves a similar purpose to org's \\ but with a
> major difference being that hard-newlines are not saved to file.  There
> are several cases where this is the desired behaviour:
>     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.

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

> 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'd like to hear what others think about this.

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

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Visuwesh]

[செவ்வாய் செப்டம்பர் 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.

Re: FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Ihor Radchenko]

Visuwesh <visuweshm@gmail.com> writes:

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

Let me clarify.

Current state of affairs is: Org ignores `use-hard-newlines'
Proposed: Org sometimes ignores `use-hard-newline' and sometimes not.

I do believe that what you suggest is a good idea (respecting
`use-hard-newlines' when filling). However, I notice that some people
may be more confused if we implement this FR compared to the existing
situation. So, I am asking for feedback from other users instead of
accepting the FR.

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

# This is
# a comment

#+begin_comment
This is a
comment block.
#+end_comment

See 13.6 Comment Lines section of the manual.

I do not see why `use-hard-newline' should affect normal paragraphs but
not comments.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Visuwesh]

[செவ்வாய் செப்டம்பர் 20, 2022] Ihor Radchenko wrote:

>>> 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.
>
> Let me clarify.
>
> Current state of affairs is: Org ignores `use-hard-newlines'
> Proposed: Org sometimes ignores `use-hard-newline' and sometimes not.
>
> I do believe that what you suggest is a good idea (respecting
> `use-hard-newlines' when filling). However, I notice that some people
> may be more confused if we implement this FR compared to the existing
> situation. So, I am asking for feedback from other users instead of
> accepting the FR.

My point is that I don't see how this is confusing when the user who
turns on use-hard-newlines knows all its caveats, but like you say, lets
see what others say.

>> 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.
>
> [...]
>
> I do not see why `use-hard-newline' should affect normal paragraphs but
> not comments.

I phrased my poorly.  I did not look at the calls of
fill-paragraph-as-region simply because the I hadn't tried to use
hard-newlines in comments.  I agree that we should support it comments
too.