May 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Hrvoje Niksic

[ Added Cc to xemacs-mule ] Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > However I still think there is a problem with file coding > there. This code presumably worked in latin-1 and Japanese > environments. Given that he also has a problem writing the file out > again I think this illustrates a general problem. IMHO, All coding > systems should be such that when an arbitrary binary file is read in > with them and written back out the things should be the same. Even I admit this is impossible. I say "even I" because I've had many requirements along similar lines, but this one really can't be met in the current framework. A little background: when we "read in" a file, we always convert it to the internal representation. That's what the coding systems are for. All the other manipulations are performed with the internal data. Now, when we "write out" the file, we convert it to an external representation, which might or might not be the same as the one we read the file in was. Even when reading and writing representations are the same, you can lose data. As Stephen J. Turnbull illustrated: imagine that we are reading a binary file with ISO-2022 and that it contains binary sequences <Ltn2><Ltn1><Ltn2>some-chars... The switch from Latin 2 to Latin 1 and back to Latin 2 will be lost on the input because it will have been "optimized away". And these switching sequences are by no means rare. :-( If you consider that all of out Latin N coding systems are in fact ISO-2022 with the appropriate default for 160-255 range, you see why Mule is in trouble.

1 participants
0 comments

Re: current-line.el 26 years

SL Baur

Tudor Hulubei <tudor(a)cs.unh.edu> writes in xemacs-beta(a)xemacs.org: > On Saturday, 24 April 1999, Tudor Hulubei wrote: >> I find useful sometimes to have the current line highlighted in some >> major modes (vm-summary-mode, buffer-menu-mode, dired-mode, >> compilation-mode, etc). If there is no code in XEmacs that does that >> (I looked, but you never know :-)), the following will work fine, with >> both XEmacs and GNU Emacs. > I've submitted the code to the FSF, and RMS included it in FSF Emacs. > The thing is, he changed the name from current-line to curline, and I > don't know if he changed only the file name, or something else in the > file :-). I will repost the code as soon as I get kerberos running > and be able to login on the FSF machines to check this out. O.K. I'll put it in when you resubmit it. He probably also changed the point-at-[eb]ol stuff you had. Those functions have new horrible name that I cannot remember.

2 participants
1 comments

Re: package-get & md5 26 years

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > I understand all that, I just want to make sure that your proposed fix > doesn't break something else. > > I am not sure that this call to insert-file-contents-literally even > needs to work with EFS; Jan might know that. I think the fix is correct. See the comment in the code there. I wanted to use i-f-c-literally but for some reason I thought it had gone away. The whole let form should be replaced by a single i-f-c-literally call. (BTW where does i-f-c-literally ensure there was no coding system conversion?) However I still think there is a problem with file coding there. This code presumably worked in latin-1 and Japanese environments. Given that he also has a problem writing the file out again I think this illustrates a general problem. IMHO, All coding systems should be such that when an arbitrary binary file is read in with them and written back out the things should be the same. See for instance the problems with the KOI-8 coding system. Jan

1 participants
0 comments

crash in xlib XIM handling 26 years

Gunnar Evermann

I have experienced a couple of crashes related to the XIM xlib stuff some time ago (see backtrace below). Karl Kleinpaste has been reporting similar crashes for some time. Alas I have not been able to find a way to reproduce this. I am running XFree86 3.3.2.3 on i586-pc-linux. The problem is the following code in x_to_emacs_keysym() in event-Xt.c:781 #ifdef XIM_XLIB XIC xic = FRAME_X_XIC (x_any_window_to_frame (get_device_from_display (event->display), event->window)); #endif /* XIM_XLIB */ for some reason x_any_window_to_frame() can't find the window in any frame and returns 0. I'm not sure which window this event is referring to and don't know how to figure this out from the core dump. In some other places in event-Xt.c we check whether x_any_window_to_frame() found a frame and otherwise just toss the event away. Would this be appropriate in this case as well? We could presumably just return Qnil. Any comments? Gunnar #2 <signal handler called> #3 error_check_frame_type (f=0x0, sym=138049092) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/frame.h:248 #4 0x8193c59 in x_to_emacs_keysym (event=0xbfffef64, simple_p=0) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/event-Xt.c:782 #5 0x8194422 in x_event_to_emacs_event (x_event=0xbfffef64, emacs_event=0x8982444) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/event-Xt.c:997 #6 0x8196cb4 in emacs_Xt_event_handler (wid=0x8559410, closure=0x0, event=0xbfffef64, continue_to_dispatch=0xbfffeea3 "\001°kv\b$éQ\b\030O\017＠") at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/event-Xt.c:2440 #7 0x400ca0bf in XtDispatchEventToWidget () #8 0x400caa6d in _XtDefaultDispatcher () #9 0x400caca3 in XtDispatchEvent () #10 0x400d3ce3 in XtAppProcessEvent () #11 0x8197310 in drain_X_queue () at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/event-Xt.c:2596 #12 0x8197426 in emacs_Xt_event_pending_p (user_p=1) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/event-Xt.c:2709 -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University

