November 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Char-related crashes (hopefully) fixed 25 years

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Second, I'm repeating it because as far as I know everybody who > writes Emacs Lisp would prefer that their code function correctly in > as many environments as possible, as long as it costs them nothing > to write it that way. You feel that way, too, you've said so. Do > you habitually write code _knowing_ that if the wrong somebody > borrows it, their application will break? I don't know how I write code anymore. The MULE APIs have never been documented, and it's never been published what is and what is not safe in Mule. I know my code contained the implicit int->char conversions, because that was easier to write. Mule breaks too much to be worthy of so much consideration at this level. Yes, I believe new C code should adhere to existing abstractions, but I'm not so convinced that we should break (the rest of) the Lisp world for the sake of Asians. I explained to you many times now why I tell all my friends to compile _without_ Mule. I'm not about to repeat it.

5 participants
6 comments

Re: Binary editing problems persist 25 years

Jan Vroonhof

"Peter B. West" <pbwest(a)netscape.net> writes: > Having earlier experienced under-the-bonnet changes of 0x0D to 0x0A when > using hexl-mode to edit a file, whose coding had been set to binary, I > have just re-compiled from the latest CVS sources, and the problem > persists. Did I mention that I compile --with-mule? This is of course an inexcusable bug. Can you give a recipe to reproduce? Note that you must specify the coding system before reading in the file. > coding. Does anyone have any suggestions as to how this problem can be > resolved? Can it be solved? Is there an assumption that one of the EOL > transformation must always be applied? hexl seems broken for Mule at the moment. hexl-find-file now does some weird conditioning on the system type. Maybe a sync with the hexl from FSF Emacs 20.4 is in order. > The easiest way to edit a file with no conversion of any kind is with > the `M-x find-file-literally' command. This uses `binary', and also > suppresses other XEmacs features that might convert the file contents > before you see them. *Note Visiting::. This function does not exist, maybe it should be reinstated. The closest function that does is insert-file-contents-literally. That function is currently also broken (I have a patch but am waiting for a new version of EFS) > Setting `binary' by hand, as noted, does not prevent bitrot. Has no one > else seen this problem? What is the avenue of attack? Is this the sort > of change that is guaranteed to break something else? A start would be to sync hexl-mode from FSF emacs. Since they have mule always, they must have fixed the coding problems. If it uses i-f-c-literally, just give me yell and I will get it fixed. Your problems are exactly why Mule has a bad name. It breaks stuff that used to work, the API changes all the time and thus function are broken and the documentation is out of date. Jan

3 participants
2 comments

LDAP extended and revamped 25 years

Oscar Figueiredo

Here's a new patch to the current LDAP code that takes into account the recent discussion on the subject. The LDAP code design remains unchanged, it consists of two layers: - a low level layer that closely matches the C LDAP API. These functions that used to be named `*-internal' are now named more simply: `ldap-open', `ldap-close', `ldap-search', `ldap-add', `ldap-modify'. They should be used directly for very specific purposes (such as multiple operations on a connection) only. - a higher-level layer provides a more convenient way to access LDAP directories hiding the subtleties of handling the connection, translating arguments and ensuring compliance with LDAP internationalization rules and formats (currently partly implemented only). This layer provides atomic operations for searches, modification, addition and deletion of multiple entries at once: ldap-search-entries, ldap-add-entries, ldap-delete-entries and ldap-modify-entries *** IMPORTANT NOTE *** Due to the function renaming, this patch introduces an incompatible change that breaks the packages using the current LDAP API, most notably EUDC and W3. A new version of EUDC is ready for commit if the patch is accepted, please notify me. Oscar 1999-11-27 Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> * eldap.h (Fldap_search) Renamed from Fldap_search_internal: (Fldap_add, Fldap_modify, Fldap_delete): New functions * eldap.c (Qadd, Qreplace): New constant symbols (Fldap_open): Use the LDAP_OPT_RESTART option to avoid interruptions by XEmacs signals Remove unnecessary calls to slow_down_interrupts and speed_up_interrupts (Fldap_search): Renamed from Fldap_search_internal Added new optional parameter VERBOSE that triggers progress messages display Remove unnecessary calls to slow_down_interrupts and speed_up_interrupts LDAP result code analysis rewritten (Fldap_add, Fldap_modify, Fldap_delete): New functions (syms_of_eldap): Define the new symbols and functions 1999-11-27 Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> * ldap.el (toplevel): Test if LDAP support has been compiled in (ldap-verbose): New option (ldap-search-entries): Renamed from ldap-search Conditionalize message display on ldap-verbose (ldap-add-entries, ldap-modify-entries, ldap-delete-entries): New defuns

