November 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Patch queue status 23 years, 5 months

Adrian Aichner

>>>>> "SY" == Steve Youngs <youngs(a)xemacs.org> writes: SY> * "APA" == Adrian Aichner <adrian(a)xemacs.org> writes: APA> What packaging route should we take regarding APA> ps-print-nomule APA> vs. APA> ps-print-mule APA> vs. APA> ps-print SY> How about... SY> - rename the package ps-print-nomule to ps-print SY> - ps-print.el is turned into a wrapper kind of thing: SY> (if (featurep 'mule) SY> (require 'ps-print-mule) SY> (require 'ps-print-nomule)) SY> - ps-print-mule.el becomes the Mule equiv of the old SY> ps-print.el SY> - ps-print-nomule.el becomes the non-Mule equiv of old SY> ps-print.el SY> Just a thought, what do you think? Emacs-20.7 has this: d:\tmp\emacs-20.7\lisp: total 212 drwxrwxrwx 2 AichnerAd 5 0 Nov 14 12:27 . drwxrwxrwx 2 AichnerAd 5 0 Nov 14 12:27 .. -r--r--r-- 1 AichnerAd 5 16189 Mar 10 1999 ps-bdf.el -r--r--r-- 1 AichnerAd 5 42569 Nov 20 1999 ps-mule.el -r--r--r-- 1 AichnerAd 5 154333 Jun 15 1999 ps-print.el where ps-print.el requires ps-mule.el. ps-mule.el uses autoloaded functions from ps-bdf.el (no require 'ps-bdf). I have merged our ps-print.el with http://www.xemacs.org/list-archives/xemacs-patches/199912/msg00158.html and am in the process of testing. My view: Ideally we should have one ps-print package with ps-bdf.el ps-mule.el ps-print.el in it. How we make use of ps-bdf.el and ps-mule.el remains to be discussed. My upcoming patch will deliver a merged ps-print.el somewhat more up-to-date than emac-20.7 ps-print, BUT with MULE functionality commented out. Thoughts? Adrian SY> -- SY> |---<Regards, Steve Youngs>-----------[GnuPG KeyID: 59E4C4B2]---| SY> | XEmacs - It's not just an editor... | SY> | It's a way of life. | SY> |----------------------------------<mailto:youngs＠xemacs.org>---| -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org

3 participants
2 comments

21.2 and trouble with menus 23 years, 5 months

James N. Potts

I just switched back to 21.2 (from 21.1) after not using it for a while, and noticed the change in the menu structure, ie the movement of the frame and window commands from the File menu to the new View menu. I don't mind this in and of itself (in fact, it makes sense), but it runs into trouble with some modes. For example, if you switch to html-mode, the View menu is replaced by html-mode's View menu. No more "New Frame" or "Split Window" via the mouse. What this really boils down to is poorly behaved packages that assume that there's no standard menu named "foo" and don't bother checking. I don't know that there's an easy solution to this. -Jim Potts

1 participants
0 comments

Re: Problem compiling func-menu.el 23 years, 5 months

Hrvoje Niksic

Steve Youngs <youngs(a)xemacs.org> writes: > Will a (eval-and-compile ...) cause problems for 21.1 people? > Should I revert the patch or is it safe to leave in? Please revert the patch. It is simply wrong.

2 participants
1 comments

Re: My location: Munich, Germany! 23 years, 5 months

Hrvoje Niksic

Michael Harnois <mdharnois(a)home.com> writes: > Awesome. Does this also mean you have, like, a job, income, etc? I had all these things before. Unless you're talking about Real Job, Real Income, etc. But that path is dangerous because it inevitably leads to the question of Real Life! :-)

2 participants
1 comments

Who is the portable dumper expert? 21.2.37 Portable dumper still broken. 23 years, 5 months

Troy Noble

I now have a few cycles to look at the portable dumper bug a little more, and figured out that (setq-default ) on an opaque type doesn't work properly after the dumper reloads it into memory. It appears to apply to SYMVAL_BOOLEAN_FORWARD variables (defined as DEFVAR_BOOLEAN) that are buffer local. Don't know yet if it's more pervasive than that. Who's the portable dump expert, and are there plans to fix this anytime soon? If not, I'd like to ask a few questions and see if I can fix it myself... but don't know if the list wants to see all that traffic, so could correspond with them offline if need be. It may be as simple as making sure the opaque variables get into the reloc_table so they get handled by the call to pdump_reorganize_hash_table. I'm not sure yet though. dumper.c, Line 1040 is the last time the variable gets "touched" if my debugger watchpoint doesn't lie. /* Put back the opaques */ for (i=0; i<((dump_header *)pdump_start)->nb_opaquedmp; i++) { struct pdump_dumpopaqueinfo di = PDUMP_READ (p, struct pdump_dumpopaqueinfo); > memcpy (di.data, p, di.size); p += di.size; } Thanks, Troy

2 participants
1 comments

My location: Munich, Germany! 23 years, 5 months

Hrvoje Niksic

One thing I haven't announced to xemacs-beta yet: As of some time ago, I live and work in Munich, Germany. If you're a Munich resident or if you're visiting Munich, and you want to meet me, drop me a mail.

2 participants
1 comments

Re: Who is the portable dumper expert? 21.2.37 Portable dumper still broken. 23 years, 5 months

Adrian Aichner

>>>>> "Troy" == Troy Noble <troy.noble(a)channelpoint.com> writes: Troy> I now have a few cycles to look at the portable dumper bug a Troy> little more, and figured out that (setq-default ) on an Troy> opaque type doesn't work properly after the dumper reloads Troy> it into memory. It appears to apply to Troy> SYMVAL_BOOLEAN_FORWARD variables (defined as DEFVAR_BOOLEAN) Troy> that are buffer local. Don't know yet if it's more Troy> pervasive than that. Troy> Who's the portable dump expert, and are there plans to fix Troy> this anytime soon? See Coding Projects in http://xemacs.sourceforge.net/Develop/jobs.html Troy> If not, I'd like to ask a few questions and see if I can fix Troy> it myself... but don't know if the list wants to see all Troy> that traffic, so could correspond with them offline if need Troy> be. xemacs-beta is the right list for that. Fixing these problems is highly desirable! Best regards, Adrian Troy> It may be as simple as making sure the opaque variables get Troy> into the reloc_table so they get handled by the call to Troy> pdump_reorganize_hash_table. I'm not sure yet though. Troy> dumper.c, Line 1040 is the last time the variable gets "touched" if Troy> my debugger watchpoint doesn't lie. Troy> /* Put back the opaques */ Troy> for (i=0; i<((dump_header *)pdump_start)->nb_opaquedmp; i++) Troy> { Troy> struct pdump_dumpopaqueinfo di = PDUMP_READ (p, struct Troy> pdump_dumpopaqueinfo); >> memcpy (di.data, p, di.size); Troy> p += di.size; Troy> } Troy> Thanks, Troy -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org

1 participants
0 comments

RE: Fw: Build failure, 21.2, current cvs, VC5 23 years, 5 months

Troy Noble

It's not just in CVS. It appears that it also made it from CVS into the xemacs-21.2.37.tar.gz, since I ran into it last night when I downloaded and compiled with MSVC 5.0: ftp://ftp.xemacs.org/xemacs/beta/xemacs-21.2/xemacs-21.2.37.tar.gz So might want to refresh that snapshot as well, or quickly turn out a 21.2.38... not sure which is the preferred approach. Thought you'd like to know though. Troy -----Original Message----- From: Andy Piper [mailto:andyp＠bea.com] Sent: Tuesday, November 14, 2000 12:35 PM To: James N. Potts Cc: xemacs-beta(a)xemacs.org; xemacs-nt(a)xemacs.org Subject: Re: Fw: Build failure, 21.2, current cvs, VC5 Oops, that wasn't mean't to get committed. andy At 12:43 PM 11/14/00 -0600, you wrote: >I meant to copy you on this. >-----Original Message----- >From: James N. Potts <jpmail(a)limolink.com> >To: xemacs-beta(a)xemacs.org <xemacs-beta(a)xemacs.org> >Date: Tuesday, November 14, 2000 12:40 PM >Subject: Build failure, 21.2, current cvs, VC5 > > >When I try building from a fresh cvs checkout, I get: > >]event-msw.c >]H:\src\XEMACS~1.2\nt\..\src\event-msw.c(2799) : error C2143: >] syntax error : missing ';' before '}' >]NMAKE : fatal error U1077: 'cl' : return code '0x2' >]Stop. > >This comes from Andy's patch: > >]1.38.2.61 Tue Nov 7 23:24:26 2000 by andyp >]CVS Tags: r21-2-37, r21-2-latest-beta; Branch: release-21-2 >]Diffs to 1.38.2.60 >]gutter fix > > >--- xemacs/src/event-msw.c 2000/09/20 02:38:34 1.38.2.60 > >+++ xemacs/src/event-msw.c 2000/11/07 23:24:26 1.38.2.61 >[...] > >＠＠ -2792,6 +2794,8 ＠＠ > > case CBN_SELCHANGE: > > if (!NILP (mswindows_handle_gui_wm_command (frame, cid, id))) > > return 0; > >+ case BN_SETFOCUS: > >+ > > } > > /* menubars always must come last since the hashtables do not > > always exist*/ > >Is there a reason for this empty case? In any case (pun not intended), I >just pulled out my copy of Harbison & Steele, and there must be a >statement after a case-label. A bare semi-colon does the trick. > >-Jim Potts -------------------------------------------------------------- Dr Andy Piper Principal Consultant, BEA Systems Ltd

