Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
Hi Martin, On Wednesday 20 October 2010 22:51:12 Martin Roppelt wrote: Zum Beispiel hat mir eine Bekannte erzählt, dass sie im Tippkurs gelernt hat, dass bei Neo „sh“ das „s“ vom Zeigefinger und das „h“ vom Mittelfinger gedrückt werden sollte. Ja, natürlich, es wird eine stetige Beibehaltung der Grundstellung gelehrt. Das Tippen mit schwebenden Händen ist interessant und auch möglich (neulich hatte mir jemand erzählt er hat Qwertz über 2-Finger-System gelernt, Finger dazugenommen – und irgendwann hat er das blind gemacht, ohne sich dabei an irgendwelche „Regeln“ zu halten), aber schwieriger (zu lernen). Das war bei mir auch so. Der Nachteil war, dass ich nie wirklich blind tippen konnte, weil ich alle paar Wörter meine Handhaltung prüfen musste („ist die Taste wirklich da?“). Der Vorteil war, dass die Haltung etwas angenehmer war als die Starre, weil eben die Hände sich stetig etwas bewegt haben. Solche Bewegungen ließen sich dann auch abbilden. Werden sie dann Standard? Wird dann gleichzeitig auf „normale“ und diese Schreibweise optimiert? Btw finde ich die starre besser, die andere mag allerdings mehr Möglichkeiten eröffnen, ergonomisch zu schreiben (oder auch nicht …), fragt sich dann nur, ob das dann wirklich noch ergonomisch ist. Ich denke, um das zu diskutieren ist die Liste hier da. Ich habe keine Ahnung, wie viele Leute hier starr oder schwebend tippen. Ich finde an der Starren v.a. gut, dass ich sie schnell lernen konnte. Aber gerade bei 2-mod-Griffen breche ich aus ihr aus, und ich denke mit mehr Schreibpraxis im starren tippen werde ich an noch mehr Stellen aus ihr ausbrechen. Mein Qwertz hatte 10 Jahre mit kontinuierlich viel Tippen, um sich zu entwickeln, mein Neo hat bisher nichtmal ein Jahr. Ein Gedanke, den ich noch hatte ist, bei uB die Fingerkollision von u und shift-L stärker zu werten als bei Bu, weil shift etwas früher gedrückt und gelöst wird als b. Macht Sinn. Dann schau ich das mal genauer an. Danke! Liebe Grüße, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. - Arne (http://draketo.de) signature.asc Description: This is a digitally signed message part.
Re: [Neo] Schwebende vs. starre Handhaltung (was: Brauche Hilfe bei)
Am 21.10.2010 08:18, schrieb Arne Babenhauserheide: Hi Martin, On Wednesday 20 October 2010 22:51:12 Martin Roppelt wrote: Zum Beispiel hat mir eine Bekannte erzählt, dass sie im Tippkurs gelernt hat, dass bei Neo „sh“ das „s“ vom Zeigefinger und das „h“ vom Mittelfinger gedrückt werden sollte. Ja, natürlich, es wird eine stetige Beibehaltung der Grundstellung gelehrt. Das Tippen mit schwebenden Händen ist interessant und auch möglich Ich finde, eine optimierte Tastatur wie Neo sollte schon von einer festen Grundstellung ausgehen, und genau dafür optimieren. Schwebende Handhaltung ist dann höchstens ein Mittel, um nicht-optimale Bigramme zu tippen, wie das englische „sh“, auf das Neo 2 nicht optimiert ist. Aber eigentlich sollten so ungünstige Fingerkollisionen zumindest bei Neo 3 so selten vorkommen, dass es sich nicht lohnt, dafür spezielle Grifftechniken zu trainieren. Nora
Re: [Neo] Probleme mit der Zeichenkodiernung
Am 21.10.2010 10:16, schrieb Florian Janßen: Hallo, die beiden vorigen Mails werden in meinem TB beide richtig dargestellt, aber wenn ich bei Christians Mail antworte, werden alle Zeichen richtig dargestellt, bei der Mail von Ersafan so: Meinst du î? das »î« sollte ein ⋮ sein Compose: k| sollte „Compose:♫…|“ sein. Kann das jemand bestätigen? Oder ist das bei mir ein einzel Fall? Gruß Florian P.S.: Ich verwende TB3.1.5 auf Win7 64bit Wenn ich dir antworten will, scheint alles in Ordnung, wenn ich auf Ersafans Antwort antworten will, habe ich mit meinem TB genau die gleichen Fehler. Gruß Konrad
Re: [Neo] Probleme mit der Zeichenkodiernung
Hallo, hier schon wieder kaputt :( Kannst du noch mal auf meine Mail antworten, diesmal jedoch ohne(!) PGP-Signierung? Gruß Florian P.S.: Kannst die Mail auch direkt an mich schicken, dann wird die Liste nicht vollgemüllt.
[Neo] inline-PGP ist böse (was: Re: Problem e mit der Zeichenkodiernung)
Am 21.10.2010 10:43, schrieb Ersafan Rend: Antwort _ohne_ Signatur Jetzt klappt es. Drum bekommst nun auch du diese Mail (ich habe sie auch schon bekommen, ich glaube da muss jeder mit TB und PGP durch ;) ) Mail geht wieder an die Liste, da es auch andere betrifft: Hallo Ersafan, schon oft wurde diese Forderung über die Mailingliste verschickt, weil Enigmail/Thunderbird ziemlich altbackene Standardeinstellungen hat. Man kann seine E-Mails mit zwei Verfahren verschlüsseln/unterschreiben. ‣ inline-PGP ‣ PGP/MIME Verwenden sollte man nur letzteres¹: Der Vorteil von PGP/MIME ist, dass die ganze Nachricht samt Anhängen verschlüsselt/signiert wird. Darüber hinaus verträgt sich PGP/MIME auch mit HTML-Nachrichten und speziellen Zeichensätzen wie UTF-8 oder Chinesisch (beides Stolpersteine für Inline PGP). Nochmal auf englisch²: Why is it bad? The problems include: * Attachments doesn't work. * Non-ASCII doesn't work reliably. * Format=flowed (RFC 2646/3676) doesn't work reliably. * UseNet '-- ' signatures trigger space stuffing, which break compatibility with RFC 1991. * Sending 'diff' patches via inline PGP signed e-mail trigger space stuffing, which break cut'n'paste into 'patch'. So, und nun zum konkreten Problem: Du Florian sendest Deine Nachrichten mittels inline-PGP-Unterschrift (böööse!). ;-) Dass Du sie überhaupt unterschreibst ist natürlich super, dann weiß man wenigstens, dass sie wirklich von Dir kommen. Umstellen kannst Du das hier: Linux: »Bearbeiten → Konten… → OpenPGP-Sicherheit → PGP/MIME immer verwenden« (Haken setzen). Windows: »Extras → Konten… → OpenPGP-Sicherheit → PGP/MIME immer verwenden«. Wenn Du mal eine Nachricht mittels inline-PGP versenden willst (also *nicht* PGP/MIME), dann musst Du einfach beim Verfassen der Nachricht im Menü »OpenPGP → PGP/MIME verwenden« abwählen. ¹ http://www.thunderbird-mail.de/wiki/Enigmail_OpenPGP_-_FAQ ² http://josefsson.org/inline-openpgp-considered-harmful.html signature.asc Description: OpenPGP digital signature
Re: [Neo] [ticket] #187: Gnome: Compose-Problem
#187: Gnome: Compose-Problem --+- Reporter: dennis | Owner: Type: Fehler/Defekt| Status: closed Priority: niedrig | Milestone: Neo Version 2.0 Component: Treiber: Linux – Xkbmap | Version: 2.0 Final Resolution: worksforme |Keywords: Gnome, Compose --+- Changes (by dennis): * priority: normal = niedrig * status: new = closed * version: 2.0 BETA = 2.0 Final * resolution: = worksforme Comment: Ich schließe mal dieses Ticket: Ich glaube, meine ~/.XCompose war einfach zu gross, bei einer ›normalen‹ Größe (also ohne solchen ›fetten‹ Module wie ♫uu) kann ich den Fehler selbst nicht mehr nachvolliehen. -- Ticket URL: https://wiki.neo-layout.org/ticket/187#comment:3 Neo-Layout http://neo-layout.org/ Das Neo-Tastaturlayout ist ein freies und ergonomisch optimiertes Tastaturlayout für die deutsche Sprache, das auch sehr viele Sonderzeichen direkt verfügbar macht.
Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
Sorry, ich habe das gestern versehentlich direkt an Arne geschickt. Jetzt aber richtig: Für Leute, deren Job Kernelprogrammierung ist, könnte sich die Optimierung lohnen. Auch wenn die Programmiersprache oder sogar das Programmierprojekt feststeht, man müsste noch wissen ob emacs, vi oder Eclipse benutzt wird. Was im Korpus steht ist nicht alles auch getippt worden. Tools nehmen unter Umständen einiges ab. Genauso für Leute, die viel Griechisch oder mathematische Symbole schreiben. Die bevorzugten Symbole sind in unterschiedlichen Disziplinen verschieden. Ich glaube nicht, dass sich ein repräsentativer Korpus für mathematische Symbole finden lässt. Ausserdem, wenn man annimmt, dass die lateinischen und griechischen Buchstaben aneinander kleben (a am α und so weiter) müsste man normale Texte und Formeln gegeneinander abwiegen. Dafür brauchen wir „nur“ einen korrekten Korpus :) Es geht schließlich darum, das tippen zu können, was im Korpus steht. Ja, man braucht einen hinreichend korrekten Korpus, weil nur ein korrekter Korpus repräsentiert, was man tippen will. Ich habe mir tatsächlich schon überlegt, meinen (3MB) Korpus zu bearbeiten, aber das ist viel Arbeit mit sehr begrenztem Nutzen. Ich fände es grundlegend noch schöner, die feste Zuordnung der Finger auf die Tasten aufzulösen. Zum Beispiel hat mir eine Bekannte erzählt, dass sie im Tippkurs gelernt hat, dass bei Neo „sh“ das „s“ vom Zeigefinger und das „h“ vom Mittelfinger gedrückt werden sollte. Das läuft darauf hinaus, dass derselbe Text bei derselben Belegung mit unterschiedlichen Bewegungen getippt werden kann. Schwierig zu bewerten und schwierig zu lernen. Es könnte aber wirklich die Tippeffizienz steigern. Gerade auf der linken Tastaturhälfte könnte man einiges mit den «falschen» Fingern machen. Das ist das Bigrammgewicht Mod6R-Mod6L. Hier müsste man allerdings noch berücksichtigen, dass Mod4R ausnahmsweise vom Ringfinger getippt wird. Du meinst M4L, oder? Ja, richtig. Um das hier zu berücksichtigen, müsste die Handverschiebung von M3L-M4L erhalten bleiben, d.h. wir müssten komplett auf Trigramme wechseln (teuer). Da braucht man noch keine Trigramme. Die Idee mit virtuellen Tasten ist ja gerade, das gleichzeitige Drücken von Mod3L und Mod4 wie einen einzigen Tastendruck zu behandeln. Ein Gedanke, den ich noch hatte ist, bei uB die Fingerkollision von u und shift-L stärker zu werten als bei Bu, weil shift etwas früher gedrückt und gelöst wird als b. …ich glaube allerdings, die Idee ist auch von dir ;) Ich bin von meiner Ansicht abgerückt. Heute behaupte ich, man müsste die u-ShiftL-Kollision normal und die von u-b Kollision schwächer werten, weil zwischen u und b ja noch eine Taste (ShiftL) gedrückt wird. Das ist ein Spezialfall einer «indirekten Kollision»: Einer Kollision zwischen Tasten, zwischen denen eine weitere Taste mit der anderen Hand oder mit dem Daumen getippt wird. Mein aktuelles Lieblingsthema. In den Bigrammen tut eine zusätzliche if-Abfrage nicht sehr weh. In den Trigrammen wäre das etwas anderes… :) Auf die Gefahr hin, dir auf die Nerven zu fallen: Vielleicht solltest du die N-gramm-Strafpunkte und -häufigkeiten in simplen Matrizen tabellieren. Dann ist die Auswertung im wesentlichen ein Skalarprodukt zwischen Strafpunkten und Häufigkeiten, und sowas rechnet sich gut und schnell, auch wenn in den Matrizen viele Nullen stehen die man unnütz abarbeitet. Ich mache das so ähnlich, und kann auch mit Trigrammen einige hundert lokal optimale Tastaturen pro Minute berechnen. Es würde mich wundern wenn es bei den numerischen Erweiterungen für Python nicht etwas gäbe, mit dem man zumindest bis auf eine Grössenordnung daran heran kommt. Andreas
Re: [Neo] Brauche Hilfe bei der Behandlung von bigrammen mi t Großschreibung und höheren Ebenen
Hi Andreas, On Wednesday 20 October 2010 22:49:01 wettstein...@solnet.ch wrote: Auch wenn die Programmiersprache oder sogar das Programmierprojekt feststeht, man müsste noch wissen ob emacs, vi oder Eclipse benutzt wird. Was im Korpus steht ist nicht alles auch getippt worden. Tools nehmen unter Umständen einiges ab. Stimmt. Für eine extrem einfache max() Funktion sähe mein Korpus in emacs in etwa so aus: def max(l): ges = 0 for num in l: ges += num tabtabrettab ges … tab muss auf eine Daumentaste :) Die bevorzugten Symbole sind in unterschiedlichen Disziplinen verschieden. Ich glaube nicht, dass sich ein repräsentativer Korpus für mathematische Symbole finden lässt. Ausserdem, wenn man annimmt, dass die lateinischen und griechischen Buchstaben aneinander kleben (a am α und so weiter) müsste man normale Texte und Formeln gegeneinander abwiegen. Das stimmt. Würde ich eigentlich dann auch so machen (ist aber in switch_key noch nicht drin). Ja, man braucht einen hinreichend korrekten Korpus, weil nur ein korrekter Korpus repräsentiert, was man tippen will. Ich habe mir tatsächlich schon überlegt, meinen (3MB) Korpus zu bearbeiten, aber das ist viel Arbeit mit sehr begrenztem Nutzen. Ich würde gerne mal wieder schauen, ob ich nicht einen ein-tag-korpus erstellen kann. Mit dem Prog von Klausler kann ich zumindest mein Programmieren mit emacs einfangen. Vielleicht kann emacs das auch direkt (müsste über einen hook gehen – irgendwie :) ). Da ich fast alles auf emacs umstellen kann (auch mein Mailprogramm), müsste ich so alle Daten sammeln können. Das läuft darauf hinaus, dass derselbe Text bei derselben Belegung mit unterschiedlichen Bewegungen getippt werden kann. Schwierig zu bewerten und schwierig zu lernen. Es könnte aber wirklich die Tippeffizienz steigern. Gerade auf der linken Tastaturhälfte könnte man einiges mit den «falschen» Fingern machen. Jupp. Aber Neora könnte auch recht damit haben, dass ein gutes Layout das unnötig machen sollte. Um das hier zu berücksichtigen, müsste die Handverschiebung von M3L-M4L erhalten bleiben, d.h. wir müssten komplett auf Trigramme wechseln (teuer). Da braucht man noch keine Trigramme. Die Idee mit virtuellen Tasten ist ja gerade, das gleichzeitige Drücken von Mod3L und Mod4 wie einen einzigen Tastendruck zu behandeln. Das würde dann den einen Sonderfall abfangen. Wenn es nicht allzu viele davon gibt, sollte es gehen, ja. Ich bin von meiner Ansicht abgerückt. Heute behaupte ich, man müsste die u-ShiftL-Kollision normal und die von u-b Kollision schwächer werten, weil zwischen u und b ja noch eine Taste (ShiftL) gedrückt wird. Das ist ein Spezialfall einer «indirekten Kollision»: Einer Kollision zwischen Tasten, zwischen denen eine weitere Taste mit der anderen Hand oder mit dem Daumen getippt wird. Mein aktuelles Lieblingsthema. Könntest du mir das erklären? Am besten direkt auf der Liste :) Das ist nämlich effektiv das, an dem ich gerade dransitze und das ich genau jetzt korrekt machen kann. Auf die Gefahr hin, dir auf die Nerven zu fallen: Vielleicht solltest du die N-gramm-Strafpunkte und -häufigkeiten in simplen Matrizen tabellieren. Damit fällst du mir definitiv nicht auf die Nerven. Ich habe den Port auf python2 (branch: py2) ursprünglich genau dafür gemacht (es gibt scipy noch nicht für python3, und das kann effiziente Matrizenrechnung, allerdings nur in 2D). Allerdings kommt scipy zum Glück bald für py3 (numpy ist schon da). Ich habe allerdings noch kein effizientes System im Kopf, um das sauber zu machen. Wie hast du das implementiert? Die Kosten von Tasten (nicht Zeichen) kann ich ja eigentlich zwischencachen (die bleiben bei dem Layout ja gleich). Mappst du dann einfach die Tastenpositionen und Kosten auf eine Matrix und schreibst die Bigramme in Positionen um? Dann ist die Auswertung im wesentlichen ein Skalarprodukt zwischen Strafpunkten und Häufigkeiten, und sowas rechnet sich gut und schnell, auch wenn in den Matrizen viele Nullen stehen die man unnütz abarbeitet. Ich mache das so ähnlich, und kann auch mit Trigrammen einige hundert lokal optimale Tastaturen pro Minute berechnen. *selbst testen will* :) Ich muss nur noch ein geeignetes Schema finden, um alle Kostenfunktionen auf Matrizenoperationen umzuschreiben. Es würde mich wundern wenn es bei den numerischen Erweiterungen für Python nicht etwas gäbe, mit dem man zumindest bis auf eine Grössenordnung daran heran kommt. Gibt es: SciPy. Noch effizienter mit scipy.weave (C++ in Python). Aber halt bisher nur in python2 (vermutlich nur noch ein paar Wochen lang :) ). Dazu, es im Python2 branch zu testen, bin ich durch pypy erstmal nicht gekommen (weil es im Gegensatz zu pypy Umstrukturierungen benötigt). Hoffentlich komme ich in 2 Wochen oder so dazu (jetzt wird es erstmal etwas turbulent…). Liebe Grüße, Arne -- A man in the streets faces a knife. Two policemen are there it
