"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Jamie has excerpts from the mailing lists at <URL:http://www.jwz.org/doc/lemacs.html>;. It is my personal opinion that you need a solid pack of blinders in view of the following message (and others in its ilk) to call RMS' version a "damned lie". It was quite clearly spelled out that Lucid would only do merge work if they were in complete control of the resulting Emacs. And it never really was an option that the merge work could be done by people outside the Zawinski/Wing circle: code and documentation quality was not sufficient for outsider work. Heck, not even the current XEmacs maintainers get along all too well managing that code. So yes, the options were either let the Lucid people take over control of Emacs development, or not get a merge because of unavailable sustainable technical expertise. Jamie spells this out quite explicitly, and Richard took his pick. In my opinion, prudently even when putting aside political issues and only considering the technical ones: it would have put Emacs development at the mercy of those few understanding the code, and that actually has turned out to be a bottleneck for XEmacs these days. I recommend to anybody interested in the story to read the other mails Jamie puts up. It is a story of incurable differences, not one of heroes and liars, as you choose to see it.

"Vladimir G. Ivanovic" <vgivanovic(a)comcast.net&gt; writes: XEmacs 21.5 is _Beta_. So is Emacs 23. So for antialiased fonts you are AFAICS reliant on beta either way. Except that Emacs 22.3 for Gtk at least has antialiasing outside the text area (menus, title bar and stuff like that). One problem with such a comparison chart is that it is more likely to reflect what users _believe_ are the differences than what they actually are. Another problem is that on a mere checklist scale, there is quite a lot that is present at a checklist level in both editors, but the quality of implementation is vastly different. Things like tooltips. Both have them. In Emacs, they have been the default for years and are even present for menu entries. In XEmacs, they have been there for a few more years, are switched off by default, and interfere with character entry. They also pop up in decorated windows (probably one of the reason for their sluggish behavior) and tend to obstruct things. There is a reason they are off by default. Things like font-locking. Both have it. In XEmacs, is has been the default for quite a few years. In Emacs, is has become the default only after quite some fights, and after performance regressions for large files have been fixed. As a consequence, XEmacs still becomes useless for large files in many modes. Somewhat ironically, XEmacs has the facility to open files of size 1GB whereas Emacs draws the line at 256MB. And that's what I find often the case: on the checklist level, XEmacs sometimes offers more while it sucks. And I should not be surprised if the experience for XEmacs users is similar, just because you get hooked on _those_ features that actually work well in your daily workflow and decide that you don't really need those that don't. For a lot of features, the dividing point is not just the presence or absence of the feature, but the actual look and feel and usability of it, and the integration into the daily workflow. And that makes it pretty hard to come up with a good check list for decision making. -- David Kastrup _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

on 02/22/2009 01:21 AM David Kastrup said the following: In general, I find your messages unhelpful. They do not advance the discussion in a meaningful way. The are needlessly tendentious. They are negative instead of positive. I would add you to my kill file (the only person so honored) except that too many people answer your emails. So I have to suffer. --- Vladimir -- Vladimir G. Ivanovic _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: Probably so. <sigh /> Well, what are they? Ben had his huge blueprint of the future at http://www.xemacs.org/Architecting-XEmacs/. Mike has his long-range plans regarding garbage collection and replacing the Lisp engine. Jamie has a list of ten items from like 1997, all of which are at least partly relevant to XEmacs today. http://www.xemacs.org/Releases/Public-21.2/wishes/jwz-wishlist.html I've published a number of desiderata. The only one getting active attention at the moment is Unicode support, where Aidan is doing work these days. Some of my ideas are in the 21.4 release plan: http://www.xemacs.org/Releases/Public-21.2/planned.html http://www.xemacs.org/Releases/Public-21.2/first-draft.html http://www.xemacs.org/Releases/Public-21.2/execution.html Speaking for myself, there has not been much enthusiasm for my proposals, not expressed in code contributions, anyway. I'm not able to execute the larger ones myself, not for delivery in the near future. So I'd be willing to put in administrative support and do patch reviews in support of other people's goals. But what are other people's goals? And who's going to do the work? I can do some, Aidan will do some it would seem. But we need more people coding. Even if you don't feel comfortable contributing code yet, you can read Architecting XEmacs, and look at the task lists above, and post what you think is important here. Or start a page on the EmacsWiki. I suspect that will be most effective if somebody takes responsibility for editing it, and putting it into a form that looks like a release proposal (not necessarily like first-draft.html cited above, but definitely it has to look like there is some action coming). But it won't hurt to just start one if you're a wiki-oriented person. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Vladimir G. Ivanovic writes: A very few have, but mostly not. Let me also add the following mostly implemented stuff I've got lying around: (1) A workspace with native bindings to libcurl and neon. (2) A workspace with libffi bindings (courtesy of Steve Youngs; I've done none of the implementation). I plan to publish both as Mercurial branches in the near future (within two weeks). The issue with (1) is that it's in the same state as Xft: it works, but there is little documentation and fewer examples of practical application. (2) is ready to go but of course it's not cross-platform (works only with GCC, and I don't know if it even works on Cygwin). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Rodney Sparapani writes: [Nice trim! Thank you!] Worked for me on Mac OS X in light testing. I basically agree with your vision, and would certainly want it to work on Cygwin. That gives us a reasonable shot at covering three big platforms. OTOH, it's a very useful facility for prototyping use of DLLs from Lisp, and for platforms that don't support libffi, there is the regular XEmacs module (which is higher cost and does the function binding at compile time). So I'm definitely going to create the branch so people who want to try it can try it. Indeed, and that's one of the important distinctions between XEmacs and SXEmacs. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Rodney Sparapani writes: OK. I'll talk to Sun's OpenSolaris proponent in Tokyo. It's not a question of vision, it's a question of what the developers use. AFAIK the SXEmacs developers all are small-company/consultant types and/or students. So Linux is what they use. They're also very much feature creatures, as you can see from the list of rather specialized libraries they have Lisp bindings for. To each his own! Vive la difference! At the very least, there is a lot of potential for cross pollination, and we will carry the torch for portability (to the extent that we don't totally stumble and drop everything ;-). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen J. Turnbull wrote: Well, this has been discussed before; see http://article.gmane.org/gmane.emacs.xemacs.beta/25929 (How do you unroll a thread in gmane?) I don't really consider it a bug per se, I was just hoping that this is adopted as a feature request as long as we were talking about the future and OS X came up. Carbon. Yes, I know. I should probably work on it myself. as you'll see in that thread, I did contribute to the original XEmacs port by Andrew. I had created a patch that allows the Alt/Option key to be Meta. However, a later patch by Andrew which I have identified does something that prevents my patch from working. Another thing that is holding me back is the recent Cocoa port of Emacs just works the "right" way and it is just too easy to use that right now. -- Rodney Sparapani Center for Patient Care & Outcomes Research (PCOR) Sr. Biostatistician http://www.mcw.edu/pcor 4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW) WWLD?: What Would Lombardi Do? Milwaukee, WI, USA _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Giacomo Boffi wrote: That is what I am currently using at home, but elsewhere in this thread we see that code base is rolled into the Emacs beta (although, I didn't bother to download it and try it; when I find something that works, I stop digging). However, you will notice that you are not using XEmacs pretty quickly. Some of the key presses are different. But, I mainly just use ESS and AUCTeX. In those modes, the differences between Emacs and XEmacs are minuscule. Believe me, I would love to see an XEmacs.app that doesn't need tty or X11! -- Rodney Sparapani Center for Patient Care & Outcomes Research (PCOR) Sr. Biostatistician http://www.mcw.edu/pcor 4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW) WWLD?: What Would Lombardi Do? Milwaukee, WI, USA _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Rodney Sparapani <rsparapa(a)mcw.edu&gt; wrote: I use an X version of XEmacs on a Mac everyday. You have to tweak the keyboard configuration a bit but that's all. Here's my Xmodmap file on Darwin: clear mod1 clear mod2 keycode 66 = Meta_L keycode 63 = Mode_switch add mod1 = Meta_L This leaves the command key alone and uses alt/option for Meta. -- European Lisp Symposium, May 2009: http://www.european-lisp-symposium.org European Lisp Workshop, July 2009: http://elw.bknr.net/2009 Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Andreas Roehler writes: I'm not sure what improvements you have in mind. Launchpad has some nice features, but we are not going to make another repository move soon, especially not if it involves changing VCS to bzr. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Andreas Roehler writes: I'm not going to, until you convince others that it's worth doing, and get the ball rolling there. If you want to try that, just do it. There's no need to get permission, just participants. :-) The main reason I mentioned EmacsWiki is that people we'd like to have notice that we're gearing up are already there. IMO, getting things going requires people, review, and code in that order. Get the people, have them start reviewing each others' ideas, and the code will come. So whatever you think about doing, the main questions are "Will people come? How do they get here? How do they find out about it?" Infrastructure is secondary (except to the leader, ie, if you're in the mood to do some leading, then the infrastructure needs to be comfortable for you, and you get to choose it). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> Well, what are they? Well, the vision seems hard. Although that is probably the most important thing but let's drop that for a while and look into goals and plans. Maybe the vision materializes after looking into the details for a while ... My suggestion for a plan would be this: - Release 21.5 as stable (Do as little as possible to get there.) - Go GPLv3 for the next release after that. - Select a portable windows system to be used on all platforms. (So little time to support all so we need to focus on one plus we need eye-candification.) - Better, faster, support for parsing to improve font-locking and better code browsing, (This is a code editor, right!?) Process related: - Faster release schedule (Move in smaller steps.) - Clear plan so we can help out and focus on the next release. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell wrote: Requires a release manager, but given a release manager we can do that. IMHO there's a lot to be done, though. A lot of the attractive features suck. Eg, Xft's complete confusion in configuring fonts. We also really ought to consider a massive GNU sync if we want to recover any of the mindshare that that wiki page indicates we've lost. I think this is actually the highest priority, as it prevents most people from doing any GNU syncing (althoug Aidan has demonstrated it's possible). It's also something that somebody other than Ben Wing can do. Jamie has suggested "HTML". This is a rather large amount of work (eg, probably more than one Google SoC student could handle). A big technical problem we face there is that they all come with their own event loops. So much of what makes Emacs nicer than many other editors is the modelessness, but making that work smoothly depends a lot on features like C-g actually interrupting Emacs quickly. I don't know if there are any high-level toolkits that allow you to do this. Another problem is that many of them only can handle one display at a time AFAIK. Unacceptable to me personally, I'd have to stop using XEmacs! I suppose GTK can handle multiple displays by now? But how about the higher level toolkits like wxWindows? And do they flexibly allow input from other sources like background subprocesses and TTY displays and gnuclient? This is hard. Slowness in extents is at a very low level in the code. The fastest way to get speed here may actually be to implement widechar buffers. Andreas Roehler writes: Go right ahead. :-) Er, shouldn't it be a branch off the trunk? So not unless you plan to take the main repo with it. Eventually you want to merge it, no? Or does launchpad support Mercurial repos? _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

