April 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Akram Khodadadi

Hello Please answer my question. We maked a player in Linux with Lisp languaege ,but we dont know how to make a UDP connection between our player and the server with Lisp languaege. We looked in many sources ,but we didn't attain any affects. Please say to us for making a UDP connection and geting and sending messages with that Lisp languaege which orders . Please explan with an example. Thanks Mrs Khodadadi

3 participants
2 comments

Re: objectives for 21.0? 26 years, 6 months

SL Baur

[I'm widening the response to this reasonable question to xemacs-beta]. Andy Piper <andyp(a)parallax.co.uk> writes: > Steve, > I'm just wondering what the objectives for 21.0 are. Its just that we have > most of the pieces in place for a really kick-ass mswindows version of > XEmacs. However there are still a few major outstanding bugs and some bits > missing - mainly the rest of the image code. Do you want to target 21.0 as > the first official mswindows release, or has it just been too long between > releases? MS Windows support is a priority for 21.0, make it so, but please exercise due haste in putting it together.

3 participants
2 comments

Re: [Success] 21.0 "Repartida-pre2" XEmacs Lucid (beta38-pre2) on i 386-pc-cygwin32 26 years, 7 months

SL Baur

Ian MacKinnon <IMacKinnon(a)telia.co.uk> writes: > Does any one else have to hack the filename of the pre patches so > patch-xemacs will work ? Is this the case? The pre-patches are generated the same way the beta-n -> beta-n+1 patches are generated and should work with any reasonable version of patch. I know `cvs diff' causes heartache, weeping and gnashing of teeth with malformed filenames in patches, but this is the first I've heard of `cvs rdiff' having a problem. Index: xemacs-20.0/CHANGES-beta diff -u xemacs-20.0/CHANGES-beta:1.125 xemacs-20.0/CHANGES-beta:1.128 --- xemacs-20.0/CHANGES-beta:1.125 Sat Apr 25 21:07:11 1998 +++ xemacs-20.0/CHANGES-beta Wed Apr 29 16:03:42 1998 You have to specify `-p1' to patch to make the first part of the path go away, but that should be all.

2 participants
1 comments

[PATCH] font handling for w3 under mswindows 26 years, 7 months

Andy Piper

Well, this allows w3 to begin displaying a page, but there are then further unrelated errors. Really someone who understands w3 needs to revisit all of this under mswindows. andy 1998-04-29 Andy Piper <andyp(a)parallax.co.uk> * font.el (mswindows-font-create-name) (mswindows-font-create-object): new functions for mswindows type fonts. * msw-faces.el (mswindows-font-canicolize-name): fix so that strings are parsed as well as font objects.

2 participants
4 comments

Process output problem? 26 years, 7 months

Andy Piper

I notice that process output under cygwin is not triggering the correct output coding. For instance doing vc-diff with cvs generates a buffer full of ^M's, does anyone else see this under the native port? andy

3 participants
3 comments

Re: [PATCH] Generalization of system metrics 26 years, 7 months

Kirill M. Katsnelson

Some time ago, Ben Wing wrote... |+ | I think you should implement this using the standard property mechanism for Lisp | objects. | | There are a million strange properties for a device under X, such as "does | backing store" (Aren't there some other weird hacks that exist for this?). | Unfortunately, most of the properties that you implemented for Windows exist | under X only in the context of an add-on package such as Motif or CDE. Anyone | want to implement a CDE interface for XEmacs? I have been thinking about using properties for that, and my opinion is that a separate function would do better. These properties are different that "regular" object properties in so that - they are never settable; - we cannot allow a window system not to have one of these. They are numerous, and if someone sets any of these under a window system which treats this property as "just a symbol", this code will fail under another window system which treats a property by the same name specially. This will likely be a source of bugs. - Getting "device-properties" may be costly. We cannot disallow getting a list of all properties. For "metrics" which are different than properties this is ok though when they are not availble wholesale. The properties I listed are not specific for Windows, I think there are only 75% of these are obtainable from Windows. I tried to compile a list of properties useful as XEmacs fallbacks for different geometrical metrics, so "does backing store" perhaps not worthy listing here. Kirill | | Kirill M. Katsnelson wrote: | | > I implemented a single lisp function, which returns many information | > aspects about the window system. There were six such functions already: | > device-{pixel,mm}-{height,width}, device-bitplanes, device-color-cells. | > Recently I added a Windows specific function which obtain default | > scrollbar sizes. If this continues, there will be a flood of device | > specific functions. | > | > You pass this function a device and a symbol for the capability you | > want, and it returns metric's value. May I please ask everyone to | > review the current list of capabilities, and to add what I missed? | > Maybe not restricted to X and MS Windows, anything which fits into a | > window system model and applies to XEmacs. | > | > Another question is which of these metrics are supported by X. | > I implmented only 6 old metrics, maybe an X server can be asked | > for more information? | > | > Here's a docstring, to avoid snarfing the patch file: | > | > DEFUN ("device-system-metrics", Fdevice_system_metrics, 2, 2, 0, /* | > Get metrics for DEVICE as provided by the system. | > | > METRIC must be a symbol specifying requested metric. Note that | > the metrics returned are these provided by the system internally, | > not read from resources, so obtained from the mostly internal level. | > | > If a metric is not provided by the system, return value is nil. | > Boolean values are returned as zero and non-zero integers. | > | > Metrics, by group, are: | > | > COLORS. Colors are returned as valid color instantiators. No other | > assumption on the returned valie should be made (i.e. it can be a | > string on one system but a color instance on another). For colors, | > returned value is a cons of foreground and background colors. Note | > that if the system provides only one color of the pair, the second | > one may be nil. | > | > 'color-default Standard window text foreground and background. | > 'color-select Selection highligh text and backgroun colors. | > 'color-balloon Ballon popup text and background colors. | > 'color-3d-face 3-D object (button, modeline) text and surface colors. | > 'color-3d-light Fore and back colors for 3-D edges facing light source. | > 'color-3d-dark Fore and back colors for 3-D edges facing away from | > light source. | > 'color-menu Text and background for menus | > 'color-menu-high Selected menu item colors | > 'color-menu-button Menu button colors | > 'color-menu-unsel Unselectable menu item colors | > 'color-toolbar Toolbar foreground and background colors | > 'color-scrollbar Scrollbar foreground and background colors | > 'color-desktop Desktop window colors | > 'color-workspace Workspace window colors | > | > FONTS. Fonts are returned as valid font instantiators. No other | > assumption on the returned value should be made (i.e. it can be a | > string on one system but font instance on another). | > | > 'font-default Default fixed width font. | > 'font-menubar Menubar font | > 'font-dialog Dialog boxes font | > | > GEOMETRY. These metrics are returned as conses of (X . Y). As with colors, | > either car or cdr of the cons may be nil if the system does not provide one | > of corresponding dimensions. | > 'size-cursor Mouse cursor size. | > 'size-scrollbar Scrollbars (WIDTH . HEIGHT) | > 'size-menu Menubar height, as (nil . HEIGHT) | > 'size-toolbar Toolbar width and height. | > 'size-tbbutton Toolbar button size. | > 'size-tbborder Toolbar border width and height. | > 'size-icon Icon dimensions. | > 'size-icon-small Small icon dimensions. | > 'size-device Device screen size in pixels. | > 'size-workspace Workspace size in pixels. This can be less than the above | > if window manager has decorations which effectively shrink | > the area remaining for application windows. | > 'size-device-mm Device screen size in millimeters. | > 'device-dpi Device resolution, in dots per inch. | > | > 'num-bit-planes Integer, number of deive bit planes. | > 'num-color-cells Integer, number of device color cells. | > | > FEATURES. This group reports various device features. Boolean values retuned | > as integer 1 for true and zero for false, or nil if the feature is unknown | > for the system. | > | > 'mouse-buttons Number of mouse buttons, or zero if no mouse (integer). | > 'swap-buttons Non-zero if left and right mouse buttons are swapped | > 'show-sounds User preference for visual over audible bell (boolean). | > 'slow-device Device is slow, avoid animation (boolean). | > 'security Non-zero if user environment is secure. | > 'dbcs Window system supports DBCS (boolean). | > 'ime Device embeds an input method editor (boolean). | > 'mid-east Non-zero if the window system is enabled for Hebrew | > and Arabic (left-to-right reading) languages. | > */ | > (device, metric)) | > | > Steve, I haven't built with tty and X, only compiled for syntax check | > (build with X still fails on NT, and I'm far away from solaris). Could | > you please ensure that the 6 (2 on ttys) moved lisp functions return | > correct values? I C-x C-e'ed them right in ChangeLog :) TIA. | > |-

