June 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [PATCH] modeline-format docstring fix 26 years, 5 months

Kirill M. Katsnelson

Some time ago, SL Baur wrote... |+ | Kirill M Katsnelson <kkm(a)kis.ru> writes: | | > A question. %f expands to filename, or nothing if a buffer is not | > associated with a file. I want to be able to display buffer name | > as a fallback if there's no file. What is better: introduce a | > new construct for this, say %F, or modify %f? | | Probably a new letter would be better. Does FSFmacs work as you | describe? |- I do not have it installed, so do not know. Anyone? Kirill

1 participants
0 comments

Re: bogus binding of button3 in widget keymaps... 26 years, 5 months

William M. Perry

Andy Piper <andyp(a)parallax.co.uk> writes: > At 09:24 AM 6/14/98 -0500, William M. Perry wrote: > > I'm just now getting around to bitching about it because I finally have > >some time to hack on XEmacs and Emacs/W3 again. :) > > Great! I have *lots* of web pages that don't display correctly under > w3/mswindows. Well, I didn't say a _lot_ of time, but some. :) I need to get a XEmacs working under NT first. I'll be firing up my new 21" IBM Paperwhite display at work on monday, so will see if the NT drivers work reliably. If they do, I'll play around with getting XEmacs to build on the machine. Gotta love a monitor that will do 65,000 shades of gray ＠ 1600x1200 ＠ 80Hz, with .11 dot pitch. Ahhhhh. Can't wait. -Bill P.

1 participants
0 comments

Lisp source contributions. 26 years, 5 months

Rajesh Vaidheeswarran

Thanks to one and all for the clarification regarding the submission of lisp sources. Now that I know that you do accept GPL'd sources (mine is), I still would like to know how to submit. Do I mail to to a particular mailing list, or is there an ftp server where I can put it into an incoming directory, etc. Any help in this would be greatly appreciated. Thanks. rv

2 participants
1 comments

Re: column number starts at 1 or 0? 26 years, 5 months

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > Whatever we do, we have to be consistent. The user-visible and > lisp-visible column-numbering have to match. But understand that it is impossible to be consistent both with how lines are represented and how columns are represented in Lisp. > Since (current-column) can't change, column-number-mode and > what-cursor-position have to use 0-based column numbers as well (at > least by default). Yuck! No! > If you add in Stallmacs-compatibility, the decision is clear. I don't care about Stallmacs compatibility, but to me it seems much more sensible for column numbers to start at 1. > I feel strongly about this. Isn't our current behavior obviously > totally broken? It looks like a bug, so it is a bug. No, our current behaviour is definitely *not* totally broken. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Memory is like an orgasm. It's a lot better if you don't have to fake it." -- Seymour Cray, on virtual memory

5 participants
4 comments

Re: column number starts at 1 or 0? 26 years, 5 months

Hrvoje Niksic

"Mauro Condarelli" <MC5686(a)mclink.it> writes: > > >>>>> "Andy" == Andy Piper <andyp(a)parallax.co.uk> writes: > > > > Andy> I'm with Kyle on this. But then I'm a hacker and my brain is > > Andy> wired up to start at 0 rather than 1. > > > > What's the difference between a rookie programmer and an > > experienced one? > > > > A novice thinks that a megabyte is 1000 bytes; > > An expert thinks that a kilometer is 1024 meters. > Exactly. > Let the novice have the default. > Make it possible for the expert to change it. Yeah, but Kyle's argument was that other Emacs functions, like set-fill-column, don't support this notion. I cannot help but agree, so the feature must go away. Which is a shame. :-( -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- 4. Thou shalt not warlorde a sig if it bee the sig of Kibo, nor if it bee the sig of the Inner Circle.

1 participants
0 comments

Re: Toolbar and XEmacs 21.0-b43 26 years, 5 months

Oliver Graf

Andy Piper <andyp(a)parallax.co.uk> writes: > However, I am worried that you gnus and normal toolbars look different. > If you have not set modeline face or toolbar face then your toolbars should > look the same as the modeline, which should look the same as the default > face if none are set. In general you probably want to change gui-element > face rather than modeline or toolbar. I forgot the image... Regards, Oliver.

1 participants
0 comments

Re: Toolbar and XEmacs 21.0-b43 26 years, 5 months

Oliver Graf

