>> It doesn't help: it should *not* move to that place, since the `* >> Heading` is not a (fillable) paragraph, whereas `fill-forward-paragraph` >> should move to the end of a (fillable) paragraph. > Are you sure it is how it is designed to work? > I just tried a quick test making fill-forward-paragraph-function return > its argument - never fill anything.
Why would you want to do that? In which sense is the region between point and point a fillable paragraph? > Then, M-x fill-region inf-loops. GIGO, eh? >> I'd guess for `fill-region` (and thus indirectly `unfill-paragraph`), >> you'd similar use the `fill-forward-paragraph-function` and >> `fill-region-as-paragraph` hooks to switch to the `emacs-lisp-mode` >> buffer and re-call the function there. > > Kinda, but I am not sure if that's going to work well. > fill-region-as-paragraph assumes that any region can be filled into a > single paragraph. But it is not always possible in Org. For example, > imagine that the region includes code block + something else. The best > Org can do in fill-region-as-paragraph is filling the code block > separately and the rest separately. `fill-region-as-paragraph-function` should not try to outwit its caller: if it's called with a region which doesn't make sense, it's OK for it to output something broken. As I said elsewhere, it's the responsibility of its caller to make sure the region is meaningful (e.g. in Org's case, the caller should make sure it doesn't straddle a code-block boundary). >>> However, in Org's context, filling region as paragraph does not always >>> make sense. >> >> Not all regions make sense, indeed. It's the responsibility of the >> caller of `fill-region-as-paragraph` to make sure the region is indeed >> "a (fillable) paragraph". Usually this is done by calling >> `fill-forward-paragraph` to determine the bounds of the region. > > Is it? The docstring says > > "Fill the region as if it were a single paragraph. > > It never hints that the region SHOULD be a single paragraph. >From where I stand, "as if it were a single paragraph" is saying exactly that. > After all, what is the point of that function if there is fill-paragraph > already. `fill-region-as-paragraph` is used internally in `fill-paragraph` (and `fill-region`). > It ought to do something else. Filling is divided into two tasks: A. Finding the boundaries of "fillable paragraphs". This is what `fill-forward-paragraph-function` is about. B. Filling those "fillable paragraphs". This is what `fill-region-as-paragraph-function` is about. `fill-paragraph` uses A to find the paragraph to fill, and then uses B once. `fill-region` uses A to find the paragraphs and then uses B on each one of the paragraphs. When called via `M-x fill-region-as-paragraph`, the users play the part of A and if they do it poorly, they get what they deserve. >> I'd expect that `fill-region-as-paragraph-function` is usually concerned >> with things like indentation, preserving line-prefixes, preserving >> line-suffixes, etc... > > Well... the default also joins paragraphs together: Why shouldn't it? The caller of the function states "please treat this as a single fillable paragraph, regardless of what it looks like". === Stefan
