October 1998 - XEmacs-Beta - XEmacs Mailing List Archives

cvs-mode-add-changelog.. broken pcl-cvs-1.37 26 years, 1 month

Neal D. Becker

'A' in cvs mode (cvs-mode-add-changelog...) is broken. Here is what you get: ----- 1998-10-29 <nbecker(a)fred.net> * ------ The name of the file is missing.

1 participants
0 comments

Re: bug? 26 years, 1 month

Jan Vroonhof

Georg Nikodym <georgn(a)canada.sun.com> writes: > Thanks for the excellent advice, but my font-menu-this-frame-only-p is > set to t (through no deliberate act of my own) and I still see the > weirdness. Here it works. Note that when font-menu-this-frame-only-p is t the code is exactly the same as the old font menu the new custom related code is only invoked when font-menu-this-frame-only-p is nil. Funny that font-menu-this-frame-only-p is t for you. It defaults to nil. > Now, I hazard to point out that changing the _font_ appears to work > but _size_ changes appear to be global... > > Hmmm, not that simple either. Changing _font_ in this VM compose > frame to Bembo worked. Changing size to 14 resulted in this frame > changing OK, my "main" frame's "Help" buffer to change to bembo at > size 14 and my VM frame to entirely to bembo 14. Can you reproduce this with xemacs -vanilla and just scratch buffers? Secondly. You are running with the latest version of x-font-menu.el ? In particular one that has this snippet ;; If we need to be frame local we do the changes ourselves. (if font-menu-this-frame-only-p ;;; WMP - we need to honor font-menu-this-frame-only-p here! (set-face-font 'default new-default-face-font (and font-menu-this-frame-only-p (selected-frame))) ;; OK Let Customize do it. (when (and family (not (equal family from-family))) (setq new-props (append (list :family family) new-props))) Without this change I can understand the behaviour but if you are really running the latest I am at a loss. Jan

2 participants
1 comments

Re: [patch] automatic loading of package-get-base 26 years, 1 month

Greg Klanderman

Adrian, I don't recall you having problems with my patches in the past, and this one certainly came thru fine back to me. I'll try it as a mime enclosure in a few formats below, let me know what works better for you.

1 participants
0 comments

Re: a new user 26 years, 1 month

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > > [this is incompatible with Emacs, and there is no hope to > > > persuade RMS to do this, and it is "a sudden change of > > > behaviour" etc. so I would be surprised is there were even a > > > single person supporting this :-] > > > > This sounds like a good idea to me, for one. Yes, it's a new thing, > > but it only affects the users who set debug-ignored-errors. > > And the change is quite minimal too. I like it. Also, `debug-on-error' already accepts "magical" values other than t/nil, so we already have a precedence. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}

1 participants
0 comments

Re: [patch] automatic loading of package-get-base 26 years, 1 month

Adrian Aichner

