There is a bug in xedit that causes some users to lose data. Data loss in a text editor is always unacceptable. Please stop distributing xedit binaries from http://xorg.freedesktop.org/archive/individual (and included with Xorg, if you still include it with Xorg) until this bug is fixed or until a workaround is implemented. To repro the bug: 1. Start xedit 1.1.1 by typing: /usr/bin/xedit anyfilename (Choose any filename you want.) 2. Type some valuable text that you don't want to lose. 3. Click the "X" button at the top-right corner. What happens: xedit abandons your work and quits. What should have happened: xedit should have prompted you to save. Note: It seems that xedit is not detecting that changes have been made to the file. When you explicitly try to save by clicking Save, xedit says: "Save: No changes need to be saved, Save again to override." When you click Save again, xedit actually saves. Thanks to M. Dietrich for reporting this at http://bugs.debian.org/321434 Ideal fix: Fix things so that xedit does not lose my work. A text editor should never ever lose a person's work. If the ideal fix is not possible: xedit should be renamed to xriskyedit to make sure nobody uses it. Then write a shell script called "xedit" that calls xedit with the user's specified parameters and adds whichever -xrm parameter is necessary to workaround this problem. If possible, also make xriskyedit show a warning dialog if it is not called with the needed -xrm parameter.
Xorg doesn't distribute binaries - only sources, so if that's all you want, this bug can be closed as "NOT A BUG" - but that doesn't really help, does it? Let's change the Summary to something more useful then...
Here is the relevant IRC discussion I had a week before filing this bug. ----- [2008-09-15] ----- ... [15:48:00] *** unfo (n=anonymou@[...]) has joined chat #xorg-devel. [...] [16:40:09] <pcpa> unfo: You probably have your environment setting the international resource to true. Xedit only works in multibyte or singlebyte, no utf8. Ensure the Xedit and Xedit-color files, as well as latest binaries are installed. I probably should also create a setup to force iso8859-1 or similar... [...] [16:46:00] <pcpa> unfo: [...] I need to check what is wrong with Xaw sometime, it used to work correctly sometime ago... But I never use Xaw widgets in multibyte mode [...] [16:51:31] <pcpa> unfo: This should not matter if you have the *international resource not set. Try running as "# /usr/bin/xedit -xrm '*international: 0'". Probably the MultiSrc widget is not calling the proper callback. I basically only maintained Xaw and xedit in XFree86. In Xorg I become maintainer again recently, and I don't think anybody cares about Xaw... [16:53:14] <unfo^ % /usr/bin/xedit -xrm '*international: 0' foo3 [16:53:14] <unfo> Warning: locale not supported by C library, locale unchanged [16:53:15] <unfo> Error: Source object is not a subclass of asciiSrc [16:53:43] <unfo> The command pcpa told me didn't work on xedit-1.0.3 on zsh on Debian lenny. Why not? [...] [16:54:40] <unfo> By the way, "xrdb -query | grep -i international" returns no output at all. [16:56:08] <pcpa^ ah, you don't have the latest freedesktop.org xedit version, where I fixed these problems (xedit was basically unusable for several years in xorg...) [...] [18:07:57] <unfo> pcpa, now I built like this: "make clean && ./configure --prefix=/usr && make && (./xedit &)." Now xedit built and ran. Thank you for your patience. But the initial bug I reported to you still is present in xedit-1.1.1. My $LANG is still set to fr_FR.UTF-8. Let me retest with LANG= empty. [...] [18:22:16] <unfo^ [...] ok, "./xedit -xrm '*international: 0'" works fine. "./xedit" has the bug. Should I file a bug report? [...] [18:29:27] <pcpa> unfo: Sure :-) With enough motivation one could fix these problems in Xaw... I considered creating an external widtget (to not touch libXaw) that would be a modified version of the "single byte" one to understand utf, but I don't think it is worth the work, personally I don't need it, but it shouldn't be too hard to do; at least for me that understand Xaw... [18:29:39] <pcpa> need to go... closing building here... [...] [18:32:28] <unfo> do you have time for me to ask: is it an Xaw bug? or an xedit bug? [...] [18:51:18] <unfo> all : Is it an Xaw bug? or an xedit bug? [18:57:39] <alanc> I'm not sure anyone but pcpa knows much about either xedit or Xaw [18:58:02] <unfo> :( [18:58:10] <unfo> alanc: so i'll file a bug against xedit. [18:58:20] <unfo> I'll also file a bug in debian asking them to pull in a newer xedit [18:58:38] <alanc> seems reasonable, he can move to the libXaw category if it turns out to be there [18:58:46] <unfo^ thanks for the reply anyway :) [18:58:53] <unfo> now I know not to keep waiting here. [...] [19:01:15] <daniels> unfo: probably Xaw, but odds are we can't change Xaw due to compat reasons [...] [19:01:19] <gravity> unfo: Want to maintain it for Debian? [19:01:22] <unfo> daniels: no thanks [...] [19:01:37] <unfo> daniels: can't change it due to compat reasons? [...] [19:02:17] <daniels> unfo: it's likely numerous applications depend on those exact xaw semantics [19:02:26] <daniels> just use gtk or qt apps ... [19:02:48] <unfo^ so those apps can be fixed, no? [...] [19:04:52] <daniels> unfo: sure, but what's the point? [...] [19:06:19] <unfo^ the point is that then, a dataloss bug in xedit can be fixed [19:08:05] <DrNick> yes, but nobody uses xedit [...] [19:09:08] <unfo> does debian provide popcon data on xedit? [...] [19:11:47] <daniels> No Popularity contest entry for xedit [19:12:09] <unfo> it's part of the package x11-apps [19:12:42] <daniels> ah, so that means a hell of a lot of people are going to have it installed [19:13:18] <unfo> too bad it's all one package. [19:13:52] <unfo> do any other other Linux distros (other than Debian derivatives) capture app usage data? [19:14:00] <unfo> maybe someone has more-granular data. [19:19:58] * svu_ wonders why xedit is still around [19:20:10] <unfo> because some people like it [19:22:11] <DrNick> Fedora doesn't even ship xedit [19:23:45] <anholt> daniels: that's unfortunate [19:24:36] <keithp> daniels: so kick jcristau and make him split xedit into a separate package [19:24:40] <unfo> maybe they don't like xedit's bugs so they decided it's not worth shipping. I applaud that. [19:25:12] <unfo> xedit is old, and the maintainer does not have infinite time, so it is still buggy. [...] [20:07:37] <unfo> where on the xorg ftp server can i download all of x11-apps? [20:10:32] <alanc> http://xorg.freedesktop.org/releases/individual/app/ [...] [04:35:16] <jcristau> keithp: i'm all for removing xedit from x11-apps, then somebody else can worry about maintaining it in a separate package. [...] ----- [2008-09-16] ----- [00:56:30] *** unfo has left chat #xorg-devel (quit).
This was fixed in: commit cc7cb041c4144f1401fd520f05018028c0e0c87e Author: Paulo Cesar Pereira de Andrade <pcpa@mandriva.com.br> Date: Fri Sep 26 17:34:50 2008 -0300 Proper implementation of AddDoubleClickCallback I tracked it down to http://cvsweb.xfree86.org/cvsweb/xc/programs/xedit/commands.c?rev=1.5&content-type=text/vnd.viewcvs-markup After my patches to libXaw. Instead of checking for "if (XtIsSubclass(w, asciiSrcObjectClass)) {" it should really do something like "if (isXaw7orNewer) {". But I believe only XFree86 and Xorg versions of Xaw have the XawVersion macro in XawInit.h... This corrects the problem described in http://bugs.freedesktop.org/show_bug.cgi?id=17726 And the main reason is that xedit always default'ed to use a 8 bits iso8859-x locale, while in Xorg it was modified to use multibyte by default. ----- The newest Xorg version of xedit changes back to use only 8 bit characters (it doesn't know about utf8), but xedit is mean't to be an editor for programs/scripts only now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.