February 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: tab breakage yet again (XEmacs 21.2.29 is released.) 25 years, 1 month

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > If you look at the code, you'll see that it's not *that* hard to > support the three widget sets. They all use the Xt framework, so > stuff like XtNextEvent, XtAddInput, etc. work on all without > modification. The problem is that they all have subtly different bugs... Jan

1 participants
0 comments

Re: tab breakage yet again (XEmacs 21.2.29 is released.) 25 years, 1 month

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > Rewrite as in "write them from scratch to also support Gtk" or rewrite > as in "write new versions that support Gtk without touching the > originals"? The second (although despite the differences the other files are still a good template to start from). > None of these need be rewritten in the first sense. Gtk works in an > almost totally different manner. You'd write a separate event-gtk.c, > menubar-gtk.c, etc. Of course. Jan

1 participants
0 comments

Re: tab breakage yet again (XEmacs 21.2.29 is released.) 25 years, 1 month

Hamish Macdonald

>>>>> On 17 Feb 2000 13:58:47 +0100, >>>>> In message <byputwkmt4.fsf(a)urysohn.math.ethz.ch>, >>>>> Jan Vroonhof <vroonhof(a)math.ethz.ch> wrote: Jan> It depends a bit on the whether you want to have gtk exclusively etc Jan> c) Change Gtk/Gdk to support multiple displays. [Note: If you can do Jan> this and get the error handling correct you have won point a) Jan> automatically]. Jan> That would be it... :-). Point c) is the show-stopper at the moment again. Jan> It would be a killer feature marketingwise though.. Presumably c) is not a show-stopper if those who want gtk don't *care* about multiple display support, and gtk is just another windowing alternative. Hamish.

1 participants
0 comments

Re: tab breakage yet again (XEmacs 21.2.29 is released.) 25 years, 1 month

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > b) Figure out whether the GtkEvent loop actually can handle not being > in full control. I think the answer here is yes. The details are described in Havoc's book. > d) Rewrite event-Xt.c menubar-x.c scrollbar-x.c gui-x.c > input-method-*.c redisplay-x.c device-x.c. Rewrite as in "write them from scratch to also support Gtk" or rewrite as in "write new versions that support Gtk without touching the originals"? None of these need be rewritten in the first sense. Gtk works in an almost totally different manner. You'd write a separate event-gtk.c, menubar-gtk.c, etc.

1 participants
0 comments

Re: tab breakage yet again (XEmacs 21.2.29 is released.) 25 years, 1 month

Jan Vroonhof

Jens Lautenbacher <jtl(a)schlund.de> writes: Hi LTNT! > Maybe anybody can also comment, just for my information, what exactly > had to be done to maybe switch over to gtk. It depends a bit on the whether you want to have gtk exclusively etc a) Convince Kyle it is worth it. In particular guarantee somebody will be around to maintain it next year. b) Figure out whether the GtkEvent loop actually can handle not being in full control. c) Change Gtk/Gdk to support multiple displays. [Note: If you can do this and get the error handling correct you have won point a) automatically]. d) Rewrite event-Xt.c menubar-x.c scrollbar-x.c gui-x.c input-method-*.c redisplay-x.c device-x.c. Thanks to the Windows support the platform specific stuff is much more separate now. e) Make sure all properties can be (easily) changed from elisp. There are no resources to fallback on. f) Handle Andy embracing you in a state of utter joy. g) Take some heat from old XEmacs maintainers on comp.emacs.xemacs. Fortunately you can point Mly to your superior solution of c). That would be it... :-). Point c) is the show-stopper at the moment again. It would be a killer feature marketingwise though.. Jan

1 participants
0 comments

Re: tab breakage yet again (XEmacs 21.2.29 is released.) 25 years, 1 month

Hrvoje Niksic

Jens Lautenbacher <jtl(a)schlund.de> writes: > Andy Piper <andy(a)xemacs.org> writes: > > > The problem is that I have to do things under both mswindows and > > about 3 variants of widgets under X. It always works for me under > > windows (hence generally no complaints on xemacs-nt) but for the X > > stuff I have to rely on other people to report problems. > > With all this work going into embeddeable widgets, tabs and stuff, > doesn't this raise again the question if it is really such a good > decission to support 3 (or more with variants) widget sets under X?? If you look at the code, you'll see that it's not *that* hard to support the three widget sets. They all use the Xt framework, so stuff like XtNextEvent, XtAddInput, etc. work on all without modification. Supporting Gtk should be approached like supporting a different window system. That requires some work, but it's not impossible for a motivated and competent hacker, as demonstrated by the Windows folks. > But can anybody comment on the state of the lucid widget set? is > there anybody who really understands them anymore today? Andy and Jareth have at least a passing understanding of Lucid widget code. Now that we have Ben reachable and in our ranks, you can add him to the list, more likely than not. > Maybe anybody can also comment, just for my information, what > exactly had to be done to maybe switch over to gtk. See above. I can expound on that some more, but I'd prefer someone who understands *both* XEmacs and Gtk to do that.

1 participants
0 comments

Re: XEmacs 21.2.29 is released. - Problems with buffer tabs. 25 years, 1 month

ALTMARK＠de.ibm.com

Thanks for answering, Andy. I'm convinced that this will get fixed. And although the tabs can be annoying if they're broken from time to time, I'd like to nominate gutter & tabs as the - at least one of the - most valuable new features in 21.2. Keep up the good work! Markus Andy Piper <andy(a)xemacs.org> on 02/17/2000 11:02:17 AM Please respond to Andy Piper <andy(a)xemacs.org> To: Markus Alt/Germany/IBM＠IBMDE, xemacs-beta(a)xemacs.org cc: Subject: Re: XEmacs 21.2.29 is released. - Problems with buffer tabs. At 08:50 PM 2/16/00 +0100, ALTMARK(a)de.ibm.com wrote: >But now in b29, it looks even worse: When I cycle through the buffers using >`switch-to-buffer' or the clickable modeline, only *one* (seldomly two) >buffer tab(s) is/are displayed and the tab shown doesn't match the buffer >I'm currently visiting, i.e. it's another buffer's tab. (I have set the >buffers-tab variables to show up all buffers in the gutter and this worked >in former betas.) Its very broken. I know its very broken. I didn't realise Martin was going to release 21.2.29. I have most of it patched, but the last little bit is eluding me. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Re: tab breakage yet again (XEmacs 21.2.29 is released.) 25 years, 1 month

Jens Lautenbacher

Andy Piper <andy(a)xemacs.org> writes: > The problem is that I have to do things under both mswindows and about 3 > variants of widgets under X. It always works for me under windows (hence > generally no complaints on xemacs-nt) but for the X stuff I have to rely on > other people to report problems. With all this work going into embeddeable widgets, tabs and stuff, doesn't this raise again the question if it is really such a good decission to support 3 (or more with variants) widget sets under X?? I know that gtk lacks the convenient foundation on Xt, so I have no real hope that it could be used without much work (which I basically can't comment on, as I don't know Xt or Motif nor how much XEmacs depends on e.g. the Xt eventloop). But can anybody comment on the state of the lucid widget set? is there anybody who really understands them anymore today? Couldn't they be extented to be usuable as a single working solution without the need to mix in e.g. Motif? Or making lesstif the single supported solution? Maybe anybody can also comment, just for my information, what exactly had to be done to maybe switch over to gtk. jtl

1 participants
0 comments

Re: tab breakage yet again (XEmacs 21.2.29 is released.) 25 years, 1 month

Hrvoje Niksic

Andy Piper <andy(a)xemacs.org> writes: > >- turn off by default for non-beta releases. Or, we could hold a vote > > in xemacs-beta or even comp.emacs.xemacs as to whether this feature > > is one they are using. Unfortunately, getting an unbiased result of > > such a vote is tough. > > Please don't judge it until I at least think it is stable. I don't > think it is there yet, but it is close, despite the breakage people > are seeing. If they're to be in at all, the tabs really should be on by default. That's the way it's always been done in XEmacs.

1 participants
0 comments

Re: Tag table searching 25 years, 1 month

Jan Vroonhof

Martin Buchholz <martin(a)xemacs.org> writes: > > M-x find-tag RET write-region-internal RET > M-x find-tag RET write-region RET ;; it won't find it... The FSF version did :-) > Kyle and Hrvoje, you've been maintaining this file. Christoph, you've > wanted to replace our version with an improved one. And I will fix > this if no one else is willing to. Who will do it? Warning: if I end > up doing this, it might be a long detour. I have been using the FSF etags (from Christoph) for a week now (not intensively as I am not doing much programming now. For TeX reftex is much better). The thing I miss most from the XEmacs version is the fact that XEmacs etags can find a tag table in the parent directory. That shouldn't be so difficult to hack back in. In addition I really thing the "M-," should work as in the XEmacs version (Christoph has already shown how to this, I just thing it should go in the real version). FSF-etags signals an error in this case so there isn't a compatibility problem. Jan

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