March 1999 - XEmacs-Beta - XEmacs Mailing List Archives

William M. Perry

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > > > Because the custom font-model is based on the FSF font model and > > ignores the specifier system completely. > > It isn't based on the "FSF font model", as there is no such thing. It is > based on the pre-specifier *face* model, plus a subset of wmperrys > font.el package, the closest thing you get to a *font* model on either > emacs. font.el now has pretty full support for the new Emacs redisplay code as well, so if custom continues to use some subset of font.el, it should work 'out of the box'. > > In FSF Emacs this is trivial since customize exactly matches the FSF > > font model. Adapting customize to more powerful font models (whether > > for XEmacs or for FSF 20.5+) without overly complicating the > > interface will be a challenge. > > There is no XEmacs font model, which is the only hard thing about it. I > discussed with wmperry how to make it use the full font.el font model, > that's not hard, it is just a small matter of programming. I would dearly love to see this change. Perhaps the new Emacs redisplay will force us to do it. :) The merging of font properties is very nice and powerful. -Bill P.

2 participants
1 comments

Re: Customize bug? 25 years, 3 months

Didier Verna

Hrvoje Niksic writes: >> On both emacsen. But you can overwrite the customize setting with X >> ressources, which only leaves explicit Lisp settings. Hrvoje> It depends. I think the *default* customize settings (such as in Hrvoje> `defface' forms) should be overridden with X resources. On the other Hrvoje> hand, hand-changed customize settings (such as with `M-x Hrvoje> customize-face') should override X resources. The last bits of this thread also has the virtue of showing that there's currently not even a consensus on the priority of assignments, and not only because Custom or X resources can't really handle specifiers. While I agree with what Hrovje says here, I have the feeling that the face resources should go away in a medium-term. It's no good to have multiple interfaces to the same functionality, especially when those interfaces are either partially efficient, or doesn't interact very well with each other. My experience with X has always shown me that using the X resources mechanism for just about everything is a /bad thing/. X resources should be used _only_ for stuff that we _know_ only happen under X. Widgets backgrounds, size of frames etc. For instance, it's a nonsense to have an attributeBackground[Pixmap] resource for the default face which actually behaves almost like a background [pixmap] setting for the frame. The only thing that faces should inherit from X resources should be a general *foreground setting. Using X resources everywhere only confuse novice users, make the work harder for us, and we need another specification interface anyway. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: Paren expression staying permanently highlighted? 25 years, 3 months

Adrian Aichner

>>>>> "Reid" == Reid Rivenburgh <reid(a)ldap-green.lanl.gov> writes: Reid> Hi, Reid> I just recently joined the beta mailing list, so sorry if Reid> this has come up before. (I did look on dejanews, but I Reid> came up empty.) Reid> I've been using version 21.0 betas for quite some time now Reid> (currently b65), and occasionally a paren expression will Reid> highlight and stay highlighted, even when the cursor is Reid> moved away. This ends up leaving chunks of garish green in Reid> my buffer. (That green is a fine color for temporary Reid> matches, but not all the time....) It doesn't always Reid> happen, and I haven't figured out what causes it. I'm Reid> seeing it at the moment running on: Reid> OSF1 turbo-01 V4.0 878 alpha Reid> and I'm pretty sure I've also seen it on Solaris. I'm not Reid> doing anything peculiar in my .emacs relating to paren Try starting xemacs -vanilla and see if you still see this problem. Reid> matching. I don't think this happened before the 21.0 Reid> series. Reid> Anyone else seen this or am I crazy? Reid> Thanks, Reid> Reid -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: Customize bug? 25 years, 3 months

Jan Vroonhof

John Whitley <whitley(a)cse.buffalo.edu> writes: > Using menu item Customize -> Faces... to bring up the *Customize > Faces* buffer, then open the "Bold" face or any other face using a > bold font, as in: It is a weakness in the current design of the customize face model. Unlike with variables you do not see the current situation, but the current custom font-spec. If you did not customize this font these are likely to be different. > > Bold: (sample) * > > [State]: this face has not been changed with customize. ...and thus could very well have been changed outside of it. It is one of the sacrifices Per made to have user interface simplicity and inter Emacs compatibility. Hopefully this can go away when/if customize is better integrated with the XEmacs font-specifier model. Jan

3 participants
3 comments

Re: Customize bug? 25 years, 3 months

Jan Vroonhof

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > If so, why does it work perfectly well on Emacs 20.3? Because the custom font-model is based on the FSF font model and ignores the specifier system completely. There is code to construct a specifier from Custom specs, but not the other way around. In FSF Emacs this is trivial since customize exactly matches the FSF font model. Adapting customize to more powerful font models (whether for XEmacs or for FSF 20.5+) without overly complicating the interface will be a challenge. I would be cool to have M-x edit-faces back for real. > XEmacs reimplementation[1] of the Customize face support. Things are > initialized in the wrong sequence. MULE fonts are screwed. And now > this. I think I know how to fix the MULE problems. (By doing a partial port to specifiers. This fixes the throw-away-what-I-don't-understand attitude the Customize takes on XEmacs). What would be cool is a _true_ port to specifiers, but I am afraid this also needs some hacking on the specifiers for the light-vs-dark isse. > Will there be time for any hacking sessions in Japan? I think it > would be useful if some of us I sure hope so. I am bringing my new notebook and I'll put a late model XEmacs on it, so we can just lock us up in our hotel room and hack at night (which also gives us a good Solution to jet-lag). Jan

2 participants
1 comments

[21.0] Better NEWS entry 25 years, 3 months

Jan Vroonhof

At the request of Hrvoje, I rewrote this to be clearer. bolzano:/scratch/vroonhof/cvs/xemacs-20> cvs diff -u etc/NEWS Index: etc/NEWS =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/etc/NEWS,v retrieving revision 1.64 diff -u -u -r1.64 NEWS --- NEWS 1999/03/12 09:59:45 1.64 +++ NEWS 1999/03/16 20:16:35 ＠＠ -161,8 +161,7 ＠＠ *** Like the old 'gnudoit' program. Gnuclient -batch now can read from stdin. -*** Again like the old 'gnudoit' program, gnuclient now can return multiple -lines. +*** Gnuclient -batch no longer breaks off the output at the first LF. ** C mode changes -- Jan Vroonhof http://www.math.ethz.ch/~vroonhof/ Mathematik, vroonhof ＠ math.ethz.ch HG E16, ETH-Zentrum, Tel: +41-1-6325456/25154 Raemistrasse 101, CH-8092 Zuerich. Fax: +41-1-6321085

1 participants
0 comments

dumping under XEmacs... 25 years, 3 months

William M. Perry

I cannot successfully dump xemacs 21.2.13 under Solaris 2.6 (on a SPARCbook 3GX). Anybody else seen this? -bp

1 participants
0 comments

layouts (Was Re: Backspace direction reversion) 25 years, 3 months

Tor Arntsen

On Mar 16, 8:57, Hrvoje Niksic wrote: >SL Baur <steve(a)xemacs.org> writes: > >> `Normal'? `Normal'??? It's _not_ a normal keyboard for any canonical >> meaning of normal. The parens are shifted left to be above `8' and >> `9', `"' and `＠' are on the wrong keys, the square and curly braces >> are on the wrong keys. > >Heh heh; so far, this looks like you're working on a keyboard with >Croatian[1] mappings. My condolences. > > >[1] >In fact, the ideas were imported from German keyboards. I don't know >why the Japanese do the same. Hey, that keyboard sounds like the Norwegian layout too.. maybe the weird one is the US keyboard layout :-) - Tor

1 participants
0 comments

Re: A few problems with XEmacs 21.2.11. 25 years, 3 months

Jan Vroonhof

Dan Glastonbury <Dan.Glastonbury(a)adelaide.maptek.com.au> writes: > My other problem is when I try required packages in the package list buffer > with the `r' key. I get in the mini-buffer" > Wrong type argument: number-char-or-marker-p, nil > > How do I fix these problems?! This _should_ be fixed in newer betas. If you also het it there, please post a backtrace. Jan

1 participants
0 comments

Re: Frustration on new install 25 years, 3 months

Jan Vroonhof

Erik Arneson <erik(a)mind.net> writes: > it. I guess I should learn to abandon my fear of C-s. I found also > that upgrading to the newest XFree86 fixes the problem without enabling > the sw_cursor option. This is also good to know. Jan

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta March 1999