September 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [Richard Stallman <rms@santafe.edu>] Re: [kinoue@ic.rdc.ricoh.co.jp: widget-choose] 27 years

William M. Perry

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > >> Perhaps we should add some upper limit to the # of items in a > >> menu before widget-menu-minibuffer-flag is ignored and we > >> prompt in the minibuffer (via completing-read) regardless? > > > We should probably do a similar patch for the XEmacs version of custom... I > > don't have the latest source right now though... just a heads up. > > XEmacs already has a hardcoded limit of 10. This should be customizable. Hardcoded limits bad! Unless the hardcoded limit is (- (char-int ?z) (char-int ?0)) -Bill P.

1 participants
0 comments

Re: fix for Motif >=2.0 27 years

Didier Verna

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Just by reading though the manpages of the functions involved, It > seems that Motif 2.x's resource code specifies unspecified pixmap not > using NULL but using XmUNSPECIFIED_PIXMAP (!=NULL). That's it. There's actually a difference in the management of top and bottom shadow pixmaps (welcome to motif): those resources are defined in the XmPrimitive widget class. the XmNbottomShadowPixmap is bound to XmUNSPECIFIED_PIXMAP by default, whereas XmNtopShadowPixmap is computed dynamically. I think this is because XmPrimitive inherits directly from Core, which defines the XmNborderPixmap resource, and this resource is used in the topShadowPixmap computation (not in the bottomShadowPixmap one). --XmNdidier

1 participants
0 comments

Re: [Russ Allbery <rra@stanford.edu>] Re: Status of pcl-cvs development? 27 years

Hannu Koivisto

greg(a)alphatech.com (Greg Klanderman) writes: [Thanks for your initiative, Jari. Personal addresses stripped from cc-list to avoid duplicated mails as all people involved are on those two lists anyway.] | I too prefer pcl-cvs. This is what I thought would be the case for most CVS+Emacs users. Thanks for the comments, you and Russ. I have been toying with an idea to make a sort of a VC-replacement-layer for pcl-cvs so that you could use the same functionality from "two views", that is, via VC-based interface from buffers with the current buffer/file being the default target of operation and from pcl-cvs' traditional UI. I'll see if I can get anything usable out of this idea. | I'm currently synching our (XEmacs) version | with Greg Woods' pcl-cvs 2.0b2 and adding several features. This will I hope your additions are usable also with Emacs. | Eventually I hope to get it working on NT too, though I do not | actually use NT so I'll need some help there. I may be able to do testing at least. Assuming that I re-install NT -- I swore I never touch NT again, but I guess I have to, if not for other reasons, then simply to be able to maintain and test my emacs configuration's NT support which some people depend on :) //Hannu

1 participants
0 comments

Re: Text properties slow down XEmacs 27 years

Hrvoje Niksic

Simon Marshall <simon(a)gnu.org> writes: > If you paste text from a C mode buffer into a Text mode buffer it > should not take its highlighting with it. This is already the case in XEmacs; that's what the "non-duplicable" properties are for. > But I don't know why font-lock.el uses text properties. Perhaps it > is just because they were (and still are) much easier to use than > overlays/extents for the purposes of font-lock.el. Maybe. One of these days, I'll probably be bored enough to try it otherwise... -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Suburbia is where the developer bulldozes out the trees, then names the streets after them. -- Bill Vaughn

1 participants
0 comments

Re: [Richard Stallman <rms@santafe.edu>] Re: [kinoue@ic.rdc.ricoh.co.jp: widget-choose] 27 years

Hrvoje Niksic

We already have something like this; look at wid-edit.el:216. I took 10 items to be the max size for single-character prompt, because there are as many digits. I don't see a reason to make this customizable. If you want to turn off the whole feature, just set widget-menu-minibuffer-flag to t. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- You have an unusual magnetic personality. Don't walk too close to metal objects which are not fastened down.

1 participants
0 comments

Re: Text properties slow down XEmacs 27 years

Simon Marshall

Hrvoje> Simon, you know things about font-lock. Perhaps you'd like to Hrvoje> comment on this? We're having a discussion about whether it Hrvoje> is better to use text properties or extents for font-locking. Hrvoje> (Text properties are much slower in XEmacs than they are in Hrvoje> GNU Emacs.) Sure. IMHO, for conceptual, reasons font-lock.el should use overlays/extents. Text properties are what the phrase says---they are intrinsic to the text and so should get saved with the text. In the case of font-lock.el, we just want to change how some "text" looks to make it easier to read---because the text has meaning that is not intrinsic to the text. (When the "text" is a C program, superficially it appears that font-lock.el is right to use text properties, but I think this is misleading because font-lock.el usually gets it right.) If you like, I think the highlighting is a property of the major-mode rather than the buffer text. If you paste text from a C mode buffer into a Text mode buffer it should not take its highlighting with it. But I don't know why font-lock.el uses text properties. Perhaps it is just because they were (and still are) much easier to use than overlays/extents for the purposes of font-lock.el. I don't know why XEmacs has non-duplicable text properties. Sounds like an oxymoron. Simon.

1 participants
0 comments

[Richard Stallman <rms@santafe.edu>] Re: [kinoue@ic.rdc.ricoh.co.jp: widget-choose] 27 years

William M. Perry

We should probably do a similar patch for the XEmacs version of custom... I don't have the latest source right now though... just a heads up. -Bill P.

1 participants
0 comments

Re: [Richard Stallman <rms@santafe.edu>] Re: [kinoue@ic.rdc.ricoh.co.jp: widget-choose] 27 years

Jan Vroonhof

>> Perhaps we should add some upper limit to the # of items in a >> menu before widget-menu-minibuffer-flag is ignored and we >> prompt in the minibuffer (via completing-read) regardless? > We should probably do a similar patch for the XEmacs version of custom... I > don't have the latest source right now though... just a heads up. XEmacs already has a hardcoded limit of 10. Jan

1 participants
0 comments

Re: fix for Motif >=2.0 27 years

Jan Vroonhof

Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes: > Sorry for the really dumb Changelog entry -- I have no idea what this > patch does, I'm only forwarding it :-( Just by reading though the manpages of the functions involved, It seems that Motif 2.x's resource code specifies unspecified pixmap not using NULL but using XmUNSPECIFIED_PIXMAP (!=NULL). The patches fixes the code that decides whether to request the pixmap to be be "in the graphics context". Somebody with real understanding should check whether all the ifs above need changing too (I suspect they do). Jan

1 participants
0 comments

Re: pcl-cvs synching issues 27 years

Greg Klanderman

>>>>> "Oscar" == Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes: Oscar> >>>>> "Greg" == Greg Klanderman <greg(a)alphatech.com> writes: Greg> Sorry about the mixup. Oscar's policy looks fine with me... just to Greg> clarify, it doesn't mean I should have made a branch, just set a Greg> "current" tag? Are tags (for pcl-cvs) of the form pcl-cvs-rX.YY Greg> appropriate? It seems you want the package name in there since XEmacs Greg> and all the packages are in the same repository. Or maybe not. Oscar> Oscar> I don't see the need for having the package name in the release tag names. It Oscar> looks somewhat redundant. Sharing a common tag name for different projects in Oscar> the same CVS repository is no problem as long as the projects are distinct and Oscar> are manipulated independently. ok Oscar> Besides note you can not use dots in tag names so the tag name for release 1.12 Oscar> should probably be something like `r1-12'. yup, that's what I meant.. g

1 participants
0 comments

2025

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 September 1998