January 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: 8-bit vs. 24-bit on new Sun hardware. 25 years, 11 months

Hrvoje Niksic

FWIW, I also vote for us to do what Netscape does: determine the best available colormap and use it.

1 participants
0 comments

Re: The redisplay engine is getting really messy ... 25 years, 11 months

Hrvoje Niksic

Didier Verna <verna(a)inf.enst.fr> writes: > When I read (quickly I admit) through Andrew Innes's page, it > appeared very very technical to me. Didier, do you perhaps mean Joe Nuspl's page? He had a very technical page regarding the XEmacs redisplay optimizations he planned to implement (but, alas, gave up!), and it is those we talked about while we were in Paris. Andrew Innes is the guy who implemented the new FSF Emacs redisplay, and introduced and implemented many useful *concepts*, such as stretched glyphs, correct font merging, etc. etc. I think that stuff is worth a good look at.

1 participants
0 comments

Re: The redisplay engine is getting really messy ... 25 years, 11 months

Adam Hammer

Didier Verna <verna(a)inf.enst.fr> writes: > When I read (quickly I admit) through Andrew Innes's page, it > appeared very very technical to me. Where is this page?

1 participants
0 comments

Re: 8-bit vs. 24-bit on new Sun hardware. 25 years, 11 months

Didier Verna

Stephen J Turnbull writes: Stephen> This isn't true in theory; O'Reilly's Xlib Programmer's Guide claims Stephen> it wasn't true in practice (even as of the X11R4 edition). A server Stephen> can implement multiple hardware colormaps, and there will not Stephen> necessarily be any flashing when different window use different Stephen> colormaps. Yup. This is probably why Martin didn't notice any flashing. Stephen> you _can't_ have a private colormap with Truecolor (I think, or is Stephen> that directcolor?. The concept of "private" colormap is meaningless in the case of TrueColor. You can perfectly well create your own TrueColor colormap, but the color cells are Read Only, and have predefined values assigned by the server. On the other hand, a DirectColor colormap is like a TrueColor one, except that the cells are modifiable. Stephen> ? Those are orthogonal options, aren't they? Not completely. Stephen> If the server allows you to specify a visual, it has to provide a Stephen> compatible default colormap. Don't be so confident in X ;-) When you create an XWindow, you may assign it a particular visual and colormap. The obvious constraint is that the colormap must be of the same visual type as the window (this is why the options are not completely orthogonal). But the point is that by default, the colormap assigned to a newly created window inside the XWindowAttribute structure is CopyFromParent. Consequently, if for instance you create a TrueColor24 XWindow on a PseudoColor8 (by default) screen and don't explicitely give it a proper colormap, you'll get a BadMatch error. This brain damage in the conception is also visible with the Intrinsics widgets and Motif. A naive Motif application running under the same circumstances as described above will crash immediately when you try to open a menu. This is because the menus widgets (which inherits from Shell) inherits the visual and depth from their parent WIDGET, but the colormap from their parent WINDOW. Hence the BadMatch error. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: 8-bit vs. 24-bit on new Sun hardware. 25 years, 11 months

Didier Verna

