November 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Ethiopic in 21.1.7++ 24 years, 6 months

Jan Vroonhof

Vin Shelton <acs(a)xemacs.org> writes: > Symbol's function definition is void: setup-ethiopic-environment-internal > > Signaling: (void-function setup-ethiopic-environment-internal) > setup-ethiopic-environment-internal() > set-language-environment("Ethiopic") > eval((set-language-environment "Ethiopic")) > > I'd like to get this working before I release 21.1.8 (tonight, I > hope). Can anyone offer a patch? I tried making the obvious path (namely copying 'setup-ethiopic-environment-internal from an old mule base into the core), however then I stopped. auto-autoloads.el from mule-base contains (autoload 'setup-ethiopic-environment-internal "ethio-util" nil nil nil) so how could this happen? IMO it would be better to have an 21.1.8 now with broken ethiopic support than on sunday with a fix. Jan

3 participants
2 comments

Re: (insert 8000) crashes XEmacs 21.2.16 24 years, 6 months

Hrvoje Niksic

Yoshiki Hayashi <t90553(a)m.ecc.u-tokyo.ac.jp> writes: > Ben Wing <ben(a)666.com> writes: > > > When I wrote all this code, I made a conscious decision, for compatibility > > reasons, to allow integers wherever characters are allowed. If we're going to > > change this, (a) we should think carefully about what this means, and (b) we > > should fix this all throughout XEmacs. > > I am confused. Your plan and Kyles' plan below can't coexist. Which means that they disagree on this one. I agree with Ben here, for two reasons: 2. If we are to disallow inserting integers, we should do it with some more care about where integers can popup. Believe me, it's in many many places (as both Ben and Kyle know); 1. The patch as it stands doesn't really fix the source of the problem. If (insert 8000) signals an error, but (insert (int-char 8000)) crashes XEmacs, then something is wrong. > It's easy to fix and here is the patch. I'll send this to > xemacs-patches if this is needed after discussions are over. [...] This patch looks good to me, but I'll wait for Ben's judgement, as he is the one who really understands that code.

1 participants
0 comments

Re: [HEADS UP] movemail locking overhaul ahead 24 years, 6 months

Michael Sperber

