On Thu, 15 Dec 2011, Francisco Vila wrote:
2011/12/15 Francisco Vila :
Entity: line 5: parser error : Input is not proper UTF-8, indicate encoding !
Bytes: 0xFF 0xFF 0xFF 0xFF
2011/12/16 Martin Tarenskeen :
> On Thu, 15 Dec 2011, Francisco Vila wrote:
>>> Entity: line 5: parser error : Input is not proper UTF-8, indicate
>>> encoding !
>>> Bytes: 0xFF 0xFF 0xFF 0xFF
>>> >> rdf:about='52da2502-5ec5-11ec--73b663e6b6fuuid:52
>>> Entity: line 5: parser error
It turns out that display-scheme-music, unlike typical display-*
functions, returns the value it displays. The LilyPond code base
(including regtests) does not make use of that feature, and it is
totally disruptive when used on the Guile command line (because then any
use of display-scheme-music
Hi Han-Wen,
Sorry for taking a while to answer this but I've been caught up in the
normal teacher end-of-Christmas-term insanity. . .
On 14/12/11 12:11, Han-Wen Nienhuys wrote:
> On Tue, Dec 13, 2011 at 5:56 PM, Ian Hulin
> wrote:
>
>> I pulled out and tested the examples in separate .ly file an
Hi Han-Wen,
On 15/12/11 12:48, Han-Wen Nienhuys wrote:
> On Wed, Dec 14, 2011 at 12:51 AM, Ian Hulin wrote:
>
>> In order to get the markup stuff to compile or be interpreted
>> correctly with Guile V2, I had to get the procedures validating the
>> markup commands to look in a single module at t
Ian Hulin writes:
> Guile V2 insists on some thing, particularly macros being defined
> before they are used.
That's not unreasonable.
> When Patrick M. first tried out using Lily with Guile 2, the only way
> we could use it was by relying on the equivalent of the Guile
> --auto-compile option.
David Kastrup gnu.org> writes:
> It turns out that display-scheme-music, unlike typical display-*
> functions, returns the value it displays.
I think the reason is to support \displayMusic, which lets users see
the internal representation of a bit of their music along with the output.
On Dec 16, 2011, at 6:46 PM, Ian Hulin wrote:
> Hi Han-Wen,
>
> On 15/12/11 12:48, Han-Wen Nienhuys wrote:
>> On Wed, Dec 14, 2011 at 12:51 AM, Ian Hulin wrote:
>>
>>> In order to get the markup stuff to compile or be interpreted
>>> correctly with Guile V2, I had to get the procedures validati
Plan for revising markups ::
NAMESPACE MANGLING OF GROB PROPERTIES
--) function
All grob properties will be associated with their interface. So, `Y-extent'
will no longer be internally represented as `Y-extent' but rather
`Y-extent@grob-interface'. When someone does:
\override Stem #'Y-exte
Ian Hulin writes:
> Because this means serious fiddling with the maoing markup code. I
> really hope you didn't write it because I agree with David, it's a
> fetid pile of Dingo's kidneys to maintain, and I fear it'll take me a
> lo-o-o-ong time and much cursing and swearing to change it.
I act
"m...@apollinemike.com" writes:
> I know very little about this whole Guile 2.0 business, but if there
> were ever a time to rewrite the markup code, this'd be it.
>
> It'd be a shame for Ian to do backflips over markups only to have them
> gutted in the future.
>
> Ideally, I would like to see e
Keith OHara writes:
> David Kastrup gnu.org> writes:
>
>> It turns out that display-scheme-music, unlike typical display-*
>> functions, returns the value it displays.
>
>
> I think the reason is to support \displayMusic, which lets users see
> the internal representation of a bit of their music
> It turns out that display-scheme-music, unlike typical display-*
> functions, returns the value it displays. The LilyPond code base
> (including regtests) does not make use of that feature, and it is
> totally disruptive when used on the Guile command line (because then
> any use of display-sch
This is an old, but good, article on bug handling. It just
occurred to me that maybe some people hadn't seen it before:
http://www.joelonsoftware.com/articles/fog29.html
Money quote (as far as I'm concerned):
A bug is like a hot potato: when it's assigned to you, you are
responsible t
On 16/12/11 17:51, David Kastrup wrote:
> Ian Hulin writes:
>
>> Guile V2 insists on some thing, particularly macros being
>> defined before they are used.
>
> That's not unreasonable.
>
>> When Patrick M. first tried out using Lily with Guile 2, the only
>> way we could use it was by relying o
On 16/12/11 18:07, David Kastrup wrote:
> Ian Hulin writes:
>
>> Because this means serious fiddling with the maoing markup code.
>> I really hope you didn't write it because I agree with David,
>> it's a fetid pile of Dingo's kidneys to maintain, and I fear
>> it'll take me a lo-o-o-ong time and
David Kastrup gnu.org> writes:
> > I think the reason is to support \displayMusic, which lets users see
> > the internal representation of a bit of their music along with the
> > output.
>
> That kind of support is neither required nor used by \displayMusic.
>
??
Well, of course the *user* of \
Keith OHara writes:
> David Kastrup gnu.org> writes:
>
>> > I think the reason is to support \displayMusic, which lets users see
>> > the internal representation of a bit of their music along with the
>> > output.
>>
>> That kind of support is neither required nor used by \displayMusic.
>>
> ?
If this is all it takes to solve the problem, then by all means let's do
it!
LGTM.
Carl
http://codereview.appspot.com/5487056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
19 matches
Mail list logo
