June 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Simon Josefsson

Oliver Graf <ograf(a)fga.de> writes: > Darryl Okahata <darrylo(a)sr.hp.com> writes: > > > I took a look at my mailer (mh-e), and my patches are being sent > > out as application/octet-stream instead of text/plain due to bugs in TM. > > I'll fix this in a day or two and submit patches (which I realize > > probably won't make it into 21.0). > > Perhaps mh-e, tm, or whatever module of XEmacs is reponsible should do a bit > file-magic and guess the type of the file to use the correct MIME > type. That's what the mime-types file is for. Is there a reason (beside it's "beta"-status, I guess one should wait for it to become stable) not to switch from TM to SEMI? I haven't had any serious problems with it (that wasn't my fault, anyway) for months, and it has popup-menus and stuff that is very XEmacsy. :-) /S

1 participants
0 comments

Re: Patches & MIME 26 years, 6 months

Michael Sperber

>>>>> "Oscar" == Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes: Oscar> I have the same comment as Jan Vroonhof: patch files having an Oscar> application/octet-stream type is not a bug it's definitely a feature. Patch Oscar> files are input for the patch program not plain text. Input for the patch program *is* plain text. More specifically, patches sent to xemacs-patches are *primarily* text because someone needs to read them before patch ever gets to chew on them. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Icons in toolbar are wrong 26 years, 6 months

Ian MacKinnon

Xemacs - vanilla give me some wrong icons in the toolbar Print, paste and Search/replace all appear as open They work OK, its just the icon that's wrong This b42, cygwin plus Andy latest patches for xbms running on NT It may also have been just plain b42, I'm not sure. Anyone else seeing this ? --- Ian

2 participants
1 comments

Re: Info warnings 26 years, 6 months

Oscar Figueiredo

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> OK, for quite a few betas Info has been pretty insistent in throwing Hrvoje> warnings in my face. I was kind of hoping this would be resolved, so Hrvoje> I stayed silent. However, it is not getting solved, so I have to Hrvoje> speak up. The subject has been discussed for a while some time ago. I made some changes according to the state that discussion was left and since nobody complained, I assumed that everybody accepted the current behaviour. Hrvoje> The warning is this: Hrvoje> (1) (info/notice) Outdated info dir file: /usr/local/info/dir This is not strictly a warning but a notice. Hrvoje> Of course, I don't even have permission to modify the Hrvoje> /usr/local/info/dir file, and neither has any of the users on the Hrvoje> machine I run XEmacs on. So, the warning will be seen by all of them, Hrvoje> and likely many more of our users in the world. Hrvoje> What is the *purpose* of this warning, anyway? Warnings should inform Hrvoje> the user of a condition he/she should remedy. Your not having the right to overwrite that file at the moment you run Info does not mean you can not acquire that right. So you may be able to remedy the problem with that file. This notice tells you also you should be aware that the Info directory you're seeing is not the one that's on your disk but one that was automatically generated on the fly. I suppose that by default a user wants this kind of information. As usual, if this is not the case and you don't want that information you're not helpless, you can either: - set `Info-rebuild-outdated-dir' to `never' or `always' - set `display-warning-minimum-level' to 'warning - set `display-warning-suppressed-classes' to '(info) Hrvoje> I don't see how I could remedy this -- even if I bug my sysadmin into Hrvoje> updating `dir', it will get outdated the first time he installs Hrvoje> another package. The first time he installs another package he should update the dir file consequently with `install-info' or `xemacs -batch -f Info-batch-rebuild-dir DIR' Hrvoje> I don't even see why I *should* remedy this situation, because XEmacs Hrvoje> appears perfectly able to deal with the situation. This is not an error but an informative message so XEmacs has no problem dealing with the situation. IMO, the current default is good (provided I document better how to change that behaviour, which I will do ASAP) and it seemed to me from the previous discussion there was a majority in favour. I may be wrong however (and then will agree to change that default once again), so I would like more feedback on the issue before making any further change. Oscar

1 participants
0 comments

[Success + DnD ok] 21.0 "Somali" XEmacs Lucid (beta42) on sparc-sun-solaris2.6 26 years, 6 months

Oliver Graf

