September 1999 - XEmacs-Beta - XEmacs Mailing List Archives

patch to pcl-cvs-2.9.7 to avoid needing easy-mmode on XEmacs 24 years, 6 months

Charles G Waldman

I would like to sync the version of the pcl-cvs package bundled with XEmacs with Stefan Monnier's latest 2.9.7 version. One minor obstacle is that the newer versions of pcl-cvs.el use the function `easy-mmode-define-minor-mode' to define the cvs-minor-mode. Now, this function does not exist in XEmacs. The Pcl-CVS FAQ suggests using the version of "easy-mmode.el" which comes with Emacs, but there are several reasons why the XEmacs maintainers would prefer not having to drag this file into the XEmacs "pcl-cvs" package. Attached is a patch which uses the XEmacs `add-minor-mode' function to set up the minor mode when in Emacs, and uses `easy-mmode-define-minor-mode' otherwise. Pending some feedback on this patch, I will make pcl-2.9.7 into an XEmacs package, compatible with the new XEmacs package system. pcl-cvs-2.9.7 can be gotten from ftp://rum.cs.yale.edu/pub/monnier/pcl-cvs you also need to get the "diff-mode.el" which has been split out from pcl-cvs. I would like any feedback from anybody who tries using this package with XEmacs version 21. --- pcl-cvs-2.9.7/pcl-cvs.el 1999/09/30 14:39:07 1.1 +++ pcl-cvs-2.9.7/pcl-cvs.el 1999/09/30 16:35:59 ＠＠ -275,15 +275,38 ＠＠ ;;;; -(easy-mmode-define-minor-mode - cvs-minor-mode - " +;;; XEmacs change +(if (null (boundp 'running-xemacs)) + (defvar running-xemacs (string-match "XEmacs\\|Lucid" emacs-version))) + +(if running-xemacs + (progn + (defvar cvs-minor-mode nil + "Non-nil when cvs mode is active.") + (defun cvs-minor-mode (arg) + "Toggle cvs-minor-mode. +With ARG, turn cvs-minor-mode on if arg is positive, off otherwise. This mode is used for buffers related to a main *cvs* buffer. All the `cvs-mode' buffer operations are simply rebound under the \\[cvs-mode-map] prefix. " - nil " CVS") -(put 'cvs-minor-mode 'permanent-local t) + (interactive "P") + (make-local-variable 'cvs-minor-mode) + (setq cvs-minor-mode + (if (null arg) + (not cvs-minor-mode) + (> (prefix-numeric-value arg) 0))) + (redraw-modeline) + (add-minor-mode 'cvs-minor-mode "CVS"))) + + (easy-mmode-define-minor-mode + cvs-minor-mode + "This mode is used for buffers related to a main *cvs* buffer. +All the `cvs-mode' buffer operations are simply rebound under +the \\[cvs-mode-map] prefix. +" + nil " CVS") + (put 'cvs-minor-mode 'permanent-local t)) (defvar cvs-temp-buffers nil)

1 participants
0 comments

Re: [gnu.emacs.sources] coffee.el --- Sumbit a BREW request to an RFC2324-compliant coffee device 24 years, 6 months

Eric Marsden

>>>>> "dv" == Didier Verna <verna(a)inf.enst.fr> writes: dv> Is it `sweetner' or `sweetener' that we should say ? ecm> sweetener. dv> So there's a coffee bug. Actually, there's a coffee bug in either dv> case :-) yes, someone already pointed that out, and given the inestimable importance of coffee.el I immediately uploaded a corrected version to my web page. -- Warning: This article may be fatal if swallowed.

1 participants
0 comments

Re: [gnu.emacs.sources] coffee.el --- Sumbit a BREW request to an RFC2324-compliant coffee device 24 years, 6 months

Didier Verna

Eric Marsden <emarsden(a)mail.dotcom.fr> wrote: > >>>>> "dv" == Didier Verna <verna(a)inf.enst.fr> writes: > > ecm> You can probably guess how this came about ...yadda yadda... do > ecm> everything but make coffee ...yadda yadda... > > dv> Is it `sweetner' or `sweetener' that we should say ? > > sweetener. So there's a coffee bug. Actually, there's a coffee bug in either case :-) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: [gnu.emacs.sources] coffee.el --- Sumbit a BREW request to an RFC2324-compliant coffee device 24 years, 6 months

Eric Marsden

>>>>> "dv" == Didier Verna <verna(a)inf.enst.fr> writes: ecm> You can probably guess how this came about ...yadda yadda... do ecm> everything but make coffee ...yadda yadda... dv> Is it `sweetner' or `sweetener' that we should say ? sweetener. -- Eric Marsden It's elephants all the way down

1 participants
0 comments

Re: [gnu.emacs.sources] coffee.el --- Sumbit a BREW request to an RFC2324-compliant coffee device 24 years, 6 months

Didier Verna

nbecker(a)fred.net wrote: > From: Eric Marsden <emarsden(a)mail.dotcom.fr> > Subject: coffee.el --- Sumbit a BREW request to an RFC2324-compliant coffee device > Newsgroups: gnu.emacs.sources > Date: 29 Sep 1999 18:08:59 +0200 > X-Sent: 15 hours, 57 minutes, 36 seconds ago > Organization: LAAS-CNRS http://www.laas.fr/ > > You can probably guess how this came about ...yadda yadda... do > everything but make coffee ...yadda yadda... Is it `sweetner' or `sweetener' that we should say ? -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: And now, for an exploding XEmacs 24 years, 6 months