Martin Buchholz writes: Martin> However, the default visual is only 8-bit. This is a decision by Sun Martin> (mistaken, in my opinion) to improve backward compatibility with old Martin> apps. How mistaken indeed. It has always surprised me to find apps running properly under PseudoColor displays and not under TrueColor ones. Martin> A system administrator can change the default visual by copying Martin> /usr/dt/config/Xservers to /etc/dt/config and hacking it to add Martin> under-documented flags like -defdepth 24. Few system administrators Martin> will be able to figure this out. You can also launch directly your Xserver with options changing the default depth. When running a Creator3D machine, I've been using this for several years now (the dev option is needed if you want to mess up with the rest): | openwin -dev /dev/fb defclass TrueColor defdepth 24 Martin> An application running in this kind of environment should be able to Martin> recognize that the display is truly 24-bit and create 24-bit windows. Martin> For example, recent netscape's do this properly. Martin> xwininfo on a netscape window: Depth: 24 Visual Class: TrueColor Martin> xwininfo on a xemacs window: Depth: 8 Visual Class: PseudoColor I don't quite understand what you mean here. If you're running under a TrueColor 24 visual BY DEFAULT and don't mess up with it (neither with the colormap), you simply get windows of the same visual. Here, your X server was probably not launched with TrueColor24 by default, and I wouldn't be surprised that netscape comes with the --install option (and a private colormap). If you're telling us that /regardless/ of the default visual, XEmacs should use the best one by default, I strongly disagree. For instance, if you have PseudoColor8 by default and force XEmacs to use TrueColor24, you'll get colormap flashing because it needs a different one (remeber there's a strong relation between the visual you choose and the colormaps you can use) and user scream :-) On the other hand, you can use the -visual option to change the default visual. BTW, I'd be curious to see if XEmacs is clever enough, when given the -visual option, to figure out whether he needs a private colormap too... -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

3 participants
2 comments

Shell command error 25 years, 11 months

Wayne Newberry

I'm running XEmacs 21.0 "Pyrenean" [Lucid] (i386-pc-win32) of Tue Jan 05 1999 on HERMES, the pre-compiled binary for Windows 95 (XEmacs-21.0-b62). To print a text file, I did: M-x shell-command and entered the following text. copy c:\log.txt \\Dvxma001\ps_wes_doc_5si In the minibuffer, I saw the following message: Spawning child process: Exec format error I turned on Debug On Error" in the Lisp-Interaction menu, and saw the following in buffer that appeared: Signaling: (file-error "Spawning child process" "Exec format error") call-process-internal("C:\\WINDOWS\\COMMAND.COM" "C:\\windows\\TEMP\\emzu0B3Y" #<buffer "*Shell Command Output*"> nil "/c" "copy c:\\log.txt \\\\Dvxma001\\ps_wes_doc_5si") apply(call-process-internal "C:\\WINDOWS\\COMMAND.COM" "C:\\windows\\TEMP\\emzu0B3Y" #<buffer "*Shell Command Output*"> nil ("/c" "copy c:\\log.txt \\\\Dvxma001\\ps_wes_doc_5si")) call-process("C:\\WINDOWS\\COMMAND.COM" "C:\\windows\\TEMP\\emzu0B3Y" #<buffer "*Shell Command Output*"> nil "/c" "copy c:\\log.txt \\\\Dvxma001\\ps_wes_doc_5si") apply(call-process "C:\\WINDOWS\\COMMAND.COM" "C:\\windows\\TEMP\\emzu0B3Y" #<buffer "*Shell Command Output*"> nil ("/c" "copy c:\\log.txt \\\\Dvxma001\\ps_wes_doc_5si")) call-process-region(239 239 "C:\\WINDOWS\\COMMAND.COM" nil #<buffer "*Shell Command Output*"> nil "/c" "copy c:\\log.txt \\\\Dvxma001\\ps_wes_doc_5si") shell-command-on-region(239 239 "copy c:\\log.txt \\\\Dvxma001\\ps_wes_doc_5si" nil) #<compiled-function (command &optional output-buffer) "...(66)" [output-buffer bufferp barf-if-buffer-read-only push-mark call-process shell-file-name nil t shell-command-switch command exchange-point-and-mark match-data match-data (...) string-match "[ ]*&[ ]*$" background 0 shell-command-on-region] 7 153592 (list (read-shell-command "Shell command: ") current-prefix-arg)>("copy c:\\log.txt \\\\Dvxma001\\ps_wes_doc_5si" nil) call-interactively(shell-command) command-execute(shell-command t) execute-extended-command(nil) call-interactively(execute-extended-command) In the minibuffer, I now saw: Wrong type argument: number-char-or-marker-p, nil I tested the "copy" command line in an MS-DOS window, and the file printed properly. I tested the same shell-command function using Emacs (the Voelker version for PCs) and the file printed properly. I looked through process.el, and found references such as (if (eq system-type 'windows-nt) and confirmed that for my PC system-type is equal to windows-nt. Is there a format difference for the string that the XEmacs shell-command takes? Any assistance appreciated. Wayne -- Wayne Newberry - Principal Technical Writer Davox Corporation, 6 Technology Park Drive, Westford, MA 01886 Web: http://www.davox.com Email: waynen(a)davox.com or waynen(a)wordsmith.ultranet.com Phone: (978) 952-0564 FAX: (978) 952-0201

