February 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Nifty icons for XEmacs? 25 years, 9 months

SL Baur

Jonathan B Leffert <jonathan(a)leffert.net> writes in xemacs-beta(a)xemacs.org: > ==> Jan Vroonhof writes: Jan> I think jonathan gave his OK for us to distribute the icons Jan> (under the GPL) of course. I cannot find his e-mail at the Jan> moment though, so let's ask him again to be sure. Jan> Jonathan? > I originally took the icons from screenshots of the OmniGroup's > OmniWeb: a NeXTSTEP web browser. I reduced the icons in size, put > them over transparent backgrounds, converted them to xpm format, and > placed them into the XEmacs toolbar. As to the issue of distributing > the icons, I have no problem with it as long as they are distributed > under the GPL as you have indicated. Yes. We (the XEmacs developers) cannot and will not change the copyright and if the icons are GPL'ed we can distribute them. > The only issue is the rights of the OmniGroup. But since I put this > package together, I believe OmniWeb has gone opensource. So, the > long and the short of it is that I have no problem with it, but the > OmniGroup might. This is a problem. We need permission from them it would seem.

1 participants
0 comments

Re: xemacs.org needs a slave DNS server 25 years, 9 months

SL Baur

My thanks to everyone who offered Slave/Secondary name services. We're all set now and very widely dispersed so hopefully Black Monday will be the last time we have xemacs.org DNS go down. SL Baur <steve(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > Is there anyone who can provide slave DNS services for xemacs.org? If > you can, please get in contact with me off-list. Thanks.

1 participants
0 comments

Re: --no-split and XEmacs mode 25 years, 9 months

Akim Demaille

>>>>> "rms" == Richard Stallman <rms(a)gnu.org> writes: rms> You wrote this to me: Richard> This illustrates a general point: if you test things in Richard> XEmacs, and rms> Actually, I wrote that to Demaille. You can call me Akim ;) rms> I wanted to ask him to work with me, just as he works with your rms> group. Actually, I did mean to help Emacs development here since I sent a copy of the mail to the maintainer of the file info.el: Dave Gillespie <daveg(a)synaptics.com>. Because I saw further in the file that the XEmacs version is not sync'd with the FSF version, I also sent it to xemacs-beta. Because I was not sure the problem was not from makeinfo, I also told Karl. I truly don't know whether such `bug reports' should be sent to bug-emacs, or to the maintainer of the file. I thought the latter was the more appropriate, and I'm sorry if I gave the impression I was trying to help more one of the Emacsen as *it is not my intention*. Akim -- P-mail: Akim Demaille, 107 rue Bobillot, F-75013 Paris, France E-mail: demaille(a)inf.enst.fr V-mail: +33 1 45 81 78 81

2 participants
1 comments

Re: --no-split and XEmacs mode 25 years, 9 months

Didier Verna

Richard Stallman writes: Richard> Actually, I wrote that to Demaille. I wanted to ask him to work with Richard> me, just as he works with your group. I did not know that you were Richard> one of the XEmacs maintainers--I didn't know why you were in the cc Richard> list of the message I received--and I'm sorry I gave you the wrong Richard> impression by cc'ing my message to you. Here are the headers of the message you sent. This explains why I felt that you were talking to me, and not to Akim: ,---- | From: Richard Stallman <rms(a)gnu.org> | To: verna(a)inf.enst.fr | CC: demaille(a)inf.enst.fr, bug-texinfo(a)gnu.org, daveg(a)synaptics.com | In-reply-to: <qyju2wr793l.fsf(a)metheny.enst.fr> (message from Didier Verna on | 12 Feb 1999 19:47:10 +0100) | Subject: Re: --no-split and XEmacs mode `----- -- / / _ _ 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

2 participants
1 comments

Re: Nifty icons for XEmacs? 25 years, 9 months

Jonathan B. Leffert