build from plain sources plus an extra CDE DnD patch (to be posted this evening). CDE Drag AND Drop now both work fine for me (CDE 1.0.2, tested text, file, multi-file drags and drops in and out of XEmacs together with dtfile and dtpad). > XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /import/sw/epoch/lib/xemacs/api/build/xemacs-21.0-b42/Installation: > (Output from most recent run of ./configure) uname -a: SunOS benn 5.6 Generic sun4u sparc SUNW,Ultra-1 ./configure '--prefix=/import/sw/epoch/lib/xemacs/api/install' '--gung-ho' '--use-union-type' XEmacs 21.0-b42 "Somali" configured for `sparc-sun-solaris2.6'. Where should the build process find the source code? /import/sw/epoch/lib/xemacs/api/build/xemacs-21.0-b42 What installation prefix should install use? /import/sw/epoch/lib/xemacs/api/install What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.h' What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/dt/include /usr/X11R6/include Where do we find X Windows libraries? /usr/dt/lib /usr/X11R6/lib Runtime library search path: /usr/dt/lib:/usr/X11R6/lib:/usr/local/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for JPEG image conversion. Compiling in support for TIFF image conversion. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in support for LDAP (UMich libs). Compiling in support for CDE. Compiling in support for ToolTalk. Compiling in support for Drag'n'Drop ( CDE ). Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using the union type for Lisp_Objects. Using Lisp_Objects with minimal tagbits. Using indexed lrecord implementation. Compiling in extra code for debugging. Compiling in code for checking XEmacs memory usage. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- > /import/sw/epoch/lib/xemacs/api/build/xemacs-21.0-b42/beta.err does not exist!

1 participants
0 comments

Re: Patches & MIME 26 years, 6 months

Oscar Figueiredo

>>>>> "Darryl" == Darryl Okahata <darrylo(a)sr.hp.com> writes: Darryl> Oliver Graf <ograf(a)fga.de> wrote: >> Perhaps mh-e, tm, or whatever module of XEmacs is reponsible should do a bit >> file-magic and guess the type of the file to use the correct MIME type. Darryl> I believe TM is responsible. Darryl> TM will also guess the type based upon the file extension (see the Darryl> alist, "mime-file-types", in tm/tm-edit.el). There are even entries for Darryl> the extensions ".diff" and ".patch"; unfortunately, the defaults for Darryl> these are application/octet-stream (I'd like to change them to Darryl> text/plain w/base64 -- any comments?). For unrecognized files, the Darryl> default is also application/octet-stream. I have the same comment as Jan Vroonhof: patch files having an application/octet-stream type is not a bug it's definitely a feature. Patch files are input for the patch program not plain text. I agree however that TM should provide a means to display application/octet-stream typed attachments as text on user request (what I currently do in Gnus is toggle MIME processing on and off with 'W m'). I think you should not change the patch type to text/plain without thoroughly checking it won't break patches containing multi-byte characters. Oscar

1 participants
0 comments

[PATCH] for PNG-crash 26 years, 6 months

Gunnar Evermann

Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes: > when I enter customize in a vanilla XEmacs the png-code crahses. Do I > need a different lib?? I have: libpng-1.0.1 and zlib-1.1.2 > (dbx) where > [1] _kill(0x0, 0xb, 0x0, 0x0, 0x6f8a227c, 0xf121c), at 0x6f8872e0 > =>[2] fatal_error_signal(sig = 11), line 262 in "emacs.c" > ---- called from signal handler with signal 11 (SIGSEGV) ------ > [3] _memcpy(), at 0x6f8c05b0 > [4] png_read_from_memory(png_ptr = 0x84e800, data = 0x80b000 "", length = 144U), line 738 in "glyphs-eimage.c" > [5] png_read_data(0x84e800, 0x80b000, 0x90, 0x13, 0x6ffeb790, 0x6ffed640), at 0x6fdd1d7c [rest snipped] I think I found a rather serious error in the PNG-handling code... Deep inside png_instantiate() (glyphs-eimage.c:848) in a nested block some kind of initialization for the upcoming png-read is done, specifically a struct named tbr is declared as a local variable and the address is stored in the png_ptr. the code looks like this: /* Initialize the IO layer and read in header information */ { Lisp_Object data = find_keyword_in_vector (instantiator, Q_data); CONST Extbyte *bytes; Extcount len; struct png_memory_storage tbr; /* Data to be read */ assert (!NILP (data)); /* #### This is a definite problem under Mule due to the amount of stack data it might allocate. Need to think about using Lstreams */ GET_STRING_BINARY_DATA_ALLOCA (data, bytes, len); tbr.bytes = bytes; tbr.len = len; tbr.index = 0; png_set_read_fn (png_ptr,(void *) &tbr, png_read_from_memory); } If I'm not mistaken, at this time (after the closing brace) the stack-allocated tbr can (and will) be overwritten. For me this happens when a new block is opened and new local variables are declared. The following png_read's still access the old location ... Boom! I moved the tbr declaration one level up and this fixes my problem -- somebody who actually knows this code should have a look at it. Gunnar 1998-06-03 Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> * glyphs-eimage.c (png_instantiate) move 'struct png_memory_storage tbr' out of nested block to avoid dangling reference glyphs-eimage.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/glyphs-eimage.c,v retrieving revision 1.2 diff -u -r1.2 glyphs-eimage.c --- glyphs-eimage.c 1998/04/28 00:24:57 1.2 +++ glyphs-eimage.c 1998/06/04 01:32:01 ＠＠ -798,6 +798,7 ＠＠ struct png_unwind_data unwind; int speccount = specpdl_depth (); int height, width; + struct png_memory_storage tbr; /* Data to be read */ /* PNG variables */ png_structp png_ptr; ＠＠ -844,7 +845,6 ＠＠ Lisp_Object data = find_keyword_in_vector (instantiator, Q_data); CONST Extbyte *bytes; Extcount len; - struct png_memory_storage tbr; /* Data to be read */ assert (!NILP (data));

2 participants
1 comments

Re: DnD, CDE, and experimental 26 years, 6 months

Oliver Graf

Rebecca Ore <rebecca.ore(a)op.net> writes: > Oliver Graf writes: > > > > > Something else: KDE uses a dnd protocol that is 'stolen' from OffiX. I can add > > the support for KDE straight in the first 21.1 version. > > > > If you need me to test anything, make it either early before > the weekend or after I've settled in the upgrade or reinstall of Red > Hat 5.1 (on to the libc formerly known as six). Also, let the kde > people in on it -- I forwarded mail to you from one of their > developers. Yes, thanxx. I'm already conferencing with the KDE developers, but support for them will not go into 21.0 (the changes for the current protocol are small: OffiX must recognize type 128 drops as multi-URL drops) cause of the feature freeze (or should I add it -- well I will send in a patch if it is not good we can put it in the tests dir for people who want to try...). KDE will soon switch to the Xdnd protocol, but this will take time on their side also. If you want to test the code, eval tests/Dnd/droptest.el. But 'real' tests are only possible after I put hand on dired... Regards, Oliver.

1 participants
0 comments

Re: Patches & MIME 26 years, 6 months

SL Baur

Darryl Okahata <darrylo(a)sr.hp.com> writes: > Ben's complaint is not about MIME and/or the MIME encoding > (e.g., base64 -- as I and others mistakenly inferred), but that the MIME > type and subtype are typically "application/octet-stream", which his > mailreader can't (easily) handle (it's marked as an attachment, and the > text is not displayed to the user). O.K. We've been over this issue before. I don't like this behavior either. Be careful how you go about `fixing' this as there are reasons for why it behaves as it does. ... > Ben also suggests that Kyle's patchbot be modified to automatically > translate incoming application/octet-stream to text/plain (if > appropriate). Please don't do this unless you have verified that this won't break patches that contain multibyte characters.

2 participants
1 comments

Re: [problem] suspending-emacs with GPM under Linux 26 years, 6 months

Jens-Ulrik Petersen

>>>>> "juhp" == Jens-Ulrik Petersen <petersen(a)kurims.kyoto-u.ac.jp> writes: juhp> [Sorry if this has been reported before, I don't have time juhp> to read the list much these days...] Mark Borges kindly pointed out to me privately that this is already mentioned in "PROBLEMS". Does GPM work on any other system than Linux? If not, wouldn't it be better to disable this option in "configure"? juhp> In a Linux console with GPM (mouse support), when I try to juhp> suspend beta42-pre2 (compiled with gpm support), xemacs just juhp> seems to hang indefintely. Has/can anyone else seen/see juhp> this? (This is with a recently installed Debian-unstable juhp> 2.0 dist.) -- Jens-Ulrik Holger Petersen <http://www.kurims.kyoto-u.ac.jp/~petersen/> Research Institute for Mathematical Sciences, Kyoto University

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 June 1998