February 2000 - XEmacs-Beta - XEmacs Mailing List Archives

T. V. Raman

Hi, Hoping that someone who knows the secrets of https on the xemacs list will have a chance to look at this. I have w3 set up to use https via openssl; I'll attach the configuration which I got working using Bill Perry's help a few months ago. The problem is that many sites end up returning w3 a blank (0 bytes) page --the one I'm trying to overcome right now is sourceforge.net. I'll append the w3 configuration for ssl that is know to at least work part of the time: (setq ssl-program-name "essl" ssl-program-arguments '("s_client" "-quiet" "-host" host "-port" service "-verify" (int-to-string ssl-certificate-verification-policy) "-CApath" ssl-certificate-directory)) --and I use the following shell script (essl refered to above) to wrapper openssl #!/bin/sh #redirect stderr so emacs doesn't barf on opensll exec 2>/dev/null exec openssl "$＠" -- Best Regards, --raman Email: raman(a)cs.cornell.edu WWW: http://cs.cornell.edu/home/raman/ PGP: http://cs.cornell.edu/home/raman/raman.asc

1 participants
0 comments

Re: XEmacs' desktop icon greyed out - revisited 24 years, 2 months

Jan Vroonhof

Taking a few seconds off from my feynman graphs.. ALTMARK(a)de.ibm.com writes: > With regard to the splash screen: I see the same logo on b27 and b11, but the If you think this problem got introduced after 21.2.11 I would suspect 1999-02-16 Kazuyuki IENAGA <ienaga(a)jsys.co.jp> * device-x.c: Support to find best visual without flashing. Which went in in between 21.2.11 and 21.2.12 http://www.xemacs.org/list-archives/xemacs-patches/199902/msg00036.html Jan

1 participants
0 comments

[patch] Ienaga's address change 24 years, 2 months

Kazuyuki IENAGA

Dear all, I'm going to step down the company "jsys.co.jp". The address "ienaga(a)jsys.co.jp" will be unreachable or invalid after 15 Feb. 2000. Could you please change your e-mail database if you collected mine? The address "kazz(a)imasy.or.jp" is valid unless I stop the contract with internet service provider (and I don't think to stop). The patch can be applied genuine 21.2.27 and I'm not sure if it's ok for latest CVS version of xemacs. Thanks, kazz 2000-02-04 Kazuyuki IENAGA <kazz(a)imasy.or.jp> * about.el: Ienaga's e-mail address change. =================================================================== RCS file: lisp/RCS/about.el,v retrieving revision 1.1 diff -u -r1.1 lisp/about.el --- lisp/about.el 2000/01/19 02:09:56 1.1 +++ lisp/about.el 2000/01/19 02:10:13 ＠＠ -71,7 +71,7 ＠＠ (jmiller "Jeff Miller" "jmiller(a)smart.net") (juhp "Jens-Ulrik Holger Petersen" "petersen(a)kurims.kyoto-u.ac.jp") (jwz "Jamie Zawinski" "jwz(a)jwz.org") - (kazz "IENAGA Kazuyuki" "ienaga(a)jsys.co.jp") + (kazz "IENAGA Kazuyuki" "kazz(a)imasy.or.jp") (kyle "Kyle Jones" "kyle_jones(a)wonderworks.com") (larsi "Lars Magne Ingebrigtsen" "larsi(a)gnus.org") (marcpa "Marc Paquette" "marcpa(a)CAM.ORG")

1 participants
0 comments

Re: XEmacs' desktop icon greyed out - revisited 24 years, 2 months

ALTMARK＠de.ibm.com