-----BEGIN PGP SIGNED MESSAGE----- ==> Jan Vroonhof writes: Jan> I think jonathan gave his OK for us to distribute the icons Jan> (under the GPL) of course. I cannot find his e-mail at the Jan> moment though, so let's ask him again to be sure. Jan> Jonathan? I originally took the icons from screenshots of the OmniGroup's OmniWeb: a NeXTSTEP web browser. I reduced the icons in size, put them over transparent backgrounds, converted them to xpm format, and placed them into the XEmacs toolbar. As to the issue of distributing the icons, I have no problem with it as long as they are distributed under the GPL as you have indicated. The only issue is the rights of the OmniGroup. But since I put this package together, I believe OmniWeb has gone opensource. So, the long and the short of it is that I have no problem with it, but the OmniGroup might. Jonathan - -- Jonathan B. Leffert <jonathan(a)leffert.net> <jonathan(a)cs.uchicago.edu> "I resigned because I have come to the conclusion that my time would be better spent studying Greek, drinking beer, and trying to prevent this school from becoming a clone of Northwestern." -- Ben Tievsky -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNsiMmptsxuuDQth5AQEO3gQAiakTTlxrZVjWs2rYCfZsYxB3huqCe0xu skhRkzomQ7R1zVCkj9GEK777ZaZuH1M0PCS+N8hPwTnM3pu5HshVk8ZU6sVXscwZ /P3LsilyBxDCHEU77xs6YSp8aTCfLPfXI4uM25G7xPFwHgX6PwZjno1QqV+0CMP1 UwJKQLHkXNs= =dfK0 -----END PGP SIGNATURE-----

1 participants
0 comments

[Patch] xemacs-21.2b10 browse-url with kfm 25 years, 9 months

Neal D. Becker