2 participants
3 comments

Re: [PATCH] Ghost specifiers 26 years, 7 months

Ben Wing

What you say about the way magic specifiers appear at the Lisp level is correct. However, I really don't think you should add needless extra parameters to any specifier functions. Instead, just decide that specifier-fallback definitely does not copy a specifier that it returns, and maybe add a read only flag to specifiers if you don't want the ghost specifiers to be modified except during initialization time. For that matter, there would be no need to call copy-tree at all if it were possible to mark conses and vectors (and strings) as read-only. This should be possible using minimal tag bits, and I think it would be a great feature to add as it would eliminate a lot of other places where lists are copied solely to avoid possible malicious code modifying them. Kyle? You could simulate this in the non- minimal tag bits case by allocating read-only conses in their own frob blocks, and probably figure out a way to hack the flag into strings and vectors. Kirill M. Katsnelson wrote: > Some time ago, Ben Wing wrote... > |+ > | For the most part this looks very good, but I don't like the reveal ghost specifiers > | mechanism. Instead, why don't you just have a flag that indicates whether the ghost > | specifiers are read-only? This is true except during those Lisp initialization > | functions, which retrieve the ghost specifier using specifier-fallback. In your > | current scheme, unless I'm mistaken, naughty code could retrieve the ghost specifier > | using specifier-fallback, and then modify it. > > Oops, you are right, specifier-fallback uses copy-tree to return the fallback value, > but copy-tree does not copy specifiers, just returns its argument. Maybe copy-tree > and copy-sequence should be extended to the specifier case? Specifiers *are* the > objects copying which makes sence. Implementation is 2 lines of code worthy... > > As for the reveal mechanism, I designed it with minimal changes to the hairy > initialization lisp code in mind. Anyways, what you propose really makes the design > clearer, and overweighs my consideration. > > To avoid dependency on the behavior of specifier-fallback, i.e. whether it copies a > fallback specifier or not, may it be better to add one parameter to add-spec* and > remove-spec* functions, telling that these should operate on the ghost part of a > magic specifier, if it is really magic? This gives (maybe little) benefit in so that > lisp code should not care whether a specifier is a magic one, i.e. does it have a > ghost fallback or not. > > | The purpose of the depth argument that you [Kirill] ask about is to catch inheritance > | loops, but I do not know if this is currently implemented. > > Yes, this is implemented. > > I already found out why this counter is passed to instantiate method: For faces, this > method may call specifier_instance again, with matchspec this time, thus possibly > creating an "external" loop, so it passes the counter back to specifier_instance. > I will document the usage of this parameter. > > | As for your suggestion about comparing fallbacks in the internal equal method, I think > | this is a good idea. > > Ok, I will add this. > > | I'm glad that you documented the specifier methods, and I'm impressed with the > | thoroughness and the clearness of the documentation. > > Thanks. > > | I think that you should add to the comment that explains magic specifiers, noting the > | difference between the ghost fallbacks (which contain the user preferences specified > | through window system resource files), and the fallback of the ghost fallback (which > | contains emergency backup values just to make sure that something minimally reasonable > | happens). > > And this, too. > > I do not think that magic specifications should be documented at lisp level. For a lisp > program, a magic specifier is just a regular specifier, with another specifier as its > fallback, and there is nothing magic about it. Am I correct here? > > Kirill -- This message composed using voice recognition software and foot pedals. (No keyboards were harmed while composing this message.)