1 participants
0 comments

Re: imenu.el; Sync with FSF 20.4 is in the queue since August 25 years

Andreas Jaeger

>>>>> Adrian Aichner writes: > Hello Andreas, > I have tested > imenu.el; Sync with FSF 20.4 > by > Christoph Wedler <Christoph.Wedler(a)sap-ag.de> > which can be found at > http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00077.html > I would like to suggest that this patch should be applied to > xemacs-packages\libs\xemacs-base\imenu.el > INSTEAD of my earlier patches > http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00054.html > and > http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00064.html As this patch has been approved already, I've added it now to the CVS archive. Thanks Christoph for the patch, Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Binary editing problems persist 25 years

Peter B. West

Having earlier experienced under-the-bonnet changes of 0x0D to 0x0A when using hexl-mode to edit a file, whose coding had been set to binary, I have just re-compiled from the latest CVS sources, and the problem persists. Did I mention that I compile --with-mule? In the past I have looked at the documentation and code involved in file coding in a Mule environment, and given myself a fright. I have also looked on in bemusement at some of the exchanges in this list about file coding. Does anyone have any suggestions as to how this problem can be resolved? Can it be solved? Is there an assumption that one of the EOL transformation must always be applied? The info has this: Each of the coding systems that appear in this list--except for `binary', which means no conversion of any kind--specifies how and whether to convert printing characters, but leaves the choice of end-of-line conversion to be decided based on the contents of each file. and... In contrast, the coding system `binary' specifies no character code conversion at all--none for non-Latin-1 byte values and none for end of line. This is useful for reading or writing binary files, tar files, and other files that must be examined verbatim. The easiest way to edit a file with no conversion of any kind is with the `M-x find-file-literally' command. This uses `binary', and also suppresses other XEmacs features that might convert the file contents before you see them. *Note Visiting::. Note the reference to `find-file-literally'. grepping my source files yields only one reference, in files.el, as follows: (if rawfile ;; #### FSF 20.3 sets buffer-file-coding-system to ;; `no-conversion' here. Should we copy? It also ;; makes `find-file-literally' a local variable ;; and sets it to t. nil (after-find-file error (not nowarn)) (setq buf (current-buffer)))) Setting `binary' by hand, as noted, does not prevent bitrot. Has no one else seen this problem? What is the avenue of attack? Is this the sort of change that is guaranteed to break something else? Yours faithfully, Peter -- __ /__ Peter B. West pbwest(a)netscape.net / http://www.powerup.com.au/~pbwest / "Lord, to whom shall we go?"

1 participants
0 comments

ChangeLog entry for viper.texi 25 years

Peter B. West