Thanks for the answer, Valdis. According to the 'xdpyinfo' output, the GXT2000P only supports 8 and 24 bit colorplanes (see attached file below). But it's not quite clear to me what's the conclusion of this: If the 16 bit visuals are the issue in the GXT255P and the GXT2000P doesn't support them - shouldn't I have no problem with the icons when using the latter card? (Ok, very naive approach, but please correct me if I'm on the wrong way here.) With regard to the splash screen: I see the same logo on b27 and b11, but the cycling text was introduced in b13 IIRC (excerpt from the announcement mail on xemacs-announce): to 21.2.13 "Demeter" -- Build fixes from Martin Buchholz -- experimental splash screen rewrite from Didier Verna <<< -- Various patches from Jan Vroonhof and Andy Piper -- alist.el synched up with APEL 9.13 from MORIOKA Tomohiko -- MS Window build fixes from Jonathan Harris -- UCS-4/UTF-8 support from MORIOKA Tomohiko Maybe this is causing the colormap trouble, although I can not imagine why, as the splash screen by default only contains black, blue and red text. Perhaps a redisplay problem? I'm no expert with this stuff ... ;-) What I will do, is trying to re-build b12 and b13 and see if my icon problem is associated with this version change. Markus (See attached file: xdpyinfo.out) Valdis.Kletnieks(a)vt.edu on 03/02/2000 17:26:25 Please respond to Valdis.Kletnieks(a)vt.edu To: Markus Alt/Germany/IBM＠IBMDE cc: xemacs-beta(a)xemacs.org Subject: Re: XEmacs' desktop icon greyed out - revisited On Thu, 03 Feb 2000 16:43:26 +0100, ALTMARK(a)de.ibm.com said: > Valdis asked me in a response to my mail on what RS/6000 model I was on and what > graphic card was installed. It was a 7043 model 150 with a GXT255P graphic > adapter and he told me that the latter was known to be "brain-dead with colormap > management" and that its successor, the GXT2000P, hopefully fixes the problem. > Well, meanwhile I have such a thing in my RS/6000 - and apparently it doesn't Damn. Well, I guess I won't ask my boss to buy me one then ;) Just as a quick test - does the gtx2000 support 16-bit colorplanes? You can just do a 'xdpyinfo' and see. The ancient GT4x I have in my home RS6K only has 8 and 24 bit visuals, the gtx255 has 8, 16, and 24. I'm suspecting the 16-bit visuals may be the issue (but can't prove it yet). > All this would prove that it's a hardware problem on the "better" graphic cards, > but ... a) all 21.1 XEmacsen I built on my machine (in the same environment and > with the same options to 'configure') have a nice white-red-yellow icon and b) > that old 21.2-b11 XEmacs which still sits around in my filesystem also does it > right, means: colored. > > So this leads me to the conclusion that something must have changed in the way > these icons are displayed since 21.2-b11 (or maybe in a later beta - I haven't > built each and every one in between b11 and b19). The issue is probably the order colors are allocated in. I'm willing to bet that somewhere around -b12 throughh -b19, something else got changed (when did we add the fancy new splash screen logo?) which caused the card to screw up the colormap when it ran out. > No one else on AIX and comparable hardware seeing this? And if I'm the only one > - could at least someone of the gurus please tell me what has changed in the > code so I might be able to create a workaround for my "brain-dead" ;-) hardware? For what it's worth, Netscape 4.05 through 4.7 and all Tk/Tcl since 7.6 or so have the same problems getting colors right on a GTX255. I've been hacking at Exmh the last few days, and I'm sufficiently pissed off at Tk/Tcl botching it that I'm going to go use a can opener on the Tk source and see if I can figure out what's going on. Film at 11. ;) /Valdis

1 participants
0 comments

MULE XEmacs: coding-system-for-read no-conversion; jka-compr patch 24 years, 2 months

Mark Thomas

Under linux, when coding-system-for-read is bound to 'no-conversion in MULE-enabled XEmacs 21.2.b27, end-of-line conversion still occurs. I notice that the EOL conversion differs from MULE-enabled FSFmacs 20.3. >From my zsh shell, I run the following which puts foo^Jbar in one buffer and foo^Mbar in another, then use string-equal to compare the buffers' contents. I expect the contents to be string-equal if EOL conversion occurs. $ xemacs -vanilla -batch -eval ' (let ((buf1 (get-buffer-create "*1*")) (buf2 (get-buffer-create "*2*"))) (require (quote cl)) (dolist (coding-system-for-read (quote (nil no-conversion binary))) (call-process "perl" nil buf1 nil "-e" "print qq(foo\\cJbar)") (call-process "perl" nil buf2 nil "-e" "print qq(foo\\cMbar)") (message "(coding-system-for-read %s) ==>\t%s" coding-system-for-read (string-equal (with-current-buffer buf1 (buffer-string)) (with-current-buffer buf2 (buffer-string))))))' (coding-system-for-read nil) ==> t (coding-system-for-read no-conversion) ==> t (coding-system-for-read binary) ==> nil Change "xemacs" to "emacs" and I get (coding-system-for-read nil) ==> t (coding-system-for-read no-conversion) ==> nil (coding-system-for-read binary) ==> nil This EOL conversion causes problems under jka-compr.el. Any ^M's in the output of gzip get converted to ^J's, corrupting the file. No one replied when I mentioned the auto-compression problems on this list and on comp.emacs.xemacs. The following patch to jka-compr.el changes coding-system-for-read prior to call-process; I haven't looked at crypt.el to see what needs to be done to correct its auto-compression functions. I have only tested this patch on MULE-enabled XEmacs 21.2.b27 under linux (RedHat 5.2). I wanted to post the change here for feedback before submitting to xemacs-patches. --- jka-compr.el.ORIG Thu Jan 27 11:27:37 2000 +++ jka-compr.el Thu Feb 3 18:25:22 2000 ＠＠ -464,7 +464,10 ＠＠ ;; save value used by the real write-region ;; without any code conversion. - (let ((coding-system-for-read 'no-conversion)) + (let ((;; XEmacs change: 'no-conversion still does EOL + ;; conversion which may corrupt the resulting + ;; compressed file + coding-system-for-read 'binary)) (jka-compr-call-process compress-program (concat compress-message " " base-name)

1 participants
0 comments

XEmacs' desktop icon greyed out - revisited 24 years, 2 months

ALTMARK＠de.ibm.com

Last September, I sent the note attached below to the list to report that my XEmacs' desktop (i.e. window manager) icon was greyed out (not colored) in 21.2-b19. (BTW: I have the same behaviour in each and every beta ever since, now running b27.) Valdis asked me in a response to my mail on what RS/6000 model I was on and what graphic card was installed. It was a 7043 model 150 with a GXT255P graphic adapter and he told me that the latter was known to be "brain-dead with colormap management" and that its successor, the GXT2000P, hopefully fixes the problem. Well, meanwhile I have such a thing in my RS/6000 - and apparently it doesn't ... The other thing is: I've been running a XEmacs on a RS/6000 model F50 which has a GXT120P graphic card installed (the former entry card which is only capable of displaying 256 out of 16.7 M colors). Surprisingly, on that machine, everything looks fine with the icons. All this would prove that it's a hardware problem on the "better" graphic cards, but ... a) all 21.1 XEmacsen I built on my machine (in the same environment and with the same options to 'configure') have a nice white-red-yellow icon and b) that old 21.2-b11 XEmacs which still sits around in my filesystem also does it right, means: colored. So this leads me to the conclusion that something must have changed in the way these icons are displayed since 21.2-b11 (or maybe in a later beta - I haven't built each and every one in between b11 and b19). No one else on AIX and comparable hardware seeing this? And if I'm the only one - could at least someone of the gurus please tell me what has changed in the code so I might be able to create a workaround for my "brain-dead" ;-) hardware? Any help is greatly appreciated! TIA, Markus --- Markus Alt IBM Laboratory Boeblingen, Germany ---------------------- Forwarded by Markus Alt/Germany/IBM on 02/03/2000 04:07 PM --------------------------- ALTMARK(a)de.ibm.com on 09/29/99 10:52:46 AM Please respond to ALTMARK(a)de.ibm.com To: xemacs-beta(a)xemacs.org cc: (bcc: Markus Alt/Germany/IBM) Subject: XEmacs' desktop icon greyed out in 21.2 Maybe I should have reported this much earlier, but perhaps I got used to that odd behaviour ... Nevertheless, finally: Since a few beta versions of 21.2, the desktop icon of XEmacs is displayed greyed-out on my window manager (i.e. not that usual colored red, yellow and white style). Same for dtwm and mwm window manager. I don't remember exactly in which version this occured for the first time, but it definetely happens when I start the latest 21.2-b19 (compiled from the tarballs) and on the other hand everything's ok when I start that old 21.2-b11 binary I still have (also compiled myself). As I haven't built each and every version in between, I can't determine when I saw this first. Surprisingly, when opening the file <installdir>/lib/xemacs-21.2-b19/etc/xemacs-icon.xpm within XEmacs and call "M-x xpm-mode" afterwards, the XPM image is displayed as expected at the top of the buffer. Perhaps somebody can shed a little light on this? OS is AIX 4.3.2, Installation file attached below. (BTW, when talking about the Installation file: It always complains that "Motif dialog boxes cause problems on AIX 4.3 and higher". I've never seen any of them ... What problems are these?) TIA for your help! (See attached file: Installation) --- Markus Alt IBM Laboratory Boeblingen, Germany

