On Thu Dec 5, 2024 at 3:47 PM CET, onf wrote:
> On Thu Dec 5, 2024 at 3:57 AM CET, G. Branden Robinson wrote:
> > At 2024-12-04T14:46:00-0500, Peter Schaffter wrote:
> > > How about
> > >
> > > .ne d Spring the next vertical postion trap if it is nearer than
> > > distance d (default sca
> `sp` has a noteworthy limitation.
>
> .sp dist [...]
> dist is ignored inside a diversion.
This is not true. (See below.)
> Check the final sentence. `ne` inherits this limitation. In
> a diversion, you can ask `ne` for tons of space, but you'll
> only get 1v at a time. Eve
Hi Branden,
On Thu Dec 5, 2024 at 3:57 AM CET, G. Branden Robinson wrote:
> At 2024-12-04T14:46:00-0500, Peter Schaffter wrote:
> > How about
> >
> > .ne d Spring the next vertical postion trap if it is nearer than
> > distance d (default scaling unit v). In the absence of a
> >
Hi Peter,
At 2024-12-04T14:46:00-0500, Peter Schaffter wrote:
> How about
>
> .ne d Spring the next vertical postion trap if it is nearer than
> distance d (default scaling unit v). In the absence of a
> trap, break to a new page if page bottom is nearer than d.
This is the ne
Hi Steve,
At 2024-12-04T13:28:48-0500, Steve Izma wrote:
> On Wed, Dec 04, 2024 at 12:00:52PM -0500, Douglas McIlroy wrote:
> > Subject: Re: Differences in `ne` and `bp` line-breaking behavior
> >
> > I don't see this wording as an improvement:
> >
> > &g
Hi Doug,
At 2024-12-04T12:00:52-0500, Douglas McIlroy wrote:
> I don't see this wording as an improvement:
>
> > .ne dAdvance drawing position to the next vertical
> >position trap and spring the trap, if it is
> >nearer than distance d (default scaling unit v).
>
>
On Wed Dec 4, 2024 at 6:00 PM CET, Douglas McIlroy wrote:
> I don't see this wording as an improvement:
>
> > .ne dAdvance drawing position to the next vertical
> >position trap and spring the trap, if it is
> >nearer than distance d (default scaling unit v).
>
> The p
On Wed Dec 4, 2024 at 8:46 PM CET, Peter Schaffter wrote:
> On Wed, Dec 04, 2024, Douglas McIlroy wrote:
> > Also .ne is effective in the absence of traps, a fact that groff(7)
> > misses, too.
>
> How about
>
> .ne d Spring the next vertical postion trap if it is nearer than
> distance d
> Also .ne is effective in the absence of traps, a fact
> that groff(7) misses, too.
In groff at least, the page bottom acts like a trap,
consistent with register .t (distance to the next trap)
showing the distance to the page bottom in the absence
of any other (nearer) traps.
On Wed, Dec 04, 2024, Douglas McIlroy wrote:
> I don't see this wording as an improvement:
>
> > .ne dAdvance drawing position to the next vertical
> >position trap and spring the trap, if it is
> >nearer than distance d (default scaling unit v).
>
> The proposal use
On Wed, Dec 04, 2024 at 12:00:52PM -0500, Douglas McIlroy wrote:
> Subject: Re: Differences in `ne` and `bp` line-breaking behavior
>
> I don't see this wording as an improvement:
>
> > .ne dAdvance drawing position to the next vertical
> >position
I don't see this wording as an improvement:
> .ne dAdvance drawing position to the next vertical
>position trap and spring the trap, if it is
>nearer than distance d (default scaling unit v).
The proposal uses nonstandard terminology ("drawing position"),
and is ambi
At 2024-12-04T00:08:23+0100, onf wrote:
> On Tue Dec 3, 2024 at 11:56 PM CET, Tadziu Hoffmann wrote:
> > I was thinking of something similar to
> >
> > .ne dAdvance drawing position to the next vertical
> >position trap and spring the trap, if it is
> >nearer than dist
On Tue Dec 3, 2024 at 11:56 PM CET, Tadziu Hoffmann wrote:
> I was thinking of something similar to
>
> .ne dAdvance drawing position to the next vertical
>position trap and spring the trap, if it is
>nearer than distance d (default scaling unit v).
>
> but I'm not sur
> Later in the same page we have this:
> [...]
> Does that cover the base in question? The request synopses are
> supposed to be really terse, following the CSTR #54 model and
> serve as a refresher for the experienced. The basic fact that
> moving the drawing position to (or past) a vertical
On Tue Dec 3, 2024 at 3:12 PM CET, Douglas McIlroy wrote:
> >> I invented .ne 55 years ago and have never heard a complaint about its
> >> design before. It is not a conditional .bp, because that would case a
> >> line break, which .ne never does, nor should.
>
> > I know it does not behave like a
>> I invented .ne 55 years ago and have never heard a complaint about its
>> design before. It is not a conditional .bp, because that would case a
>> line break, which .ne never does, nor should.
> I know it does not behave like a conditional `bp` (that was my
> entire argument, after all). I have
Hi Tadziu,
At 2024-12-03T00:22:40+0100, Tadziu Hoffmann wrote:
> >.ne Advance drawing position to the next vertical position
> > trap if it is nearer than one vee.
> >.ne d Advance drawing position to the next vertical position
> > trap i
>.ne Advance drawing position to the next vertical position
> trap if it is nearer than one vee.
>.ne d Advance drawing position to the next vertical position
> trap if it is nearer than distance d (default scaling
> uni
Hi Branden,
On Mon Dec 2, 2024 at 9:56 PM CET, G. Branden Robinson wrote:
> I therefore think our description of `ne` in groff(7) pretty badly needs
> revision.
>
> Here's what it says now.
>
>.ne Break page if distance to next page location trap is
> less than one v
On Mon Dec 2, 2024 at 7:05 PM CET, Douglas McIlroy wrote:
> > I have discovered recently that `ne` and `bp` behave differently in
> > regards to pending input lines. `bp` breaks such lines, while `ne`
> > does not. In practice this means that `ne` does not behave like a
> > conditional `bp` as one
At 2024-12-02T13:05:50-0500, Douglas McIlroy wrote:
> > I have discovered recently that `ne` and `bp` behave differently in
> > regards to pending input lines. `bp` breaks such lines, while `ne`
> > does not. In practice this means that `ne` does not behave like a
> > conditional `bp` as one would
On Mon Dec 2, 2024 at 7:19 PM CET, Tadziu Hoffmann wrote:
> > > I have discovered recently that `ne` and `bp` behave differently in
> > > regards to pending input lines. `bp` breaks such lines, while `ne`
> > > does not. In practice this means that `ne` does not behave like a
> > > conditional `bp`
On Sunday, 1 December 2024 23:51:22 GMT G. Branden Robinson wrote:
> I don't agree with this change, because it's not necessary. Formatter
> requests are primitive things. Most requests don't also perform breaks.
> Only a handful do. Those that do support the no-break control character
> to _sch
Re: Differences in `ne` and `bp` line-breaking behavior
> I have discovered recently that `ne` and `bp` behave differently in
> regards to pending input lines. `bp` breaks such lines, while `ne`
> does not. In practice this means that `ne` does not behave like a
> conditional `bp`
> > I have discovered recently that `ne` and `bp` behave differently in
> > regards to pending input lines. `bp` breaks such lines, while `ne`
> > does not. In practice this means that `ne` does not behave like a
> > conditional `bp` as one would reasonably expect.
>
> I invented .ne 55 years ag
On Mon Dec 2, 2024 at 5:54 AM CET, G. Branden Robinson wrote:
> At 2024-12-01T22:17:47-0600, Dave Kemper wrote:
> > On Sun, Dec 1, 2024 at 8:27 PM G. Branden Robinson
> > wrote:
> > > By contrast, your sample size for `ne` misuse is one--yourself.
> > > Formerly two, before I came to understand th
Hi Branden,
On Mon Dec 2, 2024 at 5:27 AM CET, G. Branden Robinson wrote:
> At 2024-12-02T04:45:27+0100, onf wrote:
> > We seem to interpret the word 'page break' differently. I interpret
> > it the way it's used in the groff manpage, that is, as a way of saying
> > "end the page and start a new
At 2024-12-02T05:15:36+0100, onf wrote:
> page break = end line, end page
[...]
> page break = end page
>
> Please correct me if I'm wrong.
I don't think we're to the point yet where I can say you're right or
wrong.
> Consulting the web, a 'page break' is variously defined as one of:
> start o
At 2024-12-01T22:17:47-0600, Dave Kemper wrote:
> On Sun, Dec 1, 2024 at 8:27 PM G. Branden Robinson
> wrote:
> > By contrast, your sample size for `ne` misuse is one--yourself.
> > Formerly two, before I came to understand the request.
>
> Well, I agree with onf's point that .ne's behavior defie
Hi onf,
At 2024-12-02T04:45:27+0100, onf wrote:
> On Mon Dec 2, 2024 at 3:26 AM CET, G. Branden Robinson wrote:
> > > One two three
> > > four five six
> > > 'bp
> > > seven eight nine
[...]
> > > It's obvious here that 'bp breaks page IMMEDIATELY, not when the
> > > .br
> >
> > Eh?
> >
>
On Sun, Dec 1, 2024 at 8:27 PM G. Branden Robinson
wrote:
> By contrast, your sample size for `ne` misuse is one--yourself.
> Formerly two, before I came to understand the request.
Well, I agree with onf's point that .ne's behavior defies user
expectation, so you can lump me in with that sample.
Reading your message for at least the third time, I conclude that:
On Mon Dec 2, 2024 at 3:26 AM CET, G. Branden Robinson wrote:
> [...]
> > $ nroff << EOF | sed -E 's/^/./'
> > .pl 3
> > .fi
> > One two three
> > four five six
> > 'bp
> > seven eight nine
> > .br
> > eleven twel
On Mon Dec 2, 2024 at 3:26 AM CET, G. Branden Robinson wrote:
> [...]
> > $ nroff << EOF | sed -E 's/^/./'
> > .pl 3
> > .fi
> > One two three
> > four five six
> > 'bp
> > seven eight nine
> > .br
> > eleven twelve.
> > EOF
> > output:
> > .
> > .
> > .
> > .One two thr
Hi onf,
At 2024-12-02T02:26:12+0100, onf wrote:
> D'oh. I am sure I confused you even more. I meant to say either: To
> summarize, `ne` would break line if not in compatibility mode and
> called with the regular control character.
>
> ... or ...
> To summarize, `ne` would NOT break line if
>
Hi onf,
At 2024-12-02T02:14:56+0100, onf wrote:
> No changes to groff are, strictly speaking, necessary.
> Your planned changes to .ad aren't necessary by the same logic either.
> But you desire them anyway because they make groff's behavior more
> reasonable. The same desire has motivated my prop
On Mon Dec 2, 2024 at 2:14 AM CET, onf wrote:
> To summarize, `ne` would break line if
> a) in compatibility mode
> b) not in compatibility mode and called with the regular control
> character
D'oh. I am sure I confused you even more. I meant to say either:
To summarize, `ne` would brea
Hi Branden,
On Mon Dec 2, 2024 at 12:51 AM CET, G. Branden Robinson wrote:
> At 2024-12-01T23:06:41+0100, onf wrote:
> > I propose the following changes to make their behavior consistent:
> >
> > 1. `ne` breaks line before breaking the page as `bp` does
> > 2. `ne` does not break line before br
Hi onf,
At 2024-12-01T23:06:41+0100, onf wrote:
> I have discovered recently that `ne` and `bp` behave differently in
> regards to pending input lines. `bp` breaks such lines, while `ne`
> does not. In practice this means that `ne` does not behave like a
> conditional `bp` as one would reasonably
39 matches
Mail list logo