1 participants
0 comments

Re: current-line.el 26 years

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > > > SL Baur <steve(a)xemacs.org> writes: > >> O.K. I'll put it in when you resubmit it. He probably also changed > >> the point-at-[eb]ol stuff you had. Those functions have new > >> horrible name that I cannot remember. > > > line-start-position and line-end-position, I think. I'll add the > > aliases one of these days. > > `line-beginning-position' and `line-end-position', as it turns out. I > was under the impression that we had already added aliases for them, > but I only see aliases in APEL. If you are going to add them > somewhere else, the aliases in APEL need to be removed as well. Yes. Aliases to subr's should be defined in obsolete.el so that they are always available.

1 participants
0 comments

Re: current-line.el 26 years

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > SL Baur <steve(a)xemacs.org> writes: >> O.K. I'll put it in when you resubmit it. He probably also changed >> the point-at-[eb]ol stuff you had. Those functions have new >> horrible name that I cannot remember. > line-start-position and line-end-position, I think. I'll add the > aliases one of these days. `line-beginning-position' and `line-end-position', as it turns out. I was under the impression that we had already added aliases for them, but I only see aliases in APEL. If you are going to add them somewhere else, the aliases in APEL need to be removed as well.

1 participants
0 comments

Re: cvs access for XEmacs 21.2.* 26 years

SL Baur

Kyle Jones <kyle_jones(a)wonderworks.com> writes in xemacs-beta(a)xemacs.org: ... > Forget customary. The CVS tree ought to be set up to be > convenient for developers and beta testers. I think this > means the default checkout gets you the latest version, > stable versions appear as branches. Where I've worked, any > other setup would have the developers feasting on your flesh > by the light of the moon. Fortunately, it is new moon right now. :-) O.K. Let's reverse the tags. Has anyone in the gallery ever done that before?

1 participants
0 comments

Re: package-get & md5 26 years

Hrvoje Niksic

Petr Konecny <pekon(a)informatics.muni.cz> writes: > >> Thanks for explanation. Then I think the original patch (see thread > >> in xemacs-patches) is correct. Am I wrong ? > > H> Isn't package-get stuff supposed to work with EFS? Does > H> `insert-file-contents-literally' grok EFS? > > My problem is not with downloading the package, but with computing > its md5 sum. The file is stored into /tmp and then loaded into a > buffer with insert-file-content-internal. But since my language > environment is Latin-2 (...), I understand all that, I just want to make sure that your proposed fix doesn't break something else. I am not sure that this call to insert-file-contents-literally even needs to work with EFS; Jan might know that.

1 participants
0 comments

Re: package-get & md5 26 years

Petr Konecny

>>>>> Hrvoje Niksic (H) said: >>>>> SL Baur (sb) said: sb> insert-file-contents-internal is supposed to do encoding and sb> insert-file-contents-literally is not, so I think this behavior is sb> O.K. >>>>> Petr Konecny <pekon(a)informatics.muni.cz> writes: >> Thanks for explanation. Then I think the original patch (see thread >> in xemacs-patches) is correct. Am I wrong ? H> Isn't package-get stuff supposed to work with EFS? Does H> `insert-file-contents-literally' grok EFS? My problem is not with downloading the package, but with computing its md5 sum. The file is stored into /tmp and then loaded into a buffer with insert-file-content-internal. But since my language environment is Latin-2, the resulting buffer is different from binary contents of the file and md5 sums do not match. It is in the following piece of code: (with-temp-buffer ;; What ever happened to i-f-c-literally (let (file-name-handler-alist) (insert-file-contents-internal full-package-filename)) (if (not (string= (md5 (current-buffer)) (package-get-info-prop this-package 'md5sum))) (error "Package %s does not match md5 checksum" base-filename))) When I change insert-file-contents-internal to insert-file-contents-literally the computed md5 sum is OK and the package is succesfully installed. Petr -- Admiration, n.: Our polite recognition of another's resemblance to ourselves. -- Ambrose Bierce, "The Devil's Dictionary"

1 participants
0 comments

Re: package-get & md5 26 years

Hrvoje Niksic

Petr Konecny <pekon(a)informatics.muni.cz> writes: > >>>>> SL Baur (sb) said: > > sb> insert-file-contents-internal is supposed to do encoding and > sb> insert-file-contents-literally is not, so I think this behavior is > sb> O.K. > > Thanks for explanation. Then I think the original patch (see thread > in xemacs-patches) is correct. Am I wrong ? Isn't package-get stuff supposed to work with EFS? Does `insert-file-contents-literally' grok EFS?

2 participants
1 comments

2025

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 May 1999