>> IMNSHO, `fill-paragraph-function` is a pretty bad hook whose intended >> semantics is very unclear, barely more than "do something that would be >> nice to have on `M-q`". > >> So, before we add something similar to `unfill-paragraph` I think we >> should have a clear idea of the problem it should aim to fix. >> As a starting point a clear description of why >> `fill-forward-paragraph-function` and >> `fill-region-as-paragraph-function` aren't sufficient. >> [ My secret hope is that we can fix that problem with hooks that are >> applicable also to `fill-paragraph` and/or `fill-region`. ] > > Let me give you two examples from Org: > > 1. A heading > > * This is a heading, and filling it is not allowed because it juts cannot be > multiline > SCHEDULED: <2026-06-24 Wed> > > If we do try > > * This is a heading, and filling it is not allowed because it juts > cannot be multiline > SCHEDULED: <2026-06-24 Wed> > > Org document is broken unexpectedly, because SCHEDULED line is no longer > recognized.
AFAIU `fill-forward-paragraph-function` should take care of such issues. If it doesn't, maybe there's a bug in the way we use it or the way Org defines it (where "it" is `fill-forward-paragraph-function`). > 2. A source block > > #+begin_src emacs-lisp > (if t > (message "Hello!") > (error "This should not happen!")) > #+end_src > > When filling the source block, Org expedites part of the process to > emacs-lisp-mode - something fill/unfill-paragraph has no idea about. Expedites part of the process ... of what exactly? I think I'm missing some details to understand what is the issue. > Similar case will be with various programming modes, especially when > those modes need to take special care about indentation (e.g. docstring > indentation in Elisp). Supposedly `fill-region-as-paragraph-function` should be able to handle those kinds of constraints. === Stefan
