sendUnicode() funktioniert nicht mit emacs 23.1 #168

Closed
opened 2009-08-27 00:57:17 +02:00 by dennis · 4 comments

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 » 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.
## 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](http://lists.neo-layout.org/pipermail/diskussion/2009-August/014003.html), 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()](http://neo-layout.org/svn/windows/neo-vars/src/source/varsfunctions.ahk) 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.
dennis added the
Bug
Treiber/Windows/AHK
labels 2009-08-27 00:57:17 +02:00
moesi closed this issue 2009-08-27 12:42:46 +02:00

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.

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](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.

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.

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.

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)

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)
Owner

Unter Windows 7 mit Emacs 28.2 funktionieren alle beschriebenen Fälle unter Verwendung von kbdneo, kbdneo mit ReNeo sowie ReNeo alleine (als Nachfolger von NeoVars).

Unter Windows 7 mit Emacs 28.2 funktionieren alle beschriebenen Fälle unter Verwendung von kbdneo, kbdneo mit ReNeo sowie ReNeo alleine (als Nachfolger von NeoVars).
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: neo/neo-layout#168
No description provided.