4 participants
5 comments

[patch] [bug] src/eval.c: give Fcond Scheme-style `=>' syntax. 26 years, 7 months

Karl M. Hegbloom

I've given the `cond' special form the r{4,5}rs scheme-style `=>' syntax. It's working, when the test code is run interpreted, but not when run byte-compiled. Attached is the simple test code followed by my first C code patch to XEmacs. (not counting typos in docstrings or comments.) My question is: Should the byte compiler be compiling `cond' like that, since it's in C already? Wouldn't it run faster if it only translated things like the anonymous lambda, and left the rest for the C code to run? #include <nerdy/any_ideas.h> 1998-04-27 Karl M. Hegbloom <karlheg(a)inetarena.com> * eval.c (Fcond): Support scheme-style `=>' syntax.

3 participants
2 comments

Re: bug setting scrollbar height w/ X resources? 26 years, 7 months

Hrvoje Niksic

"Kirill M. Katsnelson" <kkm(a)kis.ru> writes: > (defcustom scrollbars-visible-p ;; added for the options menu - dverna > (> (specifier-instance scrollbar-width) 0) > "Whether the scrollbars are globally visible. This variable can be > customized through the options menu." > :group 'display > :type 'boolean > ;; This is really a hack: there should be a real specifier for this, in > ;; order to turn on/off the scrollbars without altering their size. > :set '(lambda (var val) > (if val > (progn > (set-specifier scrollbar-width 15) > (set-specifier scrollbar-height 15)) > (set-specifier scrollbar-width 0) > (set-specifier scrollbar-height 0)) > (setq scrollbars-visible-p val)) > ) BURN THIS! BURN THIS! BURN THIS! (sorry, Didier! please don't take this personally, but this defcustom simply cannot be allowed to stay. it must be implemented correctly or not at all.) > But the ideal solution is a separate specifier for scrollbar > visibility, as the comment suggests. I remeber that Hrvoje said that > in last October, but perhaps it was not the first time this' been > said... :) > > Btw, this specifier will not break any backward > compatibility. Phasing out a convention that zero size toolbar is no > toolbar may then take some time but is very harmless. With Steve's permission, I could try to implement it for 21.0... -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- A radioactive cat has eighteen half-lives.

