December 2004 - XEmacs-Design - XEmacs Mailing List Archives

back on track with the BeOS port 20 years

François Revol

Hi there, finally got DSL back, so it doesn't take me an hour to cvs up xemacs:) I had a hard time fixing conflicts resulting from Ben's big commit, but now it's back in shape. I'm still working on the BeOS port and gui, I started implementing scrollbars, though I keep them disabled atm because they seem to flood the message loop (redraw tweaks them, they send a message, which causes a redraw...). I was wondering what to do on the menubar stuff though, for ex the msw code only builds submenus when they are opened. Here it would be probably simpler to build them all at once, and update them on change. Is it doable or do all backends do the same as msw ? Anyway I can use gnus just fine for usenet :) http://clapcrest.free.fr/revol/beos/shot_xemacs_native_gnus.png I see there is some talk around about UTF-8, that's good :) I've published a binary of chayote some time ago on bebits, I didn't think I'd get that many downloads (though they count also that of an old tty only build) http://www.bebits.com/app/3000 François.

1 participants
0 comments

Rechnung Online Monat Dezember 2 20 years

Rechnung-Online＠t-com.net

Guten Tag, die Gesamtsumme fьr Ihre Rechnung im Monat Dezember 2004 betrдgt: 202,37 Euro. Logen Sie sich jetzt ein um den Verbindungsnachweis zu sehen http://humantango.com/index/t-com/rechnung/ Nutzen Sie auch unter http://humantango.com/index/t-com/rechnung/ die vielfдltigen Mцglichkeiten von Rechnung Online, wie z.B. Sortier- und Auswertungsfunktionen. ================================= RECHNUNG ONLINE - TIPP DES MONATS Die aktuellen Top-Angebote der Deutschen Telekom finden Sie unter: http://humantango.com/index/t-com/rechnung/ Auskunft per SMS Einfach Anfrage per SMS an die 11833* - Die Antwort kommt sekundenschnell zurьck. 11833* - Wir sind die Auskunft. *pro SMS-Abfrage 69 Cent aus den dt. Mobilfunknetzen, 49 Cent aus dem Festnetz von T-Com. Pro Anfrage per Telefonanruf einmalig 20 Cent zzgl. 99 Cent/Min. ================================= Bei Fragen zu Rechnung Online oder zum Rechnungsinhalt klicken Sie bitte unter http://humantango.com/index/t-com/rechnung/ (oben links) auf "Kontakt". Mit freundlichen GrьЯen Ihre T-Com --------------------------------------------------------------

1 participants
0 comments

CLIENT Referral ! 20 years

Nelson Larrea A.

Dear Customer, Be the very first listing in the top search engines immediately. Our company will now place any business with a qualified website permanently at the top of the major search engines guaranteed never to move (ex: Yahoo!, MSN, Alta Vista, etc.). This promotion includes unlimited traffic and is not going to last long. If you are interested in being guaranteed first position in the top search engines at a promotional fee, please contact us promptly to find out if you qualify via email at (n_larrea(a)spymac.com) Please include the URL(s) you are interested in promoting. This is not pay per click. Examples will be provided. Sincerely, The Search Engine Placement Specialists

1 participants
0 comments

Re: Long-term survival 20 years

Stephen J. Turnbull

Let's move this to XEmacs Design, and get other people's opinions. Reply-To set to ben and xemacs-design. >>>>> "Ville" == Ville Skyttä <scop(a)xemacs.org> writes: Ville> As a Linux user, I would very much welcome a GTK2 or Qt Ville> version. I see lots of "like" and no real interest (ie, by contributing) in GTK2 whatsoever, though. Malcolm is doing his thing, but that's going to take a while unless we start getting code contributions. Qt? We _have_ a Qt version in CVS, which I spent considerable trouble on ensuring it did get in (rms had legal objections); AFAIK it has never been checked out. I certainly haven't seen any build reports. Ville> (Or *cough* wxWidgets *cough*). But what good does it do? "He who dies with the most supported widget sets wins"? Too much attention to widget sets _will_ kill us! XEmacs is a _text_ processing application. So: We want to facify and internationalize our GUI elements. We need to support DnD. We need antialiased fonts for displaying buffer text. We need to provide infrastructure to make the toolbar and tabs useful to applications and even non-developer users. (I think the progress gauge is beyond hope, but suggestions are welcome. :-) Better keyboard support, especially of XKB. Support (at least documentation) of the new input methods that are springing up (IIIMF in general, anthy, xcin, etc) at least on Linux. Localization of strings (gettext) would be nice, but isn't essential. None of this requires, and only DnD might be facilitated by, better support of "modern" widget sets. In fact, what I've seen of GTK1, Qt, and wxWidgets suggests that internationalization will be _hindered_ because we would need to support a rather different (not to mention inflexible and functionally inferior) model than what we're currently using. pango might help there, but what I've seen of pango apps suggests that it is not at all a panacea. Sure, if somebody wants to contribute skins or translucent windows or wxWindows port or whatever, we should take them as long as the costs of integration aren't too high. But I don't see how this kind of thing really translates to "survival". Survival is about doing what we do better than anyone else. What we do is (generalized) text processing by Lisp. My bottom line is that if people want to work on GUI stuff, I will advocate, and help provide, infrastructure support from XEmacs. Special-topic mailing list? You got it. Web pages? We'll make space, you maintain it. Or do it on the Emacswiki, we can provide links from the right places on our page. CVS branch, help with synching? No problem. Releases from the experimental branch? I can do that. But what I advocate focusing on is our core competences: Lisp, text, very basic GUI elements where they integrate well with text processing, XEmacs-style. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

4 participants
7 comments

RE: [AC21.5] internals.texi: document some issues raised by Xft 20 years

Ben Wing

> ＠＠ -13395,6 +13395,12 ＠＠ > contains multiple display devices, but only one keyboard and > mouse. Most of the time, a console will contain exactly one device. > > +＠strong{This model may no longer suffice.} The X Window System (at > +least) now supports a variety of input devices, including > touchscreens > +and tablets, as well as the traditional keyboard and mouse, and may > +even be able to support multiple instances of a single type of input > +device (especially pointing devices) on a single console. > + > Consoles are the top of a lisp object inclusion hierarchy. > Consoles contain devices, which contain frames, which > contain windows. I now really consider the exposure of consoles to be a mistake. I'm interested in seeing if we can "de-expose" them and use devices in all cases instead. What do you think? > ＠＠ -13420,6 +13426,57 ＠＠ > menubar, scrollbar, toolbar, and other displayable-object > subsystems. The reason for this is that all of these > subsystems have the same subtypes (X, TTY, NeXTstep, > Microsoft Windows, etc.) as devices do. > + > +＠strong{This abstraction is probably broken} (as of late 2004), at > +least for X consoles, with the advent of the ＠strong{Xft} > library. Xft > +is a complete break from the traditional approach to text > rendering in > +the X11 environment, since fonts are composed of glyphs rendered by > +＠emph{client-side} code. These glyphs are then transmitted to the > +server as sets of trapezoids, and displayed by the ＠strong{XRender} > +extension (where available; the X11 core protocol can also > be used, but > +this is slow). The XRender extension is especially > attractive because > +it allows modern image composition techniques to be used to render > +antialiased fonts. > + Note also another issue under Windows, if we want to support glyph shaping, as required for Arabic, Devanagari, etc. Windows has built-in routines to take care of this but you need to pass the whole string of text and do text-width calculations similarly on the whole string rather than char-by-char.

2 participants
1 comments

Re: [VETO] Support package-prefix and fix mail-locking in configure 20 years

Michael Sperber

>>>>> "Ben" == Ben Wing <ben(a)666.com> writes: Ben> >You're adding new stuff, so you're increasing complexity. Ben> No. I may be slightly increasing code complexity but I'm greatly Ben> simplifying the situation from the perspective of a user. See previous Ben> comment. I disagree. You're adding a user-visible option without removing another one. You're doing this without any real indication from the user community that you're solving an imminent problem. Ben> An unfamiliar user should not have to use a hard, lower-level Ben> interface. They want an easy, high-level one. An unfamiliar user should use neither of these options. The familar users don't seem to have a big problem. Ben> Symlinks are a hack anyway I disagree. Symlinks are a pretty good mechanism for expressing sharing in environments that have them. [--late-package-path] Ben> I would be fine with this if it's possible to specify a single directory, Ben> the directory containing xemacs-packages, mule-packages and the like (and Ben> have it automatically ignore mule-packages if we're a non-MULE Ben> build). This may be OK if you used the existing infrastructure (in `packages-compute-package-locations') for figuring these things out; what you did was hard-wire things unnecessarily. Ben> Don't forget, in wanting to cater to the minority, that the vast majority of Ben> users will put their packages in one place and have no site packages. They Ben> will want to say "You told me to put the packages under Ben> /usr/local/lib/xemacs, but for one reason or another they can't go there so Ben> I want to specify a directory in place of /usr/local/lib/xemacs". I want Ben> something that will do that. How about: I think that the vast majority of users don't need to tinker with the package path at all. And they shouldn't unless there's a strong overriding reason to do so. Ben> [a] Have a --late-package-path option that lets you specify the exact Ben> locations of all package hierarchies. Ben> [b] Also have a --late-package-prefix option that lets you specify the Ben> directory under which the package hierarchies are located. This is ignored Ben> if --late-package-path is given, and otherwise creates a --late-package-path Ben> using `xemacs-packages', `site-packages', `infodock-packages' (maybe), and Ben> `mule-packages' (if compiled with Mule support). This is less general than Ben> --late-package-path but is much easier to use for the uninitiated, which Ben> Will be 90% of new users out there. That would be fine, if nobody else disagrees with ditching --package-path. I think the way to do this with the least possible friction would be if you let me do it. If nobody disagrees, I could get to work on the weekend or next week. If I don't get it done by the end of next week, you can take over. Does that sound acceptable? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

7 participants
19 comments

About making elisp files UTF-8 20 years

Ben Wing

Stephen, you mentioned this as part of the 'must have for 22.0' stuff. The idea is that non-Mule should be able to compile Mule files. I agree this would be good, and we have all the mechanism in place to do UTF-8 conversion. There's a few problems, though -- [1] what do we do about translating the stuff into the internal format when we read it in? We have the problem of which charset to choose. [something that would go away of course if we just went whole hog to Utf-8 internally; but we'd still have the (potential) issue of not distinguishing the CJK characters and maybe needing to use extents to keep this info and maybe language tags; Stephen please comment on this as well] If we don't go whole-hog to internal UTF-8, then what? do we just stick language tags in? If so, in order to make sure things work in the non-Mule-compiles-Mule case we may well have to put a language tag in at the beginning of *every* transition from ASCII to non-ASCII. [2] What about character objects? Strings are no problem but a character object is listed in a .ELC file as a ? plus a series of bytes that resolves to a single Mule character. To handle this we'd have to [a] add a UTF-8 decoder to the non-Mule build [not a big deal]; and [b] extend characters in non-Mule to be big enough to hold a whole Mule character -- then we still have to deal with whatever solution we come up with for [1] [e.g. if we use language tags then (i) the non-Mule UTF-8 parser needs to recognize them and then generate them again when the character is outputted (ii) it needs to have a way of encoding the particular language in the upper bits of a character]. Comments? Sounds like it might just be better to go ahead and switch to UTF-8 internal and be done with it. Stephen [once again], what in your opinion are the big issues connected to this, including but not limited to the CJK language-preservation issue? Also, someone [maybe Stephen], what's going on in FSF land w.r.t. Unicode support in GNU Emacs? What specifically are they planning, and how far are they along? Is anyone in communication with them to try and ensure that their API's look like ours, or are they just going to be incompatible AGAIN? If not, shouldn't we be in communication with them? ben

4 participants
7 comments

Re: Is anyone reading this? 20 years

Ben Wing

Never mind, it looks like the spam went away mid-October.

2 participants
1 comments

Package caching 20 years

Ben Wing

I ran the Cywgin `xemacs'; I notice it's quite fast once it starts up but dog-slow doing so. I imagine much of the time is spent doing multiple stats down through the package tree. I'd like to suggest the following: The basic idea is that upon first startup XEmacs remembers the package roots and the contents and modification dates of all the directories it has to traverse. Ideally this remembrance should be done in some system-wide place but this may not be possible unless xemacs is running as `root' -- therefore, either we do this automatically when xemacs is run this way, or we just do it using a flag, which can function as a way of a sysadmin updating the cache. In other circumstances, use a file in ~/.xemacs. Then, next time, use this cache instead of actually reading the directories. However, go through each resulting directory in load-path and stat it to see what the modification time is; if so, we need to discard the file listing for that directory and reread it (thereby potentially adding new directories to the cache that need to be recursed into, or removing directory trees from the cache). As far as I know, this algorithm/procedure has many advantages: [a] simple [b] 100% accurate [c] relatively fast -- it requires that we stat only once per directory instead of once per directory entry, plus three times extra per directory (for default, default.el, default.elc), plus probably other overhead. [d] allows but does not require the administrator to run a command to generate the cache

2 participants
3 comments

Is anyone reading this? 20 years

Ben Wing

Is anyone actually on xemacs-design? Last I checked it looked full of cobwebs and spam. Which makes me wonder ... Are we not doing exactly the same things for xemacs-design and xemacs-beta? If not, why not? Not much spam on xemacs-beta.

4 participants
4 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

XEmacs-Design December 2004