First of all, I would like to second the idea of switching to a single cross-platform toolkit. After a serious initial effort, this would likely improve future maintenance. A whole buch of issues (namely those caused by the toolkit) can be taken care of by a much bigger community. I am thinking of itches like the stupid Xft display residue and the like. A toolkit might not solve it perfectly according to some[1], but I haven't heard anyone saying "Shit, I'd rather have XEmacs' stray pixels..." either. At least things look wrong consistently. And if it gets fixed it will look right in *all* applications. While doing this I would think of getting rid of stuff such as progress bars, home-grown tooltips, etc. Proper Lisp bindings to toolkit widgets make thinks look much better integrated. A proper print dialog! Hell, that'd be something. It ought to be possible for someone to print only a subset of pages without having to jump through hoops. And this does not imply we'd have to get rid of the ancient lpr way of doing things. Font selection using a slightly less arcane interface than Customize, comes to mind. In my day job, I find myself presenting code examples using *other editors* simply because basic things like changing the font size for a projector is such a pain in the neck (both Xft, and Win32 native). Keyboard issues could be worked around more straightforward I suppose (might have to be worked out with XEmacs low-level handling). Since my switch to Ubuntu I still don't get German Umlauts on a US keyboard the way I used to in my good old plain X11 set-up. I have to memorize stupid combinations like "AltR-y" to get "ü". This has something to do with the "ISO level 3 shift"-or-what-ever-it-was-called, I reckon. From a user perspective this sucks: XEmacs is the *only* application that I use that suffers from this problem. Emacs behaves better in that respect for crying out loud. Can't say much about GTK+ -- I'll do it ayway: "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Supposedly you can add event sources to GLIB's event loop: http://www.gtk.org/api/2.6/glib/glib-The-Main-Event-Loop.html Not sure if that would help the situation... I am fairly certain that this has been possible since GTK+-2.0. What would be the benefit of a higher level toolkit? GTK+ is cross platform already, AFAIK. MacOS support being a bit behind it seems. Development seems to be quite active though. http://developer.imendio.com/projects/gtk-macosx/ Not sure how XEmacs handles that communication. Regards Marcus, (mostly) faithful to XEmacs since about '94 Footnotes: [1] http://thread.gmane.org/gmane.emacs.xemacs.beta/23585 _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: What is the current state? Embarassingly, to a new user, Win32 support appears to integrated best of all platforms. I am not talking about technical details or internal functionality here! I am talking about "look and feel". With changes in Unix desktop world over the past couple of years, I fear that Unix support is falling behind. And, BTW, what is "native look-and-feel" these days anyway? Thanks to various skinnable and themeable applications (audio players, and certain webbrowsers), this is a thing of the past. I had to switch to Office2007 recently, which was definitely a long overdue upgrade (from '97). But it took me *several minutes* until I figured how to print my freakin' document. The new UI isn't bad it is just such a radical change that makes you hate it. And again it looks completely different from any other application. There is always a split to be made between having a particular application behave the same way on every platform, so that experienced users will feel home immediatly even when switching from, say, Unix to Windows or vice versa -- or whether that application should be as tightly integrated into each platform's user interface to make it look familiar to new users (experienced on the platform perhaps but not with the application itself), even at the expense of confusing experts. I am fully aware of this. Started looking into "Internals" and closed the book rather quickly again. And that covers only the documented part:^) Xft: Of course it is not cross platform. That's my point! We shouldn't have to worry about stuff like that. We should rely on toolkit functions for display the same way as we rely on the OS for file I/O. And if they switch to Xft2 or something (assuming little changes to the API), that should concern us about as much as it concerns us whether #'find-file reads from Ext4, ZFS, or NTFS. Windows does have one. In fact I never noticed until just now, because it only comes up when you use the menu item File->Print. And it does work nicely, indeed. On the other hand, the XEmacs idea that dialogs will only be used for functions called via menu should be relaxed. Some functions on platforms don't work reasonably well without a dialog. M-x print-buffer/-region/etc. in Win32 should maybe have similar behavior as the toolbar printer icon in other Win32 programs (use current settings of print dialog). GTK doesn't work for me since I prefer Xft in its current state over an abandoned GUI toolkit. If it GTK uses native print, I wouldn't be surprised if the behavior were similar to Win32. And with that, of course, I mean a native font selection dialog... It might be that the world around us has moved on to XKB. Maybe I'll find the time for a bug report over the weekend. We should face the inevitable truth and not fool ourselves: Any toolkit decision will cause grief for a subset of XEmacs users -- just as the current situation does for some. Thanks (also to the entire active developer crew) Marcus _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Olivier Galibert writes: I can't speak for Marcus, but ISTR that Malcolm[1] agrees that it's not worth doing anything with our GTK+ port until it's updated to GTK+ v2 APIs. I certainly would oppose anyone putting significant effort into the v1 version myself. Footnotes: [1] The most recent GTK proponent, though due to family and job responsibilities he'd probably step aside for any enthusiastic newcomer, and contribute on an as-time-available basis. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

