Issue 239930043: Add French-specific note names (Closed)
|
Created:
9 years, 11 months ago by Valentin Villenave Modified:
9 years, 1 month ago CC:
lilypond-devel_gnu.org Visibility:
Public. |
DescriptionAdd French-specific note names
French users may (and do) want to enter the D pitch
as "ré" instead of Italian-like "re".
This also brings the -x double-sharp suffix to
French input language (an unrelated but welcome addition).
Patch Set 1 #
Total comments: 4
Patch Set 2 : Add -x suffix in italiano; "ré" comes before "re" in French #Patch Set 3 : Add convert rules #
Total comments: 6
MessagesTotal messages: 22
Greetings everybody, here’s an itch I’ve been wanting to scratch for the past decade or so: as a French user, having to type "re" instead of "ré" feels unnatural (and it still does after ten years); it is not uncommon that my scores fail to compile because I’ve inadvertently typed "ré" somewhere in the source code. It’s also affecting newcomers to LilyPond, judging from my students; a few years ago, I had added \language "français" as an alias to "italiano" hoping that it would make things easier to explain, but that particular oddity remains to this day. I know that accented chars in the source code is not something traditional coders want to have, but LilyPond has been utf8-based for quite a while now so this shouldn’t be too disruptive a change.
Sign in to reply to this message.
v.villenave@gmail.com writes: > Reviewers: , > > Message: > Greetings everybody, > here’s an itch I’ve been wanting to scratch for the past decade or so: > as a French user, having to type "re" instead of "ré" feels unnatural > (and it still does after ten years); it is not uncommon that my scores > fail to compile because I’ve inadvertently typed "ré" somewhere in the > source code. > > It’s also affecting newcomers to LilyPond, judging from my students; a > few years ago, I had added \language "français" as an alias to > "italiano" hoping that it would make things easier to explain, but that > particular oddity remains to this day. Well, with notenames like "re" it should have been \language "francais"... I think we even had this at one time. No wait, that was "espanol". > I know that accented chars in the source code is not something > traditional coders want to have, but LilyPond has been utf8-based for > quite a while now so this shouldn’t be too disruptive a change. It's actually the few files containing UTF-8 characters which currently are messing up our GUILE-2 conversion. But it's not like we could make do without them either. > This also brings the -x double-sharp suffix to > French input language (an unrelated but welcome addition). Shouldn't Italian have this also then? > Please review this at https://codereview.appspot.com/239930043/ -- David Kastrup
Sign in to reply to this message.
On 2015/05/17 08:39:00, dak wrote: > Well, with notenames like "re" it should have been \language > "francais"... I think we even had this at one time. No wait, that was > "espanol". Yes. "español" is aliased to "espanol", and "français" is now aliased to "francais" in the same way. > It's actually the few files containing UTF-8 characters which currently > are messing up our GUILE-2 conversion. But it's not like we could make > do without them either. Yes. I don’t think this patch will make matters worse. > Shouldn't Italian have this also then? I thought about adding it there as well. Will do.
Sign in to reply to this message.
On 2015/05/17 09:44:52, Valentin Villenave wrote: > On 2015/05/17 08:39:00, dak wrote: > > Well, with notenames like "re" it should have been \language > > "francais"... I think we even had this at one time. No wait, that was > > "espanol". > > Yes. "español" is aliased to "espanol", and "français" is now aliased to > "francais" in the same way. Oh, I was joking. I don't think we want "francais". People were annoyed enough at "espanol".
Sign in to reply to this message.
https://codereview.appspot.com/239930043/diff/1/scm/define-note-names.scm File scm/define-note-names.scm (right): https://codereview.appspot.com/239930043/diff/1/scm/define-note-names.scm#new... scm/define-note-names.scm:566: (rébb . ,(ly:make-pitch -1 1 DOUBLE-FLAT)) It would seem to me that ré etc should be the primary French notenames and thus come before re etc in the list. This is not merely a cosmetical change since \displayLilyMusic will use the first occurence of a pitch in a given notename language in order to output a pitch.
Sign in to reply to this message.
Add -x suffix in italiano; "ré" comes before "re" in French
Sign in to reply to this message.
https://codereview.appspot.com/239930043/diff/1/Documentation/notation/pitche... File Documentation/notation/pitches.itely (right): https://codereview.appspot.com/239930043/diff/1/Documentation/notation/pitche... Documentation/notation/pitches.itely:492: @item @code{francais} or @code{français} Please don't introduce "francais". If people want to input without accents, they can do so using "italiano" in the first place. And if there is no point in naming a language "francais" rather than "français" if people are supposed to input the language using accents. https://codereview.appspot.com/239930043/diff/1/python/convertrules.py File python/convertrules.py (right): https://codereview.appspot.com/239930043/diff/1/python/convertrules.py#newcod... python/convertrules.py:3562: or re.search ('\\language\s(?!\s*#?"(?:catalan|espanol|español|italiano|francais|français|portugues|vlaams))"', str)): There are a number of things wrong here: first, we don't want a notename language "francais" in the first place when the language is supposed to support entry of "ré". That's nonsensical. Second, there is no point in treating "francais" anyway in a conversion rule for 2.17.15 where it cannot possibly be defined as this patch is intended for 2.17.21.
Sign in to reply to this message.
https://codereview.appspot.com/239930043/diff/1/Documentation/notation/pitche... File Documentation/notation/pitches.itely (right): https://codereview.appspot.com/239930043/diff/1/Documentation/notation/pitche... Documentation/notation/pitches.itely:492: @item @code{francais} or @code{français} On 2015/05/18 12:09:18, dak wrote: > Please don't introduce "francais". Then, shouldn’t we deprecate "espanol" as well? (Just above.) I can add a convert-ly rule if needed.
Sign in to reply to this message.
On 2015/05/18 17:08:20, Valentin Villenave wrote: > https://codereview.appspot.com/239930043/diff/1/Documentation/notation/pitche... > File Documentation/notation/pitches.itely (right): > > https://codereview.appspot.com/239930043/diff/1/Documentation/notation/pitche... > Documentation/notation/pitches.itely:492: @item @code{francais} or > @code{français} > On 2015/05/18 12:09:18, dak wrote: > > Please don't introduce "francais". > > Then, shouldn’t we deprecate "espanol" as well? (Just above.) It does not have non-ASCII notenames, so you might end up with "español" being the only non-ASCII word in the file. "francais" is not historical, and its distinguishing feature is that it uses non-ASCII notenames anyway. So there just is no point in adding it. If French speakers do not intend to use non-ASCII notenames, I guess they'll be happier writing "italiano" than the non-word "francais".
Sign in to reply to this message.
Add convert rules
Sign in to reply to this message.
On 2015/05/18 17:38:22, dak wrote: > It does not have non-ASCII notenames, so you might end up with "español" being > the only non-ASCII word in the file How much of a potential problem is it? Even in the absence of non-ASCII chars, users are already strongly encouraged to use UTF8 encoding in their source files. Historically, I suspect the only reason why we’ve been stuck with "espanol" for so long is because it was in fact a file name: \include "espanol.ly" (and special chars in filenames are tricky when you’re taking into account multiple platforms). Now that the \language command has been introduced (for several years, I might add), that reason has become moot so it’s only logical to complete the transformation and make full use of accented chars in language names (if not in note names, as we’ve seen).
Sign in to reply to this message.
On 2015/05/18 18:20:20, Valentin Villenave wrote: > On 2015/05/18 17:38:22, dak wrote: > > It does not have non-ASCII notenames, so you might end up with "español" being > > the only non-ASCII word in the file > > How much of a potential problem is it? Even in the absence of non-ASCII chars, > users are already strongly encouraged to use UTF8 encoding in their source > files. How so? LilyPond _only_ accepts UTF-8 input, but we don't "strongly encourage" users to use characters outside of the ASCII plane even if they don't want to.
Sign in to reply to this message.
El 18/05/2015 20:20, <v.villenave@gmail.com> escribió: > > On 2015/05/18 17:38:22, dak wrote: >> >> It does not have non-ASCII notenames, so you might end up with > > "español" being >> >> the only non-ASCII word in the file > > > How much of a potential problem is it? Even in the absence of non-ASCII > chars, users are already strongly encouraged to use UTF8 encoding in > their source files. I'd favor plain keys, common in most keyboards of the world, over the 'ASCII only' doctrine. The problem I see with 'español' only and deprecating 'espanol' (a non-word) is that not only Spanish keyboard users suppossedly will want to use the keyword. I'd like to have both as mutual aliases, so to say. I will not use either of them anyway but they are good to have. Besides, this is the status for Spanish users: 'ñ' is a non-shift-needing key in a very prominent place. On the contrary, the very lilypondish '{}[]\' set are all hidden under AltGr. > > Historically, I suspect the only reason why we’ve been stuck with > "espanol" for so long is because it was in fact a file name: \include > "espanol.ly" (and special chars in filenames are tricky when you’re > taking into account multiple platforms). > > Now that the \language command has been introduced (for several years, I > might add), that reason has become moot so it’s only logical to complete > the transformation and make full use of accented chars in language names > (if not in note names, as we’ve seen). I don't oppose but the alias is cheap. Spanish note names are not accented. BTW dear lazylist: where do you have the 'ñ' on your keyboards? -- Paco
Sign in to reply to this message.
On Mon, May 18, 2015 at 9:20 PM, Francisco Vila <paconet.org@gmail.com> wrote: > Besides, this is the status for Spanish users: 'ñ' is a non-shift-needing > key in a very prominent place. On the contrary, the very lilypondish '{}[]\' > set are all hidden under AltGr. Likewise here. > I don't oppose but the alias is cheap. Spanish note names are not accented. The alias already exists, and I don’t intend to remove it. However, since we’re recommending \language over \include, and "español" over "espanol", I’ve written a convert-ly for existing files (even though the old, non-recommended syntax will still be supported, at least for the time being). > BTW dear lazylist: where do you have the 'ñ' on your keyboards? Like most diacritics, in France it involves first typing AltGr+é for the tilda, then adding the "n" separately. Cheers, Valentin.
Sign in to reply to this message.
Valentin Villenave <v.villenave@gmail.com> writes: > On Mon, May 18, 2015 at 9:20 PM, Francisco Vila <paconet.org@gmail.com> wrote: >> Besides, this is the status for Spanish users: 'ñ' is a non-shift-needing >> key in a very prominent place. On the contrary, the very lilypondish '{}[]\' >> set are all hidden under AltGr. > > Likewise here. > >> I don't oppose but the alias is cheap. Spanish note names are not accented. > > The alias already exists, and I don’t intend to remove it. > > However, since we’re recommending \language over \include, and > "español" over "espanol", We are recommending "español" over "espanol"? Says who? > I’ve written a convert-ly for existing files (even though the old, > non-recommended syntax will still be supported, at least for the time > being). Where do you get the "non-recommended" idea? -- David Kastrup
Sign in to reply to this message.
On Mon, May 18, 2015 at 9:52 PM, David Kastrup <dak@gnu.org> wrote: > We are recommending "español" over "espanol"? Says who? Sorry. I should have said: we’re _likely_ to recommend "español" over "espanol" in the future, now that the syntax allows it. You said yourself that people had been getting annoyed at "espanol" in the past. > Where do you get the "non-recommended" idea? I was drawing a parallel with what we’ve been doing for the past year regarding \language: we’re using \language everywhere in the docs and regtests, and \include "mylanguage.ly" isn’t even documented anywhere; however, the old syntax is still supported for now. Likewise, we’ve been recommending that people use \relative c' {} rather than \relative {} (with an implicit c) for a number of years before retiring the implicit syntax and replacing it with a new meaning. So, my guess would be that we *could* start recommending \language "español" rather than \language "espanol" since both syntaxes have been available for some time now, and both will still work anyway for the time being. Unless the non-ASCII chars are a problem, of course. Cheers, Valentin.
Sign in to reply to this message.
Valentin Villenave <v.villenave@gmail.com> writes: > So, my guess would be that we *could* start recommending \language > "español" rather than \language "espanol" since both syntaxes have > been available for some time now, and both will still work anyway for > the time being. > > Unless the non-ASCII chars are a problem, of course. They may be for some users using LilyPond. The situation is different with "français" since the whole point making it different from "italiano" is "ré". -- David Kastrup
Sign in to reply to this message.
Valentin Villenave wrote Monday, May 18, 2015 8:41 PM >> BTW dear lazylist: where do you have the 'ñ' on your keyboards? > > Like most diacritics, in France it involves first typing AltGr+é for > the tilda, then adding the "n" separately. We don't have it anywhere on the English keyboard. After a bit of research (eg see http://www.forlang.wsu.edu/help/keyboards.asp) on my laptop I have to hold down the Alt key and the Fn key, and type JOU, which is actually 164 with the Fn key pressed. (It would be 164 on the numeric key pad, but my laptop doesn't have one. The Fn key simulates one using 10 letter keys. Instead of holding down Fn I could press Num Lk which does the same thing.) And here it is: ñ Alternatively I could fire up the character map which is hidden in All Programs/Accessories/System Tools, hunt for the character in the required font, and cut and paste it. Here it is: ñ The only characters under Alt Gr are acute accent vowels: áéíóú. No idea what code is generated. Pretty sure it isn't unicode. You can see why we seem to be lazy ;) Trevor
Sign in to reply to this message.
On Tue, May 19, 2015 at 11:12 PM, Trevor Daniels <t.daniels@treda.co.uk> wrote: > on my laptop I have to hold down the Alt key and the Fn key, and > type JOU, which is actually 164 with the Fn key pressed. That’s because, for some unexplainable reason, you’re still a proud Windows user :-) On a standard GNU Linux english keyboard, you’d just have to press Alt-Gr+], then "n". Anyway, this is all fine and dandy but: what do we do with my patch? Is \include "espanol.ly" -> \language "espanol" -> \language "español" an acceptable automated conversion? Cheers, Valentin.
Sign in to reply to this message.
El 19/05/2015 23:12, "Trevor Daniels" <t.daniels@treda.co.uk> escribió: > > > Valentin Villenave wrote Monday, May 18, 2015 8:41 PM > > >> BTW dear lazylist: where do you have the 'ñ' on your keyboards? > > > > Like most diacritics, in France it involves first typing AltGr+é for > > the tilda, then adding the "n" separately. > > We don't have it anywhere on the English keyboard. > > After a bit of research > (eg see http://www.forlang.wsu.edu/help/keyboards.asp) > on my laptop I have to hold down the Alt key and the Fn key, and > type JOU, which is actually 164 with the Fn key pressed. > (It would be 164 on the numeric key pad, but my laptop doesn't have > one. The Fn key simulates one using 10 letter keys. Instead > of holding down Fn I could press Num Lk which does the same thing.) > > And here it is: ñ > > Alternatively I could fire up the character map which is hidden in > All Programs/Accessories/System Tools, hunt for the character > in the required font, and cut and paste it. > > Here it is: ñ > > The only characters under Alt Gr are acute accent vowels: áéíóú. Seriously? I've played a bit on Linux and can type dozens of esoteric characters plus shift plus diacritic+shift etc. > No idea what code is generated. Pretty sure it isn't unicode. > > You can see why we seem to be lazy ;) Oh sorry, I said lazylist meaning the lazy one is really me. > > Trevor
Sign in to reply to this message.
Valentin Villenave <v.villenave@gmail.com> writes: > On Tue, May 19, 2015 at 11:12 PM, Trevor Daniels <t.daniels@treda.co.uk> wrote: >> on my laptop I have to hold down the Alt key and the Fn key, and >> type JOU, which is actually 164 with the Fn key pressed. > > That’s because, for some unexplainable reason, you’re still a proud > Windows user :-) > On a standard GNU Linux english keyboard, you’d just have to press > Alt-Gr+], then "n". > > Anyway, this is all fine and dandy but: what do we do with my patch? Is > \include "espanol.ly" -> \language "espanol" -> \language "español" > an acceptable automated conversion? In my book, no. We don't turn an ASCII-only file into UTF-8 without asking. That's just rude. -- David Kastrup
Sign in to reply to this message.
There seems to be a way to do this as a simple expansion of capabilities, so you do need to change existing input files. Have \language"français" accept 'ré', and also 're' for backward compatibility with the former use of Italian names. https://codereview.appspot.com/239930043/diff/40001/Documentation/changes.tely File Documentation/changes.tely (right): https://codereview.appspot.com/239930043/diff/40001/Documentation/changes.tel... Documentation/changes.tely:70: of the @code{\language} command. I suggest showing the complete @code{@w{\language "italiano"}) https://codereview.appspot.com/239930043/diff/40001/Documentation/changes.tel... Documentation/changes.tely:74: generic Italian-derived syntax, the @var{d} pitch may be In English the pitch names are capital and upright: "the pitch D may be" https://codereview.appspot.com/239930043/diff/40001/Documentation/changes.tel... Documentation/changes.tely:81: deprecated in favor of @code{"español"} and @code{"français"} I think we should keep "espanol" because the Castañedas and ÓHaras and Müllers of the world sometimes have to use systems that work best if we keep our text files within ASCII. There is no reason to deprecate "francais" because we do not currently have it. https://codereview.appspot.com/239930043/diff/40001/python/convertrules.py File python/convertrules.py (right): https://codereview.appspot.com/239930043/diff/40001/python/convertrules.py#ne... python/convertrules.py:3753: str = re.sub ('\\\\language\s*"francais"', '\\\\language "français"', str) We should not do an automatic conversion from ASCII to an expanded character set. https://codereview.appspot.com/239930043/diff/40001/scm/define-note-names.scm File scm/define-note-names.scm (right): https://codereview.appspot.com/239930043/diff/40001/scm/define-note-names.scm... scm/define-note-names.scm:543: (francais . ( You can have here français https://codereview.appspot.com/239930043/diff/40001/scm/define-note-names.scm... scm/define-note-names.scm:1077: ;; add two native utf-8 aliases. Pairs obey cp-like order: '(old new) "add one native utf-8 alias" The new français does not need an alias
Sign in to reply to this message.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