2 participants
1 comments

RE: [PATCH] Fix for possible `make install' bug in beta38-pre2 26 years, 7 months

Damon Lipparelli

Actually, what I found was that I had to run "autoconf" to re-generate "configure". -lipp >>>> -----Original Message----- >>>> From: SL Baur [mailto:steve＠xemacs.org] >>>> Sent: Wednesday, April 29, 1998 9:05 PM >>>> To: xemacs-beta(a)xemacs.org >>>> Subject: Re: [PATCH] Fix for possible `make install' bug >>>> in beta38-pre2 >>>> >>>> >>>> Tetsuya HOYANO <hoyano(a)ari.bekkoame.ne.jp> writes: >>>> >>>> > ----Next_Part(Thu_Apr_30_13:00:42_1998_349)-- >>>> > Content-Type: Text/Plain; charset=us-ascii >>>> > Content-Transfer-Encoding: 7bit >>>> >>>> >>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: >>>> >>>> sb> There's confusion between configure's `progname' and >>>> the `progname' >>>> sb> used by the Makefiles. This patch makes everything >>>> consistent. After >>>> sb> applying this patch, the generated src/paths.h looks >>>> cleaner anyway. >>>> >>>> > beta38-pre2 built fine, then `./config.status --recheck', >>>> >>>> I'm sorry. You must rerun configure from scratch. >>>> >>>> > `make beta' and `make install' install them into >>>> > /usr/local/lib/-21.0-b38/ not into >>>> /usr/local/lib/xemacs-21.0-b38/ >>>> > after applied this patch. >>>> >>>> > I am confusing... >>>> >>>> That sounds about right, unfortunately. Rerun configure >>>> from scratch >>>> and things should be O.K. >>>>

2 participants
1 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 April 1998