Patch to xemacs-21.2b10 to browse urls with kfm: Index: menubar-items.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/menubar-items.el,v retrieving revision 1.6.2.4 diff -c -r1.6.2.4 menubar-items.el *** menubar-items.el 1998/11/26 11:38:34 1.6.2.4 --- menubar-items.el 1999/02/16 03:06:34 *************** *** 812,817 **** --- 812,825 ---- (eq browse-url-browser-function 'browse-url-grail)) :active (and (boundp 'browse-url-browser-function) (fboundp 'browse-url-grail))] + ["Kfm" + (customize-set-variable 'browse-url-browser-function + 'browse-url-kfm) + :style radio + :selected (and (boundp 'browse-url-browser-function) + (eq browse-url-browser-function 'browse-url-kfm)) + :active (and (boundp 'browse-url-browser-function) + (fboundp 'browse-url-kfm))] ) "-----" ["Edit Faces..." (customize-face nil)] *** browse-url.el 1999/02/15 18:59:56 1.1 --- browse-url.el 1999/02/15 19:02:30 *************** *** 48,53 **** --- 48,54 ---- ;; browse-url-iximosaic IXI Mosaic ? ;; browse-url-lynx-* Lynx 0 ;; browse-url-grail Grail 0.3b1 + ;; browse-url-kfm kde ;; Note that versions of Netscape before 1.1b1 did not have remote ;; control. <URL:http://www.netscape.com/newsref/std/x-remote.html> *************** *** 341,346 **** --- 342,350 ---- ;; b-u-file-url encodes fewer chars. Multi-display support for ;; Netscape. Thanks Richard Mlynarik <mly(a)adoc.xerox.com> + ;; 0.39 15 Feb 1999 + ;; Add kfm <nbecker(a)fred.net> + ;;; Code: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; *************** *** 384,389 **** --- 388,394 ---- (function-item browse-url-lynx-xterm) (function-item browse-url-lynx-emacs) (function-item browse-url-grail) + (function-item browse-url-kfm) (function :tag "Other" nil)) :group 'browse-url) *************** *** 869,874 **** --- 874,888 ---- ((fboundp 'terminal-emulator) (terminal-emulator "*browse-url*" "lynx" (list url))) (t (error "No terminal emulation in this XEmacs"))))) + + ;;;###autoload + (defun browse-url-kfm (url &optional new-window) + ;; new-window ignored + "Ask the kfm WWW browser to load URL. + Default to the URL around or before point." + (interactive (browse-url-interactive-arg "kfm URL: ")) + (message "Sending URL to kfm...") + (start-process "kfmclient" nil "kfmclient" "openURL" url)) (provide 'browse-url)

1 participants
0 comments

Re: [21.0.63] Bad interaction b/w customize and .Xdefaults 25 years, 9 months

Paul Stodghill

> So what should have happened (under X) was: > > - reset face is called > - x-init-global-faces is called. This basically resets the 'default > face to the compiled in values. > - customize calls 'face-display-set', but as none of the display specs > matches the (type mswindows) the default font the 'default face is > is not modified. ^--- This is where things don't go as expected: I'm running under CYGWIN, so the mswindows _does_ match. However, I'm starting XEmacs from under X, so I'd like the X resources to take precedence for frames being displayed under X. Is this clear, or should I try again? > - init-face-from-resources is called. As the the default face has not > been modified the X resources should be used. And in my case, it has been modified, so I guess it's not getting set back to the X resource values. > Could you find out why that does not work for you? > > Jan

1 participants
0 comments

apel with file-coding 25 years, 9 months

Andy Piper

I supplied a patch to the apel package a while back which fixes file coding problems under mswindows without mule, but it doesn't seem to have been applied. Here it is again. emu-x21.el is a new file and needs to be added to the repository. andy 1999-02-15 Andy Piper <andy(a)xemacs.org> * emu.el: load emu-x21 if running with file-coding and not mule * emu-x21.el: new file

1 participants
0 comments

Re: [21.0.63] Bad interaction b/w customize and .Xdefaults 25 years, 9 months

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > I thought Jan fixed this particular problem by recording the > initialized state in Custom, then re-setting it after clearing it. I > get a flash on startup in 21.0.63 due to the init code setting my > 'default face, Custom clearing it, and then setting it back to my > preferences. Do you have the most recent cus*.el and are they > compiled to elc? The code he cites is the most current. In particular the save-state-on-first-call trick is not used. Instead the combination reset-face, init-global-faces is used to reproduce the startup the defaults. That is cleaner and seemed (at the time) to work for everyone. However this is already the second bug report where people really wanted the resource settings and custom to mix. Somebody (not me) needs to decide what we actually want customize to do. Moreover somebody with FSF 20.3 needs to test how customize and X resources relate there. Jan

1 participants
0 comments

Re: [21.0.63] Bad interaction b/w customize and .Xdefaults 25 years, 9 months

Jan Vroonhof

Paul Stodghill <stodghil(a)cs.cornell.edu> writes: > Suppose that you use .Xdefaults to setup the 'default face when you are > > But suppose that you use customize to set up 'default when you are running > under mswindows, Then you lose. Partly by design unfortunately. You can not mix resources and customize (for now). > (custom-set-faces > '(default ((((type mswindows) (class color)) > (:foreground "white" :background "black"))) t) > ...) However: One could argue that in this case customize is being to zealous as... > faces.el contains the following code around line 1210 or so... > > (let ((frames (relevant-custom-frames))) none of the 'frames' will later match any of the settings and thus no settings will be applied. > Is it that x-init-global-faces is called in face-spec-set? Yes, but that is intentional. > It wasn't in 20.4, > and everything seemed to work fine. Note the "seemed". There were just other failure modes. > Is it that x-init-global-faces doesn't call x-init-face-from-resources to try > to setup 'default? No it shouldn't. Note that face-spec-set does call init-face-from-resources later. So what should have happened (under X) was: - reset face is called - x-init-global-faces is called. This basically resets the 'default face to the compiled in values. - customize calls 'face-display-set', but as none of the display specs matches the (type mswindows) the default font the 'default face is is not modified. - init-face-from-resources is called. As the the default face has not been modified the X resources should be used. Could you find out why that does not work for you? 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 February 1999