Hi guys Many thanks for taking such an interest in this. I have been thinking. I can see that using the key signature to automatically donate sharps and flats is going to be a lot of work and cause problems.
Todays thoughts are: when you specify \language, then part of what you are doing is setting up the parser to understand which character sequence should indicate an f-sharp. I would like to be able to temporarily reconfigure this so that as well as mapping ‘fs’ to f-sharp you can ask it to map ‘F’ to f-sharp. I imagine that the parser is a finite state machine and that at the appropriate point it looks up a list. Normally this would say that ‘fs’ means f-sharp (or ‘fes’ means f-sharp if you were in another language). I guess it looks up a list of pitch names to check whether the current token is a pitch as expected and, if so, which one. If that list might have ‘F’ added at the beginning of the search order, then the parser would recognize the letter ‘F’ as meaning the pitch f-sharp. Later on, you could ask to remove the ‘F’ entry from that list. Removing it would automatically revert to the default behaviour because the list would still contain the entry to say that ‘fs’ means f-sharp. To avoid confusion, the request to add an item to the list would have the form (*newName, pitchNameInOriginalLanguage)*. I believe this would allow me to do what I originally wanted (to avoid having to type the accidentals when I’m working with music which is resolutely in one key) and would not raise any consequential problems. Granted one could get a headache if you mapped ‘e’ to mean f-sharp, but you’d deserve it. People who like quarter-tones might also enjoy being able to name them. This doesn’t seem to me like a big change. Gianmaria: It might possibly be doable in Frescobaldi but I don’t think it belongs there. One would end up with a source file which contained both LilyPond and Frescobaldi code. This is not an insuperable problem, but I don’t think it’s the right answer for this. Urs: I am always encoding a pitch as it is: but am asking that I get to give the pitch another name. Re the discussion about minor keys, in A minor you could set G to map to g-sharp and save keystrokes (unless you count the shift key as a keystroke in which case you might use ‘h’.) On Mon, 18 May 2020 at 18:24, Gianmaria Lari <[email protected]> wrote: > > [...]. That being said… >> >> Are not >> >> \relative f' >> >> and >> >> \fixed c''' >> >> just "feature requests for laziness with resulting opaqueness"? ;) > > [...] > >> > > We (well… modulo me LOL) don’t get this worked up about how \relative >> makes cut-and-paste a nightmare. Why start now? ;) > > > Some lilypond users get vaccinated against \relative issues and they are > using it without any problem (it's not my case). So looks pretty clear you > can live and get profit from \relative. > > Personally I really don't like \relative: it always cause problems to me > but maybe there are also aesthetic reasons for my aversion. > > As I previously said (few months ago) \relative is another thing that in > my opinion should be handle by the editor. > > Copy and paste issues with relative is only another bad things but for me > it's not the main one. For example I consider perfectly acceptable copy > and paste issues with Python indention because the benefits largely > outweigh the drawbacks imho. > G. >
