lilypond-devel
[Top][All Lists]
Advanced

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

Re: Guile-2.9.5 shortcut for gettext changed


From: Thomas Morley
Subject: Re: Guile-2.9.5 shortcut for gettext changed
Date: Sun, 8 Dec 2019 20:45:36 +0100

Am So., 8. Dez. 2019 um 20:38 Uhr schrieb Thomas Morley
<address@hidden>:
>
> Am So., 8. Dez. 2019 um 19:37 Uhr schrieb David Kastrup <address@hidden>:
> >
> > Thomas Morley <address@hidden> writes:
> >
> > > Am So., 24. Nov. 2019 um 20:24 Uhr schrieb Thomas Morley
> > > <address@hidden>:
> > >
> > >> I can't find where we define our own shortcut `_´ for `gettext´.
> > >
> > > To answer my own question, it's in lily.scm.
> > > No idea how I could overlook it there :(
> > >
> > > I now made a local patch replacing all relevant occurrencies off '_'
> > > by 'G_' on top of the other guile2-patches.
> >
> > If we define _ ourselves, why would we need to replace it with G_ ?
> >
> > --
> > David Kastrup
>
> Otherwise we always get multiples of:
> imported module (lily) overrides core binding `_'
>
> This is due to:
> "
> ** Define top-level bindings for aux syntax: `else', `=>', `...', `_'
>
> These auxiliary syntax definitions are specified to be defined in the
> R6RS and the R7RS.  They were previously unbound, even in the R6RS
> modules.  This change is not anticipated to cause any incompatibility
> with existing Guile code, and improves things for R6RS and R7RS users.
>
> ** Conventional gettext alias is now `G_'
>
> Related to the last point, since the "Fix literal matching for
> module-bound literals" change in the 2.2 series, it was no longer
> possible to use the conventional `_' binding as an alias for `gettext',
> because a local `_' definition would prevent `_' from being recognized
> as auxiliary syntax for `match', `syntax-rules', and similar.  The new
> recommended conventional alias for `gettext' is `G_'.
> "
> from the release announcement for guile-2.9.6
> https://lists.gnu.org/archive/html/guile-devel/2019-12/msg000`_' 06.html

c/p error, correct link:
https://lists.gnu.org/archive/html/guile-devel/2019-12/msg00006.html

> Could we silence the warnings?
> If so, then we cannot use guile's own`_'. A loss or not? Not sure...
>
> Cheers,
>   Harm



reply via email to

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