Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007720OCamlstandard librarypublic2018-02-02 18:342018-06-10 10:56
Reportergmelquiond 
Assigned Tooctachron 
PrioritynormalSeverityminorReproducibilityalways
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version4.06.0 
Target VersionFixed in Version 
Summary0007720: Format: spurious space at end of line
DescriptionThe code

  Format.set_margin 10; Format.printf "@[@[123456@ @[A@]@ B@]@]@\n";;

produces

  123456=
  A B

where = denotes a spurious space.

I am also wondering why A was not put at the end of the first line. (Removing the box around A does so. Removing one of the outer boxes does so too. Removing B does so too.) I guess the two issues are related.
TagsNo tags attached.
Attached Files

- Relationships
has duplicate 0007804resolvedoctachron In the format library, are boxes intended to implicitly break? 

-  Notes
(0018864)
octachron (developer)
2018-02-02 19:03

The space at the end of the line is not spurious from the point of view of Format's implementation.

This is due to the fact that "Format.set_margin 10" also sets the maximum indentation limit to 5. Consequently, the second box is rejected to the left with a forced new line. Since the break is introduced by the opening of the box, the previous break hint "@ " is printed as a space.

The easiest fix in this situation is to also adjust the maximum indentation limit:

  Format.set_margin 10; Format.set_max_indent 8;
  Format.printf "@[@[123456@ @[A@]@ B@]@]@\n";;

displays the expected output

  123456·A
  B

Similarly, the difference in behavior that you observed by shortening the length of the format string is due to the fact that when the content of a box fits on a line, all formatting indication (and the maximum indentation limit) are ignored because the box is replaced by a fits box.
(0018865)
gmelquiond (reporter)
2018-02-02 19:16

There is something I am missing. The documentation of set_max_indent says: "once this limit is reached, new pretty-printing boxes are rejected to the left, if they do not fit on the current line." But the box containing A does fit on the line. So why would it be rejected to the left?
(0018866)
octachron (developer)
2018-02-02 19:23

You are right, there is a mismatch between the documentation and the implementation here: the rejection to the left happens if the *parent* box does not fit on the line, i.e.

 "once this limit is reached, new pretty-printing boxes are rejected to the left, if their parent box do not fit on the current line."
(0018867)
octachron (developer)
2018-02-03 11:54

I have proposed a documentation fix at https://github.com/ocaml/ocaml/pull/1596. [^]
Do you wish to be mentionned as a reporter, and if yes under which name?

- Issue History
Date Modified Username Field Change
2018-02-02 18:34 gmelquiond New Issue
2018-02-02 19:03 octachron Note Added: 0018864
2018-02-02 19:16 gmelquiond Note Added: 0018865
2018-02-02 19:23 octachron Note Added: 0018866
2018-02-03 11:54 octachron Note Added: 0018867
2018-02-04 18:24 octachron Assigned To => octachron
2018-02-04 18:24 octachron Status new => assigned
2018-06-10 10:56 octachron Relationship added has duplicate 0007804


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker