December 2004 - XEmacs-Design - XEmacs Mailing List Archives

back on track with the BeOS port 20 years, 4 months

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 … [View More]

1 participants
0 comments

Rechnung Online Monat Dezember 2 20 years, 4 months

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: … [View More]

1 participants
0 comments

CLIENT Referral ! 20 years, 4 months

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 … [View More]

1 participants
0 comments

Re: Long-term survival 20 years, 4 months

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 … [View More]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. [View Less]

4 participants
7 comments

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

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 > +… [View More]

2 participants
1 comments

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

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 … [View More]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 [View Less]

7 participants
19 comments

About making elisp files UTF-8 20 years, 4 months

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 … [View More]

4 participants
7 comments

Re: Is anyone reading this? 20 years, 4 months

Ben Wing

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

2 participants
1 comments

Package caching 20 years, 4 months

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 … [View More]

2 participants
3 comments

Is anyone reading this? 20 years, 4 months

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

2025

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