[bug #61034] [me] should reject insufficient page lengths

[G. Branden Robinson]

Update of bug #61034 (project groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.23.0 

___

Follow-up Comment #1:


commit 7bfaf799c4822a99762cc30b0cf16ee89449621c
Author: G. Branden Robinson 
Date:   Fri Aug 13 08:15:31 2021 +1000

[me]: Abort if paper length too short.

* tmac/e.tmac: Validate page length to prevent too-short paper formats
  from causing traps to call each other until the input stack overflows.
  The minimum is 14v.

  (check_page_length): Define new macro to perform the check.

  (bp, @p, sh, 2c, 1c): Call it from likely candidates (@p is internal
  and called by paragraphing macros).

  (pl): Intercept and wrap the `pl` request itself; check its setting
  immediately.

Fixes .


___

Reply to this item at:

  

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

[bug #55081] [me] two-column output does not work with footnotes or very long page lengths

[G. Branden Robinson]

Update of bug #55081 (project groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.23.0 

___

Follow-up Comment #11:


commit fa5fa88957b2f2755f85fd357b4e892f5045d55f
Author: G. Branden Robinson 
Date:   Fri Aug 13 08:51:51 2021 +1000

[me]: Fix Savannah #55081.

* tmac/e.tmac (bc): Fix problem with multiple columns on long pages.
  Space to the next page location trap, not 24 inches.  Thanks to Dave
  Kemper and Bjarni Ingi Gislason for help tracking this bug down.

Fixes .


___

Reply to this item at:

  

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

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

[G. Branden Robinson]

Update of bug #58736 (project groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.23.0 

___

Follow-up Comment #10:


commit ab55f50af0599028bf7d3fd0fc50358471595b3c
Author: G. Branden Robinson 
Date:   Fri Aug 13 09:32:31 2021 +1000

[me]: Fix Savannah #58736.

* tmac/e.tmac (1c): Fix problem when combining multiple columns,
  footnotes, and return to single-column mode: do not place the
  single-column text below the footnote.  Space to the end of the page
  (\n[nl]), not the page "high-water mark" (\n[.h]).  Thanks to Bjarni
  Ingi Gislason for the suggestion.

Fixes .


___

Reply to this item at:

  

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

[bug #55060] [me] behavior of .ll does not match documentation

[G. Branden Robinson]

Update of bug #55060 (project groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.23.0 

___

Follow-up Comment #7:


commit a61cd74ad38b7948f63784ae1373e572fcf12292
Author: G. Branden Robinson 
Date:   Fri Aug 13 10:22:43 2021 +1000

[me]: Clarify breadth of application of `ll` macro.

* doc/meref.me: Document application of .ll macro only to the 3
  environments that me(7) uses, not any the user might create.
* tmac/e.tmac (@C, xl, ll): Update comments.

Fixes .


___

Reply to this item at:

  

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

[bug #59920] [PATCH] [me] documentation terminology cleanup

[G. Branden Robinson]

Update of bug #59920 (project groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.23.0 

___

Follow-up Comment #10:


commit c8d204e6e505660dff807fe1d623a7e8fed98e08
Author: G. Branden Robinson 
Date:   Fri Aug 13 21:03:08 2021 +1000

doc/meintro_fr.me: Fix grammar nit.

Thanks to Ingo Schwarze for pointing it out.

Fixes .

commit a4271cb362a5a50165ef466b2cc86c8ed1d139fc
Author: Dave Kemper 
Date:   Thu Mar 18 23:36:40 2021 +

doc/meintro_fr.me: Update translation.

[I further tweaked it to wrap at 72 columns, add an empty request
between sentences, and break an input line after a comma.  --GBR]




___

Reply to this item at:

  

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

[bug #60338] compilation error: undefined reference to "rpl_free"

[G. Branden Robinson]

Follow-up Comment #5, bug #60338 (project groff):


[comment #3 comment #3:]
>   This is caused by using both options "-O..." and -D_FORTIFY_SOURCE=2.
> 
>   Debian uses these options.

-O... (read literally) isn't a gcc option.  What are you replacing with the
ellipsis?  Does even -O0 impose this requirement when used in conjunction with
-D_FORTIFY_SOURCE=2?

___

Reply to this item at:

  

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

[bug #60512] [ms] want AD string to control default adjustment mode

[G. Branden Robinson]

Update of bug #60512 (project groff):

  Status:None => Postponed  

___

Follow-up Comment #3:

Thanks, Bjarni.  That's a good idea and should suit my needs for the time
being.  Postponing ticket.

___

Reply to this item at:

  

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

[bug #61022] [ms] documention neglects to mention FP macro

[G. Branden Robinson]

Follow-up Comment #4, bug #61022 (project groff):

Thanks, Keith.  You've presented a solid use case for .FP, I think.

The other thing that bugs me about footnote paragraphing is how elaborate the
semantics of FF 0 are.  The paragraph is indented _unless_ there's nothing to
indent it with.  This is compatible with Heirloom Doctools troff and I suppose
it makes sense for that sort of specialized, first-page-only footnote that
doesn't have a marker but instead serves as some sort of acknowledgement in
some academic/journal styles.  But if it's that specialized, I don't see the
harm in telling people to set FF to 2 for that unique, marker-less footnote
and change to another format for all other footnotes if desired.

I'm sort of tempted to simplify it and make the correspondence between
footnote formats and paragraph styles explicit.

0,1 PP
2   LP
3   IP

What do you think?

___

Reply to this item at:

  

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

[bug #61028] [refer-ms] sets comma after title in italics, should be roman

[G. Branden Robinson]

Follow-up Comment #2, bug #61028 (project groff):

[comment #1 comment #1:]
>   "refer-ms" does this correctly.
> 
>   Punctuation marks are set to match the type of their adjoining words;
> check a style guide.
> 

There's no controlling style guide for *roff citations.  (There are _many_
candidates that could be selected; I gather Peter Schaffter chose MLA for
mom(7).)  The practice in groff documentation is in fact to _not_ honor the
rule you cite, following the same principle that motivates "logical" quotation
style.

https://en.wiktionary.org/wiki/logical_quotation

I'm not wedded to the change I proposed, but if we're going to reject it in
favor of a style guide's directives regarding source citation, we should
identify one that is sufficiently detailed to address the cases we need to
handle, conform to it, and document the style in use.

___

Reply to this item at:

  

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

[bug #61036] [PATCH] xditview.am: add library to facilitate compilation with additional options

[G. Branden Robinson]

Update of bug #61036 (project groff):

  Status:None => Need Info  

___

Follow-up Comment #1:

I don't understand the patch.  How does forcing gxditview to link with
libgroff haul in a working fprintf?

___

Reply to this item at:

  

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

[bug #55060] [me] behavior of .ll does not match documentation

[G. Branden Robinson]

Follow-up Comment #8, bug #55060 (project groff):


[comment #6 comment #6:]
> [comment #5 comment #5:]
> > I think it's easiest just to call this a documentation issue
> 
> I agree with this, and on further thought, I believe the problem is that the
-Me Reference Manual describes .xl/.ll in terms of "environments" when it
never defines this term or explains how -me uses them.
> 
> Looking at this through a historical lens, where there were exactly three
environments and -me claimed them for its own use, what the problematic
sentence is trying to communicate is that .xl changes the line length only for
running text while .ll changes it globally.  Using the word "environments"
here requires the reader to have some knowledge of (a) the troff concept of
environments, and (b) how the macro set uses them internally.
> 
> (Regarding (a): the manual's opening paragraph tells what general troff
knowledge it presumes: "the reader should understand breaks, fonts, point
sizes, the use and definition of number registers and strings, how to define
macros, and scaling factors for ens, points, v's (vertical line spaces), etc."
 So knowledge of environments is explicitly not expected of the reader, making
the -Me Reference Manual's one passing reference to them inappropriate.
> 
> Further, the manual's index includes, in addition to all the macros -me
defines, "selected troff requests," and further states, "those listed can
generally be used with impunity."  The .ev request is _not_ listed, suggesting
the user should avoid it in (classical) -me documents -- which is in line with
-me's internal usage of these (limited number of) environments.
> 
> Regarding (b): maybe this was a fair assumption to make of readers in 1985;
it isn't today.)
> 
> So what the manual _should_ do is define .xl and .ll in terms of their
_effect_, not their implementation mechanism.  Remove mention of environments
from their descriptions, and the whole discussion in this bug report about
whether and how .ll should affect arbitrary created-on-the-fly environments
becomes moot.
> 
> That is, .ll changes the line length in running text, headers, and footers;
.xl affects only running text.
> 
> Today, because groff expands the number of environments from three to
infinity, perhaps -me users have the freedom to define and use their own
environments without colliding with those -me uses internally.  But meref.me
would need a larger overhaul to address this, and I don't think that's
necessary or appropriate to resolve this bug.  The fix for this bug should be
to stop explaining -me behavior in terms of undocumented implementation
details.

Can we treat this as a fresh bug?  Its scope is much greater, and it's going
to take more effort--a more probing revision of the document--to resolve.

___

Reply to this item at:

  

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

[bug #61036] [PATCH] xditview.am: add library to facilitate compilation with additional options

[Bjarni Ingi Gislason]

Follow-up Comment #2, bug #61036 (project groff):

  It was actually "libgroff_a-fprintf.o" that was missing before
"lib/libgnu".

  So the commit should have mentioned that.

A comment in the patch is also missing, for example:

/* Use 'libgroff.a' to get 'libgroff_a-fprintf.o' if needed. */


___

Reply to this item at:

  

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

[bug #61028] [refer-ms] sets comma after title in italics, should be roman

[Bjarni Ingi Gislason]

Follow-up Comment #3, bug #61028 (project groff):

  Instead of "style guide", "books on typography" is better.

This convention should thus be mentioned in most (all) style guides.



___

Reply to this item at:

  

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

[bug #60338] compilation error: undefined reference to "rpl_free"

[Bjarni Ingi Gislason]

Follow-up Comment #6, bug #60338 (project groff):

  I use '-Og'; "-O..." is a shortcut for "any type of optimisation".

  My suggestion should work without or with any type of optimisation.


___

Reply to this item at:

  

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

[bug #55081] [me] two-column output does not work with footnotes or very long page lengths

[Bjarni Ingi Gislason]

Follow-up Comment #12, bug #55081 (project groff):

 Answer to comment #10

 No to some, yes to some.

  The macro "bc" is there to switch to the next column or page.
 It is the footer-macro's job to decide what to do.

  So "bc" delegates that to the footer trap by triggering it.

  It does not do that by just going to the next trap,
 which can be anything!

  All traps located between "bc" in a column or page
 and the footer trap are touched,
 when the footer trap (the last trap in a column or page) is touched.


___

Reply to this item at:

  

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

[bug #61040] verbose_option_works.sh: option "-T..." for "nroff" is a variable, but a constant in the test string

[Bjarni Ingi Gislason]

URL:
  

 Summary: verbose_option_works.sh: option "-T..." for "nroff"
is a variable, but a constant in the test string
 Project: GNU troff
Submitted by: bjarniig
Submitted on: Sat 14 Aug 2021 12:17:26 AM UTC
Category: None
Severity: 3 - Normal
  Item Group: Warning/Suspicious behaviour
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:


src/roff/nroff/tests/verbose_option_works.sh

  A '-T' option is needed for "nroff" to match the tested string by
"grep".

  Using a variable, for example "Toption=-Tascii",
 instead of a repeated constant string,
 makes changes easier and smaller.





___

Reply to this item at:

  

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