> On Jul 1, 2018, at 13:14, [email protected] 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
