Opened 15 years ago
Last modified 15 years ago
#168 reopened Fehler/Defekt
sendUnicode() funktioniert nicht mit emacs 23.1
Reported by: | Dennis-ſ | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | Neo Version 2.0 |
Component: | Treiber: Windows – AHK | Version: | 2.0 BETA |
Keywords: | AHK, NeoVars, emacs, GTK, GTK+ | Cc: |
Description
Problem
Unter emacs 23.1 ist es nicht mehr möglich, Unicode-Zeichen (bspw. »«„“∀∃ oder nur über Compose erzeugbare Zeichen wie ₰) einzugeben. Stattdessen werden nur die Fehlermeldungen »<packet> is undefined« oder »<S-packet> is undefined« ausgegeben. Unter emacs Ver. 22.3 hat noch alles wunderbar funktioniert.
Die E-Mail mit der urspünglichen Fehlerbericht von Jan findet sich hier, ich konnte das Problem reproduzieren mit Windows XP-SP3, NeoVars_r2005_r2004 und Emacs 23.1.
Analyse
In Version 23.1 von emacs wurden mehrere wichtige Dinge geändert:
- Es wird nicht mehr Lucid, sondern GTK+ als GUI-Toolkit verwendet,
- Die interne Dateikodierung wurde auf eine Obermenge von Unicode umgestellt,
- Die Eingabe beliebiger Unicode-Zeichen ist über die Tastenkombination »C-x 8 RET 17f RET« möglich (für Nicht-emacs-Kundige: »Strg+x 8 Return 17f Return«). Dieses Beispieleingabe erzeugt das lange ſ, Unicode-Codepoint 0x0017f.
Leider versagt das GTK-Toolkit unter Windows, wenn Unicodezeichen über die Windows-API gesendet werden (genaueres hierzu findet sich in Ticket #3). Der NeoVars hat deswegen extra einen Fix in der Methode sendUnicode() eingebaut, in dem Unicodezeichen über eine GTK-spezifische Möglichkeit gesendet werden. Leider scheint dieser bei der neuen emacs-Version jedoch nicht mehr zu funktionieren (bei Inkscape, das auch auf dem GTK basiert, funktioniert er hingegen weiterhin).
Lösungsansätze
Mögliche Wege, um dieses Problem zu lösen:
- GTK unter Windows sollte endlich Unicode-Zeichen verarbeiten können, die über die Windows-API gesendet wurden;
- emacs sollte den funktionieren GTK-Workarround (send % "+u" . SubStr(charCode,3) . " ") nicht zerschießen,
- wir könnten im NeoVars eine Ausnahme für emacs innerhalb der GTK-Ausnahme einbauen und die Unicode-Zeichen über send x . 8 . return 17f return schicken. Ich habe eben versucht, diesen Weg umzusetzen, bin aber leider gescheitert (mein AHK ist leider etwas eingerostet :-().
- Als Worarround emacs 22.3 verwenden.
Change History (3)
comment:1 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 15 years ago
wer möchte, kann in varsfunctions.ahk die Sequenz "x8{Enter}" (kommt zwei mal vor) durch "!xucs-insert{Enter}" ersetzen, dann klappt’s auch mit Emacs vor 23.1! Die aktuelle Version schreibt dann aber in die Statuszeile eine Belehrung über die bessere Verwendung der kürzeren Eingabevariante.
Die ganze Lösung hat nur einen entscheidenden Haken, auch unter Emacs 23.1: Diese Sequenz lässt sich nur beim Editieren von Text anwenden, nicht aber z.B. in der Suche.
Bin für jede Idee dankbar, dieses Problem zu lösen, aber es sieht so aus, als müsste man dann wirklich in GTK eingreifen – was ja kein Makel, aber doch ein Heiden Aufwand wäre.
comment:3 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Das Problem tritt weiterhin auf. Beim normalen Schreiben funktionieren die Zeichen, aber im Minibuffer immer noch nicht. Das betrifft nicht nur die ausgefallenen Zeichen, sondern auch ~ und ^
.
Wenn ich z.B. eine Datei öffnen will (C-x C-f) und dann ~ für das Homeverzeichnis eingebe, dann öffnet der Emacs eine Datei mit dem Namen 0007E.
(Ausprobiert mit Emacs 23.2.1 unter Windows Vista)
fixed in r2056. neovars geht jetzt mit Emacs 23.1 – allerdings ungetestet auf früheren Emacs-Versionen. Sollten diese als ahk_class auch »Emacs« liefern, bräuchte man noch irgendwie eine zusätzliche Fallunterscheidung, oder man müsste auf alternative Wege zurückgreifen. Z.B. gibt es die Funktion ucs-insert http://groups.google.com/group/de.comp.editoren/browse_thread/thread/7675e814012b0c4f/ed036fcbb645781b?lnk=raot mit ähnlicher Funktion, die offenbar schon in früheren Emacs-Versionen existiert.