Re: Make Grid take an edit id

[Valentin Petzel]

The big difference here is that with the context names one would need to 
redefine the whole grid whenever something changes. Meanwhile the id way allows 
for each context to chime in and out on the grid without knowing what else is 
on the grid. This gets really useful when we do things like parts, as with the 
context name way we kind of get a problem if we remove the context that defines 
the grid.

At least I do not understand how the context name approach is supposed to 
handle such cases with just one startGrid and one stopGrid?

Also the individual approach allows us to set different grid intervals for 
different contexts very easily, while the global approach would require 
definition of multiple grids.

I am totally with you that making the input more convenient is a thing to 
strive for, but I’m not sure if the context name approach is in fact more 
convenient in most situations. At least I’m feeling kind of bad about forcing 
a need for context IDs for something like a grid.

I’ll do a test implementation for both versions, so we can have something 
solid to compare.

Is there a good reason why we limit the scheme handles for find_context to 
finding above and only by context name (and not id)? If not I’d revise this, as 
the context id based approach would require such functionality.

Cheers,
Valentin

Am Sonntag, 2. Jänner 2022, 17:00:20 CET schrieb Jean Abou Samra:
> Le 02/01/2022 à 09:20, Valentin Petzel a écrit :
> > Sorry, that was not meant that way. This was intended to demonstrate the
> > usefulness of having such an id for the line, no matter if it is a
> > separate
> > property or a value of details.
> > (Having one id property for all grobs does seem reasonable.)
> > 
> > About the other thing: It gets more complicated for both the
> > implementation
> > and the user. For example in a situation where the number of encompassed
> > Staves is not fixed, e.g. when Staves are added or removed during the
> > music (as shown in the appendend very bad example) the context name based
> > approach is rather complicated, as for each change to the staves we’d
> > need to create a new grid. Instead with an id based approach it is
> > sufficient to do something like
> > 
> > \startGrid id moment
> > for each staff in the place it is needed and
> > \stopGrid id
> > once we want to take the staff out of the grid.
> 
> As I understand it, this gives you one
> \startGrid and one \stopGrid at each
> moment when you change the grid scheme
> in your example. In contrast, context
> names give you one \stopGrid and one
> \startGrid "name of context", and you
> no longer have to declare the grids in
> advance. That's not bad, is it? Assuming
> that I'm misunderstanding what you mean,
> I still think it would be worth it to
> make the input more convenient in 90%
> of cases even if that means less convenience
> in the remaining 10%.
> 
> Best,
> Jean

signature.asc
Description: This is a digitally signed message part.