From: Psionic K <psionik@positron.solutions>
To: Samuel Wales <samologist@gmail.com>
Cc: Psionic K <psionik@positron.solutions>,
Ihor Radchenko <yantar92@posteo.net>,
emacs-orgmode@gnu.org
Subject: Re: org-(un)fill-buffer
Date: Thu, 11 Jan 2024 10:48:35 +0900 [thread overview]
Message-ID: <CADQMGAQbqshrY+QL54kTmXmXm0OQ7aVNJciQUHoyKPviPxb0-Q@mail.gmail.com> (raw)
In-Reply-To: <CAJcAo8sE47jtmkeCvkgHz+UNhoqWjzvkyiU1CxsHz-2jmnswPw@mail.gmail.com>
> 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
--
남백호
대표 겸 공동 창업자
포지트론
prev parent reply other threads:[~2024-01-11 1:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-10 9:40 org-(un)fill-buffer Psionic K
2024-01-10 12:34 ` org-(un)fill-buffer Ihor Radchenko
2024-01-10 14:04 ` org-(un)fill-buffer Psionic K
2024-01-10 14:26 ` org-(un)fill-buffer Psionic K
2024-01-10 15:50 ` org-(un)fill-buffer Ihor Radchenko
2024-01-10 16:22 ` org-(un)fill-buffer Psionic K
2024-01-10 16:36 ` fill-region-as-paragraph does not respect fill-paragraph-function (was: org-(un)fill-buffer) Ihor Radchenko
2024-01-11 1:12 ` org-(un)fill-buffer Samuel Wales
2024-01-11 1:48 ` Psionic K [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADQMGAQbqshrY+QL54kTmXmXm0OQ7aVNJciQUHoyKPviPxb0-Q@mail.gmail.com \
--to=psionik@positron.solutions \
--cc=emacs-orgmode@gnu.org \
--cc=samologist@gmail.com \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).