This is just a feature request for laziness with resulting opaqueness. I think it has been requested several times over the years because of other program's bad habits.
Shane On Mon, May 18, 2020 at 12:17 PM Urs Liska <li...@openlilylib.org> wrote: > Am Montag, den 18.05.2020, 18:11 +0200 schrieb David Kastrup: > > Gianmaria Lari <gianmarial...@gmail.com> writes: > > > > > Hello Paul, > > > > > > > > > > [...]If I'm writing music in F, then I suggest that I be able to > > > > use *bF* > > > > as a pitch instead of *bf*. The *F* would indicate that all > > > > subsequent *b*s > > > > would be flattened until one is encountered with a different > > > > accidental or > > > > until the end of the current music expression. It should have the > > > > same > > > > scope as \stemUp or similar. [...] > > > > > > > > > > I don't know "how much Frescobaldi knows" of the lilypond code the > > > user is > > > editing. If it has a logical representation of the source code it > > > could be > > > Frescobaldi (and not lilypond) to handle this feature and offering > > > to > > > autocorrect, according the key signature indicated in the source > > > code, the > > > note you write while you write it. > > > You are in F, you write b and it propose bes. > > > Maybe with different language (never used english for lilypond note > > > input) > > > this would be more difficult..... > > > > As an editing feature, this makes a lot more sense in my book: you > > see > > the effects it has and have the means to correct them immediately, > > like > > with actual graphic input. But for a batch processor, this kind of > > second-thinking is a recipe for trouble, and the more second-thinking > > there is, the harder it is to reliably get results without the > > corresponding visual feedback. > > > > I think there are only two reliable (and therefore reasonable) > approaches. Either you encode a pitch at what it "is" (a f sharp is > always an f sharp) or you encode it at how it is printed (a note in the > first staff space of a treble clef is encoded as "f" and will be > rendered as an f in c major but as an f sharp in d major. I really > dislike this idea but it is done so for example in MEI, also Amadeus' > input language works that way, and a power user insisted to me it is > superior because it doesn't cause ambiguity but substantially less > keystrokes). > > But having "f" behave depending on what has been encoded before is > begging for disaster. Copy&paste has already been mentioned, but I > think it is already harder to *read* in the input file. This by far > outweighs the saved keystrokes IMHO. > > My 2cts > Urs > > > >