In general, I don't think the "grief" in the current situation has to do with the difficulty of maintaining support for toolkits. Very little work has been done on them in the last 5 years, yet they continue to "work" at the level of providing *Emacs* features. It's "desktop integration" that has lagged, but that stuff probably is not very hard ... if somebody wants to actually do it. Rather, the issue is lack of developers. There are lots of XEmacs users like you who "want" desktop integration, but you "maybe have time to file a bug report". That's not a criticism of you; if that's where your life is at, maybe you *should* move to GNU Emacs, SXEmacs, or even Eclipse + vi. ;-) Of course I'd be very happy if you decide to step up your XEmacs activity in some way (even beyond your recent adoption of a package, I mean; in free software, there's always room for a volunteer to do more! ;-) This is a problem that I pointed out in the runup to the release of 21.4. GUI users don't become Emacs developers. So through GUI support we get a population of users with rather high expectations to support who do little to support themselves. The Mac stuff is quite extreme; there are like 5 Mac Emacsen, each of which has basically *one* developer. Windows is a little better, but we now have no active Windows experts, and GNU has only about three. My *vision* is that the most likely way to solve this problem is for XEmacs to provide some killer feature(s) that you can't get anywhere else, and attract people who want some such feature and happen to have appropriate platform knowledge that they'll put to good use sort of "in passing". Marcus Harnisch writes: Of XEmacs? Except for the CUA keymap issue that Aidan referred to, Ben put a huge amount of effort into Windows integration, indeed. I think that's the most important platform for eye candy, anyway, in terms of attracting users. I don't know if we want to do that, though, since they rarely "convert" to developers. Agreed. Au contraire. Themes are varied, but the look-and-feel is basically the same at a certain abstract level. For example, themes do not allow you to turn all your menu-based applications into a keystroke- based ones. They don't allow you to turn double-clicks into shift- ctrl-click on a system-wide basis, AFAIK. And, as Olivier points out, they introduce a whole new set of nonportable look-and-feel problems in the theme configuration system. Yeah, I know. Every GUI puts the "squeeze this nominally A4 but for some reason actually 1.01*A4 page into an A4 page" button somewhere different. This is exactly why I refuse to have any truck with GNOME or KDE on my own desktop. *They make my life harder.* Now, that probably makes me a less than optimal meta-maintainer for the mass of users who want an editor that is just like all the others except better. As ESR said, "Take my job, please!" :-) What we need is a proponent for GNOME-style theming arising who is also willing to coordinate the work to ensure that it works for Motif, Aqua, Windows, and (ooh! yuck!) KDE users, too. Because that has been a consistent theme of XEmacs development: abstract the interface to the console (ie, the GUI widget sets, TTYs, stdio streams, etc), and support them fairly across the board. I don't think the current Review Board is likely to abandon that principle, in the absence of a strong active developer willing to provide leadership in another direction. Steve Youngs was one such leader, but he decided (correctly, IMO) that a fork was necessary, as the rest of the Board was decidedly unsympathetic to initiatives like "remove Windows support". FWIW, I don't think that SXEmacs has gone in the GUI direction that you suggest as desirable. This is quite true. Yet (once again, CUA keymap aside) XEmacs does a pretty good job of providing both on Windows. Especially if you compare to Windows circa 2002, when Andy and Ben both deactivated. But we don't! Have you looked at src/sysdep* recently? And IMO we should not rely on toolkit functions. They are not sufficient to do what we need for proper Unicode support in MULE, while still supplying faces and all that stuff. What we need is something on the level of the Mozilla redisplay, "gecko", not the kind of simple widgets provided by toolkits. File a bug, please. I'd do it except that I won't know what, if anything, "/etc" means, so you can just cut and paste the paragraph above and expand $etc (to the empty string if appropriate :-). I suspect invoking dialogs from the keyboard will not work well in current 21.5 because of the unstable state of the window configuration code. I don't have time to do that; I might *implement* one for Xt/Xft, but somebody else must do it for GTK/Qt/Aqua/Motif/Windows/whatever. It's probably not hard. Almost certainly they all just require that you call one function that pops up the dialog and returns the appropriate kind of font name for the platform as a string. But of course the only ones of those with working/official support are Motif and Win32. The hardest part will be working around the modality that some toolkits insist on. Please do. I've long thought we need to support XKB, but I have no way to determine whether it works or not because my needs require an input method that simply steals the keyboard entire, or simply support for a vanilla QWERTY keyboard with control and meta keys. :-( I think there's a common misunderstanding of what a toolkit can actually provide for applications like Emacsen and web browsers. In the XEmacs architecture, implementing a feature that's already present in a toolkit and already used by other toolkits in XEmacs is something that can be done as a once-off contribution by a user (maybe with advice from a core developer). Implementing it the first time is hard, implementing the second one may require refactoring. After that, though, supporting a feature on additional platforms really just requires a user or two able and willing to dirty their hands with code. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David Kastrup wrote: So lets come back to the roots. Altogether as some problems described as "bloated" are showing up elsewhere too. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: And that's exactly why we need to outsource stuff. Pick a reasonable cross platform toolkit for XEmacs and implement as much as possible through this abstraction layer. Issues that are toolkit related will be pushed upstream. Of course this is easier said than done. And in which way would that be better for me? Is desktop integration of any of these significantly superior? I disagree. Except maybe for some extreme cases (like thesis assignments or similar), every developer starts out as user. I do agree that only a fraction of new users will end up as contributers. But even attracting just a handful would already more than double the current active developer base. Sex sells, they say. And XEmacs needs some serious boobs. Except that the definition of "killer feature" is a bit vague. XEmacs has plenty of killer features already. Problem is that people don't even consider those as long as the basic stuff doesn't work right. I suspect you are right. But had we put similar effort into a cross platform toolkit (hypothetical, because at the time these weren't in the state that they're in now) we'd have the situation solved on several platforms. What I was trying to say is that native look-and-feel of cross platform toolkits is not the issue. Perhaps a concrete example of a prohibiting lack in look-and-feel on some platform would help me understand what you are worried about. Simpler than that: I was looking for the button that does the same as File->Print in basically every GUI since the Apple Lisa. They don't for me. I use the desktop for some things but not for others. I get mad only when it *prevents* me doing something, which rarely happens. Wrong approach. That'd be fives times the work. Unlikely. Plus I appreciate XEmacs' Windows support. As I said, Windows support is one of the best these days. I forgot to mention that drag-and-drop works nicely too. Oh my God! So (X)Emacs *is* an OS. And Mozilla uses toolkits for widgets, no? It turns out $etc is the empty string. I was too lazy to check out all functions starting with `print-' No, just once -- using an appropriate toolkit. You mean the fact that I can't do anything else until I closed that print dialog? I agree in theory, but in real life this doesn't bother me very often. Perhaps. But why. That same developer would spend his/her time better with implementing *an additional* feature rather than one feature for a number of platforms. Regards Marcus _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> Executive summary: What you and Mats and everybody who thinks Stephen> a cross- platform toolkit is an attractive plan need to do to Stephen> get me on board with that idea is this. Start evaluating the Stephen> existing toolkits. Everyone is of course free to do that. I still think there are some things to do first that has much, much higher priority. So excuse me for repeating myself but releasing 21.5 and then go GPLv3 are still top on my list. (Discussing toolkits seems to be more fun though ... :-) So having said that I'd say wxWidgets sounds interesting and while we are busy with releasing and GPLV3-ing we will have plenty of time to think about these things more carefully! Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

SL Baur <steve(a)xemacs.org&gt; writes: I don't think that the Emacs world of whatever flavor has been bypassed. People more have taken a large unbelieving look and then went elsewhere. The marketing slogan "Where do you want to go today?" in this case would be met with "no idea, but certainly not there". Depending on what "pushing" is supposed to mean, it might be a reason for annoyance fairly independent of the pushee. -- David Kastrup _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Fri, Feb 27, 2009 at 11:16:51AM +0000, Julian Bradfield wrote: There are essentially two "standard" widget toolkits in the Unix world at that point~: GTK+ and Qt. Everything else is peanuts. I agree with you that switching to one toolkit would just make XEmacs crap on all architectures. [...] They won't be interested in the result. They consider their registry imitation (gconf, now becoming dconf it seems) the right way to do thing and X resources obsolete. They're neither writable nor XML you see. OG. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: Note that we also need to think about promotion to stable; I don't know if Vin would consider 21.5 something he's willing to take on. *Can* do. To relicense to GPLv3 in principle is just a global substitution, and exchanging the license text in COPYING. We should also make sure we have the FSF's address right everywhere. Finally, there is a small number of files that either have no permissions notice or lack the "or later" clause, and we need to decide what to do about that. Larry Rosen told me that it's not a crime to violate copyright unless you do it willfully to make a profit. It follows, he said, that as long as you do nothing that upsets a copyright holder, anything else is "legal". Even if a copyright holder objects, the worst that can happen is we have to take out his content, or revert to the previous license. (The latter may be possible for documentation files and freestanding helper applications like etags -- not that etags could be a problem, it's just an example of "freestanding".) So it seems to me that to satisfy both the law and ourselves that we're making the license change in good faith, we need to (1) identify "problem" files (this is done or at least there's a script to do it, I think) (2) find the relevant authors (reading the file and grepping ChangeLogs and CVS history) (3) write them an email, and wait a month (4) if there are no objections, change the license For any file where there's an objection, we'd need to decide how to deal with it. In cases of no answer, IMO we made a good faith effort, and then we decide if the risk of having to rip it out is worth it. I don't understand why you think we need to wait. It's a basically mechanical process, and one that a non-technical volunteer can do everything except assess the risk and cost of "rip outs" of code whose owner refuses to change license. That should be doable concurrently with the technical stuff that needs to be done. Actually, supporting the window systems is not so hard. Very few of the problems come from the window systems themselves as far as I know. The problems with display that I know of are due to (1) the as-yet unstable move of window configuration code to Lisp, which has little to do with redisplay and window systems, (2) font-related stuff which we must handle ourselves (unless we want to change redisplay to something like Gecko; the hideous state of Xft is one example), and (3) interactions with garbage collection. The reason that GTK or wxWindows really doesn't help that much is that in order to do things like faces, invisible text, wrapping or truncation of lines, etc, we need to handle text redisplay ourselves. That's the complex stuff, and Pango goes partway to handling Mule-related font stuff, but none of the windowing systems support a text widget with the capabilities we need. Unless you think an XEmacs where Emacs windows have the enormous power we've come to associate with browser text-entry boxes is sufficient!<wink> I believe it's in conflict with the basic architecture of *any* Emacs- like editor. Well, five of my candidates are 1. straightfoward configuration of Xft fonts from resources or Lisp (unification to Lisp only can come later; we really should provide an X-resource-file-to-Lisp translator), 2. general improvement of face and other customization, 3. Xft font turds, 4. fix window configuration management (VM at least suffers horribly), and 5. SUMO-in-source distribution (at least a simple version). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Marcus Harnisch writes: Flexible, maybe. The design looks to be an abstraction of Emacs buffers and windows. We'd have to actually start implementing to be sure. I would guess that the TextWidget provides about 1/2 of insdel.c from the features described there and a look at the APIs for the main components. But I have no idea how it performs on a 1GB buffer, and I have no idea how it performs in a buffer with 30000 GtkTextTags. I wonder if it can keep up with a buffer that's being fed by a process, and so on. There are several misfeatures I've identified already. For example, to insert a glyph that is not part of the text, like a bookmark, you have to change the buffer text! And there seems to be no way to query a buffer to find out what GtkTextTags are present at any given index. So we need to maintain both the GTK object and a Lisp object corresponding to an extent, and make sure they stay in sync. The design is clearly very different from an Emacs buffer; GtkTextIter looks to be essentially useless at the Lisp level since it becomes garbage every time the buffer is edited. Yet they say "most text manipulation is accomplished with iterators". Many many questions remain. Would we have *full* control over the keymap? How about the mouse? How do these objects interact with garbage collection? How much effort would it be to implement truncate-lines? Invisible text? Atomic extents? How would it interact with our I/O code? How about strings? My guess is that it would actually be quite a bit *harder* to implement Emacs buffers and windows using GtkTextBuffer and GtkTextView than it is to implement Emacs windows using Xlib. I'm not sure about that, of course, but I can tell for sure that a lot of effort would be involved in using this as a basis for an XEmacs window, and it's not obviously a win in terms of simplicity. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Marcus Harnisch writes: "Much larger"? Wishful thinking. Performance problems are usually the province of a *very* small group of core developers (one to three), plus whoever is suffering. We need to be realistic about the benefits we may get from this proposed rewrite. "Many eyes" is probably not one. Please, no, let's not do that. You yourself say: Please focus on the desktop integration features. What is it you need? Which toolkits provide everything you need? Then we can look at the question of whether it's worth trying to get cross-platform support from a single toolkit. We could, instead, concentrate on getting *one* X11-based toolkit, Windows, and the Mac in good shape. Maybe it's time to abandon Xt support, as Lucid found it necessary to abandon plain Xlib support. But we need to stop dreaming pipe dreams of a cross-platform toolkit that does what XEmacs does, with much less effort on our part. If we find one, use it, but really, don't expect to find one. What we surely *can* find is a small set of toolkits that provides features we want but don't have yet, and won't cost more to support than the current platforms. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: I'd rather it *not* stick out. :-) It really doesn't make any difference except to us developers. We don't backport existing features to 21.4, so all we need to do is make sure that contributors of bugfix patches to 21.5 also give us permission to use them in GPLv2 21.4 if we think that's appropriate. In fact, I think what we should do is have an announced policy that *all* patches to XEmacs will be presumed to have a "GPLv2 or later" license, unless the contributor wishes to explicitly specify otherwise. That way we can use them anywhere in XEmacs code. I'm not sure that releasing 21.5, then 24 hours later releasing 21.6 under GPL v3, is going to be good publicity. :-/ I think releasing 21.5 "as-is" would simply give XEmacs a reputation for releasing crappy software. It's going to take longer to get 21.5 released than it is to get GPLv3 set up (if somebody will just start the work on GPLv3). XEmacs is not analogous to a Java app. XEmacs is analogous to a Java Development Environment. GPLv3 and GNU sync are not necessary to a release. If people work on GPLv3 in parallel with the technical problems, we can release as GPLv3. If not, we don't have to. General GNU Emacs sync is an ideal I aim at, not a concrete goal I expect to ever achieve. That can go on in parallel with other development as soon as we have a GPLv3 tree. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: It doesn't make it easier to do a release. It makes it easier to convert packages and to sync. Remember, some developers are not going to care about the release, but would possibly be willing to contribute syncs of packages they care about a lot. As a project we need a release manager! A plan that nobody intends to follow is useless. We have a number of separate tasks, at least the following: - fix really ugly bugs in 21.5 - make some attractive features in 21.5 properly customizable - convert the license of 21.5 to GPLv3 - convert licenses of packages that want to do so to GPLv3 - sync internals (eg, jit-locking) to recent GNU - update packages that are stalled because they depend on recent GNU - fix more bugs in 21.5 (eg the intermittent memory leaks) - finish up projects (KKCC, the incremental GC, window configurations) - add features that are "almost ready now" (curl and neon bindings, libffi are in my workspaces; I imagine others have their own projects; many SXEmacs features could be ported "cheaply") that are technically independent. We need to decide which are required for a release, and then we can start planning the release. People who want to work on technically independent tasks rather than the release should be allowed to do so, but they should also be made aware that they're not helping with the release. I don't know. You seem to think a quick release is important. But technically a "sync" is not a prerequisite to a release, and putting it into the list of release tasks will delay release by many months. In fact the only absolute requirement for a release is a release manager. I can do it, but I doubt you'll see a public release this year if I do, unless people start contributing code in a hurry. I'm not in a hurry to release, myself, but I would support others if they do the work they think is needed for a release. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: dont't know Stephen's POV, but start XEmacs under X, start gnuserv, from an xterm do "gnuclient -nw" and finally try to use vm or gnus -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: Gnus has some glitches but I haven't used it in a while. Recent VM fairly well in 21.4 and 21.5.26, but it's abominable in HEAD. The cursor position consistently gets reset to a message I viewed last in 2007, on return from message mode I'll typically see the wrong summary buffer, the cursor and VM's idea of the current message are almost never in sync, etc. You can say it's VM's fault for using low-level internal facilities, but then I riposte that it's RMS's fault for being such a flasher, exposing his internals everywhere. There just aren't any internals in Emacs, everything's part of the API. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: this is what i get starting gnus from a xterm where i ran gnuclient -nw as you can see, the window used by gnus is narrower and shorter than the xterm -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

