Re: make pretty-print available in ly files (issue 222810043 by address@hidden)

[dak]

On 2015/04/07 23:25:09, thomasmorley651 wrote:
> https://codereview.appspot.com/222810043/diff/1/ly/init.ly
> File ly/init.ly (right):

> https://codereview.appspot.com/222810043/diff/1/ly/init.ly#newcode38
> ly/init.ly:38: #(use-modules (ice-9 pretty-print))
> On 2015/04/07 17:43:07, david.nalesnik wrote:
> > On 2015/04/07 16:13:44, dak wrote:
> > > Uh, where is the point?  Why wouldn't a user include a module he
wants
> > himself?
> > > Other modules are included because LilyPond itself uses them
generously.
> But
> > > this would not appear to be the case here.
> >
> > It's a convenience for people who work with Scheme in .ly files, the
same
> > motivation behind use of pretty-printing with \displayMusic.  I know
that Harm
> > frequently uses pretty-print, and I was prompted to make this change
at his
> > suggestion.  (See comments here:
https://codereview.appspot.com/217260043 )
> >
> > If you think this should be reverted we could do that of course;
however, I
> > think its inclusion is helpful.

> I really appreciate having it available in .ly-files

> And I can't see it does any harm.

How would it be unavailable without this patch?  Any unneeded modules we
load take up memory and load time.  Something like (srfi srfi-1) is
loaded anyway for the sake of the LilyPond core: loading it in init.ly
is basically only reexporting the already loaded interface (which can
lead to naming resolution conflicts nevertheless, but the current set
seems reasonably clean in that regard).

If there is a significantly relevant manner in which the use of the
prettyprint module can be considered encumbered in our current setup
(perhaps safe mode?), then we should try addressing _that_ instead of
preloading everything that somebody might at some point of time consider
useful.

https://codereview.appspot.com/222810043/