bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #58736] [me] footnote breaks two-column output


From: G. Branden Robinson
Subject: [bug #58736] [me] footnote breaks two-column output
Date: Sun, 25 Sep 2022 23:05:19 -0400 (EDT)

Follow-up Comment #30, bug #58736 (project groff):

Hi Dave,

[comment #29 comment #29:]

> Here's my idea:
> * On changes to the number of columns (calls to .1c or .2c), do nothing
extra.
> * On reaching an end-of-page trap when footnotes are pending, do the
following:
> ** If the pending footnotes were all generated under the column width
currently in effect, output them normally.
> ** If any pending footnotes were diverted using a different column width,
throw a warning, and output them anyway.  They'll probably look ugly, but the
warning lets the user know some kind of manual intervention is required to
handle the situation, and given the difficulties outlined in comment #28, -me
can't guess what will look best anyway.

This all makes sense to me.

Some Allman implementation notes:

All footnote storage is done with the diversion-append `da` request to the
`|f` diversion.  The only thing that flushes the pending footnotes (calls the
`|f` diversion) is a macro called `@o`.  It then removes `|f`.

How about this added wrinkle?

* If the footnote being added to the pending ones uses a different number of
columns than the previous, throw a warning then, too.

I believe I can keep the implementation simple by:

1. Adding a new internal register `?f` that is zero if no footnotes are
pending.
2. Starting the first footnote (since the last flush) sets `?f` to `$m`, the
column count.
3. Subsequent footnote appends check if `?f` equals `$m` before updating it. 
If not, throw a warning. (If `?f` is zero, we're not really here; see step
2.)
4. When flushing the footnotes, perform the same check again.  If `$f` is not
equal to `$m`, throw a different warning (the one you originally proposed).

In other news, _me_(7) doesn't _have_ warnings.  I'll have to add them, moving
most of the current `@err` into a `@diag` and distinguishing the diagnostic
messages with "error:" and "warning:".

Or, maybe we really should treat this as an error.  My laziness leans toward
the latter.  The users can ask for differentiated diagnostic levels if they
want them.  Maybe _me_(7) users prefer the macro package lean and mean as it
is.

What do you think?  I think I will have a patch ready soon, and may supply it
to this ticket for your evaluation before you can reply, depending on how my
own testing goes.

Regards,
Branden


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]