1 participants
0 comments

Problem compiling func-menu.el 23 years, 5 months

Steve Youngs

Hi Gang, I'm having a problem with byte-compiling func-menu.el. M-x byte-compile-file under normal circumstances works fine, but under xemacs -vanilla I get: ,---- | While compiling toplevel forms: | !! Symbol's function definition is void ((fume-bomb-proof)) `---- Here's the backtrace. -- |---<Regards, Steve Youngs>-----------[GnuPG KeyID: 59E4C4B2]---| | XEmacs - It's not just an editor... | | It's a way of life. | |----------------------------------<mailto:youngs＠xemacs.org>---|

3 participants
5 comments

Re: Problem compiling func-menu.el 23 years, 5 months

Adrian Aichner

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>> "SY" == Steve Youngs <youngs(a)xemacs.org> writes: SY> I'm having a problem with byte-compiling func-menu.el. Stephen> The defmacro of fume-bomb-proof needs to be eval-when'd. Stephen> (eval-and-compile Stephen> (defmacro fume-bomb-proof ...)) Should this be (eval-when-compile ...) or (eval-and-compile ...) ? Stephen> should do it if I've got my eval-whens straight. Stephen> -- Stephen> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Stephen> Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 Stephen> _________________ _________________ _________________ _________________ Stephen> What are those straight lines for? "XEmacs rules." -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org

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 November 2000