You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Vincent Lefevre <vi...@vinc17.net> on 2019/12/20 23:09:09 UTC
"svn list -v" column alignment issue
Hi,
There's something wrong with "svn list -v" column alignment when
there are author names with more than 8 characters. For instance,
with the gcc repository:
[...]
279442 jozefl Dec 16 12:02 libgcc/
278886 jvdelisle Dec 01 23:29 libgfortran/
[...]
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: "svn list -v" column alignment issue
Posted by Branko Čibej <br...@apache.org>.
On 21.12.2019 00:09, Vincent Lefevre wrote:
> Hi,
>
> There's something wrong with "svn list -v" column alignment when
> there are author names with more than 8 characters. For instance,
> with the gcc repository:
>
> [...]
> 279442 jozefl Dec 16 12:02 libgcc/
> 278886 jvdelisle Dec 01 23:29 libgfortran/
> [...]
This is by design, it was a change made in 1.12.
https://subversion.apache.org/docs/release-notes/1.12.html#client-server-improvements
Yes, we realize that this makes simple output parsing harder, but the
alternative -- truncating author names at 8 characters -- was considered
worse.
-- Brane
Re: "svn list -v" column alignment issue
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2019-12-23 03:21:09 +0100, Vincent Lefevre wrote:
> On 2019-12-21 08:09:46 +0000, Daniel Shahaf wrote:
> > Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> > > There's something wrong with "svn list -v" column alignment when
> > > there are author names with more than 8 characters. For instance,
> > > with the gcc repository:
> > >
> > > [...]
> > > 279442 jozefl Dec 16 12:02 libgcc/
> > > 278886 jvdelisle Dec 01 23:29 libgfortran/
> > > [...]
> >
> > As implemented, the width is initially 8 but as soon as a longer name is seen,
> > subsequent lines will be aligned with that, up to a maximum length of 16.
> >
> > Do you have a better algorithm to propose?
>
> Make the minimum width configurable, or cache the maximum length name
> in the working-copy data.
Or wait for a fraction of second, say 0.1 s, after the first data
are available, and compute the width based on these initial data.
In most cases (e.g. when -R is not used), these data will actually
be complete, so that the output will be correct.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: "svn list -v" column alignment issue
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Shahaf wrote on Tue, 07 Jan 2020 16:10 +00:00:
> Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100:
> > On 2019-12-23 06:35:08 +0000, Daniel Shahaf wrote:
> > > Vincent Lefevre wrote on Mon, 23 Dec 2019 02:21 +00:00:
> > > > On 2019-12-21 08:09:46 +0000, Daniel Shahaf wrote:
> > > > > Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> > > > > > There's something wrong with "svn list -v" column alignment when
> > > > > > there are author names with more than 8 characters. For instance,
> > > > > > with the gcc repository:
> > > > > >
> > > > > > [...]
> > > > > > 279442 jozefl Dec 16 12:02 libgcc/
> > > > > > 278886 jvdelisle Dec 01 23:29 libgfortran/
> > > > > > [...]
> > > > >
> > > > > As implemented, the width is initially 8 but as soon as a longer name is seen,
> > > > > subsequent lines will be aligned with that, up to a maximum length of 16.
> > > > >
> > > > > Do you have a better algorithm to propose?
> > > >
> > > > cache the maximum length name in the working-copy data.
> > >
> > > Let's see. We could cache the value in wc.db. Running 'ls' or 'blame' [the
> > > same considerations apply to both] would update the cache; running 'cleanup'
> > > would purge it.
> > >
> > > Two things are not immediately clear to me:
> > >
> > > - This info is only needed by the cmdline client, not by other
> > > library users. This suggests the API should be generic. A
> > > per-client cache, maybe? There's already a
> > > svn_client_ctx_t::client_name so it's not unprecedented.
> >
> > Well, you don't know what the library users will do. Perhaps the cache
> > will benefit them too. The value can be used by them or not.
>
> I think you've missed my point. I'm saying we should try to design the cache
> API in a way that will allow it to be used not only for 'svn ls -v' but also
> for other things. The API does not exist to serve the cmdline client; it
> exists to serve _all_ svn clients.
To clarify: I think we should try to design the API in a way that will
(1) let it be used not only for author names but also for other things,
(2) let it be used not only by the cmdline client.
I mean, we _could_ add a private API that does "SELECT change_author
FROM nodes ORDER BY strlen(change_author) DESC LIMIT 1" and have the
cmdline client use that, and maybe that's actually the right answer, but
let's at least _try_ to come up with a better / more generic design first.
Cheers,
Daniel
Re: "svn list -v" column alignment issue
Posted by Branko Čibej <br...@apache.org>.
On 13.01.2020 17:51, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Mon, 13 Jan 2020 10:26 +00:00:
>> On 2020-01-10 16:58:26 +0100, Johan Corveleyn wrote:
>>> Since both 'svn ls -v' and 'svn blame' can be called on a repository
>>> URL, I don't really see the point in caching the max(length(author))
>>> of the working copy.
>>>
>>> The output from a URL would still be mis-aligned. It would make the
>>> presentation inconsistent between calling it on a working copy and on
>>> a URL.
>> Good point. I was about to say that in most cases, these commands are
>> run from a working copy. But I now think that caching should be done
>> under the user's home (just like with most applications). Under Unix,
>> this would be under "$XDG_CACHE_HOME/subversion".
> When would data be evicted from the cache?
>
>> The data should be associated with the URL of the repository.
> I'd say UUID, but we don't have to decide this now.
Why are we overthinking this? This information is really not relevant
for integration with other tools:
* GUIs don't need it; they can always dynamically resize columns in forms.
* The command-line doesn't (really) need it; all information,
including untruncated commiter names, is available in --xml mode.
Adding a layer of caching is only going to add a stale-cache problem
that we don't have now.
-- Brane
Re: "svn list -v" column alignment issue
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Vincent Lefevre wrote on Mon, 13 Jan 2020 10:26 +00:00:
> On 2020-01-10 16:58:26 +0100, Johan Corveleyn wrote:
> > Since both 'svn ls -v' and 'svn blame' can be called on a repository
> > URL, I don't really see the point in caching the max(length(author))
> > of the working copy.
> >
> > The output from a URL would still be mis-aligned. It would make the
> > presentation inconsistent between calling it on a working copy and on
> > a URL.
>
> Good point. I was about to say that in most cases, these commands are
> run from a working copy. But I now think that caching should be done
> under the user's home (just like with most applications). Under Unix,
> this would be under "$XDG_CACHE_HOME/subversion".
When would data be evicted from the cache?
> The data should be associated with the URL of the repository.
I'd say UUID, but we don't have to decide this now.
Re: "svn list -v" column alignment issue
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2020-01-10 16:58:26 +0100, Johan Corveleyn wrote:
> Since both 'svn ls -v' and 'svn blame' can be called on a repository
> URL, I don't really see the point in caching the max(length(author))
> of the working copy.
>
> The output from a URL would still be mis-aligned. It would make the
> presentation inconsistent between calling it on a working copy and on
> a URL.
Good point. I was about to say that in most cases, these commands are
run from a working copy. But I now think that caching should be done
under the user's home (just like with most applications). Under Unix,
this would be under "$XDG_CACHE_HOME/subversion".
The data should be associated with the URL of the repository.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: "svn list -v" column alignment issue
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Jan 10, 2020 at 3:28 PM Vincent Lefevre <vi...@vinc17.net> wrote:
> On 2020-01-08 13:12:21 +0000, Daniel Shahaf wrote:
> > Vincent Lefevre wrote on Wed, Jan 08, 2020 at 10:28:01 +0100:
> > > On 2020-01-07 16:10:52 +0000, Daniel Shahaf wrote:
> > > > Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100:
> > > > > On 2019-12-23 06:35:08 +0000, Daniel Shahaf wrote:
> > > > > > Two things are not immediately clear to me:
> > > > > >
> > > > > > - This info is only needed by the cmdline client, not by other
> > > > > > library users. This suggests the API should be generic. A
> > > > > > per-client cache, maybe? There's already a
> > > > > > svn_client_ctx_t::client_name so it's not unprecedented.
> > > > >
> > > > > Well, you don't know what the library users will do. Perhaps the cache
> > > > > will benefit them too. The value can be used by them or not.
> > > >
> > > > I think you've missed my point. I'm saying we should try to design the cache
> > > > API in a way that will allow it to be used not only for 'svn ls -v' but also
> > > > for other things. The API does not exist to serve the cmdline client; it
> > > > exists to serve _all_ svn clients.
> > >
> > > I entirely agree. But I'm still confused by your first sentence above
> > > "This info is only needed by the cmdline client, not by other library
> > > users." or perhaps you misplaced the "not"?
> >
> > The length of the longest author name is needed by 'svn ls -v'.
> >
> > The length of the longest author name is unlikely to be needed by
> > other consumers of the svn_client_* API.
>
> A reimplementation of "svn ls -v" or "svn blame" may find this useful
> information. Graphical clients may be interested in a cached full list
> of authors to compute the size of the corresponding column.
Since both 'svn ls -v' and 'svn blame' can be called on a repository
URL, I don't really see the point in caching the max(length(author))
of the working copy.
The output from a URL would still be mis-aligned. It would make the
presentation inconsistent between calling it on a working copy and on
a URL.
Just my 2 cents ...
--
Johan
Re: "svn list -v" column alignment issue
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2020-01-08 13:12:21 +0000, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Wed, Jan 08, 2020 at 10:28:01 +0100:
> > On 2020-01-07 16:10:52 +0000, Daniel Shahaf wrote:
> > > Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100:
> > > > On 2019-12-23 06:35:08 +0000, Daniel Shahaf wrote:
> > > > > Two things are not immediately clear to me:
> > > > >
> > > > > - This info is only needed by the cmdline client, not by other
> > > > > library users. This suggests the API should be generic. A
> > > > > per-client cache, maybe? There's already a
> > > > > svn_client_ctx_t::client_name so it's not unprecedented.
> > > >
> > > > Well, you don't know what the library users will do. Perhaps the cache
> > > > will benefit them too. The value can be used by them or not.
> > >
> > > I think you've missed my point. I'm saying we should try to design the cache
> > > API in a way that will allow it to be used not only for 'svn ls -v' but also
> > > for other things. The API does not exist to serve the cmdline client; it
> > > exists to serve _all_ svn clients.
> >
> > I entirely agree. But I'm still confused by your first sentence above
> > "This info is only needed by the cmdline client, not by other library
> > users." or perhaps you misplaced the "not"?
>
> The length of the longest author name is needed by 'svn ls -v'.
>
> The length of the longest author name is unlikely to be needed by
> other consumers of the svn_client_* API.
A reimplementation of "svn ls -v" or "svn blame" may find this useful
information. Graphical clients may be interested in a cached full list
of authors to compute the size of the corresponding column.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: "svn list -v" column alignment issue
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Vincent Lefevre wrote on Wed, Jan 08, 2020 at 10:28:01 +0100:
> On 2020-01-07 16:10:52 +0000, Daniel Shahaf wrote:
> > Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100:
> > > On 2019-12-23 06:35:08 +0000, Daniel Shahaf wrote:
> > > > Two things are not immediately clear to me:
> > > >
> > > > - This info is only needed by the cmdline client, not by other
> > > > library users. This suggests the API should be generic. A
> > > > per-client cache, maybe? There's already a
> > > > svn_client_ctx_t::client_name so it's not unprecedented.
> > >
> > > Well, you don't know what the library users will do. Perhaps the cache
> > > will benefit them too. The value can be used by them or not.
> >
> > I think you've missed my point. I'm saying we should try to design the cache
> > API in a way that will allow it to be used not only for 'svn ls -v' but also
> > for other things. The API does not exist to serve the cmdline client; it
> > exists to serve _all_ svn clients.
>
> I entirely agree. But I'm still confused by your first sentence above
> "This info is only needed by the cmdline client, not by other library
> users." or perhaps you misplaced the "not"?
The length of the longest author name is needed by 'svn ls -v'.
The length of the longest author name is unlikely to be needed by
other consumers of the svn_client_* API.
Cheers,
Daniel
Re: "svn list -v" column alignment issue
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2020-01-07 16:10:52 +0000, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100:
> > On 2019-12-23 06:35:08 +0000, Daniel Shahaf wrote:
> > > Two things are not immediately clear to me:
> > >
> > > - This info is only needed by the cmdline client, not by other
> > > library users. This suggests the API should be generic. A
> > > per-client cache, maybe? There's already a
> > > svn_client_ctx_t::client_name so it's not unprecedented.
> >
> > Well, you don't know what the library users will do. Perhaps the cache
> > will benefit them too. The value can be used by them or not.
>
> I think you've missed my point. I'm saying we should try to design the cache
> API in a way that will allow it to be used not only for 'svn ls -v' but also
> for other things. The API does not exist to serve the cmdline client; it
> exists to serve _all_ svn clients.
I entirely agree. But I'm still confused by your first sentence above
"This info is only needed by the cmdline client, not by other library
users." or perhaps you misplaced the "not"?
> > In any case, making the information available will not hurt.
>
> It will hurt, actually. If we add the API we'll need to support it
> until 2.0 (= indefinitely), and everyone who ever tried to write
> code to the libsvn_client interface will have another function
> docstring to read and decide they don't care about.
Yes, perhaps this will have drawbacks at the API level, but the
information can be useful for various reasons, and the library
users could just decide to use it or not.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: "svn list -v" column alignment issue
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100:
> On 2019-12-23 06:35:08 +0000, Daniel Shahaf wrote:
> > Vincent Lefevre wrote on Mon, 23 Dec 2019 02:21 +00:00:
> > > On 2019-12-21 08:09:46 +0000, Daniel Shahaf wrote:
> > > > Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> > > > > There's something wrong with "svn list -v" column alignment when
> > > > > there are author names with more than 8 characters. For instance,
> > > > > with the gcc repository:
> > > > >
> > > > > [...]
> > > > > 279442 jozefl Dec 16 12:02 libgcc/
> > > > > 278886 jvdelisle Dec 01 23:29 libgfortran/
> > > > > [...]
> > > >
> > > > As implemented, the width is initially 8 but as soon as a longer name is seen,
> > > > subsequent lines will be aligned with that, up to a maximum length of 16.
> > > >
> > > > Do you have a better algorithm to propose?
> > >
> > > cache the maximum length name in the working-copy data.
> >
> > Let's see. We could cache the value in wc.db. Running 'ls' or 'blame' [the
> > same considerations apply to both] would update the cache; running 'cleanup'
> > would purge it.
> >
> > Two things are not immediately clear to me:
> >
> > - This info is only needed by the cmdline client, not by other
> > library users. This suggests the API should be generic. A
> > per-client cache, maybe? There's already a
> > svn_client_ctx_t::client_name so it's not unprecedented.
>
> Well, you don't know what the library users will do. Perhaps the cache
> will benefit them too. The value can be used by them or not.
I think you've missed my point. I'm saying we should try to design the cache
API in a way that will allow it to be used not only for 'svn ls -v' but also
for other things. The API does not exist to serve the cmdline client; it
exists to serve _all_ svn clients.
> In any case, making the information available will not hurt.
It will hurt, actually. If we add the API we'll need to support it until 2.0
(= indefinitely), and everyone who ever tried to write code to the
libsvn_client interface will have another function docstring to read and decide
they don't care about.
> > - What the cache keys should be. wc.db is designed to be shared
> > among multiple WC's, so presumably the cache should be per-wcroot
> > or possibly per-repository?
>
> I don't understand. The wc.db file is inside the .svn directory of
> the WC. How can it be shared by multiple WC's?
It isn't, yet. I only said it was "_designed_ to be shared among multiple
WC's". The SQL schema is designed to allow a single wc.db to reside in, say,
$HOME/wc.db and be shared by multiple working copies: for example, in the
schema working copy files are identified by a (wc_id, local_relpath) pair.
We never got around to actually making multiple working copies share a wc.db,
but the low-level support is already there.
Re: "svn list -v" column alignment issue
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2019-12-23 06:35:08 +0000, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Mon, 23 Dec 2019 02:21 +00:00:
> > On 2019-12-21 08:09:46 +0000, Daniel Shahaf wrote:
> > > Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> > > > There's something wrong with "svn list -v" column alignment when
> > > > there are author names with more than 8 characters. For instance,
> > > > with the gcc repository:
> > > >
> > > > [...]
> > > > 279442 jozefl Dec 16 12:02 libgcc/
> > > > 278886 jvdelisle Dec 01 23:29 libgfortran/
> > > > [...]
> > >
> > > As implemented, the width is initially 8 but as soon as a longer name is seen,
> > > subsequent lines will be aligned with that, up to a maximum length of 16.
> > >
> > > Do you have a better algorithm to propose?
> >
> > cache the maximum length name in the working-copy data.
>
> Let's see. We could cache the value in wc.db. Running 'ls' or 'blame' [the
> same considerations apply to both] would update the cache; running 'cleanup'
> would purge it.
>
> Two things are not immediately clear to me:
>
> - This info is only needed by the cmdline client, not by other
> library users. This suggests the API should be generic. A
> per-client cache, maybe? There's already a
> svn_client_ctx_t::client_name so it's not unprecedented.
Well, you don't know what the library users will do. Perhaps the cache
will benefit them too. The value can be used by them or not. In any
case, making the information available will not hurt.
> - What the cache keys should be. wc.db is designed to be shared
> among multiple WC's, so presumably the cache should be per-wcroot
> or possibly per-repository?
I don't understand. The wc.db file is inside the .svn directory of
the WC. How can it be shared by multiple WC's?
> Oh. I missed it before, but passing -H increases the minimum width to 14.
> That's not obvious from the --help output and variable names.
But 14 is still a bit too small for me, and -H prevents the exact
sizes from being output.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: "svn list -v" column alignment issue
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Vincent Lefevre wrote on Mon, 23 Dec 2019 02:21 +00:00:
> On 2019-12-21 08:09:46 +0000, Daniel Shahaf wrote:
> > Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> > > There's something wrong with "svn list -v" column alignment when
> > > there are author names with more than 8 characters. For instance,
> > > with the gcc repository:
> > >
> > > [...]
> > > 279442 jozefl Dec 16 12:02 libgcc/
> > > 278886 jvdelisle Dec 01 23:29 libgfortran/
> > > [...]
> >
> > As implemented, the width is initially 8 but as soon as a longer name is seen,
> > subsequent lines will be aligned with that, up to a maximum length of 16.
> >
> > Do you have a better algorithm to propose?
>
> cache the maximum length name in the working-copy data.
Let's see. We could cache the value in wc.db. Running 'ls' or 'blame' [the
same considerations apply to both] would update the cache; running 'cleanup'
would purge it.
Two things are not immediately clear to me:
- This info is only needed by the cmdline client, not by other library users.
This suggests the API should be generic. A per-client cache, maybe? There's
already a svn_client_ctx_t::client_name so it's not unprecedented.
- What the cache keys should be. wc.db is designed to be shared among multiple
WC's, so presumably the cache should be per-wcroot or possibly per-repository?
>
Another idea: The WC caches the "last changed author" information. When
initializing the display width, we could initialize it as though we'd already
encountered a line with the longest "last changed author" that's cached in wc.db
(possibly for a <handwave>relevant</handwave> subtree).
>
(To be clear, I'm just brainstorming; I'm not going to implement either of
these ideas. Patches welcome.)
> Make the minimum width configurable,
Currently it is only configurable by changing the constant's value and
rebuilding…
Oh. I missed it before, but passing -H increases the minimum width to 14.
That's not obvious from the --help output and variable names.
Re: "svn list -v" column alignment issue
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2019-12-21 08:09:46 +0000, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> > There's something wrong with "svn list -v" column alignment when
> > there are author names with more than 8 characters. For instance,
> > with the gcc repository:
> >
> > [...]
> > 279442 jozefl Dec 16 12:02 libgcc/
> > 278886 jvdelisle Dec 01 23:29 libgfortran/
> > [...]
>
> As implemented, the width is initially 8 but as soon as a longer name is seen,
> subsequent lines will be aligned with that, up to a maximum length of 16.
>
> Do you have a better algorithm to propose?
Make the minimum width configurable, or cache the maximum length name
in the working-copy data.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: "svn list -v" column alignment issue
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> There's something wrong with "svn list -v" column alignment when
> there are author names with more than 8 characters. For instance,
> with the gcc repository:
>
> [...]
> 279442 jozefl Dec 16 12:02 libgcc/
> 278886 jvdelisle Dec 01 23:29 libgfortran/
> [...]
As implemented, the width is initially 8 but as soon as a longer name is seen,
subsequent lines will be aligned with that, up to a maximum length of 16.
Do you have a better algorithm to propose?