Jan Vroonhof

Olivier Galibert <galibert(a)pobox.com> writes: > No SYMVAL_UNBOUND_MARKER, the code takes the default branch, abort();. > > This is exactly what currently happens with the portable dumper. > > The solution may be to add the case and put a sym->value = newval in > it, but I'm far from understanding the code enough to be sure. Huh? The code seemed to survive pretty well. [Putting brain in Gear] AHA! This was done with 21.1 and there symbols.c has case SYMVAL_UNBOUND_MARKER: break; This is commented out in 21.2. Presumably this was part of Martin's mega patch.. Maybe he can explain why he removed it. Jan

1 participants
0 comments

Re: And now, for an exploding XEmacs 24 years, 6 months

Jan Vroonhof

Olivier Galibert <galibert(a)pobox.com> writes: > Now the portable dumper dumps the data, and when restarting loads the > The next step is having it go through init_console_stream. The > problem is, I don't understand yet what should and shouldn't be done. > The situation is a bit weird, with initialize=1, all dumped variables > available, but with Vterminal_{console,device,frame} not dumped. For > now it breaks on Fset('device, device *) with 'device unbounded. > > Any help or hints about how it should work welcome. Are you sure this isn't simply a problem with the new dumping code? If I force an ordinary dumped XEmacs into the same code path (by using a debugger to force it into the Fmake_device branch of init_console_stream, then everything seems to work OK. It is simply setting the value of the 'device' symbol with that variable previous value being a symbol_forward of type SYMVAL_UNBOUND_MARKER. Are you sure you are dumping variables like that correctly? Breakpoint 1, Fset (sym=-1607917740, newval=539754752) at /scratch/vroonhof/cvs/xemacs-20/src/symbols.c:1610 1610 CHECK_SYMBOL (sym); (gdb) pobj sym $19 = (struct Lisp_Symbol *) 0x291f54 $20 = {next = 0x0, name = 0x1a4db0, value = 539232016, function = 539232016, plist = -1608015868, obarray_flags = 7} Symbol name: device (gdb) step 1613 valcontents = XSYMBOL (sym)->value; (gdb) next 1614 if (NILP (sym) || EQ (sym, Qt) || SYMBOL_VALUE_MAGIC_P (valcontents) (gdb) next 1628 switch (XSYMBOL_VALUE_MAGIC_TYPE (valcontents)) (gdb) pobj valcontents $21 = (struct symbol_value_forward *) 0x240710 $22 = {magic = {lcheader = {lheader = {implementation = 0x17cc30}, next = 0x0, uid = 69, free = 0}, type = SYMVAL_UNBOUND_MARKER}, magicfun = 0x16c80c <lrecord_subr>} (gdb) step

2 participants
1 comments

[gnu.emacs.sources] coffee.el --- Sumbit a BREW request to an RFC2324-compliant coffee device 24 years, 6 months

Neal D. Becker

1 participants
0 comments

Exploding++ 24 years, 6 months

Olivier Galibert

Here is the new version taking into account Jan's tests[1]. I think I'm going to apply it soon since it shouldn't change a thing when you configure without --pdump. OG. [1] Thank you thank you thank you :-)

1 participants
0 comments

Re: XEmacs' desktop icon greyed out in 21.2 24 years, 6 months

ALTMARK＠de.ibm.com

I have to admit that I didn't know that ... :-o As GXT255P is withdrawn from support, the next machines we'll get will have the GXT2000 installed. I'll try to get hold of such a box and see if the problem persists (also hoping that the new adapter has the same "missing feature" ;-) ). Meanwhile I'll try to build 21.2-b19 totatlly from scratch, maybe something went wrong when applying patches. The last tarballs I downloaded were b15. --- Markus Alt IBM Laboratory Boeblingen, Germany Valdis.Kletnieks(a)vt.edu on 09/29/99 05:32:15 PM Please respond to Valdis.Kletnieks(a)vt.edu To: Markus Alt/Germany/IBM＠IBMDE cc: xemacs-beta(a)xemacs.org Subject: Re: XEmacs' desktop icon greyed out in 21.2 On Wed, 29 Sep 1999 16:34:38 +0200, ALTMARK(a)de.ibm.com said: > I'm sitting on a 7043 Model 43P-150 with a GXT255P graphics adapter installed. > As this card has 24-bit true color depth and allows to display 16.7 million > colors *simultaneously*, I can't imagine this should be a problem. As a matter > of fact, it doesn't make a difference if I change from "more colors for > applications" (which is my default) to "more colors for desktop". Oh.. You *did* know that the GXT255P is known to be brain-dead with colormap management, didn't you? ;) Even if you fix your XServers file to start it with a 24-bit TrueColor visual as the default, some applications Lose Big Time on it. I believe if you poke around the support center databases, there's a Q&A you can find if you search for 'colormap', 'GXT255P' and 'netscape'. I know for a fact that Tk/Tcl (and particularly 'exmh') tickles the bug too, but I've never received a totally clear explanation of what the card/driver does wrong. /Valdis (who hopes like hell the GXT2000 isn't similarly borked) ;)

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