================================================================ Michael Sperber writes: uh? what way? let's try... when i switched from gnus to the scratch buffer the window shrinked again, now it's very small... anyway the results are 36 and 3 the modeline, if you trust me, is obviously wider than 36 chars, so i inserted 123456789-123456789-123456789-1234567 and at this point the line scrolled horizontally i counted the chars in modeline, 54 (54=36*3/2, if this matters) i forgot to mention: the xterm is 90x30 -- vabbuò parliamo d'altro -- Agnosco, in IFQ ================================================================ System Info to help track down your bug: --------------------------------------- uname -a: Linux boffi95 2.6.18-4-686 #1 SMP Mon Mar 26 17:17:36 UTC 2007 i686 GNU/Linux ./configure '--enable-database=berkdb' '--enable-dialogs=lucid' '--enable-error-checking=all' '--enable-memory-usage-stats' '--enable-menubars=lucid' '--enable-modules' '--enable-mule' '--enable-pdump' '--enable-scrollbars=lucid' '--enable-widgets=athena' '--with-athena=3d' '--with-optimization=yes' '--with-rel-alloc' '--with-xft=all' '--with-xim=xlib' '--with-zlib' '--enable-bignum=gmp' XEmacs 21.5-b28 "fuki" 00ed9903a988 configured for `i686-pc-linux'. Compilation Environment and Installation Defaults: Source code location: /home/boffi/src/xemacs-21.5 Installation prefix: /usr/local Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler version: gcc (Debian 4.3.3-1) 4.3.3 - GCC specs file: specs. - Compiler command: gcc -Wall -Wno-switch -Wundef -Wsign-compare -Wno-char-subscripts -Wpacked -Wunused-parameter -g -O3 libc version: GNU libc 2.7-18 (Debian) Relocating allocator for buffers: yes GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: - X Windows libraries location: - Handling WM_COMMAND properly. - Using fontconfig to manage fonts. - Compiling in support for Xft antialiased fonts (EXPERIMENTAL). Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw3d - Athena library to link: Xaw3d Using Lucid menubars. - Using Xft to render antialiased fonts in menubars. WARNING: This feature will be replaced with a face. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena native widgets. - Using Xft to render antialiased fonts in tab controls. WARNING: This feature will be replaced with a face. - Using Xft to render antialiased fonts in progress bars. WARNING: This feature will be replaced with a face. WARNING: This feature not yet implemented; setting ignored. TTY: Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Compiling in support for ALSA (Advanced Linux Sound Architecture). Compiling in support for NAS (network audio system). Databases: Compiling in support for Berkeley database. Compiling in support for LDAP. Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using raw Xlib to provide XIM support. Mail: Compiling in support for "file" mail spool file locking method. Other Features: Inhibiting IPv6 canonicalization at startup. Compiling in support for dynamic shared object modules. Compiling in support for more number types using the GNU MP library. Using the new GC mark algorithms (KKCC). WARNING: --------------------------------------------------------- WARNING: The new algorithms are experimental. They are enabled by WARNING: default for this release. Use `--disable-kkcc' to WARNING: turn it off. WARNING: --------------------------------------------------------- Using the new portable dumper. Dumping into executable. Compiling in support for extra debugging code. Compiling in support for runtime error checking. WARNING: --------------------------------------------------------- WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- Load-Path Lisp Shadows: ---------------------- (/home/boffi/lib/emacs/test/db-rdb /usr/local/share/xemacs/site-lisp/edb/db-rdb /home/boffi/lib/emacs/test/database /usr/local/share/xemacs/site-lisp/edb/database /home/boffi/lib/emacs/test/db-sort /usr/local/share/xemacs/site-lisp/edb/db-sort /home/boffi/lib/emacs/test/db-convert /usr/local/share/xemacs/site-lisp/edb/db-convert /home/boffi/lib/emacs/test/db-search /usr/local/share/xemacs/site-lisp/edb/db-search /home/boffi/lib/emacs/test/db-tagged /usr/local/share/xemacs/site-lisp/edb/db-tagged /home/boffi/lib/emacs/test/db-isbn /usr/local/share/xemacs/site-lisp/edb/db-isbn /home/boffi/lib/emacs/test/db-two-dbs /usr/local/share/xemacs/site-lisp/edb/db-two-dbs /home/boffi/lib/emacs/info-look /usr/local/share/xemacs/xemacs-packages/lisp/edit-utils/info-look /home/boffi/lib/emacs/slime/tree-widget /usr/local/share/xemacs/xemacs-packages/lisp/jde/tree-widget /usr/local/share/xemacs/mule-packages/lisp/mule-base/ethio-util /usr/local/share/xemacs-21.5-b28/lisp/mule/ethio-util /usr/local/share/xemacs/mule-packages/lisp/mule-base/china-util /usr/local/share/xemacs-21.5-b28/lisp/mule/china-util /usr/local/share/xemacs/mule-packages/lisp/mule-base/japan-util /usr/local/share/xemacs-21.5-b28/lisp/mule/japan-util /usr/local/share/xemacs/mule-packages/lisp/mule-base/korea-util /usr/local/share/xemacs-21.5-b28/lisp/mule/korea-util /usr/local/share/xemacs/mule-packages/lisp/mule-base/cyril-util /usr/local/share/xemacs-21.5-b28/lisp/mule/cyril-util /usr/local/share/xemacs/mule-packages/lisp/mule-base/viet-util /usr/local/share/xemacs-21.5-b28/lisp/mule/viet-util /usr/local/share/xemacs/xemacs-packages/lisp/xemacs-base/easy-mmode /usr/local/share/xemacs-21.5-b28/lisp/easy-mmode /usr/local/share/xemacs/mule-packages/lisp/mule-ucs/unicode /usr/local/share/xemacs-21.5-b28/lisp/unicode /usr/local/share/xemacs/xemacs-packages/lisp/build/build-report /usr/local/share/xemacs-21.5-b28/lisp/build-report /usr/local/share/xemacs/xemacs-packages/lisp/xemacs-base/regexp-opt /usr/local/share/xemacs-21.5-b28/lisp/regexp-opt) Internationalization Settings: ------------------------- Environment: Value of LC_ALL : nil Value of LC_COLLATE : nil Value of LC_CTYPE : nil Value of LC_MESSAGES : nil Value of LC_MONETARY : nil Value of LC_NUMERIC : nil Value of LC_TIME : nil Value of LANG : C Lisp locale settings: current-language-environment => "English" default-buffer-file-coding-system => iso-8859-1 default-process-coding-system => (undecided . iso-8859-1) (current-locale) => "C" keyboard-coding-system => iso-8859-1 terminal-coding-system => iso-8859-1 (coding-priority-list) => (iso-8-1 utf-16-little-endian-bom utf-16-bom utf-8-bom iso-7 no-conversion utf-8 iso-8-2 iso-8-designate iso-lock-shift shift-jis big5 utf-16-little-endian utf-16 ucs-4) Coding system aliases: 'native is aliased to iso-8859-1 'file-name is aliased to iso-8859-1 'mswindows-multibyte-system-default is not a coding system alias Installed XEmacs Packages: ------------------------- (zenirc ver: 1.16 upstream: 2.112) (xwem ver: 1.22 upstream: lg(a)xwem.org--2005/xwem--main--2.1--versionfix-1) (xslt-process ver: 1.12 upstream: 1.2.1) (xslide ver: 1.09 upstream: 0.2.2) (xlib ver: 1.14 upstream: lg(a)xwem.org--2005/xlib--main--2.1--version-0) (xetla ver: 1.02 upstream: steve(a)eicq.org--2005/xetla--main--1.1--version-0) (xemacs-devel ver: 1.78 upstream: No-Upstream-Ver) (xemacs-base ver: 2.17 upstream: No-Upstream-Ver) (x-symbol ver: 1.1 upstream: 4.5.1) (w3 ver: 1.34 upstream: 4.0pre47) (vm ver: 7.26 upstream: 7.19) (viper ver: 1.63 upstream: 3.09) (view-process ver: 1.13 upstream: 2.4) (vhdl ver: 1.22 upstream: 3.33.12) (vc-cc ver: 1.22 upstream: No-Upstream-Ver) (vc ver: 1.45 upstream: No-Upstream-Ver) (tramp ver: 1.4 upstream: 2.0.56) (tpu ver: 1.14 upstream: 4.2X) (tooltalk ver: 1.15 upstream: No-Upstream-Ver) (tm ver: 1.39 upstream: No-Upstream-Ver) (time ver: 1.14 upstream: 1.17) (textools ver: 1.15 upstream: No-Upstream-Ver) (text-modes ver: 1.95 upstream: No-Upstream-Ver) (texinfo ver: 1.3 upstream: No-Upstream-Ver) (supercite ver: 1.21 upstream: 3.55x3) (strokes ver: 1.1 upstream: No-Upstream-Ver) (speedbar ver: 1.29 upstream: 1.0pre4) (sounds-wav ver: 1.12 upstream: No-Upstream-Ver) (sounds-au ver: 1.12 upstream: No-Upstream-Ver) (sml-mode ver: 0.12 upstream: 3.9.5) (slider ver: 1.15 upstream: 0.3x1) (sieve ver: 1.18 upstream: No-Upstream-Ver) (sh-script ver: 1.24 upstream: 2.0f) (sgml ver: 1.11 upstream: No-Upstream-Ver) (semantic ver: 1.2 upstream: 1.4.4) (sasl ver: 1.16 upstream: 1.14.4) (ruby-modes ver: 1.02 upstream: 1.6.8) (rmail ver: 1.14 upstream: No-Upstream-Ver) (reftex ver: 1.34 upstream: 4.21) (re-builder ver: 1.05 upstream: 1.20) (python-modes ver: 1.1 upstream: 426) (psgml-dtds ver: 1.03 upstream: No-Upstream-Ver) (psgml ver: 1.45 upstream: 1.3.2) (ps-print ver: 1.12 upstream: 6.5.6) (prog-modes ver: 2.16 upstream: No-Upstream-Ver) (pgg ver: 1.06 upstream: 0.1) (perl-modes ver: 1.14 upstream: No-Upstream-Ver) (pcomplete ver: 1.04 upstream: 1.1.6) (pcl-cvs ver: 1.68 upstream: R-2_9_9) (pc ver: 1.28 upstream: No-Upstream-Ver) (os-utils ver: 1.4 upstream: No-Upstream-Ver) (oo-browser ver: 1.05 upstream: 4.08) (ocaml ver: 0.06 upstream: 3.06) (net-utils ver: 1.56 upstream: N/A) (mmm-mode ver: 1.02 upstream: 0.4.7) (misc-games ver: 1.2 upstream: No-Upstream-Ver) (mine ver: 1.16 upstream: 1.9) (mew ver: 1.19 upstream: 1.94.2) (mailcrypt ver: 2.14 upstream: 3.5.8) (mail-lib ver: 1.79 upstream: No-Upstream-Ver) (jde ver: 1.51 upstream: 2.3.3) (ispell ver: 1.32 upstream: 3.6) (ilisp ver: 1.34 upstream: 5.12.0) (igrep ver: 1.16 upstream: 2.111) (idlwave ver: 1.32 upstream: 5.1) (ibuffer ver: 1.09 upstream: No-Upstream-Ver) (hyperbole ver: 1.17 upstream: 5.0) (hm--html-menus ver: 1.24 upstream: 5.9) (haskell-mode ver: 1.11 upstream: 2.1) (guided-tour ver: 0.52 upstream: No-Upstream-Ver) (gnus ver: 1.93 upstream: 5.10.8) (gnats ver: 1.17 upstream: 3.101) (general-docs ver: 1.05 upstream: No-Upstream-Ver) (games ver: 1.17 upstream: 1.04) (fsf-compat ver: 1.17 upstream: No-Upstream-Ver) (frame-icon ver: 1.11 upstream: No-Upstream-Ver) (fortran-modes ver: 1.05 upstream: No-Upstream-Ver) (forms ver: 1.15 upstream: 2.37) (footnote ver: 1.16 upstream: 0.18x) (eudc ver: 1.4 upstream: 1.32) (eterm ver: 1.17 upstream: No-Upstream-Ver) (eshell ver: 1.12 upstream: 2.4.1) (escreen ver: 1.01 upstream: 1.16) (erc ver: 0.21 upstream: Version 5.1.2 Revision: 1.796.2.6) (emerge ver: 1.11 upstream: No-Upstream-Ver) (elib ver: 1.13 upstream: 1.0) (eieio ver: 1.06 upstream: 1.0pre4) (efs ver: 1.34 upstream: 1.24) (edt ver: 1.14 upstream: No-Upstream-Ver) (edit-utils ver: 2.39 upstream: No-Upstream-Ver) (ediff ver: 1.75 upstream: 2.75) (edebug ver: 1.22 upstream: No-Upstream-Ver) (ecrypto ver: 0.2 upstream: 2.0) (ecb ver: 1.22 upstream: 2.31) (docbookide ver: 0.08 upstream: 0.1) (dired ver: 1.19 upstream: 7.16) (dictionary ver: 1.16 upstream: 1.8) (debug ver: 1.18 upstream: No-Upstream-Ver) (crisp ver: 1.15 upstream: 1.34) (cookie ver: 1.15 upstream: No-Upstream-Ver) (clearcase ver: 1.1 upstream: /main/laptop/165) (cc-mode ver: 1.45 upstream: 5.30.10) (calendar ver: 1.36 upstream: No-Upstream-Ver) (calc ver: 1.26 upstream: 2.02fX3) (c-support ver: 1.22 upstream: No-Upstream-Ver) (build ver: 1.14 upstream: 2.02) (bbdb ver: 1.32 upstream: 2.35) (auctex ver: 2007.0112 upstream: 11.84) (apel ver: 1.33 upstream: 10.6) (ada ver: 1.14 upstream: 2.27) (Sun ver: 1.16 upstream: No-Upstream-Ver) (skk ver: 1.24 upstream: 10.62a) (mule-ucs ver: 1.16 upstream: 0.84) (mule-base ver: 1.52 upstream: No-Upstream-Ver) (lookup ver: 1.15 upstream: 1.0) (leim ver: 1.27 upstream: No-Upstream-Ver) (latin-unity ver: 1.2 upstream: 1.20) (latin-euro-standards ver: 1.08 upstream: 1.08) (egg-its ver: 1.27 upstream: No-Upstream-Ver) (edict ver: 1.16 upstream: 0.9.9) Installed Modules: ----------------- Features: -------- (xemacsbug shadow info vm-reply vm-delete vm-undo vm-crypto vm-pop vm-page vm-mime vm-toolbar vm-summary tapestry vm-motion vm-message vm-menu vm-folder vm-misc vm-mouse vm-window vm-autoload vm-vars vm-version vm vm-startup latin-unity-tables latin-euro-standards latin-euro-latin10 latin-euro-latin9 latin-euro-latin8 latin-euro-latin7 latin-unity-vars latin-unity flow-fill mail-extr sort gnus-fun gnus-cite gnus-agent gnus-srvr nnvirtual gnus-async gnus-bcklg gnus-score score-mode gnus-ml gnus-msg gnus-art mm-uu mml2015 pgg password pgg-parse pgg-def mm-view disp-table gnus-topic gnus-sum nndoc parse-time gnus-cache gnus-group gnus-undo nndraft nnmh nnmail mail-source format-spec efs-cu nntp nnoo uboat gnus-start gnus-spec gnus-int gnus-range message mml mml-sec mml-smime smime dig mm-decode mm-bodies mm-encode mailcap lpr mail-parse rfc2045 rfc2231 rfc2047 qp ietf-drums mail-abbrevs sendmail rfc822 mailheader canlock sha1 executable hex-util gnus-win gnus gnus-ems gnus-xmas gnuserv guided-tour paren blink-paren func-menu bbdb regexp-opt timezone jka-compr slime byte-optimize bytecomp byte-compile tree-widget wid-edit apropos edmacro timer-funcs overlay font-lock cus-face hyperspec thingatpt browse-url hideshow pp timer comint ring smiley annotations messagexmas nnheader nnheaderxm gnus-util netrc time-date mm-util mail-prsvr mail-utils x-compose filladapt image-mode view-less view mwheel advice advice-preload zenirc-autoloads xwem-autoloads xslt-process-autoloads xslide-autoloads xlib-autoloads xetla-autoloads xemacs-devel-autoloads xemacs-base-autoloads x-symbol-autoloads w3-autoloads vm-autoloads viper-autoloads view-process-autoloads vhdl-autoloads vc-cc-autoloads vc-autoloads tramp-autoloads tpu-autoloads tooltalk-autoloads tm-autoloads time-autoloads textools-autoloads text-modes-autoloads texinfo-autoloads supercite-autoloads strokes-autoloads speedbar-autoloads sounds-wav-autoloads sounds-au-autoloads sml-mode-autoloads slider-autoloads sieve-autoloads sh-script-autoloads sgml-autoloads semantic-autoloads sasl-autoloads ruby-modes-autoloads rmail-autoloads reftex-autoloads re-builder-autoloads python-modes-autoloads psgml-dtds-autoloads psgml-autoloads ps-print-autoloads prog-modes-autoloads pgg-autoloads perl-modes-autoloads pcomplete-autoloads pcl-cvs-autoloads pc-autoloads os-utils-autoloads oo-browser-autoloads ocaml-autoloads net-utils-autoloads mmm-mode-autoloads misc-games-autoloads mine-autoloads mew-autoloads mailcrypt-autoloads mail-lib-autoloads jde-autoloads ispell-autoloads ilisp-autoloads igrep-autoloads idlwave-autoloads ibuffer-autoloads hyperbole-autoloads hm--html-menus-autoloads haskell-mode-autoloads guided-tour-autoloads gnus-autoloads gnats-autoloads general-docs-autoloads games-autoloads fsf-compat-autoloads frame-icon-autoloads fortran-modes-autoloads forms-autoloads footnote-autoloads eudc-autoloads eterm-autoloads eshell-autoloads escreen-autoloads erc-autoloads emerge-autoloads elib-autoloads eieio-autoloads efs-autoloads edt-autoloads edit-utils-autoloads ediff-autoloads edebug-autoloads ecrypto-autoloads ecb-autoloads docbookide-autoloads dired-autoloads dictionary-autoloads debug-autoloads crisp-autoloads cookie-autoloads clearcase-autoloads cc-mode-autoloads calendar-autoloads calc-autoloads c-support-autoloads build-autoloads bbdb-autoloads tex-site apel-autoloads ada-autoloads Sun-autoloads skk-autoloads mule-ucs-autoloads mule-base-autoloads lookup-autoloads leim-autoloads latin-unity-autoloads latin-euro-standards-autoloads egg-its-autoloads edict-autoloads modules-autoloads mule-autoloads auto-autoloads auto-show fontl-hooks canna-leim tibetan slovenian czech romanian lao devanagari indian cyrillic code-cmds gutter-items menubar-items x-menubar mode-motion mouse behavior itimer auto-save lisp-mode easymenu easy-mmode iso8859-1 page buff-menu lib-complete loadhist cus-file derived newcomment rsz-minibuf env text-props fontconfig frame obsolete cus-start custom widget cl-extra cl cl-19 packages backquote unicode font-mgr lucid-scrollbars cut-buffer xft-fonts lucid-menubars athena-dialogs x c-balloon-help tty-frames tty toolbar nas-sound native-sound alsa-sound scrollbar unix-processes multicast network-streams subprocesses bigfloat ratio bignum number-types modules menu-accelerator-support menubar berkeley-db md5 xemacs xim mule gutter tiff png gif jpeg xface xpm xbm lisp-float-type file-coding linux dialog devices window-system base64) Recent keystrokes: ----------------- SPC h o r i z o n t a l l y RET RET t h e SPC x t e r m SPC i s SPC 9 0 x 3 0 left left left left left left left left left left left left left left left left left left i SPC f o r g o t SPC t o SPC m e n t i o n: Sh-SPC C-e M-x x e m a TAB r e TAB BS BS BS BS BS BS BS BS BS r e p o TAB button1 button1up button2 button2up Recent messages (most recent first): ----------------------------------- Loading xemacsbug...done Loading xemacsbug... Making completion list... Quit Checking new news...done Opening nndoc server on gnus-help...done Opening nndoc server on gnus-help... Opening nntp server on localhost...done Opening nntp server on localhost... Opening nntp server on news.easysw.com...done Opening nntp server on news.easysw.com... Checking new news... nntp read: 11k Reading active file from newsserver.cilea.it via nntp... Opening nntp server on newsserver.cilea.it...done Opening nntp server on newsserver.cilea.it... Type `C-x 5 0' to finish editing Decoding MIME message... done Decoding quoted-printable... done Decoding quoted-printable... -- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Quoting Michael Sperber <sperber(a)deinprogramm.de&gt;: that's exactly what i have done the value of the expressions were 36 and 3 respectively, and the modeline was longer than 36 characters at the moment i'm unable to help further, due to hardware problems in the machine where the offending behaviour was observed ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> It's going to take longer to get 21.5 released than it is to Stephen> get GPLv3 set up (if somebody will just start the work on Stephen> GPLv3). OK. Lets start again then... This is what the script produces today on the latest pulled beta version. All files marked with a question mark isn't diagnosed yet and needs to be inspected manually. Some of these might be possible to move away due to their file type, e.g., a type that isn't possible to copyright. The files are tagged like this: gplv2 -- GPLv2 or later found in file lgplv2 -- LGPLv2 or later found in file no(C) -- File type is not a candidate to copyright * -- Needs to be fixed (No file is marked with this yet.) ? -- Unknown I suggest that the first step in this process is to go through the list and try to find out what category each file belongs to. There might still be file types that can be taken care of by their extension or file type. For the rest I guess it is hard manual work that lies ahead. Equipped with that information we then have to solve the files marked with * in some way or the other. I haven't thought yet about how to book keep and publish any intermediate results while we go along but I guess it is safe to postpone this until I get some feedback! ;-) Feel free to look through the files with me. The script can be found in xemacs-builds/matsl/gplv3. "http://cvs.xemacs.org/viewcvs.cgi/XEmacs/xemacs-builds/matsl/gplv3/" Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Jerry> Did I not finish the source file audit? I thought I had. I Jerry> remember making this list after going through all the files: Aha! Nice. I had missed that completely. I'll have a look at it. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> Well, what are they? Oh yes, reftex is still not upgraded because of this issue. 2 things I would like to add - better compatibility with GNU emacs (fsf-compat): most of the package today posted are for GNU emacs exclusively. Sometimes the fix is trivial via an alias, sometimes it is more or less easy by using the functions provided in GNU emacs, but not yet implemented in Xemacs (save the GPLv3 question). Sometimes very hard because of very different implementation or built-in functions. But still the first two parts could be done. - PUI should support 3rd party pkg in the package system. Some years ago I wrote a trivial set of functions for installing 3rd party packages in site-packages. However they are not displayed in PUI. Uwe Brauer _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Didier Verna writes: I don't really consider availability a problem, and on occasion I've found it convenient to use X resources to prove to my own satisfaction that XEmacs can do what Customize is steadfastly refusing to do for me.<wink> However, certainly Lisp should be the first- and best-supported channel for customization. Well, that's not easy. Custom itself really only provides for a flat, global namespace of variables. Groups are an afterthought, and specifiers are not exploited by Custom at all. Specifiers also have some deficiencies. Specifically, there should be mode and extent locales. I believe that a mode locale would be more efficient, robust, and intelligible than the current method of using setter functions to "backpatch" all the relevant buffer locales for a mode. And the extent locale would be a way to implement the "native" mmm-mode you suggested earlier, I think. The main problem with extent locales is deciding where they would fit in the precedence hierarchy. (There isn't such a problem with mode locale, unambiguously it would have a higher precedence than the global locale, but lower than any buffer.) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

