lilypond-devel
[Top][All Lists]
Advanced

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

Re: Issue 5362: Generalize context searches (issue 344050043 by address@


From: Dan Eble
Subject: Re: Issue 5362: Generalize context searches (issue 344050043 by address@hidden)
Date: Sun, 1 Jul 2018 14:17:12 -0400

> On Jul 1, 2018, at 13:14, address@hidden wrote:
> 
> Something like
> origin->warning (_f ("Cannot find or create context: %s",
> ctx->identification ()))

Meh.  Multiple callers would repeat the message “cannot find or create context” 
which is part of what I was trying to avoid.  I wouldn’t stake this whole patch 
on getting it my way, but let’s mull it over while I work on the other 
revisions.

If there were a good example that the message ought to be tailored to each 
specific scenario, I’d more willingly let the caller provide the whole text.  I 
did think about that and couldn’t justify it to myself.

> Well, in this case ctx could not created, so we need an alternative
> static string Context::identification (id, name)

I like this, but doesn’t it run counter to the guidance in the CG under the 
statement "Split up multi-sentence messages, whenever possible” and also “When 
translating, it is preferable to put interesting information at the end of the 
message rather than embedded in the middle”?  Reading that, I thought that 
having the context name and ID each at the end of separate messages would be 
preferred.

Consider also that these proposed changes come out of an experiment with adding 
a new constraint on find-context operations: properties that must be defined.  
The names of those properties should be logged if the context is not found, but 
they are not part of the identity.  So, we could use 
Context::format_search_constraints_for_logging (name, id, property_syms), or 
let the callers handle the ID constraints and property constraints separately, 
or keep the proposed approach of passing the source location and all 
constraints into a function that does the rest.

> the
> context-identification formatter might be nice even from Scheme, with
> either a context argument or two arguments (whatever it was, symbol or
> string).  That way we'd get a uniform format for such messages.

Probably worth doing separately for its own sake.  Can you identify one place 
you would like to see it used?
— 
Dan




reply via email to

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