>>>>> "Kyle" == Kyle Jones <kyle_jones(a)wonderworks.com> writes: Kyle> Michael Sperber [Mr. Preprocessor] writes: >> - The locking policy is not an OS issue, but rather a site issue. >> The OS issue is what policies *work*, not which ones are in use. Kyle> The locking stuff in a s/*.h file reflects the locking policy Kyle> in use by the default delivery agent on that operating system. Exactly. But the delivery agent may not even run on the same system as movemail. Or it may have been replaced by something else. Kyle> OK with me, so long as it is heavily stressed that the OS-based Kyle> locking default should not be changed unless you know what you Kyle> are doing, it voids your warranty, cows will bark, etc. Right. Moreover, I think we should yell in the documentation that the installer should make an effort to find out. Otherwise it voids your warranty, cows will bark, and ET will serve your lunch. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: [HEADS UP] movemail locking overhaul ahead 24 years, 6 months

Michael Sperber

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> The locking policies can be controlled through three mechanisms (by >> descending precedence): >> >> - Specification on the movemail command line. >> - Specification of an environment variable EMACSLOCKMETHOD with the >> same possible values as the --mail-locking argument to configure. >> - Configuration via autoconf and src/config.h. Jan> I propose that it should (by default) always use dotlocking (even Jan> together with any other method). I don't believe that's a good idea: Locking would no longer be atomic, and you can get deadlocks that way. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: [HEADS UP] movemail locking overhaul ahead 24 years, 6 months

Michael Sperber

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>> "ms" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: ms> The locking policies can be controlled through three ms> mechanisms (by descending precedence): ms> - Specification on the movemail command line. ms> - Specification of an environment variable EMACSLOCKMETHOD ms> with the same possible values as the --mail-locking argument ms> to configure. ms> - Configuration via autoconf and src/config.h. Stephen> Obviously XEmacs shouldn't be allowed to specify locking methods not Stephen> implemented on the system in question. How do you plan to handle that Stephen> given the precedence specified above? Or is this not a problem? Stephen> Maybe XEmacs should bitch on startup (disabled through a site-start Stephen> facility) if the environment variable or the 'mail-lock-variable is Stephen> set to something strange for the system. Right, point taken. Thanks for the note! -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: URL loading library? 24 years, 6 months

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > I was contemplating finally rewriting the HTTP code in Emacs/W3 in > C. Does anybody have ideas for what HTTP library to use? I'd > prefer not having to write it myself. The `libghttp' stuff from > gnome looks like it could be useful. It can do asynch fetches, etc. A friend of mine has looked into libghttp and told me it's entirely broken. I haven't checked, but I've a hunch that he might be right. Wget is hardly useful for your purposes -- as I no longer have time for it (see http://fly.srk.fer.hr/archive/wget?id=87wvs347gk.fsf＠pc-hrvoje.srce.hr), it grows dusty, and it was never able to do async downloads in the first place. I was told that libwww is in much better shape than it was four years ago (people in the Lynx project also had bad experiences with old versions), and it's compatible with the GPL.

1 participants
0 comments

Re: (insert 8000) crashes XEmacs 21.2.16 24 years, 6 months

SL Baur

Yoshiki Hayashi <t90553(a)m.ecc.u-tokyo.ac.jp> writes in xemacs-beta(a)xemacs.org: > xemacs -vanilla > (insert 8000) Ouch! -- 窓番号を入力してください

4 participants
4 comments

xterm mouse support... kindof... 24 years, 6 months

William M. Perry

This gets it mostly working. I think I'll leave it for someone else to actually hack it the rest of the way. :) Main differences were writing the functions window-at and coordinates-in-window-p. coordinates-in-window-p is not 100% correct. According to the docs of Emacs 21, it should be: ------------------------------------------------------------------------------- Return non-nil if COORDINATES are in WINDOW. COORDINATES is a cons of the form (X . Y), X and Y being distances measured in characters from the upper-left corner of the frame. (0 . 0) denotes the character in the upper left corner of the frame. If COORDINATES are in the text portion of WINDOW, the coordinates relative to the window are returned. If they are in the mode line of WINDOW, `mode-line' is returned. If they are in the top mode line of WINDOW, `header-line' is returned. If they are in the bitmap-area to the left of the window, `left-bitmap-area' is returned, if they are in the area on the right of the window, `right-bitmap-area' is returned. If they are on the border between WINDOW and its right sibling, `vertical-line' is returned. ------------------------------------------------------------------------------- Nothing but the coordinate munging is done, so dragging the mode line and friends won't work. And since XEmacs unread-command-events really does what it says (command-events only), motion events are unimplemented. Enjoy! -Bill P.

1 participants
0 comments

fstat/stat bugs on Windows NT? 24 years, 6 months

Adrian Aichner

Hello Groups, I am asking for your help on another problem in XEmacs on Windows NT native: fstat and stat seem wrong on Windows NT. XEmacs tries to work around the stat problem by implementing its own version. It does however use the equally buggy fstat version of Windows NT. This creates the issue that .el files appear newer than their .elc files (created while DST was on) after DST is switches off. Inside DEFUN ("load-internal", Fload_internal, 1, 6, 0, /* in lread.c the .elc file is fstat'ed with NT's native implementation while the .el file is stat'ed with XEmacs's stat implementation. perl (This is perl, version 5.005_03 built for MSWin32-x86) gives the same results as the Windows NT compatibility function stat. Here's what I see: My computer is in the MET-1MDT timezone. I have not explicitely set env. var. TZ in the experiments below, but that did not help when I tried. With system date "nov 8 1999" I create a file called "winter". I switch the system date to "oct 8 1999" and create "summer". Now I get different time_t values for their modification time both in perl and Windows NT functions fstat/stat, depending on the current date of the computer: With computer date "oct 8 1999": d:\Users\AichnerAd\tz\summer st_mtime: 939409806 gmtime Fri Oct 8 19:10:06 1999 localtime Fri Oct 8 21:10:06 1999 d:\Users\AichnerAd\tz\winter st_mtime: 942095185 gmtime Mon Nov 8 21:06:25 1999 localtime Mon Nov 8 22:06:25 1999 With computer date "nov 8 1999": d:\Users\AichnerAd\tz\summer st_mtime: 939406206 gmtime Fri Oct 8 18:10:06 1999 localtime Fri Oct 8 20:10:06 1999 d:\Users\AichnerAd\tz\winter st_mtime: 942091585 gmtime Mon Nov 8 20:06:25 1999 localtime Mon Nov 8 21:06:25 1999 I am happy with the distances between GMT (=UTC) and localtime, which are 2 hours in summer, 1 hour in winter (for MidEuropeanTime). However, the supposedly absolute modification time of a file changes with the current computer date setting (see st_mtime: ...) above. Please confirm that this is actually a Windows NT bug! FileTimeToLocalFileTime has this bothering remark, that a FILETIME will be adjusted according to the current DST status, not according to the file's time. Yuck! Could the knowledgable please comment? Currently I suppose the fix is to also encapsulate fstat in XEmacs Windows NT native. Any suggestions? Best regards, Adrian

1 participants
0 comments

[HEADS UP] movemail locking overhaul ahead 24 years, 6 months

Michael Sperber

I was recently charged with overhauling our institutional mailing system. It has turned out that one of the principal issues is the coordination of locking policies between MTAs and MUAs. For various reasons, our MTA uses "dot-locking", i.e. atomic creation of dummy a dummy file "mailbox.lock" alongside the file itself, "mailbox". Along the way, I checked XEmacs and found out that locking seems to be an OS issue, but can be configured. --mail-locking=file was supposed to do the trick, and configure reports that it's using "dot-locking". However, this is a lie: movemail only uses dot-locking in the absence of other locking methods. Since quite a few src/s headers declare a locking method, dot-locking never gets used on these systems. So, obviously, there's a bug here. I could fix it, but I think the whole mail-locking issue is conceptually broken in XEmacs: - The locking policy is not an OS issue, but rather a site issue. The OS issue is what policies *work*, not which ones are in use. - This means our binary kits are broken by design on many sites. I therefore propose the following changes: The locking policies can be controlled through three mechanisms (by descending precedence): - Specification on the movemail command line. - Specification of an environment variable EMACSLOCKMETHOD with the same possible values as the --mail-locking argument to configure. - Configuration via autoconf and src/config.h. Moreover, XEmacs itself should have a variable `mail-lock-method' (values 'file, 'lockf, 'flock) initialized from a variable `configure-mail-lock-method' set by autoconf which prompts XEmacs to call movemail with the appropriate command-line argument. Of course, this will take convincing the various XEmacs MUA package authors. If nobody objects by the upcoming weekend, I'll implement this. Opinions? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

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