Re: org-(un)fill-buffer

[Psionic K <psionik@positron.solutions>]

> smart fill prefix reliably.  is that possible now?

It's reasonably complete for several documents I'm converting, such as
the transient showcase.  Visual fill requires two modes right now:

1. visual-line-mode (usually with visual-fill-column-mode as well)
2. adaptive-wrap-prefix-mode

Updating documents to this intended useage manner required an
"unfill."  I started off with the unfill package, which works by
setting fill-column to most-positive-fixnum.  Implementing an unfill
buffer command uncovered the issue with fill-region in org mode.


On Thu, Jan 11, 2024 at 10:12 AM Samuel Wales <samologist@gmail.com> wrote:
>
> i lost track of all the visual fill stuff vs. emacs native filling vs.
> org filling vs. filladapt back before visual filling was able to fill
> with both a fill column and a reasonably smart fill prefix reliably.
> is that possible now?
>
> also, if a new command is to be introduced, presumably it would work
> on subtrees, paragraphs, lists, and regions, so that you could have it
> not apply to informal non-org lists or code that is not in a source
> block etc.
>
> met with alex today
> yesterday he wasn't available
>   even thuogh he said he would be
>
>
> On 1/10/24, Psionic K <psionik@positron.solutions> wrote:
> > If I run fill-region on a buffer, there's a lot of errors where the
> > lack of element awareness means filling is attempted on text that does
> > not fill properly, such as property drawers, keywords, and even
> > src-blocks without newline separations.  The result requires way too
> > much cleanup.
> >
> > It is critical to be able to unfill documents for people to migrate
> > off of hard newlines and onto visual line mode with variable pitched
> > fonts.
> >
> > I could probably convert this to a region-based command and we could
> > shadow fill-region.  It might be slightly tricky to deal with the
> > region if it overlaps elements, but if I had to do it now, I would
> > make the inclusion of part of an element include all of that element.
> >
> > On Thu, Jan 11, 2024 at 12:47 AM Ihor Radchenko <yantar92@posteo.net>
> > wrote:
> >>
> >> Psionic K <psionik@positron.solutions> writes:
> >>
> >> >> You may instead just run
> >> >> (let ((fill-column most-positive-fixnum)) (fill-region (point-min)
> >> >> (point-max)))
> >> > No.  That will have to be run manually on every element and every line
> >> > of every list.  I suppose let's just not talk about it further and
> >> > I'll submit a patch so there's no confusion.
> >>
> >> May you please elaborate what is wrong with `fill-region'?
> >>
> >> > This is the org-fill-buffer command, done generically for people who
> >> > want
> >> > to fill or unfill the entire buffer, as is required when alternating
> >> > between hard newline filling and visual line mode filling.
> >> > ...
> >> > * lisp/org.el: (org-fill-buffer) this command walks the tree and will
> >> > call fill-paragraph on every paragraph or plain-list element, enabling
> >> > the user to quickly cycle between hard newlines or visual-line-mode.
> >> > They can also adjust the fill, such as after removing indentation.
> >>
> >> I'd rather make use of the existing Emacs toggles that control filling,
> >> so that `fill-region' works as expected.
> >>
> >> --
> >> Ihor Radchenko // yantar92,
> >> 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>
> >
> >
> >
> > --
> >
> > 남백호
> > 대표 겸 공동 창업자
> > 포지트론
> >
> >
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com



-- 

남백호
대표 겸 공동 창업자
포지트론