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:38:51 +0100

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

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]