2 participants
1 comments

Re: What is the EMX system? 24 years, 2 months

Daniel Pittman

On Wed, 02 Feb 2000, Kirill Katsnelson <kkm(a)dtmx.com> wrote: > Does this system exist? I notice that the support for it often > comes along with MSDOS. What is (or was) it? Is it supported? > I just want to get rid of MSDOS stuff in the C code. It's the equivalent of Cygwin for OS/2 -- a support library that maps Posix(ish) calls into the underlying Os syscalls. Daniel -- Moloch whose mind is pure machinery! Moloch whose blood is running money! Moloch whose fingers are ten armies! Moloch whose breast is a cannibal dynamo! Moloch whose ear is a smoking tomb! -- Allen Ginsberg, _Howl_

1 participants
0 comments

What is the EMX system? 24 years, 2 months

Kirill 'Big K' Katsnelson

Does this system exist? I notice that the support for it often comes along with MSDOS. What is (or was) it? Is it supported? I just want to get rid of MSDOS stuff in the C code. Big K

1 participants
0 comments

Your email may have been lost 24 years, 2 months

Martin Buchholz

My email connection has been unreliable for the last few days, so your mail to me may have gone to /dev/null. If your email was important, please resend it. I will be looking at the xemacs mailing lists as well for missed messages... Martin

1 participants
0 comments

Re: [PATCH] Recompute glyph metrics when face changes 24 years, 2 months

Hrvoje Niksic

"Kirill 'Big K' Katsnelson" <kkm(a)dtmx.com> writes: > Some time ago, Kyle Jones wrote... > >An image instance might be invalidated by a face change also. > >For instance XPM images can have a transparent background and > >therefore inherit their background color from the glyph's face. > >So this is a general problem that we have to solve. > > Oh, I missed that. Won't be hard. I can merely relax the checks, > causing more glyphs to be recomputed. Perhaps all, changing faces is > a rare operation, and often leads to the total redisplay anyway. Please be careful about these things. There are many operations that cause a complete redisplay in XEmacs that could be optimized away, and it often causes unnecessary flicker. For instance, some time in the 21.2 beta cycle, a new flicker was added when you leave the minibuffer. Something like `M-: C-g' redraws the whole frame after the C-g. This is especially annoying under TTY's.

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 February 2000