Hello Greg, I believe I reported this in the past: There seems to be breakage in your patch (others please comment). Look for "Greg> \"" below. These lines are continuations of folded lines. I don't know where along the way (Greg's MUA, xemacs-beta, Adrian's MUA) this happened but I can definitely not apply this patch. Regards, Adrian >>>>> "Greg" == Greg Klanderman <greg(a)alphatech.com> writes: Greg> + ("sunsite.cnlab-switch.ch" "sunsite.cnlab-switch.ch" Greg> "mirror/xemacs/packages") Greg> + ("tu-darmstadt.de" "ftp.tu-darmstadt.de" Greg> "pub/editors/xemacs/packages") Greg> + ("sunsite.auc.dk" "sunsite.auc.dk" "pub/emacs/xemacs/packages") Greg> + ("pasteur.fr" "ftp.pasteur.fr" "pub/computing/xemacs/packages") Greg> + ("cenatls.cena.dgac.fr" "ftp.cenatls.cena.dgac.fr" Greg> "pub/Emacs/xemacs/packages") Greg> + ("kfki.hu" "ftp.kfki.hu" "pub/packages/xemacs/packages") Greg> + ("uniroma2.it" "ftp.uniroma2.it" "unix/misc/dist/XEMACS/packages") Greg> + ("icm.edu.pl" "ftp.icm.edu.pl" "pub/unix/editors/xemacs/packages") Greg> + ("sunet.se" "ftp.sunet.se" "pub/gnu/xemacs/packages") Greg> + ("doc.ic.ac.uk" "ftp.doc.ic.ac.uk" "packages/xemacs/packages") Greg> + ("srcc.msu.su" "ftp1.srcc.msu.su" "mirror/ftp.xemacs.org/packages") Greg> + Greg> + ;; Asia Greg> + ("usyd.edu.au" "ftp.usyd.edu.au" "pub/Xemacs/packages") Greg> + ("netlab.is.tsukuba.ac.jp" "ftp.netlab.is.tsukuba.ac.jp" Greg> "pub/GNU/xemacs/packages") Greg> + ("jaist.ac.jp" "ftp.jaist.ac.jp" "pub/GNU/xemacs/packages") Greg> + ("ring.aist.go.jp" "ring.aist.go.jp" "pub/text/xemacs/packages") Greg> + ("ring.asahi-net.or.jp" "ring.asahi-net.or.jp" Greg> "pub/text/xemacs/packages") Greg> + ("SunSITE.sut.ac.jp" "SunSITE.sut.ac.jp" Greg> "pub/archives/packages/xemacs/packages") Greg> + ("dti.ad.jp" "ftp.dti.ad.jp" "pub/unix/editor/xemacs/packages") Greg> + ("kreonet.re.kr" "ftp.kreonet.re.kr" Greg> "pub/tools/emacs/xemacs/packages") Greg> + ) Greg> + "*List of remote sites available for downloading packages. Greg> +List format is '(site-description site-name directory-on-site). Greg> +SITE-DESCRIPTION is a textual description of the site. SITE-NAME Greg> +is the internet address of the download site. DIRECTORY-ON-SITE Greg> +is the directory on the site in which packages may be found. Greg> +This variable is used to initialize `package-get-remote', the Greg> +variable actually used to specify package download sites." Greg> + :tag "Package download sites" Greg> + :type '(repeat (list string string)) Greg> + :group 'package-get) Greg> +

1 participants
0 comments

Re: a new user 26 years, 1 month

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > > [this is incompatible with Emacs, and there is no hope to persuade RMS > > to do this, and it is "a sudden change of behaviour" etc. so I would be > > surprised is there were even a single person supporting this :-] > > This sounds like a good idea to me, for one. Yes, it's a new thing, > but it only affects the users who set debug-ignored-errors. And the change is quite minimal too. I like it. Jan

1 participants
0 comments

Re: a new user 26 years, 1 month

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > If it's any consolation, packages are easy to install right not, > without the fancy interface. All the user really needs to know is > what to download and where to unpack the tar file. Just this is a > big impovement over what we had before. Keep this in mind as we > start applying the lash to ourselves again. FWIW, I agree with what Kyle just said. I've been a happy user of all the packages for quite a few months, without knowing anything at all about them (except for --package-path switch to configure). This is a Good Sign. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- - When I die, shall I not be like Enkidu? - Like, no, man, you'll be, like, totally dead.

1 participants
0 comments

Re: a new user 26 years, 1 month

Hrvoje Niksic

Sam Steingold <sds(a)goems.com> writes: > What about making debug-on-error=T ignore debug-ignored-errors, while > debug-on-error=anything_but_T_or_NIL respect it? > [this is incompatible with Emacs, and there is no hope to persuade RMS > to do this, and it is "a sudden change of behaviour" etc. so I would be > surprised is there were even a single person supporting this :-] This sounds like a good idea to me, for one. Yes, it's a new thing, but it only affects the users who set debug-ignored-errors. Are you sure it's impossible to persuade Stallman of this? Not that it's a crucial point for adding the feature to XEmacs, but it's nicer to have both Emacsen do the same than not. Jan, Steve, what do you think? -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Don't hit a man when he's down -- kick him; it's easier.

1 participants
0 comments

gnuclient -nw and the minibuffer on 2 xterms 26 years, 1 month

David Wang

Hi, I'm currently running xemacs-21.0-b57 and I've noticed that if I use "gnuclient -nw" to create 2 new frames on 2 seperate xterms, the output of the minibuffer and echo area are displayed on both frames. Is there a way to have the output of the minibuffer and echo area only display on the current tty frame that I'm on like in a gnuclient frame under X? Thanks, Dave -- David H. Wang (408) 525-2720

2 participants
1 comments

Custom vs. specifier terminology in lisp/faces.el 26 years, 1 month

Stephen J. Turnbull

I'm currently looking at the relationship of Custom to Mule, primarily with respect to fonts. [Aside to Kyle: I'll keep working on this but I no longer think I'll have code to fix the custom-set-faces bug any time soon. For 21.0, the redefinition of reset-faces looks like the way to go.] Many of the face functions associated with Custom (some of which have leaked into other libraries, such as lisp/faces.el) use terminology different from that documented in Info | Lispref | Specifiers. For example, some functions (eg `face-spec-set') specialize the specifier concept of "locale" to "frame" (in the sense that the argument which represents the specifier's locale is called "frame"; I don't think the semantics are altered at all). In other cases the representation of objects is changed. Eg, specifiers characterize the display with a tag-set [simple list] like `(x color)' while Custom uses alists like `((type x) (class color))'. This use of two different interfaces in lisp/faces.el is quite disconcerting. The functions defined below the comment "used to be in cus-face.el but logically belong [in faces.el]" use a different (but not obviously so and only indirectly documented) interface from the rest of faces.el. It was very tempting to think that the DISPLAY argument was just an alias for TAG-SET, but that's not so. (1) Why does Custom do this with faces? For FSF compatibility? Or is there a technical reason to do it for XEmacs too? The kind of manipulation that Custom does with ordinary properties mostly defeats the purpose of using specifiers, as far as I can see anyway. In particular, this is going to make properly fixing the "custom-set-faces nukes all of Mule's fonts and makes my XEmacs blanch" bug quite complicated---and probably most of it will happen outside the specifier functionality by manipulating those extra properties. Extending Custom faces to handle customizing Mule fonts is going to be even worse, I'm afraid. But specifiers are capable of handling all these problems smoothly, simply by leaving them to work by themselves. Or aren't they? (2) Can the interface of a function like `faces-spec-set' in lisp/faces.el be changed? (It's one of the ones moved from cus-face.el.) I would like it to use the specifier interface (some combination of FACE LOCALE TAG-SET EXACT-P HOW-TO-ADD) but I suspect that that would cause problems in Custom. Would it be a problem to add a (partially redundant) &optional tag-set argument? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Telfax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."

2 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 October 1998