1 participants
0 comments

Re: The redisplay engine is getting really messy ... 25 years, 11 months

Didier Verna

Kyle Jones writes: Kyle> We should remember that some of this stuff has never worked right. Your Kyle> example certainly hasn't. The problem here is the lack of a proper Kyle> internal notification of the change. Exactly. Kyle> I haven't found redisplay problems hard to fix, but there is a long Kyle> period of study required before it becomes obvious where to look to fix Kyle> problem. This study would still be required if we were to do a rewrite, True :-( While I have several ideas in mind that I'd like to see implemented in redisplay, I couldn't even begin to estimate the amount of work it could require, because I know I don't master the whole engine. Kyle> alas, because Emacs has some historical display behavior that we would Kyle> have to duplicate. I don't quite understand this. Could you elaborate ? -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

2 participants
1 comments

Re: The redisplay engine is getting really messy ... 25 years, 11 months

Didier Verna

Hrvoje Niksic writes: Hrvoje> The realistic question is: do we need that level of detail? (I Hrvoje> sometimes wonder the same about specifiers.) Ben felt very strongly Hrvoje> that we didn't, and I didn't quite agree with his position, but I do Hrvoje> see a merit to the question. This is a question worth to be asked indeed. There are different things to consider here: everyone's wishes and the current state-of-the-art. Personally, I find several things annoying. The randomness of the size of the scrollbar is one, the fact that a line is 3 kilometers high just because there's an image in it is another. The fact that you can't really scroll appart from on a character basis is yet another. Now I can admit that whether those /features/ are worth rewriting is arguable. However, the current state-of-the-art shows more important things to me: when you're beginning to write kludgy code to achieve what you want to do, I simply demonstrates that you lack some features you really need. And their are already rather kludgy stuff in the current code. Again for example, computing the relative ammount of visible portion of a buffer in a window is extremely hacky because we don't have a proper way to achieve this. Hence the randomness of the scrollbar size. Facing such constraints in crucial features like scrolling appears to me a reason good enough to consider reimplementing the engine. Hrvoje> How much work is it to create such a redisplay engine? Could we use Hrvoje> the work done by Andrew Innes(sp?), who created the new FSFmacs Hrvoje> redisplay. I suspect the amount of work is ... big ;-) When I read (quickly I admit) through Andrew Innes's page, it appeared very very technical to me. If I were to start thinking of a new engine soon, I'd start with writing down the features I'd like, the high-level interface and the architecture I foresee. Then, I could have a reasonable point of view of his work and how it could be used. I can't give any valid opinion right now. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: rssh.el interactions with ange-ftp/efs 25 years, 11 months

Kai Großjohann

Why do we have to use URL syntax if it is inconvenient? Wouldn't "/ftp:user＠host:/path/to/file" work, too? kai -- Abort this operation? [Abort] [Cancel]

4 participants
3 comments

8-bit vs. 24-bit on new Sun hardware. 25 years, 11 months

Martin Buchholz

If you have a recent Sun box, it is likely to come with fancy 24-bit video cards with names like `ffb' (fast frame buffer). However, the default visual is only 8-bit. This is a decision by Sun (mistaken, in my opinion) to improve backward compatibility with old apps. A system administrator can change the default visual by copying /usr/dt/config/Xservers to /etc/dt/config and hacking it to add under-documented flags like -defdepth 24. Few system administrators will be able to figure this out. An application running in this kind of environment should be able to recognize that the display is truly 24-bit and create 24-bit windows. For example, recent netscape's do this properly. xwininfo on a netscape window: Depth: 24 Visual Class: TrueColor xwininfo on a xemacs window: Depth: 8 Visual Class: PseudoColor As a result, display of images in XEmacs is noticeably suboptimal. How do we fix this? Martin

3 participants
4 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 January 1999