[Fwd: Re: has XEmacs been ported to MacosX?]
24 years, 3 months
Ben Wing
Ben Wing
can anyone help him? i really know little about vc, but many of the list
members do, and he is getting very frustrated.
-------- Original Message --------
Subject: Re: has XEmacs been ported to MacosX?
Date: Wed, 02 Aug 2000 14:50:31 -0400
From: Rodney Sparapani <rodney(a)stat.duke.edu>
Organization: Duke Clinical Research Institute
To: Ben Wing <ben(a)666.com>
References: <8l1s5p$qi5$1(a)nnrp1.deja.com> <3975AAD1.314618E1(a)stat.duke.edu>
<m2puo9u1ii.fsf(a)zion.rcn.com> <3976F061.DCCAFF43(a)stat.duke.edu>
<3977D884.1C999ECC(a)666.com> <3978417D.9C31F66C(a)stat.duke.edu>
<397EE0C6.71317C47(a)stat.duke.edu>
Ben:
Now, you've seen it twice. What are you going to do about it?
Rodney
Rodney Sparapani wrote:
> Ben:
>
> Are you looking into this?
>
> Rodney
>
> Rodney Sparapani wrote:
>
> > Ben:
> >
> > I can't find the e-mails. It was back in April or May. But basically, the problem is
> > with VC. We don't have any problems with the same setup under FSF emacs 19.34.2. But,
> > it's a dinosaur. So we were planning to upgrade. xemacs seemed like a logical choice.
> > We are testing 21.1; May, 1999. When you first bring a file into RCS, registering goes
> > fine. However, when you want to check-out a file, it attempts to register it again;
> > which fails. If you ignore the failure, then everything behaves normally after that.
> > Please let me know if you have any ideas. I would love to get this resolved. Frankly,
> > I had given up hope. I got alot of friendly advice, but nothing seemed to help. I
> > think the consensus was to just ignore it. Normally, I would go along with that, but
> > the whole reason to use version-control, IMO, is to be very conservative.
> >
> > Rodney
> >
> > Ben Wing wrote:
> >
> > > i've never seen these. where have you supplied them? we try hard to fix bug
> > > reports that get to us. if you've supplied them repeatedly, presumably you
> > > still have the emails around and can send them to us?
> > >
> > > Rodney Sparapani wrote:
> > > >
> > > > Vin:
> > > >
> > > > I have supplied them, repeatedly. I don't think they are problems with XEmacs per
> > > > se. I'm guessing that they have to do with subtle differences between XEmacs and
> > > > emacs. The reason that I'm guessing is that no one has been able to find a
> > > > solution. I can't afford to waste time on something that may never be fixed so we
> > > > use emacs. Oh and by the way, I'm not talking about code that I wrote. These are
> > > > packages that come with XEmacs. You are better off with emacs today. I'd be
> > > > thrilled if XEmacs was usable so we would have options. We don't.
> > > >
> > > > Rodney
> > > >
> > > > Vin Shelton wrote:
> > > >
> > > > > Perhaps you could supply a few specific examples of " extermely
> > > > > troublesome" behavior. Perhaps your examples might get looked at if
> > > > > you were to supply some.
> > > > >
> > > > > Please follow-up to xemacs-beta(a)xemacs.org, if you care to.
> > > > >
> > > > > Vin Shelton
> > > > >
> > > > > >>>>> On Wed, 19 Jul 2000, Rodney Sparapani <rodney(a)stat.duke.edu> said:
> > > > >
> > > > > Rodney> Tony:
> > > > > Rodney> I don't think it has. But, is there some reason that you want XEmacs
> > > > > Rodney> rather than emacs? I have found XEmacs to be extremely troublesome.
> > > > > Rodney> I'm hoping that some day that will change, but it hasn't happened yet.
> > > > > Rodney> Of course, alot of problems are caused because of the schism between the
> > > > > Rodney> two camps. For developers of e-lisp packages like myself, getting a
> > > > > Rodney> working version on emacs alone is hard enough and modifying it for a
> > > > > Rodney> second environment is nearly impossible.
> > > > >
> > > > > Rodney> Rodney
> > > > >
> > > > > Rodney> tbennett(a)nvidia.com wrote:
> > > > >
> > > > > >> I'm just looking for XEmacs in tty mode, of course.
> > > > > >>
> > > > > >> If so, what is the config to use? config.guess was unable to
> > > > > >> figure out a good one.
> > > > > >>
> > > > > >> --
> > > > > >> --tony
> > > > > >>
> > > > > >> Sent via Deja.com http://www.deja.com/
> > > > > >> Before you buy.
> > > > >
> > > > > Rodney> --
> > > > > Rodney> WWLD? (What Would Lombardi Do?)
> > > > > Rodney> Was "Name That Tune" Rigged?
> > > > > Rodney> Rodney Sparapani, Duke Clinical Research Institute
> > > > > Rodney> For addressing and schedule information
> > > > > Rodney> see http://www.duke.edu/~spara002
> > > >
> > > > --
> > > > WWLD? (What Would Lombardi Do?)
> > > > Was "Name That Tune" Rigged?
> > > > Rodney Sparapani, Duke Clinical Research Institute
> > > > For addressing and schedule information
> > > > see http://www.duke.edu/~spara002
> > >
> > > --
> > > Ben
> > >
> > > In order to save my hands, I am cutting back on my mail. I also write
> > > as succinctly as possible -- please don't be offended. If you send me
> > > mail, you _will_ get a response, but please be patient, especially for
> > > XEmacs-related mail. If you need an immediate response and it is not
> > > apparent in your message, please say so. Thanks for your understanding.
> > >
> > > See also http://www.666.com/ben/chronic-pain/
> >
> > --
> > WWLD? (What Would Lombardi Do?)
> > Was "Name That Tune" Rigged?
> > Rodney Sparapani, Duke Clinical Research Institute
> > For addressing and schedule information
> > see http://www.duke.edu/~spara002
>
> --
> WWLD? (What Would Lombardi Do?)
> Was "Name That Tune" Rigged?
> Rodney Sparapani, Duke Clinical Research Institute
> For addressing and schedule information
> see http://www.duke.edu/~spara002
--
WWLD? (What Would Lombardi Do?)
Was "Name That Tune" Rigged?
Rodney Sparapani, Duke Clinical Research Institute
For addressing and schedule information
see http://www.duke.edu/~spara002
- 1 participants
- 0 comments
Re: Document X Font Set usage in menubar
24 years, 3 months
Vin Shelton
Vin Shelton
Stephen,
Thanks for this patch. It will go into 21.1.12.
- vin
>>>>> On Wed, 2 Aug 2000 18:36:04 +0900 (JST), "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> said:
Stephen> When configured with --with-xfs, XEmacs ignores *menubar*Font
Stephen> resources, and demands *menubar*FontSet resources. (There may be
Stephen> others like this but I didn't see any in a quick look.) This patch
Stephen> documents this and notes a possible fix in lwlib/xlwmenu.c.
Stephen> For 21.1 and 21.2. Generated against 21.2 (updated today); applies
Stephen> with some fuzz and offsets to 21.1 (also updated today).
Stephen> root ChangeLog:
Stephen> 2000-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
Stephen> * etc/Emacs.ad: Document usage of FontSet resource for menubar.
Stephen> lwlib/ChangeLog:
Stephen> 2000-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
Stephen> * xlwmenu.c: Comment suggesting treatment of X Font Set
Stephen> resources like Motif FontLists. Make comment on Motif
Stephen> algorithm for setting FontList match code.
Stephen> man/ChangeLog:
Stephen> 2000-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
Stephen> * xemacs/custom.texi: Document usage of FontSet resource for menubar.
Stephen> patch:
Stephen> Index: lwlib/xlwmenu.c
Stephen> ===================================================================
Stephen> RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/xlwmenu.c,v
Stephen> retrieving revision 1.25.2.11
Stephen> diff -u -r1.25.2.11 xlwmenu.c
Stephen> --- xlwmenu.c 2000/07/09 06:32:13 1.25.2.11
Stephen> +++ xlwmenu.c 2000/08/02 09:24:43
Stephen> ＠＠ -88,6 +88,8 ＠＠
Stephen> {XtNfont, XtCFont, XtRFontStruct, sizeof(XFontStruct *),
Stephen> offset(menu.font), XtRString, (XtPointer) "XtDefaultFont"},
Stephen> # ifdef USE_XFONTSET
Stephen> + /* #### Consider using the same method as for Motif; see the comment in
Stephen> + XlwMenuInitialize(). */
Stephen> {XtNfontSet, XtCFontSet, XtRFontSet, sizeof(XFontSet),
Stephen> offset(menu.font_set), XtRString, (XtPointer) "XtDefaultFontSet"},
Stephen> # endif
Stephen> ＠＠ -3017,10 +3019,12 ＠＠
Stephen> gray_width, gray_height, 1, 0, 1);
Stephen> #ifdef NEED_MOTIF
Stephen> + /* #### Even if it's a kludge!!!, we should consider doing the same for
Stephen> + X Font Sets. */
Stephen> /* The menu.font_list slot came from the *fontList resource (Motif standard.)
Stephen> The menu.font_list_2 slot came from the *font resource, for backward
Stephen> compatibility with older versions of this code, and consistency with the
Stephen> - rest of emacs. If both font and fontList are specified, we use font.
Stephen> + rest of emacs. If both font and fontList are specified, we use fontList.
Stephen> If only one is specified, we use that. If neither are specified, we
Stephen> use the "fallback" value. What a kludge!!!
Stephen> Index: etc/Emacs.ad
Stephen> ===================================================================
Stephen> RCS file: /usr/CVSroot/XEmacs/xemacs/etc/Emacs.ad,v
Stephen> retrieving revision 1.8.2.2
Stephen> diff -u -r1.8.2.2 Emacs.ad
Stephen> --- Emacs.ad 2000/05/03 14:46:58 1.8.2.2
Stephen> +++ Emacs.ad 2000/08/02 09:24:44
Stephen> ＠＠ -188,6 +188,13 ＠＠
Stephen> ! Note that the menubar resources do not use the `face' syntax, since they
Stephen> ! are X toolkit widgets and thus outside the domain of XEmacs proper.
Stephen> !
Stephen> +! When X Font Sets are enabled with ./configure --with-xfs (eg, for
Stephen> +! multilingual menubars and XIM), some .font resources are ignored in favor
Stephen> +! of .fontSet resources. This examples is for Japanese menubars):
Stephen> +!
Stephen> +! *menubar*FontSet: -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*, \
Stephen> +! -*-*-*-*-*-*-*-120-*-jisx0208.1983-0
Stephen> +!
Stephen> *menubar*Font: -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*
Stephen> *popup*Font: -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*
Stephen> Index: man/xemacs/custom.texi
Stephen> ===================================================================
Stephen> RCS file: /usr/CVSroot/XEmacs/xemacs/man/xemacs/custom.texi,v
Stephen> retrieving revision 1.7.2.10
Stephen> diff -u -r1.7.2.10 custom.texi
Stephen> --- custom.texi 2000/07/19 09:47:59 1.7.2.10
Stephen> +++ custom.texi 2000/08/02 09:24:45
Stephen> ＠＠ -2493,12 +2493,26 ＠＠
Stephen> colors: It uses whatever resources are appropriate to the type of widget
Stephen> which is used to implement it.
Stephen> -If Emacs was compiled to use only the Motif-lookalike menu widgets, then one
Stephen> -way to specify the font of the menubar would be
Stephen> +If Emacs was compiled to use only the Lucid Motif-lookalike menu widgets,
Stephen> +then one way to specify the font of the menubar would be
Stephen> ＠example
Stephen> Emacs*menubar*font: *-courier-medium-r-*-*-*-120-*-*-*-*-*-*
Stephen> ＠end example
Stephen> +
Stephen> +If both the Lucid Motif-lookalike menu widgets and X Font Sets are
Stephen> +configured to allow multilingual menubars, then one uses
Stephen> +
Stephen> +＠example
Stephen> +*menubar*FontSet: -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*, \
Stephen> + -*-*-*-*-*-*-*-120-*-jisx0208.1983-0
Stephen> +＠end example
Stephen> +
Stephen> +That would specify fonts for a Japanese menubar. Specifying only one
Stephen> +XLFD is acceptable; specifying more than one for a given registry
Stephen> +(language) is also allowed. When X Font Sets are configured, some .font
Stephen> +resources (eg, menubars) are ignored in favor of the corresponding
Stephen> +.fontSet resources.
Stephen> If the Motif library is being used, then one would have to use
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."
- 1 participants
- 0 comments
Re: s/wierd/weird/g;
24 years, 3 months
Vin Shelton
Vin Shelton
Martin,
Thanks for this patch. It will go into 21.1.12.
- vin
>>>>> On Wed, 2 Aug 2000 17:15:36 +0900 (JST), Martin Buchholz <martin(a)xemacs.org> said:
Martin> No changelog
Martin> Index: PROBLEMS
Martin> ===================================================================
Martin> RCS file: /usr/CVSroot/XEmacs/xemacs/PROBLEMS,v
Martin> retrieving revision 1.26.2.16
Martin> diff -u -w -r1.26.2.16 PROBLEMS
Martin> --- PROBLEMS 2000/06/30 08:49:54 1.26.2.16
Martin> +++ PROBLEMS 2000/08/02 08:14:41
Martin> ＠＠ -523,7 +523,7 ＠＠
Martin> This is usually because xmkmf is not in your path or because you are
Martin> using the default cygwin shell. The default cygwin shell (/bin/sh.exe)
Martin> -is ash which appears to work in most circumstances but has some wierd
Martin> +is ash which appears to work in most circumstances but has some weird
Martin> failure modes. I recommend replacing sh.exe with bash.exe, this will
Martin> mean configure is slower but more reliable.
Martin> Index: ./src/event-Xt.c
Martin> ===================================================================
Martin> RCS file: /usr/CVSroot/XEmacs/xemacs/src/event-Xt.c,v
Martin> retrieving revision 1.41.2.28
Martin> diff -u -w -r1.41.2.28 event-Xt.c
Martin> --- event-Xt.c 2000/07/21 10:16:00 1.41.2.28
Martin> +++ event-Xt.c 2000/08/02 08:14:47
Martin> ＠＠ -3055,9 +3055,9 ＠＠
Martin> if ((d = get_device_from_display_1(dpy))) {
Martin> visual = DEVICE_X_VISUAL(d);
Martin> if (colormap != DEVICE_X_COLORMAP(d)) {
Martin> - XtAppWarningMsg(the_app_con, "wierdColormap", "cvtStringToPixel",
Martin> + XtAppWarningMsg(the_app_con, "weirdColormap", "cvtStringToPixel",
Martin> "XtToolkitWarning",
Martin> - "The colormap passed to cvtStringToPixel doesn't match the one registerd to the device.\n",
Martin> + "The colormap passed to cvtStringToPixel doesn't match the one registered to the device.\n",
Martin> NULL, 0);
Martin> status = XAllocNamedColor(dpy, colormap, (char*)str, &screenColor, &exactColor);
Martin> } else {
Martin> Index: ./src/glyphs.c
Martin> ===================================================================
Martin> RCS file: /usr/CVSroot/XEmacs/xemacs/src/glyphs.c,v
Martin> retrieving revision 1.23.2.76
Martin> diff -u -w -r1.23.2.76 glyphs.c
Martin> --- glyphs.c 2000/07/22 19:33:24 1.23.2.76
Martin> +++ glyphs.c 2000/08/02 08:14:50
Martin> ＠＠ -887,7 +887,7 ＠＠
Martin> break;
Martin> }
Martin> - /* The image may have been previously finalized (yes that's wierd,
Martin> + /* The image may have been previously finalized (yes that's weird,
Martin> see Fdelete_frame() and mark_window_as_deleted()), in which case
Martin> the domain will be nil, so cope with this. */
Martin> if (!NILP (IMAGE_INSTANCE_DEVICE (i)))
Martin> Index: ./src/window.c
Martin> ===================================================================
Martin> RCS file: /usr/CVSroot/XEmacs/xemacs/src/window.c,v
Martin> retrieving revision 1.41.2.54
Martin> diff -u -w -r1.41.2.54 window.c
Martin> --- window.c 2000/07/22 19:33:30 1.41.2.54
Martin> +++ window.c 2000/08/02 08:14:55
Martin> ＠＠ -5228,7 +5228,7 ＠＠
Martin> font size change happened between saving and restoring, the
Martin> frame "sizes" maybe equal but the windows still should be
Martin> resized. This is tickled alot by the new "character size
Martin> - stays constant" policy in 21.0. It leads to very wierd
Martin> + stays constant" policy in 21.0. It leads to very weird
Martin> glitches (and possibly crashes when asserts are tickled).
Martin> Just changing the units doens't help because changing the
- 1 participants
- 0 comments
Re: menubar-items.el
24 years, 3 months
Vin Shelton
Vin Shelton
Martin,
Thanks for this patch. It will go into 21.1.12.
- vin
>>>>> On Wed, 2 Aug 2000 15:43:36 +0900 (JST), Martin Buchholz <martin(a)xemacs.org> said:
Martin> Here is a revised version of my previous patch, with obvious spelling
Martin> fixes. menubar and font-lock maintainers, please actually test the
Martin> functionality.
Martin> ./lisp/ChangeLog:
Martin> 2000-08-02 Martin Buchholz <martin(a)xemacs.org>
Martin> * menubar-items.el (default-menubar): Fix typo.
Martin> (default-menubar): `lambda' was mispelled as `lamda'.
Martin> Index: ./lisp/menubar-items.el
Martin> ===================================================================
Martin> RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/menubar-items.el,v
Martin> retrieving revision 1.6.2.31
Martin> diff -u -w -r1.6.2.31 menubar-items.el
Martin> --- menubar-items.el 2000/07/31 09:58:33 1.6.2.31
Martin> +++ menubar-items.el 2000/08/02 06:40:19
Martin> ＠＠ -647,8 +647,7 ＠＠
Martin> (if package-get-base
Martin> (submenu-generate-accelerator-spec
Martin> (cdr (custom-menu-create 'packages)))
Martin> - '(["Please load Package Index"
Martin> - (lamda (&rest junk) ()) nil]))))
Martin> + '(["Please load Package Index" #'ignore nil]))))
Martin> ["%_Help" (Info-goto-node "(xemacs)Packages")])
Martin> "---"
Martin> ＠＠ -1265,7 +1264,7 ＠＠
Martin> (font-lock-recompute-variables)))
Martin> :style radio
Martin> :active (fboundp 'font-lock-mode)
Martin> - :selected (and (boundp 'font-lock-maximium-decoration)
Martin> + :selected (and (boundp 'font-lock-maximum-decoration)
Martin> (or (and (not (integerp font-lock-maximum-decoration))
Martin> (not (eq t font-lock-maximum-decoration)))
Martin> (and (integerp font-lock-maximum-decoration)
Martin> ＠＠ -1280,7 +1279,7 ＠＠
Martin> (font-lock-recompute-variables)))
Martin> :style radio
Martin> :active (fboundp 'font-lock-mode)
Martin> - :selected (and (boundp 'font-lock-maximium-decoration)
Martin> + :selected (and (boundp 'font-lock-maximum-decoration)
Martin> (integerp font-lock-maximum-decoration)
Martin> (= 1 font-lock-maximum-decoration))]
Martin> ["%_Even More"
- 1 participants
- 0 comments
Re: Patch: NAS_LITTLE_ENDIAN [was: NAS related source code error?]
24 years, 3 months
Vin Shelton
Vin Shelton
Stephen,
Thanks for this patch. It will go into 21.1.12.
- vin
>>>>> On Wed, 2 Aug 2000, "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> said:
Stephen> OK, here is a patch to handle (NAS_)?LITTLE_ENDIAN correctly for old
Stephen> and new versions of NAS. It works correctly on my freshly updated
Stephen> XEmacs 21.1.11, NAS 1.2p5, Debian (woody) Linux (2.2.10) system.
Stephen> I believe this is safe with respect to other possible changes in NAS
Stephen> header usage as a quick check of other NAS headers indicates that they
Stephen> already (as of 1.2p5) used prefixes to prevent namespace pollution.
Stephen> For 21.1 assuming Raymond and Edwin report no problems. 21.2 requires
Stephen> a separate patch.
Stephen> Raymond, Edwin, would you apply the patch, run autoconf, and see if it
Stephen> works correctly on your systems? (I will also send the configure
Stephen> script I generated in a separate mail; you should throw it away if you
Stephen> have autoconf.) (1) Grepping src/config.h for "NAS_" should result in
Stephen> some stuff including
Stephen> /* #undef NAS_USES_OWN_NAMESPACE */
Stephen> on Raymond's NAS 1.2p5 system, and
Stephen> #define NAS_USES_OWN_NAMESPACE 1
Stephen> on Edwin's more recent system. (2) Also (Edwin especially) rebuild to
Stephen> make sure there are no link errors and that sounds actually come out.
Stephen> Note that the compiler will probably complain about start_interrupts;
Stephen> I have a separate patch to fix that (unrelated) problem.
Stephen> root Changelog:
Stephen> 2000-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
Stephen> * configure.in: Check for NAS_BIG_ENDIAN in <audio/fileutil.h>.
Stephen> src/Changelog:
Stephen> 2000-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
Stephen> * nas.c: Make manipulation of *_ENDIAN macros conditional on
Stephen> NAS_USES_OWN_NAMESPACE (cf. 2000-07-29 Edwin Wiles patch)
Stephen> * config.h.in: Added NAS_USES_OWN_NAMESPACE.
Stephen> patch:
Stephen> Index: configure.in
Stephen> ===================================================================
Stephen> RCS file: /usr/CVSroot/XEmacs/xemacs/configure.in,v
Stephen> retrieving revision 1.141
Stephen> diff -u -r1.141 configure.in
Stephen> --- configure.in 2000/07/31 00:33:05 1.141
Stephen> +++ configure.in 2000/08/02 03:58:37
Stephen> ＠＠ -3437,6 +3437,9 ＠＠
Stephen> dnl If the nas library does not contain the error jump point,
Stephen> dnl then we force safer behaviour.
Stephen> AC_EGREP_HEADER(AuXtErrorJump,audio/Xtutil.h,,[AC_DEFINE(NAS_NO_ERROR_JUMP)])
Stephen> + dnl NAS <= 1.2p5 defines {BIG,LITTLE}_ENDIAN in conflict with GNU libc etc
Stephen> + dnl Recent NAS prefixes NAS_ to avoid polluting namespace
Stephen> + AC_EGREP_HEADER(NAS_BIG_ENDIAN,audio/fileutil.h,[AC_DEFINE(NAS_USES_OWN_NAMESPACE)])
Stephen> esac
Stephen> dnl ---------------------
Stephen> Index: src/config.h.in
Stephen> ===================================================================
Stephen> RCS file: /usr/CVSroot/XEmacs/xemacs/src/config.h.in,v
Stephen> retrieving revision 1.56
Stephen> diff -u -r1.56 config.h.in
Stephen> --- config.h.in 2000/07/31 00:33:15 1.56
Stephen> +++ config.h.in 2000/08/02 03:58:38
Stephen> ＠＠ -579,9 +579,12 ＠＠
Stephen> /* Compile in support for NAS (Network Audio System)?
Stephen> NAS_NO_ERROR_JUMP means that the NAS libraries don't include some
Stephen> - error handling changes. */
Stephen> + error handling changes.
Stephen> + NAS_USES_OWN_NAMESPACE means NAS headers define NAS_LITTLE_ENDIAN
Stephen> + instead of LITTLE_ENDIAN etc. */
Stephen> #undef HAVE_NAS_SOUND
Stephen> #undef NAS_NO_ERROR_JUMP
Stephen> +#undef NAS_USES_OWN_NAMESPACE
Stephen> /* Compile in support for SunPro usage-tracking code? */
Stephen> #undef USAGE_TRACKING
Stephen> Index: src/nas.c
Stephen> ===================================================================
Stephen> RCS file: /usr/CVSroot/XEmacs/xemacs/src/nas.c,v
Stephen> retrieving revision 1.5
Stephen> diff -u -r1.5 nas.c
Stephen> --- nas.c 2000/07/31 00:33:15 1.5
Stephen> +++ nas.c 2000/08/02 03:58:38
Stephen> ＠＠ -69,12 +69,22 ＠＠
Stephen> #include <stdio.h>
Stephen> #include "syssignal.h"
Stephen> -#undef NAS_LITTLE_ENDIAN
Stephen> -#undef NAS_BIG_ENDIAN
Stephen> +/* NAS 1.2p5 and previous define these in conflict with GNU libc (at least) */
Stephen> +#ifndef NAS_USES_OWN_NAMESPACE
Stephen> +#undef LITTLE_ENDIAN
Stephen> +#undef BIG_ENDIAN
Stephen> +#endif
Stephen> +
Stephen> #include <audio/audiolib.h>
Stephen> #include <audio/soundlib.h>
Stephen> #include <audio/snd.h>
Stephen> #include <audio/fileutil.h>
Stephen> +
Stephen> +/* If needed (NAS <= 1.2p5) define the NAS_ versions of *_ENDIAN */
Stephen> +#ifndef NAS_USES_OWN_NAMESPACE
Stephen> +#define NAS_LITTLE_ENDIAN LITTLE_ENDIAN
Stephen> +#define NAS_BIG_ENDIAN BIG_ENDIAN
Stephen> +#endif
Stephen> #ifdef emacs
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."
- 1 participants
- 0 comments
CVS problems?
24 years, 3 months
Robin S. Socha
Robin S. Socha
I don't know much about CVS, but is this ok?
P src/ChangeLog
cvs update: checksum failure after patch to src/ChangeLog; will refetch
P src/config.h.in
cvs update: checksum failure after patch to src/config.h.in; will refetch
P src/editfns.c
cvs update: checksum failure after patch to src/editfns.c; will refetch
P src/gdbinit
cvs update: checksum failure after patch to src/gdbinit; will refetch
P src/nas.c
P src/ntheap.c
cvs update: checksum failure after patch to src/ntheap.c; will refetch
cvs server: Updating src/m
cvs server: Updating src/s
P src/s/gnu.h
cvs update: checksum failure after patch to src/s/gnu.h; will refetch
P src/s/hpux.h
cvs update: checksum failure after patch to src/s/hpux.h; will refetch
P src/s/linux.h
cvs update: checksum failure after patch to src/s/linux.h; will refetch
--
Robin S. Socha
Big. Black. Beautified. <http://socha.net/XEmacs/>
- 1 participants
- 0 comments
pcl-cvs requires mule
24 years, 3 months
Les Schaffer
Les Schaffer
while trying to use the view status function of pcl-cvs, i got this
error (below). it looks like pcl-cvs requires mule, even though its
not listed as a depends. i have all the "required" packages.
is this the culprit (cvs-status.el)????:
;; chars sets. Ripped from cvstree
(defvar cvstree-dstr-2byte-ready
(when (featurep 'mule)
(if (boundp 'current-language-environment)
does this mean i need all of mule? i dont see mule.el even in
mule-base.
les schaffer
Signaling: (file-error "Cannot open load file" "mule")
load-internal("mule" nil t nil nil nil)
load("mule" nil t nil)
require(mule)
load-internal("cvs-status" nil nil nil nil nil)
load("cvs-status" nil nil nil)
apply(load ("cvs-status" nil nil nil))
dired-handler-fn(load "cvs-status" nil nil nil)
load-internal("cvs-status" nil nil nil nil nil)
load("cvs-status" nil nil nil)
cvs-status-mode()
cvs-temp-buffer("status")
cvs-mode-do("status" ("-v") nil :dont-change-disc t :show t :postproc nil)
#<compiled-function nil "...(19)" [cvs-mode-do "status" flags nil :dont-change-disc t :show :postproc cvs-auto-remove-handled status (...)] 11>()
#<compiled-function nil "...(15)" [commandp -cvs-mode!-fun call-interactively] 2>()
cvs-mode!(#<compiled-function nil "...(19)" [cvs-mode-do "status" flags nil :dont-change-disc t :show :postproc cvs-auto-remove-handled status (...)] 11>)
#<compiled-function (flags) "...(4)" [cvs-mode! #<compiled-function nil "...(19)" ... 11>] 2 ("/usr/lib/xemacs/xemacs-packages/lisp/pcl-cvs/pcl-cvs.elc" . 49672) (list (cvs-flags-query ... "cvs status flags"))>(("-v"))
call-interactively(cvs-mode-status)
==================
;;;＠＠＠
(package-get-update-base-entry (quote
(pcl-cvs
(standards-version 1.1
version "1.47"
author-version "R-2_9_9"
date "2000-05-07"
build-date "2000-07-10"
maintainer "XEmacs Development Team <xemacs-beta(a)xemacs.org>"
distribution xemacs
priority low
category "prog"
dump nil
description "CVS frontend."
filename "pcl-cvs-1.47-pkg.tar.gz"
md5sum "5b998b880b04935a415fffeb1991d64e"
size 159934
provides (pcl-cvs generic-sc)
requires (xemacs-base elib vc dired edebug edit-utils)
type regular
=====
Result for query 'pcl-cvs mule'
Summary for query "pcl-cvs mule":
Found 0 matches in 0 files.
- 1 participants
- 0 comments
Slow invisibility
24 years, 3 months
Dan Holmsand
Dan Holmsand
Setting text to be invisible seems to mean terribly slow scrolling in
xemacs, if the invisible area is large AND there are a lot of extents
(e.g. from font-locking) in the invisible area.
An example:
Open a reasonably big file (redisplay.c will do), and go to the
beginning of the buffer.
Make sure font-lock-mode is on.
Say M-:
(put-text-property (+ (point) 2000) (+ (point) 200000) 'invisible t)
Scroll forward and backward a couple of time.
And voila: xemacs seems to hang for quite a while (at least it does on
my machine, on both cygwin and mingw builds of latest cvs).
I don't know even remotely enough to track this down, but gprof seems
to say that create_text_block in redisplay.c is spending a lot of
time.
There seems to be a check there for data.ef->invisible, that if true
steps forward to the next character - instead of going to the end of
the invisible extent. If selective display is on, on the other hand,
it makes a search directly for the end of line (which seems to be the
reasonable thing to do - but as I said, I really don't know this...).
Anyway, it would be very good to have invisibility as an alternative
to selective display in xemacs (in outline-mode etc.), as in the
latest fsfmacs.
Something to look into for someone who knows...?
/dan
--
Dan Ola Holmsand
Innehållsbolaget
dan(a)innehall.com
- 1 participants
- 0 comments
Re: NAS related source code error?
24 years, 3 months
Vin Shelton
Vin Shelton
OK. Would this patch be any better:
http://www.xemacs.org/list-archives/xemacs-patches/200006/msg00005.html
Please advise.
- vin
>>>>> On Tue, 1 Aug 2000 13:37:35 +0900 (JST), "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> said:
>>>>> "vin" == Vin Shelton <acs(a)xemacs.org> writes:
vin> Thank you for this patch. It has been applied to the 21.1
vin> branch of XEmacs and will appear in XEmacs 21.1.12.
Stephen> NOOOOOOoooooooo! (That's not a veto, I'm not on -review.)
>>>>> On Mon, 24 Jul 2000, ewiles(a)mclean.sterling.com (Edwin Wiles) said:
Edwin> Problem: LITTLE_ENDIAN is not defined in "src/nas.c".
Stephen> Sure it is, in <audio/fileutil.h>, NAS 1.2p5.
Edwin> Resolution: The NAS include files define
Edwin> "NAS_LITTLE_ENDIAN" and "NAS_BIG_ENDIAN", not
Edwin> "LITTLE_ENDIAN" and "BIG_ENDIAN".
Stephen> Not in 1.2p5. Those headers define only "LITTLE_ENDIAN" and
Stephen> "BIG_ENDIAN".
Edwin> Fix: Changed "src/nas.c" to use "NAS_*".
Stephen> Breaking all systems with 1.2p5 or earlier installed. This is true of
Stephen> Debian Linux (woody), for example.
Stephen> Please revert this patch and figure out how to do it without breaking
Stephen> older systems. This can be easily done with
Stephen> #ifndef NAS_BIG_ENDIAN
Stephen> #define NAS_BIG_ENDIAN BIG_ENDIAN
Stephen> #endif
Stephen> etc after the #includes, but it is probably preferable to fix it so
Stephen> that modern NAS installations don't have to suffer with the #undef
Stephen> BIG_ENDIAN breakage. I don't see how to do that simply in the source,
Stephen> you'll probably have to do it via configure.
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."
- 3 participants
- 2 comments
Re: menubar bugs: can't change font and weird separator rules
24 years, 3 months
Mike FABIAN
Mike FABIAN
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> (1) In 21.2.35, I am unable to change the font for the menubar using the
> incantation in etc/Emacs.ad:
>
> src/xemacs -vanilla -xrm '*menubar*Font:-*-helvetica-*-*-*-*-*-240-*iso8859-1' &
Have you tried this:
xemacs -vanilla -xrm 'XEmacs*fontSet:-*-helvetica-*-*-*-*-*-240-*iso8859-1' &
I guess you have configured your XEmacs with '--with-xfs'. In that
case, the '*menubar*Font' resource seems to be ignored and the resource
'XEmacs*fontSet' is used instead for the menu bar (and for XIM).
I have tried this only with 21.1.10, but maybe it still works in the same
way for 21.2.35? (I don't have a 21.2.35 at hand here).
--
Mike Fabian <mfabian(a)suse.de>
- 2 participants
- 1 comments