5:17 p.m.
Oops. Looks like my announcement generating scripts broke, and the
whole "brief list of changes" went missing. I'll fix that, but all
the information is in the ChangeLogs, so I won't spam the list with a
repost. Or, please give it a day and look at
http://www.xemacs.org/Releases/21.5.23.html
Better yet, download the release, check out CHANGES-beta, then build
and M-x build-report!
Steve
* XEmacs 21.5.23 "daikon" is released.
"daikon" is the twenty-fourth in the VEGETABLE series.
The successor to XEmacs 21.5.22 "cucumber", "daikon" adds mouse
pointers
generated from any color image format supported by XEmacs (adding the
modern GIF, JPEG, PNG, or TIFF formats to the increasingly rare XPM
format already supported). Support for building with arbitrary precision
arithmetic (GMP), and the Berkeley db, PostgreSQL, and LDAP databases
has been provided for native Windows NT builds. Unexec support for _LP64
architectures was fixed (at least for FreeBSD).
A number of LISP APIs and commands have been synced to conform to GNU's
(unreleased) Emacs 22. Garbage collection now triggers on a threshold
relative to total memory allocated, which reduces the frequency.
`specifier-instantiator' and related primitives were added.
Motif is no longer the default toolkit on any platform except Sun. You
need to specify --with-dialogs=motif, etc, explicitly.
XEmacs's configure no longer makes that annoying distinction between
`--with-foo' and `--enable-foo'; these now invoke the same
configuration logic for all features `foo'. Also, with non-null
argument --with-cflags-optimization now forces --with-optimization on.
For distributors, Canna support has been moved to a module,
eliminating hard dependencies on the Canna package in binary packages.
A wide variety of minor bugfixes and documentation improvements were made.
For particulars, see the brief summary of changes and list of ChangeLogs
below.
This is the development line. The current series started with XEmacs 21.5.0
(an alias for XEmacs 21.4.0 "Solid Vapor", the first release in the current
stable line). 21.5 is the code base for introduction of major new subsystems
and fixes to design bugs that experience shows will introduce instability.
So far the main effort has been on improved support for Unicode, updates to
the build infrastructure, and development of new features in memory allocation.
For general information about XEmacs, the developers, and the user community,
see our home page,
http://www.xemacs.org/
* XEmacs 21.5.23 is "beta" software.
The usual "no warranty" disclaimer (see etc/WARRANTY, sections 10 and 11)
applies. At this point in time, it is the version that most developers
are using for their daily work. However, it is certain that many bugs
remain and new ones will be introduced as development proceeds. Be sure
to take care to safe your work often and follow a regular backup regime.
* Availability
Anonymous ftp:
ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.5
See http://www.xemacs.org/Install/ for more information about building
from source.
If you already have a 21.5.22 source tree, a patchkit is available in
xemacs-21.5.22-21.5.23.patch.gz. This does not update .elcs or .infos,
they will be rebuilt when you make XEmacs. If you have an earlier
version, you can repeatedly apply patchkits.
Also, if you don't have the packages yet, see
http://www.xemacs.org/Documentation/packageGuide.html.
Anonymous (pserver) CVS:
Anonymous CVS is available. We are very grateful to the staff at our
host, SunSITE.dk, for a lot of help and quick reponse to all our
requests.
Take care that your Root is set correctly to
CVSROOT=:pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs
On platforms with a Bourne shell and find available, something like
for r in `find . -name Root`; do echo $CVSROOT > $r; done
will convert your entire tree.
To make it straightforward to access certain versions of the code, we have
a standard tagging policy. To update to release 21.5.23, use the update
flag "-r r21-5-23". To update to the current release without referring to
it specifically, use the flag "-r r21-5-current-beta". To update to the
latest commits in CVS, use the flag "-A". Then rebuild XEmacs.
For more details, see
http://www.xemacs.org/Develop/cvsaccess.html .
* Brief summary of Changes to XEmacs 21.5.23 "daikon"
Major features
User-Visible Bug Fixes and Minor Improvements
Build Infrastructure
Documentation
Lisp API
Internal API and Implementation
-------- ChangeLog Entries from ChangeLog --------
2005-10-26 Stephen J. Turnbull <stephen(a)xemacs.org>
* XEmacs 21.5.23 "daikon" is released.
2005-10-25 Malcolm Purvis <malcolmp(a)xemacs.org>
* configure.ac: Prefer Xaw to Motif on Linux, Mac and BSD. From
21.4.
* configure.ac (XE_PARSE_COMPLEX_OPTION): Remove debugging.
Fix broken --with-<complex>=no.
2005-10-20 Malcolm Purvis <malcolmp(a)xemacs.org>
* INSTALL: Reflect changes in the configure options. Update MacOS
X X11 installation instructions to reflect the changes in recent
OS releases.
2005-10-15 Malcolm Purvis <malcolmp(a)xemacs.org>
* configure.ac: Added XE_MERGED_ARG to alias all local --enable
and --with options. Configure can only be built with autoconf
2.59. Prevent many unwanted blank lines from appearing in
configure.
2005-10-13 Ben Wing <ben(a)xemacs.org>
* configure.ac (XE_COMPLEX_ARG_ENABLE):
Break lines.
* configure.ac (TAB):
Rewrite optimization help to be accurate. Setting
`--with-cflags-optimization=""' will now unilaterally turn off
optimization; setting it to something non-null unilaterally turns it
on.
2005-09-22 Stephen J. Turnbull <stephen(a)xemacs.org>
* configure.ac (Canna): Configure as module if appropriate.
* Makefile.in.in (modules/canna): Add dependency on lib-src (ellcc).
2005-09-18 Mike Alexander <mta(a)arbortext.com>
* configure.ac: Fix the cygwin, non-X build by adding XPM header
and library files to XE_CFLAGS. Patch from Rick Rankin.
2005-09-17 Malcolm Purvis <malcolmp(a)xemacs.org>
* configure.in: Replace with warning to use autoconf 2.59.
* configure.ac: Removed warning about the use of autoconf 2.59.
-------- ChangeLog Entries from etc/ChangeLog --------
2005-10-26 Stephen J. Turnbull <stephen(a)xemacs.org>
* XEmacs 21.5.23 "daikon" is released.
2005-09-17 Malcolm Purvis <malcolmp(a)xemacs.org>
* configure-2.13: Remove. autoconf 2.59 support is stable.
-------- ChangeLog Entries from lib-src/ChangeLog --------
2005-10-26 Stephen J. Turnbull <stephen(a)xemacs.org>
* XEmacs 21.5.23 "daikon" is released.
2005-10-13 Ben Wing <ben(a)xemacs.org>
* i.c:
* mmencode.c:
Always include config.h first.
* winclient.c:
Move include of windows.h after config.h.
2005-09-18 Mike Alexander <mta(a)arbortext.com>
* installexe.sh: Don't add an exe extention to a file that already
has one. Patch from Rick Rankin.
-------- ChangeLog Entries from lisp/ChangeLog --------
2005-10-26 Stephen J. Turnbull <stephen(a)xemacs.org>
* XEmacs 21.5.23 "daikon" is released.
2005-10-25 Ben Wing <ben(a)xemacs.org>
* cus-face.el:
* cus-face.el (custom-face-attributes):
* cus-face.el (custom-face-background-pixmap):
* cus-face.el (custom-set-face-inherit): New.
* cus-face.el (custom-face-inherit): New.
* faces.el:
* faces.el (face-property):
* faces.el (convert-face-property-into-specifier):
* faces.el (face-property-instance):
* faces.el (set-face-property):
* faces.el (reset-face):
* faces.el (set-face-parent):
* faces.el (face-font-name):
* faces.el (face-font):
* faces.el (face-font-instance):
* faces.el (set-face-font):
* faces.el (face-foreground):
* faces.el (face-foreground-instance):
* faces.el (set-face-foreground):
* faces.el (face-background):
* faces.el (face-background-instance):
* faces.el (set-face-background):
* faces.el (face-background-pixmap):
* faces.el (face-background-pixmap-instance):
* faces.el (set-face-background-pixmap):
* faces.el (face-display-table):
* faces.el (face-display-table-instance):
* faces.el (face-equal):
* faces.el (init-face-from-resources):
Provide a basic implementation of the `inherit' property for
faces and the :inherit property in custom. Use the new
`specifier-instantiator' function.
Update the documentation for various places in faces.el.
'foo -> `foo'.
2005-10-25 Adrian Aichner <adrian(a)xemacs.org>
* package-get.el (package-get-download-sites): Fixes after
checklink and linklint testing.
* package-get.el (package-get-pre-release-download-sites): Ditto.
2005-10-24 Ben Wing <ben(a)xemacs.org>
* next-error.el (compilation-current-error):
* next-error.el (compilation-current-error)): New.
* next-error.el (compilation-context-lines)): New.
* occur.el (occur-accumulate-lines):
* occur.el (multi-occur):
Fix some byte-compile warnings.
2005-10-23 Adrian Aichner <adrian(a)xemacs.org>
* package-get.el (package-get-download-sites): Sync packages
mirrors list with website, based on Ville's work.
* package-get.el (package-get-pre-release-download-sites): Sync
with `package-get-download-sites'.
2005-10-18 Ville Skyttä <scop(a)xemacs.org>
* package-get.el (package-get-download-sites): Sync mirrors list
with the XEmacs website.
(package-get-pre-release-download-sites): Ditto.
2005-10-21 Stephen J. Turnbull <stephen(a)xemacs.org>
UNDO:
* mule/canna-leim.el: Rename canna_api to canna-api.
2005-10-21 Stephen J. Turnbull <stephen(a)xemacs.org>
* build-report.el: Note synch to XEmacs build package version 1.49.
2005-10-04 Stephen J. Turnbull <stephen(a)xemacs.org>
* build-report.el (build-report): Refactor into interactive
portion and `build-report-create-report'.
(build-report-create-report): New function.
(batch-build-report): Non-interactive version of `build-report'
using `build-report-create-report'.
2005-10-10 Malcolm Purvis <malcolmp(a)xemacs.org>
* minibuf.el:
* minibuf.el (read-buffer): Follow GNU Emacs behaviour: Can return
empty string if require-match is t and default is nil.
* replace.el: Moved occur code to occur.el
* simple.el:
* simple.el (line-number-at-pos): New.
* subr.el:
* subr.el (delete-dups): New.
* occur.el: New. Sync with 22.0.50.1 (CVS)
* next-error.el: New. Sync with 22.0.50.1 (CVS)
2005-10-10 Steve Youngs <steve(a)sxemacs.org>
* help.el (view-emacs-news): Use `expand-file-name' instead of
`locate-data-file' as the latter will find any "NEWS" files that
might exist in packages _before_ the one in core.
2005-10-09 Adrian Aichner <adrian(a)xemacs.org>
* finder.el (finder-find-library): Return filename actually
searched for.
2005-10-04 Stephen J. Turnbull <stephen(a)xemacs.org>
* simple.el (xemacs-default-composefunc): Don't warn when batch.
2005-10-04 Stephen J. Turnbull <stephen(a)xemacs.org>
* build-report.el: Synch to Adrian's packaged version.
2005-10-04 Stephen J. Turnbull <stephen(a)xemacs.org>
* mule/canna-leim.el: Rename canna_api to canna-api.
2005-09-30 Stephen J. Turnbull <stephen(a)xemacs.org>
* mule/canna-leim.el (canna-activate): Fix typo in error symbol.
Improve docstring.
2005-09-22 Stephen J. Turnbull <stephen(a)xemacs.org>
* mule/canna-leim.el: Add comment on autoloading strategy.
(canna-activate): Handle CANNA in ELL.
* dumped-lisp.el (preloaded-file-list): Remove dependency of
canna-leim on CANNA. Canna may be an ELL.
2005-09-21 Stephen J. Turnbull <stephen(a)xemacs.org>
* mule/mule-cmds.el (input-method-alist, register-input-method):
Improve docstrings and formal parameter names.
-------- ChangeLog Entries from lwlib/ChangeLog --------
2005-10-26 Stephen J. Turnbull <stephen(a)xemacs.org>
* XEmacs 21.5.23 "daikon" is released.
2005-10-25 Ben Wing <ben(a)xemacs.org>
* lwlib-internal.h (assert):
redo assert macros to follow lisp.h and not trigger warnings.
* lwlib.c (merge_scrollbar_values):
* lwlib.c (merge_widget_value_args):
* xlwtabs.c:
* xlwtabs.c (TabsInit):
* xlwtabs.c (TabsConstraintInitialize):
* xlwtabs.c (TabsSetValues):
* xlwtabs.c (TabsConstraintSetValues):
new -> new_.
-------- ChangeLog Entries from man/ChangeLog --------
2005-10-26 Stephen J. Turnbull <stephen(a)xemacs.org>
* XEmacs 21.5.23 "daikon" is released.
2005-10-20 Malcolm Purvis <malcolmp(a)xemacs.org>
* xemacs-faq.texi (Q1.2.2):
* xemacs-faq.texi (Q2.1.1):
* xemacs-faq.texi (Q2.1.6):
* xemacs-faq.texi (Q2.2.1):
* xemacs-faq.texi (Q2.3.6):
* xemacs-faq.texi (Q2.4.3):
* xemacs-faq.texi (Q2.4.4):
* xemacs-faq.texi (Q2.4.7):
* xemacs-faq.texi (Q5.3.3):
* xemacs-faq.texi (Q6.0.8):
* xemacs-faq.texi (Q7.2.1):
Add 21.5 specific examples of configure options in addition to the
existing 21.4 ones.
2005-10-15 Malcolm Purvis <malcolmp(a)xemacs.org>
* internals/internals.texi: "API's" -> "APIs". This fixes
problems generating dvi and pdf versions.
* internals/internals.texi (The configure Script):
Describe the use of XE_MERGED_ARG.
2005-10-13 Ben Wing <ben(a)xemacs.org>
* xemacs-faq.texi (Top):
* xemacs-faq.texi (External Subsystems):
* xemacs-faq.texi (Q5.4.4):
* xemacs-faq.texi (Q5.4.5):
* xemacs-faq.texi (Q5.4.6):
Add question about need to run `rebaseall' under Cygwin.
2005-10-04 Stephen J. Turnbull <stephen(a)xemacs.org>
* emodules.texi (Distribution with XEmacs): New node describing
organization of module-related code in top-level configure.ac and
src/Makefile.in.in.
2005-09-27 Adrian Aichner <adrian(a)xemacs.org>
* lispref/compile.texi (Compilation Options): Lowercase SYMBOL
argument in `byte-compile-print-gensym' documentation, as
suggested by Stephen.
2005-09-27 Adrian Aichner <adrian(a)xemacs.org>
* lispref/packaging.texi: Get file to compile with teinfmt.el.
* lispref/packaging.texi (Packaging): Ditto.
* lispref/packaging.texi (Package Overview): Ditto.
* lispref/packaging.texi (The User View): Ditto.
* lispref/packaging.texi (The Library Maintainer View): Ditto.
* lispref/packaging.texi (Infrastructure): Ditto.
* lispref/packaging.texi (Obtaining): Ditto.
* lispref/packaging.texi (Local.rules File): Ditto.
* lispref/packaging.texi (package-info.in): Ditto.
* lispref/packaging.texi (Makefile): Ditto.
* lispref/packaging.texi (Documenting Packages): Ditto.
2005-09-27 Adrian Aichner <adrian(a)xemacs.org>
* internals/internals.texi (A Summary of the Various XEmacs
Modules): Get file to compile with texinfmt.el.
* internals/internals.texi (Windows Build Flags): Ditto.
2005-09-26 Ben Wing <ben(a)xemacs.org>
* lispref/glyphs.texi (Images):
* lispref/glyphs.texi (Image Instantiators):
* lispref/glyphs.texi (Image Instantiator Formats):
* lispref/glyphs.texi (Image Instances):
* lispref/glyphs.texi (Image Instance Functions):
* lispref/glyphs.texi (Creating Glyphs):
* lispref/glyphs.texi (Lisp API to Native Widgets):
* lispref/glyphs.texi (Glyph Properties):
* lispref/glyphs.texi (Glyph Examples):
* lispref/lispref.texi (Top):
* lispref/specifiers.texi (Specifiers):
* lispref/specifiers.texi (Introduction to Specifiers):
* lispref/specifiers.texi (Simple Specifier Usage):
* lispref/specifiers.texi (Specifiers In-Depth):
* lispref/specifiers.texi (Specifier Instantiation):
* lispref/specifiers.texi (Retrieving Specifications):
* lispref/specifiers.texi (Specifier Tag Functions):
* lispref/specifiers.texi (Specifier Validation Functions):
Use "instantiation" not "instancing". Fix some places where
"specifier" is used to mean "instantiator".
2005-09-25 Adrian Aichner <adrian(a)xemacs.org>
* lispref/compile.texi (Compilation Options): Supply missing
argument to ＠var{}, using same SYMBOL as in variable docstring of
`byte-compile-print-gensym'.
-------- ChangeLog Entries from modules/ChangeLog --------
2005-10-26 Stephen J. Turnbull <stephen(a)xemacs.org>
* XEmacs 21.5.23 "daikon" is released.
2005-10-22 Stephen J. Turnbull <stephen(a)xemacs.org>
Warning elimination:
* ldap/eldap.c (Fldap_add): Remove declaration of `current', which
is now declared by EXTERNAL_LIST_LOOP_2.
(Fldap_modify): Remove redundant variable `gcpro2',
2005-10-25 Ben Wing <ben(a)xemacs.org>
* postgresql/postgresql.c (allocate_pgconn):
* postgresql/postgresql.c (allocate_pgresult):
* postgresql/postgresql.h (struct Lisp_PGconn):
* postgresql/postgresql.h (struct Lisp_PGresult):
MC-Alloc refactoring.
2005-10-25 Ben Wing <ben(a)xemacs.org>
* ldap/eldap.c (allocate_ldap):
* ldap/eldap.h (struct Lisp_LDAP):
MC-Alloc refactoring.
2005-10-21 Stephen J. Turnbull <stephen(a)xemacs.org>
UNDO:
* canna/canna-api.c:
* canna/Makefile.in.in (MODNAME,SRCS):
Rename module from canna_api to canna-api.
2005-10-21 Stephen J. Turnbull <stephen(a)xemacs.org>
* canna/configure: Create and CVS add.
2005-10-04 Stephen J. Turnbull <stephen(a)xemacs.org>
* canna/Makefile.in.in (MODVER): Bump to 0.5.
* canna/canna-api.c:
* canna/Makefile.in.in (MODNAME,SRCS):
Rename module from canna_api to canna-api.
2005-09-22 Stephen J. Turnbull <stephen(a)xemacs.org>
* canna: New module.
* canna/canna_api.c: Move from $srcdir/src/mule-canna.c. Add module
initialization function and some boilerplate. Change name to
canna_api to reflect changed role.
* canna/configure.ac:
* canna/Makefile.in.in:
* canna/install-sh:
Standard module boilerplate, adapted to Canna.
-------- ChangeLog Entries from netinstall/ChangeLog --------
2005-10-26 Stephen J. Turnbull <stephen(a)xemacs.org>
* XEmacs 21.5.23 "daikon" is released.
-------- ChangeLog Entries from nt/ChangeLog --------
2005-10-26 Stephen J. Turnbull <stephen(a)xemacs.org>
* XEmacs 21.5.23 "daikon" is released.
2005-09-26 Ben Wing <ben(a)xemacs.org>
* README:
Major rewrite. Document how to compile various optional libs.
* config.inc.samp:
Update to recent versions of optional libs. Add support for
gmp, db, postgresql, ldap. Turn on optimization when not debug.
* minitar.c:
Include config.h.
* xemacs.mak:
* xemacs.mak (HAVE_WIDGETS):
* xemacs.mak (OPT_DEFINES):
* xemacs.mak (OPT_OBJS):
* xemacs.mak (BROWSERFLAGS):
* xemacs.mak (INCLUDES):
* xemacs.mak (DEFINES):
* xemacs.mak (TEMACS_COMMON_OBJS):
* xemacs.mak (TEMACS_OBJS):
* xemacs.mak ($(OUTDIR)\postgresql.obj):
* xemacs.mak ($(BLDLIB_SRC)/minitar.exe):
* xemacs.mak ( NOTE):
* xemacs.mak (TEMACS_LIBS):
* xemacs.mak ($(RAW_EXE)):
* xemacs.mak (mostlyclean):
* xemacs.mak (versionclean):
Figure out VC++ version and use it to set debug and browser flags
appropriately.
Add support for building gmp, db, postgresql, ldap.
Rewrite handling of optional stuff so it is all added to single
variables OPT_* rather than to various FOO_* variables.
Pass -I$(SRC) to minitar.c so it compiles.
Pass module sources, not objects, to make-docfile.
Delete more stuff in `make clean'.
2005-09-25 Adrian Aichner <adrian(a)xemacs.org>
* xemacs.mak: Fix variable initialization order.
-------- ChangeLog Entries from nt/installer/Wise/ChangeLog --------
2005-10-26 Stephen J. Turnbull <stephen(a)xemacs.org>
* XEmacs 21.5.23 "daikon" is released.
-------- ChangeLog Entries from src/ChangeLog --------
2005-10-26 Stephen J. Turnbull <stephen(a)xemacs.org>
* XEmacs 21.5.23 "daikon" is released.
2005-10-22 Stephen J. Turnbull <stephen(a)xemacs.org>
* lrecord.h: Explain the EXTERNAL_LRECORD macros better.
2005-10-25 Ben Wing <ben(a)xemacs.org>
* config.h.in (EXTERN_C):
Don't define new and catch under C++ any more.
(Places using new were just fixed by the last patch, places using
catch were fixed a couple of weeks ago.)
2005-10-25 Ben Wing <ben(a)xemacs.org>
* EmacsFrame.c (EmacsFrameInitialize):
* EmacsFrame.c (EmacsFrameSetValues):
* ExternalClient.c:
* ExternalClient.c (externalClientInitialize):
* ExternalShell.c:
* ExternalShell.c (ExternalShellInitialize):
* chartab.c (copy_char_table_entry):
* chartab.c (Fcopy_char_table):
* cmdloop.c:
* cmdloop.c (initial_command_loop):
* compiler.h:
* console.c (Fvalid_console_type_p):
* database.c:
* device-msw.c:
* device-x.c:
* device.c (Fvalid_device_class_p):
* device.c (Fdevice_class):
* device.c (Fset_device_class):
* device.c (Fdomain_device_type):
* doc.c (Fsubstitute_command_keys):
* dragdrop.c:
* eval.c:
* eval.c (throw_or_bomb_out):
* eval.c (Fsignal):
* event-msw.c:
* event-msw.c (vars_of_event_mswindows):
* event-stream.c (execute_internal_event):
* event-stream.c (push_this_command_keys):
* events.c:
* extents.c (Fset_extent_parent):
* extents.c (get_char_property):
* extents.c (put_text_prop_mapper):
* file-coding.c:
* file-coding.c (Fvalid_coding_system_type_p):
* file-coding.c (Fdetect_coding_region):
* fns.c (Freplace_list):
* frame-tty.c (tty_lower_frame):
* frame.c:
* frame.c (Fframe_visible_p):
* gpmevent.c (Fgpm_enable):
* gutter.c (Fset_default_gutter_position):
* gutter.c (gutter_size_validate):
* gutter.c (specifier_vars_of_gutter):
* hash.c (KEYS_DIFFER_P):
* imgproc.c (splitbox):
* indent.c:
* keymap.c:
* keymap.c (copy_keymap_mapper):
* keymap.c (define_key_check_and_coerce_keysym):
* keymap.c (event_matches_key_specifier_p):
* keymap.c (process_event_binding_result):
* keymap.c (where_is_recursive_mapper):
* lisp-union.h:
* lisp-union.h (union Lisp_Object):
* macros.c (store_kbd_macro_event):
* malloc.c (realloc):
* marker.c (copy_marker_1):
* menubar-x.c (menu_move_down):
* menubar.c:
* menubar.c (vars_of_menubar):
* mule-charset.c:
* mule-charset.c (Fmake_charset):
* mule-charset.c (Fcharset_property):
* mule-charset.c (Fset_charset_ccl_program):
* mule-charset.c (Fset_charset_registry):
* number.c:
* process.c:
* profile.h:
* ralloc.c (obtain):
* redisplay.c:
* redisplay.c (get_display_block_from_line):
* redisplay.c (redisplay_frame):
* redisplay.c (vars_of_redisplay):
* redisplay.c (specifier_vars_of_redisplay):
* select-common.h:
* select.c:
* select.c (vars_of_select):
* syntax.c:
* syntax.c (scan_sexps_forward):
* sysfile.h:
* sysproc.h:
* systime.h:
* syswindows.h:
* toolbar.c (Fset_default_toolbar_position):
* toolbar.c (Fcheck_toolbar_button_syntax):
* toolbar.c (specifier_vars_of_toolbar):
* tooltalk.c:
* tooltalk.c (Freturn_tooltalk_message):
* tooltalk.c (Fadd_tooltalk_message_arg):
* tooltalk.c (Fadd_tooltalk_pattern_attribute):
* tparam.c (tparam1):
* unexaix.c (PERROR):
* unexaix.c (ERROR0):
* unexaix.c (unexec):
* unexaix.c (make_hdr):
* unexaix.c (copy_text_and_data):
* unexaix.c (write_segment):
* unexaix.c (copy_sym):
* unexaix.c (mark_x):
* unexaix.c (adjust_lnnoptrs):
* unexaix.c (unrelocate_symbols):
* unexalpha.c (unexec):
* unexalpha.c (update_dynamic_symbols):
* unexconvex.c (PERROR):
* unexconvex.c (ERROR0):
* unexconvex.c (entry_address;):
* unexconvex.c (make_hdr):
* unexconvex.c (new_;):
* unexconvex.c (sptr;):
* unexconvex.c (copy_sym):
* unexconvex.c (name;):
* unexec.c:
* unexec.c (PERROR):
* unexec.c (ERROR0):
* unexec.c (unexec):
* unexec.c (make_hdr):
* unexec.c (write_segment):
* unexec.c (copy_sym):
* unexec.c (mark_x):
* unexec.c (adjust_lnnoptrs):
* unexhp9k800.c:
* unexhp9k800.c (unexec):
* unexhp9k800.c (copy_file):
* unexhp9k800.c (copy_rest):
* unexmips.c (unexec):
* unicode.c:
* unicode.c (Fchar_to_unicode):
* window.c (make_dummy_parent):
* window.c (Fsplit_window):
* window.c (Fenlarge_window):
new -> new_.
'foo -> `foo'.
2005-10-25 Ben Wing <ben(a)xemacs.org>
* alloc.c:
* alloc.c (old_basic_alloc_lcrecord):
* alloc.c (very_old_free_lcrecord):
* alloc.c (disksave_object_finalization_1):
* alloc.c (copy_lisp_object):
* alloc.c (make_lcrecord_list):
* alloc.c (alloc_managed_lcrecord):
* alloc.c (old_free_lcrecord):
* alloc.c (GC_CHECK_NOT_FREE):
* alloc.c (tick_lcrecord_stats):
* alloc.c (sweep_lcrecords_1):
* buffer.c (compute_buffer_usage):
* buffer.c (DEFVAR_BUFFER_LOCAL_1):
* console.c (DEFVAR_CONSOLE_LOCAL_1):
* emacs.c:
* emacs.c (main_1):
* file-coding.c (allocate_coding_system):
* lrecord.h:
* lrecord.h (struct old_lcrecord_header):
* lrecord.h (struct free_lcrecord_header):
* lrecord.h (struct lrecord_implementation):
* lrecord.h (struct lcrecord_list):
* lrecord.h (old_alloc_lcrecord_type):
* lrecord.h (old_copy_sized_lcrecord):
* lrecord.h (old_zero_lcrecord):
* lstream.c (Lstream_new):
* mule-charset.c (compute_charset_usage):
* print.c (debug_p4):
* scrollbar-gtk.c (gtk_compute_scrollbar_instance_usage):
* scrollbar-msw.c (mswindows_compute_scrollbar_instance_usage):
* scrollbar-x.c (x_compute_scrollbar_instance_usage):
* scrollbar.c (compute_scrollbar_instance_usage):
* symbols.c (guts_of_unbound_marker):
* symeval.h (DEFVAR_SYMVAL_FWD):
* unicode.c (compute_from_unicode_table_size_1):
* unicode.c (compute_to_unicode_table_size_1):
* window.c (compute_window_mirror_usage):
* window.c (compute_window_usage):
* xemacs.def.in.in:
rename `struct lcrecord_header' to `struct old_lcrecord_header';
likewise for `old_basic_alloc_lcrecord', `old_free_lcrecord',
`old_zero_lcrecord', `old_zero_sized_lcrecord', `old_copy_lcrecord',
`old_copy_sized_lcrecord', `old_alloc_lcrecord_type'. Created new
LISPOBJ_STORAGE_SIZE() used only on objects created through allocation
of Lisp-Object memory instead of basic xmalloc()/xfree(). This is
distinguished from malloced_storage_size(), for non-Lisp-Objects.
The definition of LISPOBJ_STORAGE_SIZE() can reduce down to
malloced_storage_size() when not MC-ALLOC, but with MC-ALLOC it's
a different function.
The whole point other than cleaning up the use of LISPOBJ_STORAGE_SIZE
is to make it harder to accidentally use the old kind (lowercase) of
function in new code, since you get a compile error.
2005-10-25 Ben Wing <ben(a)xemacs.org>
* frame-msw.c (mswindows_window_id):
Fix warning.
2005-10-24 Ben Wing <ben(a)xemacs.org>
* frame-msw.c:
* frame-msw.c (decode_mswindows_frame):
New function, like decode_x_frame.
* frame-msw.c (mswindows_window_id):
* frame-msw.c (mswindows_frame_property):
* frame-msw.c (mswindows_internal_frame_property_p):
* frame-msw.c (mswindows_frame_properties):
* frame-msw.c (vars_of_frame_mswindows):
Add `window-id' property for MS Windows frames.
2005-10-24 Ben Wing <ben(a)xemacs.org>
* alloc.c:
* alloc.c (Lisp_Free):
* alloc.c (Fcons):
* alloc.c (noseeum_cons):
* alloc.c (make_float):
* alloc.c (make_bignum):
* alloc.c (make_bignum_bg):
* alloc.c (make_ratio):
* alloc.c (make_ratio_bg):
* alloc.c (make_ratio_rt):
* alloc.c (make_bigfloat):
* alloc.c (make_bigfloat_bf):
* alloc.c (make_vector_internal):
* alloc.c (make_bit_vector_internal):
* alloc.c (make_compiled_function):
* alloc.c (Fmake_symbol):
* alloc.c (allocate_extent):
* alloc.c (allocate_event):
* alloc.c (make_key_data):
* alloc.c (make_button_data):
* alloc.c (make_motion_data):
* alloc.c (make_process_data):
* alloc.c (make_timeout_data):
* alloc.c (make_magic_data):
* alloc.c (make_magic_eval_data):
* alloc.c (make_eval_data):
* alloc.c (make_misc_user_data):
* alloc.c (Fmake_marker):
* alloc.c (noseeum_make_marker):
* buffer.c (allocate_buffer):
* buffer.c (compute_buffer_usage):
* buffer.c (nuke_all_buffer_slots):
* buffer.c (common_init_complex_vars_of_buffer):
* buffer.h (struct buffer):
* casetab.c (allocate_case_table):
* casetab.h (struct Lisp_Case_Table):
* charset.h (struct Lisp_Charset):
* chartab.c (fill_char_table):
* chartab.c (Fmake_char_table):
* chartab.c (make_char_table_entry):
* chartab.c (copy_char_table_entry):
* chartab.c (Fcopy_char_table):
* chartab.c (put_char_table):
* chartab.h (struct Lisp_Char_Table_Entry):
* chartab.h (struct Lisp_Char_Table):
* console-impl.h (struct console):
* console-msw-impl.h (struct Lisp_Devmode):
* console-msw-impl.h (struct mswindows_dialog_id):
* console.c (allocate_console):
* console.c (nuke_all_console_slots):
* console.c (common_init_complex_vars_of_console):
* data.c (make_weak_list):
* data.c (make_weak_box):
* data.c (make_ephemeron):
* database.c (struct Lisp_Database):
* database.c (allocate_database):
* device-impl.h (struct device):
* device-msw.c (allocate_devmode):
* device.c (nuke_all_device_slots):
* device.c (allocate_device):
* dialog-msw.c (handle_question_dialog_box):
* elhash.c (struct Lisp_Hash_Table):
* elhash.c (make_general_lisp_hash_table):
* elhash.c (Fcopy_hash_table):
* events.h (struct Lisp_Timeout):
* events.h (struct command_builder):
* extents-impl.h (struct extent_auxiliary):
* extents-impl.h (struct extent_info):
* extents.c (allocate_extent_auxiliary):
* extents.c (allocate_extent_info):
* extents.c (copy_extent):
* faces.c (allocate_face):
* faces.h (struct Lisp_Face):
* file-coding.c (Fcopy_coding_system):
* file-coding.h (struct Lisp_Coding_System):
* frame-impl.h (struct frame):
* frame.c (nuke_all_frame_slots):
* frame.c (allocate_frame_core):
* glyphs.c (allocate_image_instance):
* glyphs.c (Fcolorize_image_instance):
* glyphs.c (allocate_glyph):
* glyphs.h (struct Lisp_Image_Instance):
* glyphs.h (struct Lisp_Glyph):
* gui.c (allocate_gui_item):
* gui.h (struct Lisp_Gui_Item):
* keymap.c (struct Lisp_Keymap):
* keymap.c (make_keymap):
* lisp.h (struct Lisp_Vector):
* lisp.h (struct Lisp_Bit_Vector):
* lisp.h (struct weak_box):
* lisp.h (struct ephemeron):
* lisp.h (struct weak_list):
* lrecord.h:
* lrecord.h (struct toolbar_button):
* lstream.c (COPY_SIZED_LCRECORD):
* lstream.h (struct lstream):
* mule-charset.c (make_charset):
* mule-charset.c (compute_charset_usage):
* objects-impl.h (struct Lisp_Color_Instance):
* objects-impl.h (struct Lisp_Font_Instance):
* objects.c (Fmake_color_instance):
* objects.c (Fmake_font_instance):
* objects.c (reinit_vars_of_objects):
* opaque.c (make_opaque):
* opaque.h (Lisp_Opaque):
* opaque.h (Lisp_Opaque_Ptr):
* print.c (default_object_printer):
* process.c (make_process_internal):
* procimpl.h (struct Lisp_Process):
* rangetab.c (Fmake_range_table):
* rangetab.c (Fcopy_range_table):
* rangetab.h (struct Lisp_Range_Table):
* scrollbar-gtk.c (gtk_compute_scrollbar_instance_usage):
* scrollbar-msw.c (mswindows_compute_scrollbar_instance_usage):
* scrollbar-x.c (x_compute_scrollbar_instance_usage):
* scrollbar.c (create_scrollbar_instance):
* scrollbar.c (compute_scrollbar_instance_usage):
* scrollbar.h (struct scrollbar_instance):
* specifier.c (make_specifier_internal):
* specifier.h (struct Lisp_Specifier):
* symbols.c (Fdefvaralias):
* symeval.h (SYMBOL_VALUE_MAGIC_P):
* toolbar.c (update_toolbar_button):
* toolbar.h (struct toolbar_button):
* tooltalk.c (struct Lisp_Tooltalk_Message):
* tooltalk.c (make_tooltalk_message):
* tooltalk.c (struct Lisp_Tooltalk_Pattern):
* tooltalk.c (make_tooltalk_pattern):
* ui-gtk.c (allocate_ffi_data):
* ui-gtk.c (allocate_emacs_gtk_object_data):
* ui-gtk.c (allocate_emacs_gtk_boxed_data):
* ui-gtk.h:
* unicode.c (compute_from_unicode_table_size_1):
* unicode.c (compute_to_unicode_table_size_1):
* window-impl.h (struct window):
* window-impl.h (struct window_mirror):
* window.c (allocate_window):
* window.c (new_window_mirror):
* window.c (make_dummy_parent):
* window.c (compute_window_mirror_usage):
* window.c (compute_window_usage):
Eliminate the majority of #ifdef MC_ALLOC occurrences through
macros LCRECORD_HEADER, ALLOC_LCRECORD_TYPE, MALLOCED_STORAGE_SIZE,
etc. (defined in lrecord.h).
2005-10-21 Stephen J. Turnbull <stephen(a)xemacs.org>
* Makefile.in.in (mule_canna_objs): Revert canna-api to canna_api.
2005-10-13 Ben Wing <ben(a)xemacs.org>
* config.h.in:
* alloc.c:
* alloc.c (struct):
* alloc.c (alloc_lrecord):
* alloc.c (noseeum_alloc_lrecord):
* alloc.c (finalize_string):
* alloc.c (make_uninit_string):
* alloc.c (make_string_nocopy):
* alloc.c (garbage_collect_1):
* alloc.c (object_memory_usage_stats):
* alloc.c (HACK_O_MATIC):
* alloc.c (Fgarbage_collect):
* alloc.c (Ftotal_memory_usage):
* alloc.c (recompute_need_to_garbage_collect):
* alloc.c (common_init_alloc_early):
* alloc.c (syms_of_alloc):
* alloc.c (vars_of_alloc):
* dumper.c (pdump_load_finish):
* emacs.c:
* emacs.c (main_1):
* emacs.c (shut_down_emacs):
* lrecord.h:
* lrecord.h (MC_ALLOC_CALL_FINALIZER):
* mc-alloc.c (remove_cell):
* mc-alloc.h:
* symbols.c (init_symbols_once_early):
Rename MC_ALLOC_TYPE_STATS to ALLOC_TYPE_STATS, since
(with refactoring) this is not really specific to mc-alloc.
Generalize code to implement the GC % threshold for garbage
collecting. Rename `lrecord-stats' to `object-memory-usage-stats'
(defined when not mc-alloc, too). Rename `memory-usage' to
`total-memory-usage' and add `object-memory-usage'. Bump
gc_cons_threshold to 2,000,000 (suggestion by Stephen Turnbull).
Avoid use of C++ reserved word `catch'.
Change address for crash reporting to xemacs-beta(a)xemacs.org from
crashes(a)xemacs.org.
new -> new_ in emacs.c.
Turn on _CRT_SECURE_NO_DEPRECATE under Visual C++ to avoid tons of
warnings in VC8.
2005-10-10 Andrey Slusar <anrays(a)gmail.com>
* unexelf.c: define `Elfw(type)' for FreeBSD alpha and all _LP64
archs.
From Dejan Lesjak <dejan.lesjak(a)ijs.si>
2005-10-04 Stephen J. Turnbull <stephen(a)xemacs.org>
* Makefile.in.in (mule_canna_objs): Use correct name of .o.
2005-09-22 Stephen J. Turnbull <stephen(a)xemacs.org>
* Makefile.in.in (HAVE_CANNA): Handle Canna as a module.
* emacs.c (main_1): Update Canna initializers to *_canna_api names.
* mule-canna.c: Moved to modules/canna/canna_api.c.
* symsinit.h (syms_of_mule_canna):
(vars_of_mule_canna):
Rename to *_of_canna_api.
2005-09-29 Ben Wing <ben(a)xemacs.org>
* alloca.c (xemacs_c_alloca):
Don't declare a variable `register' when it can be passed to
xfree(), which may take its address.
new -> new_.
2005-09-26 Marcus Crestani <crestani(a)xemacs.org>
* symbols.c (check_module_subr): Fix new allocator's module
support: remove duplicating the subr.
2005-09-27 Ben Wing <ben(a)xemacs.org>
* glyphs.c:
* glyphs.c (find_instantiator_differences):
* glyphs.c (Fvalid_image_instance_type_p):
* glyphs.c (Fimage_instance_type):
* glyphs.c (Fcolorize_image_instance):
* glyphs.c (Fglyph_type):
* glyphs.c (glyph_image_instance):
* glyphs.c (image_instantiator_format_create):
* glyphs-eimage.c:
* glyphs-eimage.c (jpeg_instantiate):
* glyphs-eimage.c (gif_instantiate):
* glyphs-eimage.c (png_instantiate):
* glyphs-eimage.c (tiff_instantiate):
* glyphs-x.c:
* glyphs-x.c (image_instance_convert_to_pointer):
* glyphs-x.c (init_image_instance_from_x_image):
* glyphs-x.c (x_init_image_instance_from_eimage):
* glyphs-x.c (x_xpm_instantiate):
* glyphs-x.c (x_colorize_image_instance):
* glyphs-gtk.c:
* glyphs-gtk.c (image_instance_convert_to_pointer):
* glyphs-gtk.c (init_image_instance_from_gdk_image):
* glyphs-gtk.c (gtk_init_image_instance_from_eimage):
* glyphs-gtk.c (gtk_xpm_instantiate):
* glyphs-msw.c:
* glyphs-msw.c (mswindows_init_image_instance_from_eimage):
* console-impl.h:
* console-impl.h (struct console_methods):
Allow all kinds of color images (GIF, JPEG, ...) to be mouse pointers.
new -> new_, 'foo -> `foo'.
2005-09-27 Ben Wing <ben(a)xemacs.org>
* Makefile.in.in (cppflags):
Always include SRC, so <config.h> in lib-src always works.
2005-09-27 Ben Wing <ben(a)xemacs.org>
* sysdep.c (emacs_set_tty):
* sysdep.c (qxe_link):
* sysdep.c (qxe_rename):
* sysdep.c (dup2):
Fix bit-rotted dup2 code. Also new -> new_.
* nt.c:
* nt.c (mswindows_closedir):
* nt.c (mswindows_link):
Fix possible use of uninitialized var. Also new -> new_.
2005-09-27 Ben Wing <ben(a)xemacs.org>
* text.c (wcscmp_ascii):
* text.c (COPY_TEXT_BETWEEN_FORMATS):
* event-Xt.c (x_event_to_emacs_event):
* event-Xt.c (ShellVisualPatch):
* lisp.h:
* lisp.h (assert_with_message):
* number-gmp.c (bigfloat_to_string):
* number-gmp.h:
Fix compilation warnings. A couple of changes of new -> new_,
'foo -> `foo'.
2005-09-26 Ben Wing <ben(a)xemacs.org>
* specifier.c:
* specifier.c (Fvalid_specifier_type_p):
* specifier.c (Fvalid_specifier_locale_p):
* specifier.c (Fvalid_specifier_domain_p):
* specifier.c (Fvalid_specifier_locale_type_p):
* specifier.c (Fdefine_specifier_tag):
* specifier.c (specifier_get_external_inst_list):
* specifier.c (Fspecifier_specs):
* specifier.c (Fspecifier_fallback):
* specifier.c (specifier_instance_from_inst_list):
* specifier.c (CHECK_INSTANCE_ENTRY):
* specifier.c (specifier_instance_1):
* specifier.c (specifier_instance):
* specifier.c (specifier_matching_foo):
* specifier.c (Fspecifier_instance):
* specifier.c (Fspecifier_instantiator):
* specifier.c (Fspecifier_matching_instance):
* specifier.c (specifier_matching_foo_from_inst_list):
* specifier.c (syms_of_specifier):
Add `specifier-instantiator' and related primitives.
2005-09-26 Ben Wing <ben(a)xemacs.org>
* rangetab.c:
* rangetab.c (Fmap_range_table):
Fix bug in handling of range endpoints when not start-closed, end-open.
2005-09-17 Olivier Galibert <galibert(a)xemacs.org>
* intl.c (Fset_current_locale): setlocale return string is valid
only until the next setlocale call.
2005-09-12 Mike Alexander <mta(a)arbortext.com>
* intl-win32.c (mswindows_current_locale): Define in non-MULE
build.
2005-09-14 Marcus Crestani <crestani(a)xemacs.org>
* mc-alloc.c (set_lookup_table): Adjust parameter to other memset
calls.
* mc-alloc.c (init_mc_allocator): Zero global allocator structure.
-------- ChangeLog Entries from tests/ChangeLog --------
2005-10-26 Stephen J. Turnbull <stephen(a)xemacs.org>
* XEmacs 21.5.23 "daikon" is released.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
2:58 a.m.
Stephen J. Turnbull, XEmacs 21.5 Beta Engineer wrote:
Oops. Looks like my announcement generating scripts broke, and the
whole "brief list of changes" went missing. I'll fix that, but all
the information is in the ChangeLogs, so I won't spam the list with a
repost. Or, please give it a day and look at
http://www.xemacs.org/Releases/21.5.23.html
Better yet, download the release, check out CHANGES-beta, then build
and M-x build-report!
Steve
* XEmacs 21.5.23 "daikon" is released.
"daikon" is the twenty-fourth in the VEGETABLE series.
The successor to XEmacs 21.5.22 "cucumber", "daikon" adds mouse
pointers
generated from any color image format supported by XEmacs (adding the
modern GIF, JPEG, PNG, or TIFF formats to the increasingly rare XPM
format already supported). Support for building with arbitrary precision
arithmetic (GMP), and the Berkeley db, PostgreSQL, and LDAP databases
has been provided for native Windows NT builds. Unexec support for _LP64
architectures was fixed (at least for FreeBSD).
A number of LISP APIs and commands have been synced to conform to GNU's
(unreleased) Emacs 22. Garbage collection now triggers on a threshold
relative to total memory allocated, which reduces the frequency.
gc-cons-threshold also got raised to 2 million. maybe it should be
higher; 2MB isn't much these days :)
ben
8:20 p.m.
Ben Wing <ben(a)xemacs.org> writes:
Stephen J. Turnbull, XEmacs 21.5 Beta Engineer wrote:
>Oops. Looks like my announcement generating scripts broke, and the
>whole "brief list of changes" went missing. I'll fix that, but all
> the information is in the ChangeLogs, so I won't spam the list with a
> repost. Or, please give it a day and look at
>
> http://www.xemacs.org/Releases/21.5.23.html
>
>Better yet, download the release, check out CHANGES-beta, then build
>and M-x build-report!
>
>Steve
>
>
>* XEmacs 21.5.23 "daikon" is released.
> "daikon" is the twenty-fourth in the VEGETABLE series.
>
>
>The successor to XEmacs 21.5.22 "cucumber", "daikon" adds mouse
pointers
>generated from any color image format supported by XEmacs (adding the
>modern GIF, JPEG, PNG, or TIFF formats to the increasingly rare XPM
>format already supported). Support for building with arbitrary precision
>arithmetic (GMP), and the Berkeley db, PostgreSQL, and LDAP databases
>has been provided for native Windows NT builds. Unexec support for _LP64
>architectures was fixed (at least for FreeBSD).
>
>A number of LISP APIs and commands have been synced to conform to GNU's
>(unreleased) Emacs 22. Garbage collection now triggers on a threshold
>relative to total memory allocated, which reduces the frequency.
>
>
gc-cons-threshold also got raised to 2 million. maybe it should be higher;
2MB isn't much these days :)
I've been using 1e7 for quite some time.
Adrian
ben
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
9:59 a.m.
My personnal package path has vanished:
I configured --with-package-prefix=/usr/local/share/xemacs
I get this in paths.h:
#ifdef PACKAGE_PATH_USER_DEFINED
#define PATH_PACKAGEPATH
"~/.xemacs::/usr/local/share/xemacs/site-packages:/usr/local/share/xemacs/xemacs-packages:/usr/local/share/xemacs/mule-packages"
#endif
And my load path gives this:
"/usr/local/share/xemacs/site-packages/lisp/"
"/usr/local/share/xemacs/site-packages/lisp/Slime/"
bla bla bla, the normal stuff under the prefix.
No trace of my ~/.xemacs/xemacs-packages tree.
For a comparison, here's what I have with 21.4:
configure --package-path=\
/usr/local/share/xemacs/site-packages\
:/usr/local/share/xemacs/mule-packages\
:/usr/local/share/xemacs/xemacs-packages
which gives this in paths.h (note that there is no ~/.xemacs/ here):
#ifdef PACKAGE_PATH_USER_DEFINED
#define PATH_PACKAGEPATH
"/usr/local/share/xemacs/site-packages:/usr/local/share/xemacs/mule-packages:/usr/local/share/xemacs/xemacs-packages"
#endif
But the resulting load-path is correct, and is:
"/home/didier/.xemacs/xemacs-packages/lisp/"
"/usr/local/share/xemacs/site-packages/lisp/"
"/usr/local/share/xemacs/site-packages/lisp/Slime/"
bla bla bla, the normal stuff under the prefix.
--
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org
6:27 p.m.
--- Didier Verna <didier(a)xemacs.org> wrote:
My personnal package path has vanished:
I configured --with-package-prefix=/usr/local/share/xemacs
I get this in paths.h:
#ifdef PACKAGE_PATH_USER_DEFINED
#define PATH_PACKAGEPATH
"~/.xemacs::/usr/local/share/xemacs/site-packages:/usr/local/share/xemacs/xemacs-packages:/usr/local/share/xemacs/mule-packages"
#endif
And my load path gives this:
"/usr/local/share/xemacs/site-packages/lisp/"
"/usr/local/share/xemacs/site-packages/lisp/Slime/"
bla bla bla, the normal stuff under the prefix.
No trace of my ~/.xemacs/xemacs-packages tree.
For a comparison, here's what I have with 21.4:
configure --package-path=\
/usr/local/share/xemacs/site-packages\
:/usr/local/share/xemacs/mule-packages\
:/usr/local/share/xemacs/xemacs-packages
which gives this in paths.h (note that there is no ~/.xemacs/ here):
#ifdef PACKAGE_PATH_USER_DEFINED
#define PATH_PACKAGEPATH
"/usr/local/share/xemacs/site-packages:/usr/local/share/xemacs/mule-packages:/usr/local/share/xemacs/xemacs-packages"
#endif
But the resulting load-path is correct, and is:
"/home/didier/.xemacs/xemacs-packages/lisp/"
"/usr/local/share/xemacs/site-packages/lisp/"
"/usr/local/share/xemacs/site-packages/lisp/Slime/"
bla bla bla, the normal stuff under the prefix.
I ran afoul of this a couple of weeks ago when building from CVS on Cygwin. I
meant to report it, but found a work-around and promptly forgot about it. The
work-around I found was to move the lisp directory from
~/.xemacs/xemacs-packages to ~/.xemacs. After I made that move, XEmacs located
my personal packages again.
This changed sometime in the last month or so. I had a version of b22 that I
checked out from CVS around 9/28 and it worked as expected WRT finding personal
packages in ~/.xemacs/xemacs-packages. When I built from CVS a week or so
later, this had changed. At the time, I wasn't sure if the change was
accidental or intentional.
--Rick
7:53 a.m.
>>>> "Rick" == Rick Rankin
<rrankin1424-xemacs(a)yahoo.com> writes:
Rick> --- Didier Verna <didier(a)xemacs.org> wrote:
> My personnal package path has vanished:
> I configured --with-package-prefix=/usr/local/share/xemacs
This is by design. --with-package-prefix is designed to simplify
package-path specification. It omits last-package-path entirely and
hard-codes early-package-path to ~/.xemacs.
Use --with-package-path.
FWIW, I don't see much point in arguing about the defaults. IMHO the
package path specification stuff is basically broken from the point of
view of allowing users to say what they want simply.
Rick> This changed sometime in the last month or so.
Are you sure? I suspect that you switched from --package-path to
--package-prefix.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
8:46 a.m.
Stephen J. Turnbull wrote:
This is by design. --with-package-prefix is designed to simplify
package-path specification.
... and actually makes things more complicated. As you mention later
in your message, I discovered the existence of --package-prefix, and
interpreted it as a simpler way to precise the standard package location,
avoiding the need to specify site, xemacs and mule locations by hand with
--package-path. So I went from
--package-path=/usr/local/share/xemacs/site-packages:\
/usr/local/share/xemacs/mule-packages:\
/usr/local/share/xemacs/xemacs-packages
to
--with-package-prefix=/usr/local/share/xemacs
Note that my own (~/.xemacs) package directory isn't specified anywhere. Now
you're telling me that these two options silently affect the user's package
path in a different way /by design/ ?? Well, I think the design is severely
broken then.
FWIW, I don't see much point in arguing about the defaults.
Uh, if you go that way, I don't see much point in arguing about
anything then.
IMHO the package path specification stuff is basically broken from
the point
of view of allowing users to say what they want simply.
This, we agree on :-)
--
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org
3:13 p.m.
>>>> "dvl" == Didier Verna
<didier(a)xemacs.org> writes:
dvl> Note that my own (~/.xemacs) package directory isn't
dvl> specified anywhere. Now you're telling me that these two
dvl> options silently affect the user's package path in a
dvl> different way /by design/ ??
No; in the case of --package-path it's literal-minded. --package-path
is explicitly low-level. In particular, anything you don't specify is
defined to be empty.
--package-prefix is intended to provide a consistent set of choices
with a minimum of user input. But it doesn't allow specification of
the user package path.
> FWIW, I don't see much point in arguing about the defaults.
dvl> Uh, if you go that way, I don't see much point in
dvl> arguing about anything then.
That's just well-meant advice. ;-)
The interfaces in question were specified by Mike (--package-path) and
Ben (--package-prefix). If you try to change them, you will most
likely get strong opposition (especially from Ben, who will no longer
be able to use the option he designed and contributed, unless he
changes his own installation layout).
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
8:51 a.m.
Stephen J. Turnbull wrote:
>>>>> "dvl" == Didier Verna
<didier(a)xemacs.org> writes:
dvl> Note that my own (~/.xemacs) package directory isn't
dvl> specified anywhere. Now you're telling me that these two
dvl> options silently affect the user's package path in a
dvl> different way /by design/ ??
No; in the case of --package-path it's literal-minded. --package-path
is explicitly low-level. In particular, anything you don't specify is
defined to be empty.
I think we don't understand each other. What I've explained in my
previous posting is that before, I used --package-path to change
/usr/local/lib to /usr/local/share[1], but never mentioned my ~/.xemacs tree
in it. However, I got ~/.xemacs/xemacs-packages/lisp in my load-path, as I
expected.
So your assertion "anything you don't specify is defined to be empty" is
wrong. I never specified explicitely my local tree, but it was not defined to
be empty. On the contrary, I kept its default value.
What I'm complaining about is that --with-package-prefix doesn't behave the
same way: it seems to take its value as the *unique* tree under which to look
for packages, actually removing the local tree from the load-path.
Footnotes:
[1] which should have been that way from the beginning BTW.
--
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org
5:21 p.m.
>>>> "dvl" == Didier Verna
<didier(a)xemacs.org> writes:
dvl> I think we don't understand each other. What I've
dvl> explained in my previous posting is that before, I used
dvl> --package-path to change /usr/local/lib to
dvl> /usr/local/share[1], but never mentioned my ~/.xemacs tree in
dvl> it. However, I got ~/.xemacs/xemacs-packages/lisp in my
dvl> load-path, as I expected.
dvl> So your assertion "anything you don't specify is defined to
dvl> be empty" is wrong.
OK. I guess the truth is that it works like EMACSPACKAGEPATH: the
default for last-packages is empty, that for early-packages is
~/.xemacs/{xemacs,mule,site}-packages.
dvl> What I'm complaining about is that --with-package-prefix
dvl> doesn't behave the same way: it seems to take its value as
dvl> the *unique* tree under which to look for packages, actually
dvl> removing the local tree from the load-path.
No, it's a bug in the default. It defaults to ~/.xemacs for early
packages. I thought Ben did that intentionally, but it looks like
he's willing to change to reflect what the posters actually do.
The reason you don't see anything in load-path is that XEmacs only
adds the package directories it finds, and you don't have any
~/.xemacs/lisp/$PACKAGE/*.el files.
dvl> [1] which should have been that way from the beginning BTW.
Last time this was brought up, Mike disagreed vehemently.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:43 a.m.
New subject: with-package-prefix
On Mon, 2005-10-31 at 09:46 +0100, Didier Verna wrote:
Stephen J. Turnbull wrote:
> This is by design. --with-package-prefix is designed to simplify
> package-path specification.
... and actually makes things more complicated. As you mention later
in your message, I discovered the existence of --package-prefix, and
interpreted it as a simpler way to precise the standard package location,
avoiding the need to specify site, xemacs and mule locations by hand with
--package-path. So I went from
--package-path=/usr/local/share/xemacs/site-packages:\
/usr/local/share/xemacs/mule-packages:\
/usr/local/share/xemacs/xemacs-packages
to
--with-package-prefix=/usr/local/share/xemacs
Note that my own (~/.xemacs) package directory isn't specified anywhere. Now
you're telling me that these two options silently affect the user's package
path in a different way /by design/ ?? Well, I think the design is severely
broken then.
What's the point of with-package-prefix, if ~/.xemacs cannot be
specified with it? The following design would be much more usefule:
--with-package-path as now
--with-package-prefix would automatically include
~/.xemacs(/xemacs-packages) OR
--with-packages-prefixes (or something like that) to allow specifying
multiple prefixes, something like /usr/local/share/xemacs:/local/xemacs
2:34 p.m.
New subject: with-package-prefix
>>>> "Pema" == Pekka Marjola <pema(a)iki.fi>
writes:
Pema> What's the point of with-package-prefix, if ~/.xemacs cannot
Pema> be specified with it?
Allowing you to keep multiple installed package trees around. This is
really of most interest to developers with large changes in their
packages who also need to test against the stable versions of
packages. Most users or administrators should simply figure out the
incantation for --with-package-path that corresponds to site policy
for installing third-party software, save it in a script, and not need
to worry ever again.
In greater detail: we have been heading in the direction of a layout
where
(1) XEmacs version-specific material is installed under a single root
$prefix (by default /usr/local),
(2) the system package hierarchies are installed in xemacs-packages,
mule-packages, and site-packages[1], under a single root
$package_prefix (by default /usr/local/lib/xemacs), and
(3) personal package hierarchies are installed in xemacs-packages,
mule-packages, and site-packages under a single root (pretty much
hard-coded to ~/.xemacs, although you can use --user-init-directory to
change it at run-time).
So there's actually little point to allowing the user to specify a
single location for early (ie, personal) packages.
It seems a little silly to have the extra layer of subdirectories
under ~/.xemacs since most users will not have personal packages
containing non-ASCII characters while using a no-Mule XEmacs. I guess
Ben decided to code --with-package-prefix that way. I personally
do use the extra layer of subdirectories, and it simplifies the
load-path-generating code slightly, but I can't really say Ben's way
is *wrong*. (That's why I say there's no point in arguing the
defaults, in the absence of other improvements.)
There's also some disagreement on (1) how much we should "encourage"
the simple architecture (which currently violates the FHS for system
installs because we don't use $prefix/share), and (2) whether (and how
much) we should "encourage" a particular relationship of $prefix and
$package_prefix (specifically package_prefix=$prefix/lib/xemacs,
although in practice the proponent of that restriction effectively
uses package_prefix=$prefix in his personal installation).
Footnotes:
[1] The division into xemacs-packages, mule-packages, and
site-packages is mostly for administrative convenience.
(mule-packages does have the role of allowing literal non-ASCII
characters, which no-Mule XEmacs can't read correctly and can even
cause a syntax error, but that restriction will also go away in the
next release.) There's no reason why an installation can't put
everything into xemacs-packages.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
3:17 p.m.
New subject: with-package-prefix
On Tue, 2005-11-01 at 23:34 +0900, Stephen J. Turnbull wrote:
Pema> What's the point of with-package-prefix, if
~/.xemacs cannot
Pema> be specified with it?
Allowing you to keep multiple installed package trees around. This is
really of most interest to developers with large changes in their
packages who also need to test against the stable versions of
packages. Most users or administrators should simply figure out the
incantation for --with-package-path that corresponds to site policy
for installing third-party software, save it in a script, and not need
to worry ever again.
I used to use --package-path. Then --with-package-prefix was
implemented, which supposedly simplifies things (no need to specify
mule-packages etc.) - but ~/.xemacs is not in the path generated. Or has
that changed?
(2) the system package hierarchies are installed in xemacs-packages,
mule-packages, and site-packages[1], under a single root
$package_prefix (by default /usr/local/lib/xemacs), and
Basically, this is the only path I want to change... But
--(with-)package-path requires all directories in search path to be
specified. That's what I'm using now, since --with-package-prefix does
not seem to work as I would like.
(3) personal package hierarchies are installed in xemacs-packages,
mule-packages, and site-packages under a single root (pretty much
hard-coded to ~/.xemacs, although you can use --user-init-directory to
change it at run-time).
So there's actually little point to allowing the user to specify a
single location for early (ie, personal) packages.
That's true. But if I just use --with-package-prefix, ~/.xemacs is not
included in paths.
I only want to specify a single common package root (with
xemacs-packages, mule-packages & site-packages), and ~/.xemacs should be
added to path automatically. --with-package-prefix did not do this last
time I checked - maybe it has been changed.
4:20 p.m.
New subject: with-package-prefix
>>>> "Pema" == Pekka Marjola <pema(a)iki.fi>
writes:
Pema> I used to use --package-path. Then --with-package-prefix was
Pema> implemented, which supposedly simplifies things (no need to
Pema> specify mule-packages etc.) - but ~/.xemacs is not in the
Pema> path generated. Or has that changed?
The code in ./configure _does_ put ~/.xemacs in the default package
search path, along with $package_prefix/{site,mule,xemacs}-packages.
What this means (in theory, I will have to test to make sure) is that
when XEmacs starts up, it looks for a lisp subdirectory in each root,
and under the lisp directory for each package subdirectory it adds
that subdirectory to the load path.
That means you need ~/.xemacs/lisp/local-package containing Lisp
files. Is that what you have?
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
4:58 a.m.
New subject: with-package-prefix
On Wed, 2005-11-02 at 01:20 +0900, Stephen J. Turnbull wrote:
>>>>> "Pema" == Pekka Marjola
<pema(a)iki.fi> writes:
Pema> I used to use --package-path. Then --with-package-prefix was
Pema> implemented, which supposedly simplifies things (no need to
Pema> specify mule-packages etc.) - but ~/.xemacs is not in the
Pema> path generated. Or has that changed?
The code in ./configure _does_ put ~/.xemacs in the default package
search path, along with $package_prefix/{site,mule,xemacs}-packages.
That means you need ~/.xemacs/lisp/local-package containing Lisp
files. Is that what you have?
Nope, ~/.xemacs/xemacs-packages/lisp/local-package. At one point this
was expected directory.... Yup, my Windows build (21.5b17, from
xemacs.org) expects that there is ~/.xemacs/xemacs-packages/lisp. So
what's it gonna be?
6:22 a.m.
New subject: with-package-prefix
Pekka Marjola wrote:
On Tue, 2005-11-01 at 23:34 +0900, Stephen J. Turnbull wrote:
> Pema> What's the point of with-package-prefix, if ~/.xemacs cannot
> Pema> be specified with it?
>
>Allowing you to keep multiple installed package trees around. This is
>really of most interest to developers with large changes in their
>packages who also need to test against the stable versions of
>packages. Most users or administrators should simply figure out the
>incantation for --with-package-path that corresponds to site policy
>for installing third-party software, save it in a script, and not need
>to worry ever again.
>
>
I used to use --package-path. Then --with-package-prefix was
implemented, which supposedly simplifies things (no need to specify
mule-packages etc.) - but ~/.xemacs is not in the path generated. Or has
that changed?
when i first implemented this, ~/.xemacs was definitely added by
default. could we rethink this? we obviously want
--with-package-prefix to do the thing most users want; developers and
others can use the complex api if they don't want this.
ben
6:23 a.m.
New subject: with-package-prefix
Stephen J. Turnbull wrote:
It seems a little silly to have the extra layer of subdirectories
under ~/.xemacs since most users will not have personal packages
containing non-ASCII characters while using a no-Mule XEmacs. I guess
Ben decided to code --with-package-prefix that way. I personally
do use the extra layer of subdirectories, and it simplifies the
load-path-generating code slightly, but I can't really say Ben's way
is *wrong*. (That's why I say there's no point in arguing the
defaults, in the absence of other improvements.)
defaults are extremely important. they should work the way most users
expect them to.
6:27 a.m.
New subject: with-package-prefix
Pekka Marjola wrote:
On Mon, 2005-10-31 at 09:46 +0100, Didier Verna wrote:
>Stephen J. Turnbull wrote:
>
>
>
>>This is by design. --with-package-prefix is designed to simplify
>>package-path specification.
>>
>>
> ... and actually makes things more complicated. As you mention later
>in your message, I discovered the existence of --package-prefix, and
>interpreted it as a simpler way to precise the standard package location,
>avoiding the need to specify site, xemacs and mule locations by hand with
>--package-path. So I went from
>
>--package-path=/usr/local/share/xemacs/site-packages:\
> /usr/local/share/xemacs/mule-packages:\
> /usr/local/share/xemacs/xemacs-packages
>
>to
>
>--with-package-prefix=/usr/local/share/xemacs
>
>
>Note that my own (~/.xemacs) package directory isn't specified anywhere. Now
>you're telling me that these two options silently affect the user's package
>path in a different way /by design/ ?? Well, I think the design is severely
>broken then.
>
>
What's the point of with-package-prefix, if ~/.xemacs cannot be
specified with it? The following design would be much more usefule:
--with-package-path as now
--with-package-prefix would automatically include
~/.xemacs(/xemacs-packages) OR
--with-packages-prefixes (or something like that) to allow specifying
multiple prefixes, something like /usr/local/share/xemacs:/local/xemacs
pekka, i'm a bit confused. the code for with-package-prefix (in
configure.ac) reads
if test -z "$with_package_path" && test -n
"$with_package_prefix" ; then
if test "$enable_mule" = "yes" ; then
with_package_path="~/.xemacs::${with_package_prefix}/site-packages:${with_package_prefix}/xemacs-packages:${with_package_prefix}/mule-packages"
else
with_package_path="~/.xemacs::${with_package_prefix}/site-packages:${with_package_prefix}/xemacs-packages"
fi
fi
so it does set ~/.xemacs. what should it do instead?
btw probably it should also take multiple prefixes; i'll see about
fixing this.
ben
4:02 p.m.
New subject: with-package-prefix
>>>> "Ben" == Ben Wing <ben(a)xemacs.org>
writes:
Ben> so it does set ~/.xemacs. what should it do instead?
After some discussion with Mike, it seemed simplest if ~/.xemacs has
the same structure as /usr/local/lib/xemacs: it should have
xemacs-packages and mule-packages (if the user has mule-specific local
packages but uses no-mule XEmacsen, otherwise mule-packages is not
needed).
Probably the code should do
if test -z $package_path -a -n $package_prefix; then
package_path=~/.xemacs/site-packages
package_path=$package_path:~/.xemacs/mule-packages
package_path=$package_path:~/.xemacs/xemacs-packages
package_path=$package_path::$package_prefix/site-packages
package_path=$package_path:$package_prefix/mule-packages
package_path=$package_path:$package_prefix/xemacs-packages
fi
Ben> btw probably it should also take multiple prefixes; i'll see
Ben> about fixing this.
Please don't mess with this. Fix the default, yes, if you agree that
the above default is acceptable. However, there's no apparent demand
for multiple prefixes. What everybody who's posted wants is to set
_one_ system prefix, and for configure to set up defaults for user
packages so XEmacs automatically picks them up.
Also, I haven't worked out the configure UI for
packages-in-source-tarball yet, and multiple prefixes will make it
more complex to adapt to existing installations.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
5:32 p.m.
New subject: with-package-prefix
--- "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
>>>>> "Ben" == Ben Wing
<ben(a)xemacs.org> writes:
Ben> so it does set ~/.xemacs. what should it do instead?
After some discussion with Mike, it seemed simplest if ~/.xemacs has
the same structure as /usr/local/lib/xemacs: it should have
xemacs-packages and mule-packages (if the user has mule-specific local
packages but uses no-mule XEmacsen, otherwise mule-packages is not
needed).
Probably the code should do
if test -z $package_path -a -n $package_prefix; then
package_path=~/.xemacs/site-packages
package_path=$package_path:~/.xemacs/mule-packages
package_path=$package_path:~/.xemacs/xemacs-packages
package_path=$package_path::$package_prefix/site-packages
package_path=$package_path:$package_prefix/mule-packages
package_path=$package_path:$package_prefix/xemacs-packages
fi
From what I've read so far, this makes the most sense to me. While
it's not
obvious what, if any, value the extra layer (xyz-packages) adds, I
think a
consistent layout would make it easier for the user to figure out where to put
packages. It would have saved me a couple of hours of debugging, anyway ;-)
--Rick
2:23 a.m.
New subject: with-package-prefix
Stephen J. Turnbull wrote:
>>>>>"Ben" == Ben Wing <ben(a)xemacs.org>
writes:
>>>>>
>>>>>
Ben> so it does set ~/.xemacs. what should it do instead?
After some discussion with Mike, it seemed simplest if ~/.xemacs has
the same structure as /usr/local/lib/xemacs: it should have
xemacs-packages and mule-packages (if the user has mule-specific local
packages but uses no-mule XEmacsen, otherwise mule-packages is not
needed).
Probably the code should do
if test -z $package_path -a -n $package_prefix; then
package_path=~/.xemacs/site-packages
package_path=$package_path:~/.xemacs/mule-packages
package_path=$package_path:~/.xemacs/xemacs-packages
package_path=$package_path::$package_prefix/site-packages
package_path=$package_path:$package_prefix/mule-packages
package_path=$package_path:$package_prefix/xemacs-packages
fi
Ben> btw probably it should also take multiple prefixes; i'll see
Ben> about fixing this.
Please don't mess with this. Fix the default, yes, if you agree that
the above default is acceptable. However, there's no apparent demand
for multiple prefixes. What everybody who's posted wants is to set
_one_ system prefix, and for configure to set up defaults for user
packages so XEmacs automatically picks them up.
Also, I haven't worked out the configure UI for
packages-in-source-tarball yet, and multiple prefixes will make it
more complex to adapt to existing installations.
ok, sure. the above default sounds good to me and i'll fix it.
ben
11:54 a.m.
New subject: with-package-prefix
>>>> "Ben" == Ben Wing <ben(a)xemacs.org>
writes:
Ben> ok, sure. the above default sounds good to me and i'll fix it.
OK, but can you hold off for a few days until I commit my configure changes?
I'm having touch lots of areas in configure.ac and I think I'll get thrown
into create confusion if the original file gets changed underneath me while
I'm finalising the patch.
Malcolm
--
Malcolm Purvis <malcolmp(a)xemacs.org>
2:40 p.m.
New subject: with-package-prefix
Sorry to be chiming in so late here.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Ben" == Ben Wing
<ben(a)xemacs.org> writes:
Ben> so it does set ~/.xemacs. what should it do instead?
Probably the code should do
if test -z $package_path -a -n $package_prefix; then
package_path=~/.xemacs/site-packages
package_path=$package_path:~/.xemacs/mule-packages
package_path=$package_path:~/.xemacs/xemacs-packages
package_path=$package_path::$package_prefix/site-packages
package_path=$package_path:$package_prefix/mule-packages
package_path=$package_path:$package_prefix/xemacs-packages
fi
Ben> btw probably it should also take multiple prefixes; i'll see
Ben> about fixing this.
Please don't mess with this. Fix the default, yes, if you agree that
the above default is acceptable. However, there's no apparent demand
for multiple prefixes. What everybody who's posted wants is to set
_one_ system prefix, and for configure to set up defaults for user
packages so XEmacs automatically picks them up.
Yes. The problem is that I dropped the ball on finishing to propagate
the changes I made in December 2004.
The thing to do is to propagate the {early,late,last} package
directories separately from configure to the running XEmacs. Could
you guys give me a week to do that, or at least let me review patches
on this issue before they're committed? (I promise I'll be more
responsive than in the past few weeks.)
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
2:52 a.m.
--- "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
>>>>> "Rick" == Rick Rankin
<rrankin1424-xemacs(a)yahoo.com> writes:
Rick> --- Didier Verna <didier(a)xemacs.org> wrote:
>> My personnal package path has vanished:
>> I configured --with-package-prefix=/usr/local/share/xemacs
This is by design. --with-package-prefix is designed to simplify
package-path specification. It omits last-package-path entirely and
hard-codes early-package-path to ~/.xemacs.
Use --with-package-path.
FWIW, I don't see much point in arguing about the defaults. IMHO the
package path specification stuff is basically broken from the point of
view of allowing users to say what they want simply.
Rick> This changed sometime in the last month or so.
Are you sure? I suspect that you switched from --package-path to
--package-prefix.
You're right, I did. Although at this point, I don't remember exactly why. I
use a script to build, and I seem to recall that at one point when I tried to
build from CVS, I got some sort of error from configure related to
--package-path. Did --package-path have a different name before, maybe prior to
the switch to autoconf-2.5?
Whatever the error was, it caused me to look at the path options, and that's
when I changed.
--Rick
7:11 a.m.
>>>> "Rick" == Rick Rankin
<rrankin1424-xemacs(a)yahoo.com> writes:
Rick> You're right, I did.
I'm sorry for your trouble, but at least things now make sense to me.
Rick> Did --package-path have a different name before, maybe prior
Rick> to the switch to autoconf-2.5?
IIRC the old name was --package-path, and in the switch to autoconf
2.5x it got renamed to --with-package-path, which would give you an
error. --with-package-prefix (formerly named --package-prefix) is a
few months older than the switch to autoconf 2.5x, but you very likely
wouldn't have noticed the new option if your old command line was
working fine.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6756
days inactive
6780
days old
24 comments
8 participants
participants (8)
-
Adrian Aichner -
Ben Wing -
Didier Verna -
Malcolm Purvis -
Michael Sperber -
Pekka Marjola -
Rick Rankin -
Stephen J. Turnbull