Can we keep this on hold yet? I haven't gotten myself to a more in-depth review of this yet and think this is going into a direction that is going to make more consistent behavior harder to provide at a later point of time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I implemented the easiest solution, and I don't see a contradiction. What issue #5240 talks about could be accomplished with something similar to overlapping slurs (i.e., using tags).
Of course, I won't do a commit without David's approval since he has the best eye IMHO for syntax things.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's part of what is troubling me: with slurs we can have immediately adjacent slurs and need to use spanner-id (using \=) for overlaps. Your proposed solution does one form of overlaps by default and would require some \=-like mechanism for immediate adjacency. I am not sure if "immediate adjacency" is the correct description for brackets both including the same note, though. And some special mechanism might be needed for disentangling the brackets: I have to do a few experiments to get a good hang of the current situation with regard to code and user interface and see how this fits in.
If I can't find a definite way to move forward, part of the reason we have unstable releases is to test drive such changes and get further feedback. It just becomes harder to dial them back once people have gotten to rely on them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2019-08-01
Patch: countdown --> push
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2019-08-01
Patch counted down - please push
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2019-08-10
Patch counted down - please push
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No shortage in chances here. Am still trying to get a hang of how this kind of nestedness fits with what we do elsewhere. At least the current form of brackets makes it infeasible to stop and start a bracket at the same time. I am not sure that banking on this is a good idea. At any rate, I still need to get a hang of what code would appropriately reflect a consistent design. As mentioned, we usually don't rely on order of events in engravers. I am not sure that the nesting of brackets is likely different here: after all they can start/end at the same moment and be labelled differently.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2019-08-25
I'll leave tihs another countdown
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2019-08-28
Patch: push --> needs_work
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2019-08-28
I am going to move this back to 'needs_work' (but feel free to change that if it is in appropriate).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Diff:
Passes make, make check and a full make doc.
Patch on countdown for Aug 1
Can we keep this on hold yet? I haven't gotten myself to a more in-depth review of this yet and think this is going into a direction that is going to make more consistent behavior harder to provide at a later point of time.
And it contradicts issue [#5240]. You cannot have both—single moment brackets and adjacent brackets—with the current input syntax.
Related
Issues: #5240
Well, I implemented the easiest solution, and I don't see a contradiction. What issue #5240 talks about could be accomplished with something similar to overlapping slurs (i.e., using tags).
Of course, I won't do a commit without David's approval since he has the best eye IMHO for syntax things.
That's part of what is troubling me: with slurs we can have immediately adjacent slurs and need to use spanner-id (using
\=) for overlaps. Your proposed solution does one form of overlaps by default and would require some\=-like mechanism for immediate adjacency. I am not sure if "immediate adjacency" is the correct description for brackets both including the same note, though. And some special mechanism might be needed for disentangling the brackets: I have to do a few experiments to get a good hang of the current situation with regard to code and user interface and see how this fits in.If I can't find a definite way to move forward, part of the reason we have unstable releases is to test drive such changes and get further feedback. It just becomes harder to dial them back once people have gotten to rely on them.
Patch counted down - please push
Patch counted down - please push
I'm going to get myself look at this topic thoroughly this weekend.
Patch on countdown for Ausgut 15th
Patch counted down - please push.
David, did you have a chance to look at the issue?
No shortage in chances here. Am still trying to get a hang of how this kind of nestedness fits with what we do elsewhere. At least the current form of brackets makes it infeasible to stop and start a bracket at the same time. I am not sure that banking on this is a good idea. At any rate, I still need to get a hang of what code would appropriately reflect a consistent design. As mentioned, we usually don't rely on order of events in engravers. I am not sure that the nesting of brackets is likely different here: after all they can start/end at the same moment and be labelled differently.
I'll leave tihs another countdown
I am going to move this back to 'needs_work' (but feel free to change that if it is in appropriate).