[Bug 244613] New: cut & past of non-ASCII characters from urxvt -> xemacs doesn't work.
https://bugzilla.novell.com/show_bug.cgi?id=244613 Summary: cut & past of non-ASCII characters from urxvt -> xemacs doesn't work. Product: openSUSE 10.3 Version: Alpha 0plus Platform: x86-64 OS/Version: Linux Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: mfabian@novell.com QAContact: sndirsch@novell.com When running in any UTF-8 locale, trying to cut and paste a non-ASCII string from urxvt into xemacs fails. For example when trying to paste täst the result in xemacs is t?st xemacs is started with the '-q' option to make sure that it is not a problem in the configuration of the user. Pasting from urxvt into many other applications, e.g. xterm, KDE-Applications, .. works. These other applications can even be used as a workaround to paste from urxvt to xemacs: 1) cut and paste from urxvt to xterm or a KDE application. 2) cut and past from the xterm or the KDE application to xemacs. This works. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 mfabian@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team- |werner@novell.com |screening@forge.provo.novell| |.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 mfabian@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|cut & past of non-ASCII |cut & paste of non-ASCII characters from urxvt - |characters from urxvt -> |> xemacs doesn't work. |xemacs doesn't work. | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #1 from mfabian@novell.com 2007-02-13 15:12 MST ------- xemacs-21.5.27.20060705/lisp/select.el line 36 ff: ;; gives us more information when taking data from other XEmacs invocations, ;; Mozilla will happily give us broken COMPOUND_TEXT where a non-broken ;; UTF8_STRING is available. (defvar selection-preferred-types (let ((res '(UTF8_STRING COMPOUND_TEXT STRING image/png image/gif image/jpeg image/tiff image/xpm image/xbm))) (unless (featurep 'mule) (delq 'COMPOUND_TEXT res)) res) "An ordered list of X11 type atoms for selections we want to receive. We prefer UTF8_STRING over COMPOUND_TEXT, for compatibility with a certain widely-used browser suite, and COMPOUND_TEXT over STRING. (COMPOUND_TEXT isn't available on non-Mule.) We also accept several image types. When seeing this I thought this might be the problem because in cutting and pasting from urxvt into GNU Emacs only works if (set-selection-coding-system 'compound-text-with-extensions) is use, it does *not* work if (set-selection-coding-system 'utf-8) is used instead. Therefore I thought having UTF8_STRING preferred might cause the problem. But this doesn't really seem to be the problem. I selected a non-ASCII string in urxvt and then manually called the function ‘get-selection’ (defined in select.e. line 117): (get-selection 'PRIMARY 'UTF8_STRING) " 火曜日 22:59:40 CET " (get-selection 'PRIMARY 'COMPOUND_TEXT) " 火曜日 22:59:40 CET " (get-selection 'PRIMARY 'STRING) " ??? 22:59:40 CET " Seems to work both for UTF8_STRING *and* COMPOUND_TEXT. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #2 from mfabian@novell.com 2007-02-13 15:32 MST ------- Results of the function ‘get-selection-internal’ when a string is selected in different applications: (get-selection-internal 'PRIMARY 'TARGETS) konsole: [text/plain\;charset=UTF-8 text/plain\;charset=ISO-10646-UCS-2 text/plain text/plain\;charset=utf-8 UTF8_STRING] Firefox: [TIMESTAMP TARGETS MULTIPLE] xterm: [STRING TEXT COMPOUND_TEXT UTF8_STRING LENGTH LIST_LENGTH TIMESTAMP] urxvt: [TARGETS TIMESTAMP STRING] I.e. urxvt sends neither UTF8_STRING, COMPOUND_TEXT, nor MULTIPLE. This is probably the reason why it doesn't work. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #3 from mfabian@novell.com 2007-02-13 16:23 MST ------- The code in urxvt doesn't look that wrong. screen.C line 3537: void rxvt_term::selection_send (const XSelectionRequestEvent &rq) NOTHROW { XSelectionEvent ev; ev.type = SelectionNotify; ev.property = None; ev.display = rq.display; ev.requestor = rq.requestor; ev.selection = rq.selection; ev.target = rq.target; ev.time = rq.time; if (rq.target == xa[XA_TARGETS]) { Atom target_list[6]; Atom *target = target_list; *target++ = xa[XA_TARGETS]; *target++ = xa[XA_TIMESTAMP]; *target++ = XA_STRING; *target++ = xa[XA_TEXT]; *target++ = xa[XA_COMPOUND_TEXT]; #if X_HAVE_UTF8_STRING *target++ = xa[XA_UTF8_STRING]; #endif [...] Makes me think this might be a 64 bit problem... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #4 from mfabian@novell.com 2007-02-13 16:28 MST ------- Yes, it is a 64bit problem in urxvt indeed. On 32bit platforms I get (get-selection-internal 'PRIMARY 'TARGETS) [TARGETS TIMESTAMP STRING TEXT COMPOUND_TEXT UTF8_STRING] and therefore cut and paste from urxvt to xemacs works fine. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #5 from mfabian@novell.com 2007-02-13 16:54 MST ------- mlterm has the same problem. There was a patch on the mlterm mailing list a while ago which seems to attach this problem: http://sourceforge.net/mailarchive/forum.php?thread_id=31025519&forum_id=3020 This patch is already included in our mlterm package in STABLE (mlterm-2.9.3.20070123-2.7 (CVS from 20070123)) but the bug is still there on x86_64 (on i386 it works). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #6 from mfabian@novell.com 2007-02-14 10:15 MST ------- GNU Emacs has a similar function called ‘x-get-selection-internal'. When something is selected in urxvt one gets GNU Emacs: (x-get-selection-internal 'PRIMARY 'TARGETS) STABLE-x86_64: [TARGETS TIMESTAMP STRING] 10.2-i386: [TARGETS TIMESTAMP STRING TEXT COMPOUND_TEXT UTF8_STRING] XEmacs: (get-selection-internal 'PRIMARY 'TARGETS) STABLE-x86_64: [TARGETS TIMESTAMP STRING] 10.2-i386: [TARGETS TIMESTAMP STRING TEXT COMPOUND_TEXT UTF8_STRING] I.e. GNU Emacs and XEmacs show exactly the same difference in behaviour between STABLE-x86_64 and 10.2-i386 when requesting the list of targets in the primary selection. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #7 from werner@novell.com 2007-02-14 10:31 MST ------- Hmmm ... is this an urxvt/mlterm bug or do we see a problem in the X11 libraries its self? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #8 from mfabian@novell.com 2007-02-14 10:35 MST ------- I found another application for testing the selection: http://www.pygtk.org/pygtk2tutorial/sec-RetrievingTheSelection.html http://www.pygtk.org/pygtk2tutorial/examples/getselection.py Using this application when urxvt owns the primary selection gives (click on [Get Targets]): mfabian@magellan:~/bin$ getselection.py TARGETS TIMESTAMP STRING TEXT COMPOUND_TEXT UTF8_STRING -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #9 from mfabian@novell.com 2007-02-14 10:37 MST ------- Werner> Hmmm ... is this an urxvt/mlterm bug or do we see a problem in Werner> the X11 libraries its self? Coolo and me also thought that this might be in the X11 libraries. But now that I found the Python program to test the selection which gets it right on STABLE-x86_64, it seems to be more likely that both GNU Emacs and XEmacs have a 64bit but in ‘x-get-selection-internal' and ‘get-selection-internal’ respectively. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #10 from mfabian@novell.com 2007-02-14 13:08 MST ------- Created an attachment (id=119230) --> (https://bugzilla.novell.com/attachment.cgi?id=119230&action=view) bugzilla-244613-cut-paste-64bit-non-ascii.patch The attached tentative patch does *NOT* help. It doesn't change the behaviour at all. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #11 from tiwai@novell.com 2007-02-14 18:10 MST ------- Right, it's actually a wrong patch. I noticed this after my dinner :) XGetWindowProperty() returns indeed a long array when format is 32 regardless of architecture. On LP64, the size of array thus doesn't match with the value of format. This mismatch must be handled in the application properly. My rough guess is that the problem is in src/select-x.c (in the case xemacs). There, in x_get_window_property(), the byte size is calculated from format. An untested patch comes below. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #12 from tiwai@novell.com 2007-02-14 18:13 MST ------- Created an attachment (id=119293) --> (https://bugzilla.novell.com/attachment.cgi?id=119293&action=view) 64bit selection fix for xemacs -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #13 from mfabian@novell.com 2007-02-14 19:17 MST ------- This patch causes a core dump when pasting from urxvt into XEmacs. Nevertheless I think it must be the right idea. Somehow it rings a bell, I think I have seen exactly that problem before. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #14 from tiwai@novell.com 2007-02-14 19:21 MST ------- Hmm, further looking revealed more problematic codes. The Atom is accessed in select-common.h as 32bit arrays. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 tiwai@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #119293|0 |1 is obsolete| | ------- Comment #15 from tiwai@novell.com 2007-02-14 19:22 MST ------- Created an attachment (id=119299) --> (https://bugzilla.novell.com/attachment.cgi?id=119299&action=view) 64bit selection fix for xemacs (take2) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #16 from mfabian@novell.com 2007-02-14 19:52 MST ------- I think that patch causes a core dump as well. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #17 from werner@novell.com 2007-02-15 02:55 MST ------- Please be carefull with using of type long to avoid a fixed 64bit but broken 32bit xemacs/emacs :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #18 from mfabian@novell.com 2007-02-16 09:04 MST ------- Actually the parts of Takashi's patch which exchanged “XE_ATOM_TYPE” with “long” were not needed because “XE_ATOM_TYPE” is the same as “Atom” which is already the same as “unsigned long” in the X library and X clients. I.e. this doesn't break anything but it is not needed either. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #19 from mfabian@novell.com 2007-02-16 09:05 MST ------- Created an attachment (id=119668) --> (https://bugzilla.novell.com/attachment.cgi?id=119668&action=view) bugzilla-244613-cut-paste-64bit-non-ascii.patch Tested patch which works. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #20 from mfabian@novell.com 2007-02-16 09:14 MST ------- This patch uses the necessary hunk from Takashi's patch and one extra hunk. The extra hunk is needed because XGetWindowProperty returns only half the number of bytes in “bytes_after_return” which are really needed to store the “prop_return” array. man XGetWindowProperty: man> SYNTAX man> int XGetWindowProperty(Display *display, Window w, Atom property, long man> long_offset, long long_length, Bool delete, Atom req_type, Atom man> *actual_type_return, int *actual_format_return, unsigned long man> *nitems_return, unsigned long *bytes_after_return, unsigned char man> **prop_return); man> man> [...] man> man> prop_return man> Returns the data in the specified format. If the returned format man> is 8, the returned data is represented as a char array. If the man> returned format is 16, the returned data is represented as a man> array of short int type and should be cast to that type to obtain man> the elements. If the returned format is 32, the property data man> will be stored as an array of longs (which in a 64-bit applica- man> tion will be 64-bit values that are padded in the upper 4 bytes). man> [...] For example, if the “prop_return” array contains 6 32 bit values, it has a length of 48 bytes total. man> man> o If the specified property exists and either you assign AnyPropertyType man> to the req_type argument or the specified type matches the actual man> property type, XGetWindowProperty returns the actual property type to man> actual_type_return and the actual property format (never zero) to man> actual_format_return. It also returns a value to bytes_after_return man> and nitems_return, by defining the following values: man> man> N = actual length of the stored property in bytes man> (even if the format is 16 or 32) man> I = 4 * long_offset man> T = N - I man> L = MINIMUM(T, 4 * long_length) man> A = N - (I + L) man> man> The returned value starts at byte index I in the property (indexing man> from zero), and its length in bytes is L. If the value for long_off- man> set causes L to be negative, a BadValue error results. The value of man> bytes_after_return is A, giving the number of trailing unread bytes in man> the stored property. Nevertheless “bytes_after_return” returns “24” instead of “48” for the example of 6 32 bit values, i.e. one needs to allocate twice as much space for the “prop_return” array on 64 bit platforms. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 mfabian@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #21 from mfabian@novell.com 2007-02-16 09:18 MST ------- Fixed package submitted to STABLE and to the openSUSE build service. Closign as FIXED. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=244613 ------- Comment #22 from mfabian@novell.com 2007-02-16 11:18 MST ------- Reported upstream. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
participants (1)
-
bugzilla_noreply＠novell.com