Andy Piper <andyp(a)parallax.co.uk> writes: > xpm-color-symbols is read when an xpm image is instantiated and ignored > thereafter. You need to change the face attributes before the images get > instantiated. Are you saying that if you customize it and stop and start > emacs then this doesn't work? Just customizing will not automatically Restarting does not work with customize. I need to add the set-face call manually into .emacs. > change the colors on the fly - you need to change the icons or do something > that causes the colors to be reread. Changing visibility or captions also did not work. Only restarting after the thing was added to .emacs (not the custom!), or starting a thing that creates a new toolbar. > However, I am worried that you gnus and normal toolbars look different. > If you have not set modeline face or toolbar face then your toolbars should > look the same as the modeline, which should look the same as the default > face if none are set. In general you probably want to change gui-element > face rather than modeline or toolbar. Nope. Attached is a pic showing modeline and toolbar of an xemacs started WITH the custom: '(toolbar ((t (:background "gray80"))) t) in my .emacs, but without the set-face call. All toolbars after this one are OK with the custom set. Only the first is white in background... Regards, Oliver.

1 participants
0 comments

Re: bogus binding of button3 in widget keymaps... 26 years, 5 months

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Andy Piper <andyp(a)parallax.co.uk> writes: > > > At 11:16 PM 6/13/98 +0200, Hrvoje Niksic wrote: > > >wmperry(a)aventail.com (William M. Perry) writes: > > > > > >> Why not make button1 do what you want there? > > > > > >Context-sensitive menus have always been activated by button3, not > > >button1 or button2. Widgets like `State' look like a > > >context-sensitive menu to me. > > > > Was this change made recently. If so maybe its behind button3 menus in > > customize being broken? > > No! The "change" has been done in the 20.3 beta cycle. I'm just now getting around to bitching about it because I finally have some time to hack on XEmacs and Emacs/W3 again. :) -Bill P

2 participants
1 comments

Re: Toolbar and XEmacs 21.0-b43 26 years, 5 months

William M. Perry

Andy Piper <andyp(a)parallax.co.uk> writes: > At 07:13 AM 6/14/98 -0500, William M. Perry wrote: > > This is totally broken. You should not have to define a face to have > >XEmacs come up correctly. The _only_ thing I have in my personal > >Xresources is > > > >Emacs.Foreground: black > >emacs.Background: white > >Emacs.default.attributeBackground: white > >Emacs.modeline.attributeBackground: Gray75 > >Emacs*XlwScrollBar*knobStyle: dimple > >Emacs*XlwScrollBar*ShadowThickness: 1 > > > > And is all I have had in there for the past god knows how many years. > >And all of a sudden my toolbar buttons got hosed. We should _not_ be > >relying on something like the default background color to be the same as > >the toolbar color. > > So what color do you expect your toolbar buttons to be - I suspect gray80 > which is hardcoded into xpm-color-symbols. This has to change because the > color is (a) hardcoded (b) not the right color under mswindows. I expect them to be the same color as the toolbar, which by default is #ce72ce72ce72 on my box. Changing my default face or the face of the modeline should have no effect on them. > i) I am happy to set the toolbar face background to gray80 in the X domain, > but this is precisely the change that everyone has got so heated about over > the modeline. Why can't it just pick it up from the app defaults database like everything else, and the appropriate thing under windows? We should be able to fallback to whatever the 'color theme' for toolbars is under windows. > > Why exactly couldn't the color be set under windows? > > Because there are no X resources and setting xpm-color-symbols directly > is wrong. I think we should find another way. Face settings come too late to affect the toolbar very well. -Bill P.

2 participants
1 comments

Release schedule for 21.0 26 years, 5 months

SL Baur

XEmacs 21.0-beta43 "Spanish" (hastily renamed today) will be the final 21.0 beta. It will be released tonight, probably within an hour or two. I'm not very close to emptying the incoming patch queue, and I haven't even started on Lisp package changes so don't panic if you don't see one or some of your patches in this beta. I intend to make a release on schedule on Saturday (~24 hours from this writing). This will be called 21.0-pre1 "Swedish Landrace". There will be other 21.0-pre releases made as show stopping bugs are found. I'm looking for a quiet ~2 week testing period before settling on the version we will release. The more testing we do now, the better off we are in the long term. This is do or die time for MS Windows testers. Please bang on things as hard as you can. We know everything isn't perfect, but it is important that there aren't any easy crashes left. The first XEmacs I released was 20.0, and it advertised Mule and Canna support for the first time. It was trivially easy to make this drop core (enter Canna fence mode and hit Delete). I do not want the same kind of oversight in the newest feature of 21.0 which is the non-Unix support. And yes, running on MS Windows '98 is something desirable and needs to be tested. I'm well-aware of the main short-comings in packages and those too have to be fixed prior to release. I seriously doubt we'll get the documentation issues completed by the end of the month so there's still time to get the worst of the bugs fixed.

3 participants
2 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 June 1998