Follow-up Comment #8, bug #66447 (group groff):

[comment #7 comment #7:]
> At 2024-11-15T18:38:59-0500, anonymous wrote:
>> Follow-up Comment #6, bug #66447 (group groff):
>> [comment #5 comment #5:]
>>> I know that for other requests, I sometimes want to "schedule"
>>> something to take place when the next break happens without actually
>>> _causing_ a break.  I haven't thought carefully through enough
>>> scenarios to decide that this would never be the case with `ne`.
>> 
>> I thought that's the entire purpose of the no-break control char, no?
> 
> Yes, but like _most_ formatter requests, `ne` does not behave
> differently depending on the control character used to invoke it.
> 
> In fact, I've considered adding a formatter "style" warning advising the
> user when they uselessly invoke a request with the no-break control
> character.
> 
> https://savannah.gnu.org/bugs/index.php?62776#comment4

I think this his a much simpler solution. `ne` should cause a line break
before breaking the page when invoked with the regular control char, and
should not cause a line break when invoked with the no-break control char.

I realize it might be a bit unusual for a request invoked with the no-break
char to cause a page break. In any case however, I consider the current
behavior wrong.

If `ne`'s description reads "[b]reak page if distance to next page location
trap is less than [given distance]", and `bp`'s description reads
"[b]reak page and start a new one", I expect the two to behave similarly.
In essence, I expect `ne` to behave like a conditional `bp`, a shorter way
of writing `if \n[.t]u<(v;DIST) .bp`. The fact that it doesn't behave this
way betrays user expectations, regardless of whether you consider it a bug
or not.

If you really think it should continue working like this, the documentation
should be updated to make its actual behavior clear.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66447>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature

Reply via email to