On 02.05.2010 12:35, Martin Roppelt wrote:
> Mir sind ein paar Sachen aufgefallen:
Danke für’s Durchschauen!
> * Statt T_breve (o.ä.) ist ˘ angegeben. Angleichen?
> * Müsste es nicht T__abrg (ABove RiNg, siehe auch T__abdt) statt T__obrg
> heißen?
Ja, danke, siehe r2298
> * Die nun schon vor einiger Zeit vereinbarte Regelung für die Pseudoebene von
> d und y
> ist, so weit ich sehe, noch nicht aufgenommen. Was wäre dann das
> neo-vars-Äquivalent
> zu KP_Decimal? S_NSDec? Sollten wir vielleicht besser S_SNDot in S_SNSep (wie
> Separator)
> umbenennen? Oder S_NSCom für KP_Decimal nehmen?
Das verstehe ich jetzt nicht. Derzeit sind d und y in neovars folgendermaßen
definiert:
> EDS("027",1,"d","D",":","S__NDot","δ","Δ") ; d
> EDS("028",1,"y","Y","@","." ,"υ","∇") ; y
und das Komma am Zahlenblock so:
> EDNS("053",0,"S__NDot",".",",","S__NDel","S_SNDel","′","″") ; NumpadDot
Also auf d(4) und dem Zahlenblock-Komma(1) ist S__NDot, das sich in das
Windows-systemspezifische Zeichen für das Komma des Nummernblockes verwandelt,
siehe shortcuts.ahk:
> CSS__NDot := "NumpadDot"
So wird das dann vom AHK hinausgeschickt und erzeugt in aller Regel in den
Programmen ein Komma, außer das Programm arbeitet grundsätzlich mit einem
Punkt als Komma. Es ist also für die Funktion von AHK als nicht-Treiber sondern
Key-Remapper die kompatibelste Form, wenn es auf einem System mit
aktiviertem deutschen Layout eingesetzt wird.
Das ist natürlich anders, wenn man es bei einem aktivierten englischsprachigen
oder sonstwelchen Layout einsetzen will, das auf dem Zahlenblock einen
Punkt hat. Dann wird eben kein Komma mehr ausgegeben, sondern ein Punkt, wie es
den Systemgepflogenheiten entspricht.
Ich wüsste nicht, wie man diese Diskrepanz anders auflösen sollte.
– Mœsi