Sorry, forgot a ChangeLog entry. 1999-11-27 Peter B. West <pwest(a)netscape.net> * viper.texi: Add trailing `,' omitted after xref entry. -- __ /__ Peter B. West pbwest(a)netscape.net / http://www.powerup.com.au/~pbwest / "Lord, to whom shall we go?"

2 participants
1 comments

Problems with CVS build 25 years

Peter B. West

I encountered the following problems in building packages from the CVS sources: make[2]: Entering directory `/opt2/src/xemacs/xemacs-packages/oa/text-modes' /usr/local/src/xemacs/xemacs-beta/src/xemacs -no-autoloads -batch -l ../../package-compile.el -- ispell fsf-compat xemacs-base -- filladapt.el Loading /usr/local/src/xemacs/xemacs-beta/lisp/auto-autoloads... Loading /opt2/src/xemacs/xemacs-packages/libs/xemacs-base/auto-autoloads... Loading /opt2/src/xemacs/xemacs-packages/libs/fsf-compat/auto-autoloads... Loading /opt2/src/xemacs/xemacs-packages/oa/ispell/auto-autoloads... Symbol's value as variable is void: ispell-xemacs xemacs exiting. make[2]: *** [filladapt.elc] Error 255 make[2]: Entering directory `/opt2/src/xemacs/xemacs-packages/comm/eudc' /usr/local/src/xemacs/xemacs-beta/src/xemacs -no-autoloads -batch -l ../../package-compile.el -- fsf-compat xemacs-base bbdb -- eudc.el Loading /usr/local/src/xemacs/xemacs-beta/lisp/auto-autoloads... xemacs exiting.Cannot open load file: /opt2/src/xemacs/xemacs-packages/comm/bbdb/lisp/auto-autoloads make[2]: *** [eudc.elc] Error 255 make[2]: Entering directory `/opt2/src/xemacs/xemacs-packages/libs/mail-lib' /usr/local/src/xemacs/xemacs-beta/src/xemacs -no-autoloads -batch -l ../../package-compile.el -- xemacs-base -- browse-url.el Loading /usr/local/src/xemacs/xemacs-beta/lisp/auto-autoloads... Loading /opt2/src/xemacs/xemacs-packages/libs/xemacs-base/auto-autoloads... Compiling /opt2/src/xemacs/xemacs-packages/libs/mail-lib/browse-url.el... Loading cl-macs... (file cl-macs.el is newer) While compiling toplevel forms in file /opt2/src/xemacs/xemacs-packages/libs/mail-lib/browse-url.el: !! File error (("Cannot open load file" "term")) Done --------------------------------- Note that I do not have the bbdb package, which probably means I should not have eudc either. I do have term.el from the eterm package. The following warning is thrown when I open my first file: (1) (warning/warning) Autoload error in: /usr/local/lib/xemacs/xemacs-packages/lisp/ispell/auto-autoloads: Symbol's value as variable is void: ispell-xemacs How do I fix this one? When compiling viper I ran into a problem with viper.texi. Attached is a patch for that problem. There were two alternatives for fixing this trivial problem, so maybe the author should be consulted. I have no idea about patching - where the patch should go, how it should be created, etc - so advice is welcome. In Domino. Peter -- __ /__ Peter B. West pbwest(a)netscape.net / http://www.powerup.com.au/~pbwest / "Lord, to whom shall we go?" --- viper.texi Sat Nov 27 02:31:11 1999 +++ viper.texi.patched Sat Nov 27 02:54:10 1999 ＠＠ -3427,7 +3427,7 ＠＠＠item m . Set the Emacs mark (＠pxref{Emacs Preliminaries}) at point. ＠item m ^ -Set the Emacs mark (＠xref{Emacs Preliminaries}) back to where it was last +Set the Emacs mark (＠xref{Emacs Preliminaries},) back to where it was last set with the ＠kbd{m.} command. This is useful when you set the mark with ＠kbd{m.}, but then some other command (such as ＠kbd{L} or ＠kbd{G}) changes it in a way that you didn't like.

1 participants
0 comments

imenu.el; Sync with FSF 20.4 is in the queue since August 25 years

Adrian Aichner

Hello Andreas, I have tested imenu.el; Sync with FSF 20.4 by Christoph Wedler <Christoph.Wedler(a)sap-ag.de> which can be found at http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00077.html I would like to suggest that this patch should be applied to xemacs-packages\libs\xemacs-base\imenu.el INSTEAD of my earlier patches http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00054.html and http://www.xemacs.org/list-archives/xemacs-patches/9908/msg00064.html Schöne Grüße, Adrian

1 participants
0 comments

Re: Success on solaris2.6 [STIKE :) (Was Re: build-failure on solaris2.6) 25 years

William M. Perry

Nils Bokermann <bokerman(a)uni-bielefeld.de> writes: > On Wed, Nov 24, 1999 at 04:36:07PM +0100, Jan Vroonhof wrote: > > Nils Bokermann <bokerman(a)uni-bielefeld.de> writes: > > > > > Bye, Nils -- if someone wants access to THIS system (is a SPARCbook) drop me > > > a line > > > > Hmmm.. Wmperry also has a sparcbook. > > > After a new compilation (and configure) I have a XEmacs running :-) Is this using the unexsol2.o or unexsol2-6.o? -Bill P.

1 participants
0 comments

Re: build-failure on solaris2.6 25 years

Hrvoje Niksic

Georg Nikodym <georgn(a)home.com> writes: > However, the best outcome is that I'll start the wheels turning on a > patch. I assume you mean a Solaris patch. If the symptom really is the result of a Solaris bug, patch will be definitely useful because people can be told to patch up their systems to make XEmacs work. Also, configure can check the Solaris version and the existence of the life-saving patch, and decide whether to use dynodump or dldump() based on that information.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta November 1999