SL Baur writes: I wish you'd had the insight to tackle it when customize was added.... ;-) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

on 02/23/2009 02:05 AM Leo said the following: Would posting a list of such features be worthwhile? The list needn't been exhaustive to be useful. --- Vladimir -- Vladimir G. Ivanovic _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Leo writes: [A bunch of stuff, of which at least half of the truly technical advances are already in XEmacs.] Really the big technical difference is good support for non-Western, non-Hanzi scripts (although I note GNU is still missing bidi support). But what's really important in your list is lots of love from a large developer population. Unfortunately, some of those developers are people I am not comfortable working with (most importantly, RMS), and I dislike working on GNU code (XEmacs code, Ben Wing's stuff notwithstanding, is way easier for me to figure out than Emacs code at least up to pre-22). It's a shame we can't merge the GNU docs. And better Unicode support is going to take some effort. But the other stuff you mention was either pioneered by XEmacs, or not so hard to add. The bottom line is that I'll have to take a look at NEWS, but in the list of technology you present here there's nothing particularly scary. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David Kastrup writes: Good advice. But it seems there remain a number of points where your own understanding is belated or insufficient. Which is, of course, what I have been telling you for nearly a decade. I didn't call anyone a liar, though I admit that Jamie is one of my personal heroes.[1] I said that the claim that Lucid tried to hijack the Emacs project is a damned lie. Not only did Jamie and Richard Gabriel say over and over again that their goal for a merge was a GNU- maintained Emacs (indeed, alluding to "your version of Emacs" in the post you quote, clearly foreseeing that the merge interlude would be brief, and after that full control would return to GNU, and Lucid would again be maintaining their own version), but all their behavior and the incentives of a commercial firm back that assertion up. The main point is that it was RMS who insisted that they try to merge, not Lucid. And Lucid insisted on control of the merge process that RMS asked them to perform, not ongoing maintainership. But I have never seen it that way; yet another "damned lie", and I wish you would stop attributing to me views I have never held. True, IMO Lucid *was* heroic, trying to build a major commercial endeavor based partly on free software. But they were not fairy-tale heroes in the fork; Gabriel knew Stallman very well, and baiting him with the announcement of "Emacs 19 is here, now, not at GNU" was nasty and dumb at best. On the other hand, there is substantial evidence of their goodwill and contribution to Emacs: the Lucid code in Emacs proper (ie, excluding the Lucid Widget Library and the interface to the Energize product) was already assigned to the FSF as of May 1992 (Lucid Emacs 19.0), almost a year before the flamewar. So even if they wanted to, they had absolutely no legal possibility of "hijacking" anything! Footnotes: [1] He got that way not by producing Lucid Emacs, but on the quality of his bug reports, and the purity of the acid in his flames. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta