June 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Jareth Hein

Olivier Galibert <galibert(a)pobox.com> writes: > On Tue, Jun 09, 1998 at 06:19:35PM -0400, Kyle Jones wrote: > > Even if we keep > > the Lucid stuff, is supporting another toolkit under X worthwhile, > > when we already have functional menus and scrollbars? What would > > we get out of this as a reward for the work and misery? > > - Gnome and/or KDE integration > - Real dialog boxen. Replace, for instance, should not use the > modeline when invoked from the menu but create a nifty dialog box. > - Eventual ditch of the infamous Lucid stuff. Or will you implement > teardrop menus, detachable toolbars, themeable widgets elements, > etc... ? > > You will have a *lot* of work if you want lwlib to reach the level of > what is expected from toolbars, menus and scrollbars nowadays. Most of which I think is bloat and completely unnecessary for an application like XEmacs. I never use toolbars, and 90% of the menu accesses I do involve the popup menu for buffer listings. I personally would like to keep XEmacs UI as uncluttered as possible (at least have options for this). And for this purpose, lwlib is nice and light compared to most others. I'll add dialogs here, hopefully withing a month or so, and we'll see... Gee, I'm not 30 either, yet I've used punchcards and paper terminals... Maybe I should join Martin in the old fogie's home... However, the day I see a dolphin or a talking paperclip peering out at me from XEmacs is the day I become a VI heretic. -- Jareth Hein | jareth(a)camelot.co.jp | ハインジェラス Toolsmith & Program lead | http://www.camelot.co.jp | 開発部チーフ Camelot Software, Ltd. | |（株）キャメロット "Contrary to popular belief, penguins are not the salvation of modern technology. Neither do they throw parties for the urban proletariat."

1 participants
0 comments

Re: Projects ideas 27 years

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > But then everyone's time is their own to hack what they wish. I'll > be doing the module support again soon, even if nobody every wants > to use it but me. :) Module support is **dangerous**. Beware! -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}

1 participants
0 comments

Re: Projects ideas 27 years

William M. Perry

Olivier Galibert <galibert(a)pobox.com> writes: > On Tue, Jun 09, 1998 at 06:19:35PM -0400, Kyle Jones wrote: [...] > > Display improvements, > > like text that wraps around images, pixel-based scrolling, background > > color transparency in more image types, subwindow support, beveling > > as an extent property. > > I think aiming at something able to render efficiently XML/CSS2 kind of > documents would give us enough bangs to make a word equivalent. You can > even have vertical text :-) I already have the XML parser done. :) I've got a testbed external parser adapted from James Clark's expat parser. It's really nice and fast, and I'm working on turning it into a module for XEmacs 21.1 [...] > > Even if we keep > > the Lucid stuff, is supporting another toolkit under X worthwhile, > > when we already have functional menus and scrollbars? What would > > we get out of this as a reward for the work and misery? > > - Gnome and/or KDE integration It's a fundamental flaw in their design if they cannot deal with applications that are not written using their specific toolkit. Not having session management in kwm just because XEmacs doesn't use Qt is really lame. Or has that been fixed? > - Real dialog boxen. Replace, for instance, should not use the > modeline when invoked from the menu but create a nifty dialog box. It would be nice to just do this in normal emacs frames... then all operating systems get them. > - Eventual ditch of the infamous Lucid stuff. Or will you implement > teardrop menus, detachable toolbars, themeable widgets elements, > etc... ? > > You will have a *lot* of work if you want lwlib to reach the level of > what is expected from toolbars, menus and scrollbars nowadays. This is a good reason... eventually. I think we have bigger fish first. But then everyone's time is their own to hack what they wish. I'll be doing the module support again soon, even if nobody every wants to use it but me. :) -Bill P.

1 participants
0 comments

Re: toolkit wars again 27 years

Oliver Graf

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > > We need to lose this inferiority complex about ourselves and our > > code. > > By the same argument, we should have left the old GIF code in instead > of replacing it with an external library. Implementing new stuff is the thing that keeps us going... > It would be nice to have Gtk support in XEmacs. However, it doesn't > mean that we should lose the Xt support, at least as far as I'm > concerned. Qt is out, because it's C++ and because it's not free. Yup. Keep the but add gtk+ for more fun (but I will be no fun to implement this, cause the gtk+ API is radically different to the current Xt stuff). But hey! If trolltech can port mozialla to Qt, we can port XEmacs to gtk+ also! Regards, Oliver.

2 participants
1 comments

Bug when selecting TTY frames 27 years

Hrvoje Niksic

The selection of TTY frames has broken somewhere along the lines. To repeat: $ xemacs -nw -q C-x 5 2 ; to create and select a new frame M-: (select-frame (next-frame)) ; select the original frame For me, this creates a strange effect where keyboard "focus" goes to the other frame, but it is not redisplayed. This is not only obviously wrong, but in discordance with the documentation, that says: Lisp programs can switch frames "temporarily" by calling the function `select-frame'. This does not override the window manager; rather, it escapes from the window manager's control until that control is somehow reasserted. When using a text-only terminal, there is no window manager; therefore, `select-frame' is the only way to switch frames, and the effect lasts until overridden by a subsequent call to `select-frame'. Only the selected terminal frame is actually displayed on the terminal. Each terminal screen except for the initial one has a number, and the number of the selected frame appears in the mode line after the word `XEmacs' (*note Modeline Variables::.). I believe this has been broken by Greg's recent changes to select-frame mechanism. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- 4. Thou shalt not warlorde a sig if it bee the sig of Kibo, nor if it bee the sig of the Inner Circle.

1 participants
0 comments

Re: [patch] correct fix (Was: Fix for Re: Bug (I think) limit on popup menu strings) 27 years

Hrvoje Niksic

Colin Rafferty <craffert(a)ms.com> writes: > I wanted to, but I didn't know that we could depend on alloca on all > platforms. > > Oops, I just grepped src/*.c. I guess I can count on it. Note that XEmacs sources include `alloca.c', in the unlikely case that the OS doesn't provide one. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Thou Who might be our Father Who perhaps may be in Heaven... -- Roger Zelazny

2 participants
1 comments

Re: Binary distributions [ was Re: [PROPOSAL] fix for bad Xrefs ... ] 27 years

Hrvoje Niksic

Olivier Galibert <galibert(a)pobox.com> writes: > On Tue, Jun 09, 1998 at 08:52:32PM +0200, Hrvoje Niksic wrote: > > Why would that be illegal, if the CD contains the XEmacs sources? Or, > > do you mean that the CD should contain the sources to InstallShield -- > > which would be ridiculous, because it's impossible to achieve! OK, this "impossible to achieve" was the wrong argument. What I really meant was: The GPL'ed code we are distributing is XEmacs itself, accompanied by all the sources. If I understand correctly what this InstallShield thing is, then it has nothing to do with XEmacs -- it's just yet another installation tool. Having it on the same CD as XEmacs well falls into the "mere aggregation" clause: In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. The important thing is: InstallShield is **not** required to get a fully workable version of XEmacs. It's all that matters. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Unspeakable horrors from outer space paralyze the living and resurrect the dead!

4 participants
3 comments

Inline, inline, inline 27 years

Martin Buchholz

Ben says: > Use INLINE_HEADER in .h files > Use INLINE in .c files > Never use `inline' in the source code > Never use `static' together with `inline' since inline already > implies internal linkage This stuff is tricky. gcc info docs have this to say: Note that in C and Objective C, unlike C++, the `inline' keyword does not affect the linkage of the function. The upcoming C standard http://www.dkuug.dk/JTC1/SC22/ introduces the `inline' keyword into the C language References (Grab 'em with `wget -r' before they become standards and disappear forever) http://osiris.dkuug.dk/JTC1/SC22/WG14/www/docs/ http://www.maths.warwick.ac.uk/cpp/pub/wp/html/cd2/ 6.5.4 Function specifiers Syntax [#1] function-specifier: inline Constraints [#2] Function specifiers shall be used only in the declaration of an identifier for a function. [#3] An inline definition (see below) of a function with external linkage shall not contain a definition of an object with static storage duration that can be modified, and shall not contain a reference to an identifier with internal linkage. [#4] The inline function specifier shall not appear in a declaration of main. Semantics [#5] A function declared with an inline function specifier is an inline function. Making a function an inline function suggests that calls to the function be as fast as possible by using, for example, an alternative to the usual function call mechanism known as ``inline substitution''.101 The __________ 101. Inline substitution is not textual substitution, nor does it create a new function. Therefore, for example, the expansion of a macro used within the body of the Language 135 Working Draft, 1997-11-21, WG14/N794 J11/97-158 extent to which such suggestions are effective is implementation-defined.102 [#6] Any function with internal linkage can be an inline function. For a function with external linkage, the following restrictions apply. If a function is declared with an inline function specifier, then it shall also be defined in the same translation unit. If all of the file scope declarations for a function in a translation unit include the inline function specifier without extern, then the definition in that translation unit is an inline definition. An inline definition does not provide an external definition for the function, and does not forbid an external definition in another translation unit. An inline definition provides an alternative to an external definition, which a translator may use to implement any call to the function in the same translation unit. It is unspecified whether a call to the function uses the inline definition or the external definition. Examples [#7] The declaration of an inline function with external linkage can result in either an external definition, or a definition available for use only within the translation unit. A file scope declaration with extern creates an external definition. The following example shows an entire translation unit. ____________________________________________________________ function uses the definition it had at the point the function body appears, and not where the function is called; and identifiers refer to the declarations in scope where the body occurs. Similarly, the address of the function is not affected by the function's being inlined. 102. For example, an implementation might never perform inline substitution, or might only perform inline substitutions to calls in the scope of an inline declaration. 136 Language Working Draft, 1997-11-21, WG14/N794 J11/97-158 inline double fahr(double t) { return (9.0 * t) / 5.0 + 32.0; } inline double cels(double t) { return (5.0 * (t - 32.0)) / 9.0; } /* Creates an external definition. */ extern double fahr(double); double convert(int is_fahr, double temp) { /* A translator may perform inline substitutions. */ return is_fahr ? cels(temp) : fahr(temp); } [#8] Note that the definition of fahr is an external definition because fahr is also declared with extern, but the definition of cels is an inline definition. Because there is a call to cels, an external definition of cels in another translation unit is still required by 6.7. >From the inline proposal: This proposal adds the inline keyword to Standard C in such a way that it can be implemented with existing linker tech- nology and also is compatible with C++. This is achieved by requiring that one and only one of the translation units 25 containing the definition of an inline function be specified as the one that provides an external definition for the function. Because that specification consists simply of a declaration that lacks the inline keyword, it will also be accepted by a C++ translator. 30 This proposal does extend the C++ specification in two ways. First, if a function is declared inline in one translation unit, it need not be declared inline in every other transla- tion unit. This allows, for example, a library function that is to be inlined within the library but to be available 35 only through an external definition elsewhere. (The alter- native of using a wrapper function for the external function both requires an additional name and may adversely impact performance, if a translator does not actually do inline substitution.) 40 Second, the requirement that all definitions of an inline function be ``exactly the same'' is replaced by the require- ment that the behavior of the program should not depend on - 1 - 30 May 1997 Inlining Proposal, ReviWG14/N709 (J11/97-072) whether a call is implemented with a visible inline defini- tion or the external definition of a function. This allows an inline definition to be specialized for its use within a particular translation unit. For example, the external 5 definition of a library function might include some argument validation that is not needed for calls made from other functions in the same library. These extensions do offer some advantages, and programmers who are concerned about compatibility can simply abide by 10 the stricter C++ rules. Nevertheless, the extensions are not central to the proposal and the C++ rules could easily be substituted. Still reading??? For the masochists, here are excerpts from the C++ standard: 2 A function declaration (_dcl.fct_, _class.mfct_, _class.friend_) with an inline specifier declares an inline function. The inline specifier indicates to the implementation that inline substitution of the func- tion body at the point of call is to be preferred to the usual func- tion call mechanism. An implementation is not required to perform this inline substitution at the point of call; however, even if this inline substitution is omitted, the other rules for inline functions defined by this subclause shall still be respected. 3 A function defined within a class definition is an inline function. The inline specifier shall not appear on a block scope function declaration.2) 4 An inline function shall be defined in every translation unit in which it is used and shall have exactly the same definition in every case (_basic.def.odr_). [Note: a call to the inline function may be _________________________ 2) The inline keyword has no effect on the linkage of a function. encountered before its definition appears in the translation unit. ] If a function with external linkage is declared inline in one transla- tion unit, it shall be declared inline in all translation units in which it appears; no diagnostic is required. [Note: a static local variable in an extern inline function always refers to the same object. ]

1 participants
0 comments

Re: Qt/XEmacs (was: Re: Bug (I think) limit on popup menu strings) 27 years

SL Baur

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > And according to the FSF interpretation[1] of the Qt and GPL licenses, > distributing a linked binary would thus violate the GPL. Why isn't this an issue with a Motif-linked XEmacs? Because Motif can usually be considered a system library? -- This is a temporary e-mail address while I'm alpha testing Vmailer.

3 participants
2 comments

Re: Qt/XEmacs (was: Re: Bug (I think) limit on popup menu strings) 27 years

William M. Perry

Oliver Graf <ograf(a)fga.de> writes: > SL Baur <steve(a)vmailer.xemacs.org> writes: > > > Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > > > > > And according to the FSF interpretation[1] of the Qt and GPL licenses, > > > distributing a linked binary would thus violate the GPL. > > > > Why isn't this an issue with a Motif-linked XEmacs? Because Motif can > > usually be considered a system library? > > This is a good point! My linux had no Motif 'til a bought one for about > $100. And so I think this is commercial also. > > Motif allows dynamic as well es static linking for distribution (I bought > a developers license), Qt allows the same, Xforms (another good example) > also, only GPL collides with it... but nobody cares. > > So we have only one choice: drop Motif (just joking ;-) Nothing wrong with that. :) All my systems at home come with Qt, but not with Motif, so what does that say? :) -Bill P.

1 participants
0 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 June 1998