October 1998 - XEmacs-Beta - XEmacs Mailing List Archives

SL Baur

Martin Buchholz <martin(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > The latest set of packages leaves me with these messages: > /home/martin/x/mule-packages/lisp/leim/greek hides /home/martin/x/mule-packages/lisp/mule-base/greek > /home/martin/x/mule-packages/lisp/leim/cyrillic hides /home/martin/x/mule-packages/lisp/mule-base/cyrillic > Indeed, leim-1.09-pkg.tar.gz and mule-base-1.22-pkg.tar.gz both have a > cyrillic.el and greek.el. This is a side-effect of the repackaging changes and definitely breaks Cyrillic. I don't think it's wise to have identically named lisp files, but it appears we're stuck. Fix in the next package update.

1 participants
0 comments

Re: Mew problem 25 years, 7 months

SL Baur

Charles G Waldman <cgw(a)pgt.com> writes in xemacs-beta(a)xemacs.org: > Just realized, trying out a bunch of packages on WinNT, the "mew" package > has a little problem - there are two files in the package called > etc/mew/mew-folder.xpm > and > etc/mew/mew-Folder.xpm > which is fine on Unix, but a no-go on a case-insensitive filesystem (like > WinNT). The packaged Mew is a beta. Does MS Windows NT handle the Mew MH replacement?

1 participants
0 comments

Re: glitch in package-get-base.el 25 years, 7 months

SL Baur

Charles G Waldman <cgw(a)pgt.com> writes in xemacs-beta(a)xemacs.org: > xemacs-21.0-b57/lisp/package-get-base.el says: > (xemacs-devel > filename "xemacs-devel-1.16-pkg.tar.gz" > but ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.0/packages/binary-packages > has nothing newer than xemacs-devel-1.15-pkg.tar.gz Packages have been moved to their official home: ftp://ftp.xemacs.org/pub/xemacs/packages/ The old packages were left in their previous location and new packages have been installed in the new location.

1 participants
0 comments

Re: [BUG] Too frequent redisplays 25 years, 7 months

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: ... > To repeat, split XEmacs with `C-x 2' then press `M-: t RET'. You > should see the screen redrawn. This is especially visible and > annoying on TTY's. Duplicated and ... > This bug did not exist in XEmacs 20.4, ... duplicated :-(. > It would be nice if people who understand redisplay could look into > it. Yup.

1 participants
0 comments

Re: [bug] auctex 1.12 binkit 25 years, 7 months

SL Baur

Greg Klanderman <greg(a)alphatech.com> writes in xemacs-beta(a)xemacs.org: > auto-autoloads.el has the wrong version: > (package-provide 'auctex :version 1.09 :type 'regular) AUC TeX was repackaged. Do you still have problems with 1.13?

1 participants
0 comments

Re: Separators on TTY 25 years, 7 months

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > SL Baur <steve(a)xemacs.org> writes: >> Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: >> >> > When a window is split horizontally (C-x 3) on a TTY, no separator is >> > drawn. This used to work correctly in 20.4. >> >> The divider width is explicitly set to 0. > Then this is a bug. It should be 1 on TTY's, not 0. I've already dug around the sources to find who made this change. The closest I can come up with is Kirill (hope he's O.K. and still in Los Angeles). The change made some sense to me because screen real estate is precious in 80x24, but InfoDock reverted it to 1 some time ago and if there is no consensus to keeping it the way it is I am amenable to this change.

1 participants
0 comments

[Nathan Robertson <cyrus1@ozemail.com.au>] The Site 25 years, 7 months

SL Baur

He's right. The screen shots I have on the web are woefully out of date and misindexed. IIRC the late David Moore was doing up a webpage of this sort of thing. Is his work still there?

4 participants
3 comments

Proposed version number change for 21.2 25 years, 7 months

SL Baur

I would like to drop the beta designation as it currently exists and change the version to a triplet -- 21.2.XX. I am undecided whether the string `beta' should remain in the version string. This proposal is biased towards the side of minimal change. In terms of programmer visible changes, the variable `emacs-version' would change from: "21.2 \"Aglaia-pre1\" XEmacs Lucid (beta3)" to: "21.2.3 \"Aglaia-pre1\" XEmacs Lucid (beta)" with the " (beta)" disappearing when the release is imminent. The function `emacs-version' which currently returns (something like) "XEmacs 21.2 \"Aglaia-pre1\" [Lucid] (i586-pc-linux, Mule) of Tue Sep 29 1998 on altair.xemacs.org" would now return: "XEmacs 21.2.3 \"Aglaia-pre1\" [Lucid] (i586-pc-linux, Mule) of Tue Sep 29 1998 on altair.xemacs.org" The variable `emacs-beta-version' gets obsoleted and becomes `emacs-build-version' and the variable `xemacs-betaname' continues as a boolean test whether or not the running XEmacs is experimental or not. This resolves the obvious naming problems when we need multiple post-beta releases prior to 'net release and eliminates the problem of consecutive numbering when shifting from -betaXX to -pre1. If there aren't any serious objections, I'll make a patch which implements this for 21.2.3. Comments?

4 participants
3 comments

Re: CVS problems: how to put xemacs-20 and xemacs-packages together? 25 years, 7 months

SL Baur

[Jareth, are you back? This response might be useful to put up for developers until something more formal gets written.] Joerg Plate <plate(a)psyche.kn-bremen.de> writes in xemacs-beta(a)xemacs.org: > After switching to CVS to get the latest sources, I don't know how > to put things together. I checked out "xemacs-20" > (emacs_major_version=21 emacs_minor_version=0 emacs_beta_version= > xemacs_codename="Poitou") and "xemacs-packages", but when I compile > "XEmacs" the executable "src/xemacs" cannot find the packages in > "xemacs-packages". What is the right place or the right option to > solve this problem. (<URL:http://cvs.xemacs.org> has nothing about > this). The `xemacs-packages' lisp source hierarchy is not intended to be run from. This is a deliberate feature and allows the maintainer/installer to keep multiple incompatible versions of packages around. There are two such in my tree right now -- Pterodactyl Gnus & Gnus 5.6 and VC & VC with clearcase. Another thing to remember is that XEmacs 19 & 20 are bludgeons -- you get hammered with everything whether you want it or not. The current structure is set up to allow the builder to tune to a fairly[1] fine degree what lisp gets installed. As noted below, I only run with about 56% of the total XEmacs packages installed and I enjoy the leaner XEmacs. Before you go any further, make sure you have a full complement of GNU tools. You will need at a minimum GNU make, GNU tar and GNU cp. GNU cp is only needed if you don't have a system cp that preserves timestamps when copying. To bootstrap yourself you only need one package installed -- mule-base. You don't need mule-base if you're not building with Mule. Grab the mule-base binary package tarball from ftp.xemacs.org, create a directory called `mule-packages' in the toplevel XEmacs core source directory and install mule-base there. Configure the XEmacs core as you wish and build but don't `make install'[2]. To build the rest of the XEmacs packages, go into the toplevel xemacs-packages directory and edit XEmacs.rules to fit your installation. You will need to adjust the `XEMACS =' assignment to point to the run-in-place binary you built in the previous step. Comment out the `BUILD_MULE=t' assignment if you're not building with Mule. Note that `PKGDIR' is currently ignored[3]. If you're brave[4], change the `STAGING =' assignment to point to where you are going to install the XEmacs packages. You will install them somewhere based on how you set $prefix when configuring XEmacs. The default is /usr/local, in which case packages get installed in /usr/local/lib/xemacs/xemacs-packages and /usr/local/lib/xemacs/mule-packages. After editing XEmacs.rules, type `make bindist' and let it churn. Depending on the speed of the machine you're building on, this may take awhile. After this is done, create the xemacs-packages and mule-packages directories in $prefix/lib/xemacs and install the -pkg.tar.gz files of the packages you wish to have at run-time. I only install 45 of the 81 available packages for my own use, so don't feel compelled to install everything. If you're installing into an empty directory, a straight `tar zxf' will work. If you're installing into an already populated directory you should always delete the previous version of a package before installing a new one. From the command line: $ rm `cat pkginfo/MANIFEST.${PACKAGE}` where ${PACKAGE} is the name of the package you are installing, will suffice to get rid of the previous version. If you are running with an old package tree that doesn't have the pkginfo directory, $ rm -rf lisp/${PACKAGE} etc/${PACKAGE} should work too. Lisp files get moved and seeing shadowed files at the next XEmacs dump is a sure sign you missed deleting an obsoleted lisp file that got moved to another package. Footnotes: [1] When single-file packages are implemented, you will be able to further tune what lisp files get installed. [2] Well, go ahead and `make install' if you really wish to. It doesn't really matter. I find it easier to run the binary in place during development and only run `make install' on final versions. [3] Now that a safe package delete exists, it will be straightforward to implement a straight `make install' that bypasses tarball generation. [4] And not building with Mule.

1 participants
0 comments

Re: [patch] enhancements to package-ui.el 25 years, 7 months

Darryl Okahata

[ Followups redirected from xemacs-patches to xemacs-beta. ] greg(a)alphatech.com (Greg Klanderman) wrote: > I've added a few enhancements to package-ui.el. I'm not sure these > are the best ways to add this functionality, but I think these things > are sorely needed in some form or another. Darryl, please let me know > what you think about this. > > The patch adds the following features: > > * M-x pui-list-packages now takes a prefix argument. With the > prefix argument, it prompts for a package-get-base.el filename > (using a sane default) which it then loads before doing anything > else. Could you please separate the code that grabs the new package-get-base.el into a separate function (in package-admin.el or package-get.el -- and not package-ui.el)? Reasons: * Sometimes you just want to update package-get-base.el. * People who access these functions via menu picks cannot specify a prefix (there's no way to specify a prefix using menu picks). We'll probably have to provide a separate (?) menu pick that updates package-get-base.el, and maybe yet-another-menu-pick (ugh) that updates package-get-base.el before entering the visual package installer. > Maybe it should just always do this? Dunno. I can think of reasons to do it, and reasons to not do it. > * In the *Packages* buffer, `x' (pui-install-selected-packages) now > takes a prefix argument for whether to also update the packages > required by those you are updating. The variable > pui-default-fetch-requires controls the default and is t by default. This is fine for an interim (temporary) solution, but what we really need is for the installer to (optionally) auto-select all dependent packages (and make it stop automatically grabbing the dependent packages without telling the user). That way the user can see everything that will be installed, and he can then manually unselect anything that he doesn't want (with a suitable warning message when unselecting dependent packages). If this is done, we'd only have to call `package-get' instead of `package-get-all'. > * In the *Packages* buffer, `x' (pui-install-selected-packages) now > prompts for the directory in which to install packages, after > confirming that you'd like to install the selected packages. This feature needs to be added, but your implementation has potential problems: * The package install directory information needs to be managed by package-admin.el. It's best if all the directory information is maintained by one module. * Do we really want to allow installations into arbitrary directories (that is, ones which will NOT be located by XEmacs' automatic package path finder)? This is an issue for novice users. Personally, I think we should restrict package installations to specific "system" locations (e.g., to the package-paths specified at configure time) or to the user-local location ("~/.xemacs/packages"???). Creating a good user-interface for this is a pain, though, and so we might want to just settle for some kind of warning if the user enters a "bad" path. > The remaining issue for me is that if I have a newer version of a > package installed than in package-get-base, it will happily overwrite > it with the older version. Being able to disable installation of This sounds like a bug. Newer versions should never be overwritten with an older one (well, maybe we should provide yet another prefix arg/variable that forces an installation for advanced users). -- Darryl Okahata darrylo(a)sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day.

2 participants
1 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