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