February 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: old patch still not applied? (really: xemacs-review flame) 24 years, 2 months

Vin Shelton

It is on my list, yes. I will apply it in the next day or so. - vin >>>>> On 06 Feb 2000, Gunnar Evermann <ge204(a)eng.cam.ac.uk> said: Gunnar> could one of the members of the secret inner xemacs-review Gunnar> circle tell me if there is a reason why Gunnar> http://www.xemacs.org/list-archives/xemacs-patches/199912/msg00036.html Gunnar> 1999-12-06 Jan Vroonhof <vroonhof(a)math.ethz.ch> Gunnar> * src/syntax.h (SYNTAX_START_P): Check whether the two chars Gunnar> actually can start a common comment type. Gunnar> * src/syntax.h (SYNTAX_END_P): ditto for end. Gunnar> hasn't been applied to 21.2 yet? Gunnar> Jan, I am not blaming you, in case you forgot. I am just angry Gunnar> that the xemacs-review board which should take care of such Gunnar> things, keeps missing stuff like this and non-members are left Gunnar> in the dark about the status of patches... Gunnar> I can apply it tomorrow if you like. Gunnar> Vin, this one should go into 21.1.9 as well (I know, you Gunnar> probably have it ticked already :-) )

1 participants
0 comments

old patch still not applied? (really: xemacs-review flame) 24 years, 2 months

Gunnar Evermann

could one of the members of the secret inner xemacs-review circle tell me if there is a reason why http://www.xemacs.org/list-archives/xemacs-patches/199912/msg00036.html 1999-12-06 Jan Vroonhof <vroonhof(a)math.ethz.ch> * src/syntax.h (SYNTAX_START_P): Check whether the two chars actually can start a common comment type. * src/syntax.h (SYNTAX_END_P): ditto for end. hasn't been applied to 21.2 yet? Jan, I am not blaming you, in case you forgot. I am just angry that the xemacs-review board which should take care of such things, keeps missing stuff like this and non-members are left in the dark about the status of patches... I can apply it tomorrow if you like. Vin, this one should go into 21.1.9 as well (I know, you probably have it ticked already :-) ) Gunnar

1 participants
0 comments

find-tag 24 years, 2 months

wefing＠gmx.de

>Submitter-Id: net >Originator: Stephan Wefing >Organization: none >Confidential: no >Synopsis: bugs in find-tag >Severity: non-critical >Priority: low >Category: auxiliary >Class: change-request >Release: gnats-3.101 >Environment: System: Linux kato 2.2.10-smp #8 SMP Fri Sep 17 16:45:09 CEST 1999 i686 unknown Architecture: i686 >Description: (1) in contrast to emacs 20.3 the find-tag function of xemacs 20.4 cannot find tags associated with c/c++ struct/union/class members like "stack_s::nof_objects". Such tags are generated by the gnu etags program if the "--members" flag is set. (2) in contrast to emacs 20.3 the find-tag function of xemacs 20.4 may fail to find the definition of a type directly. >How-To-Repeat: (1) consider the file "include.h" which contains the following single line: > struct abc_s {int counter;}; calling the gnu etags program with /usr/bin/X11/etags -C --members -S include.h gives the following TAGS file: > ^L > include.h,70 > struct abc_s ^?abc_s^A1,0 > struct abc_s {int counter;^?abc_s::counter^A1,0 (here i substituted each cntrl character by 2 ascii characters for transport via email). passing "abc_s::counter" to the find-tag command gives the message "No entries matching abc_s::counter". (2) consider the file etags_test.h containing the single line > typdef struct {int i;} obj_t; and a file etags_test.c containing the two following lines: > #include "etags_test.h" > typedef struct abs_s {obj_t o;} abs_t; calling the gnu etags program with /usr/bin/X11/etags -C --members -S etags_test.c etags_test.h gives the following TAGS file: > ^L > etags_test.c,83 > typedef struct abs_s ^?abs_s^A2,24 > typedef struct abs_s {obj_t o;} abs_t;^?abs_t^A2,24 > ^L > etags_test.h,41 > typedef struct {int i;} obj_t;^?obj_t^A1,0 passing "obj_t" as a tag to xemacs' find-tag command positions the curser first to the typdef statement in etags_test.c, whereas emacs first positions to the correct typedef statement in etags_test.h. in both cases i use the same TAGS file. i admit that this example is fairly artificial. however, the problem may become really disturbing for real life code, especially if you use other etags programs like that of darren hiebert (http://darren.hiebert.com/ctags/index.html). the problem is a consequence of the fact that (x)emacs does not only scan the tag fields of a TAGS file but also its context fields. it would be very useful if one could direct (x)emacs to scan only the tag fields of a TAGS file. >Fix: --=-=-=--

1 participants
0 comments

Re: [21.1] popup menus still offset (PR#1123) 24 years, 2 months

Jan Vroonhof

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > I think it was a different thing but if you want to dig through Dnd, > be my guest ...: :-) I don't even have access to a machine with Sun's > CDE. Neither do I... I guess I should be happy for that :-) Jan

1 participants
0 comments

NEED_MOTIF in configure (PR#1129) 24 years, 2 months

Gunnar Evermann

1 participants
0 comments

Re: [21.1] popup menus still offset (PR#1123) 24 years, 2 months

Vin Shelton

>>>>> On 06 Feb 2000, Gunnar Evermann <ge204(a)eng.cam.ac.uk> said: Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: >> Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: >> >> > suggestions? >> >> Change the HAVE_WMCOMMAND to HAVE_SESSION. It works for me... Gunnar> ok let's do that then. Vin, do you want a patch? :-) Gee, I think I can handle this one. It seems to work for me - unless anyone objects, I will apply this patch tonight. 2000-02-06 Vin Shelton <acs(a)xemacs.org> * menubar-x (make_dummy_xbutton_event): Change HAVE_WMCOMMAND to HAVE_SESSION in order to fix popup menu location. --- src/menubar-x.c~ Mon Nov 1 23:17:15 1999 +++ src/menubar-x.c Sun Feb 6 11:14:23 2000 ＠＠ -684,7 +684,7 ＠＠ btn->x = eev->event.button.x; btn->y = eev->event.button.y; shellx = shelly = 0; -#ifndef HAVE_WMCOMMAND +#ifndef HAVE_SESSION { Widget shell = XtParent (daddy); - vin

1 participants
0 comments

Re: [21.1] popup menus still offset (PR#1123) 24 years, 2 months

Gunnar Evermann

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > > suggestions? > > Change the HAVE_WMCOMMAND to HAVE_SESSION. It works for me... ok let's do that then. Vin, do you want a patch? :-) > > BTW: I still can't build 21.1.9pre on Irix5.3 with gcc... :-( > > $＠$＠#! The dumping patch was intentionally changed to ONLY affect Irix > 6.x. This under the assumption that we wouldn't want to break Irix5 > which worked with Alexandre Oliva's patch. You are saying that isn't > the case :-(? I already forgot most of the results from the last round of tests. I think I've never seen a version of xemacs I could build on 5.3 with gcc without the -G0 hack. BTW this is now using gcc2.95.2. To be honest, I'm so disgusted by all this IRIX mess that I'd prefer to forget all about it... Maybe I will have a look tonight after I have done some Real Work[TM]. > P.S. Did you see that one of the latest incoming bugs contains a > reproduction recipe for a D&D crash yes, but note that a recipe was never the problem: take a SUN with CDE, without moving the mouse click 3x button1 and then button2... BOOM > (maybe similar to the one that has been bugging us all the time). I think it was a different thing but if you want to dig through Dnd, be my guest ...: :-) I don't even have access to a machine with Sun's CDE. Gunnar

1 participants
0 comments

Re: [21.1] popup menus still offset (PR#1123) 24 years, 2 months

Jan Vroonhof

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > Jan, sorry for interrupting the work on your thesis. OK, for one second :-) > for 21.1.7 the following patch was applied: > > > 1999-08-28 Jan Vroonhof <vroonhof(a)math.ethz.ch> > > * menubar-x.c (make_dummy_xbutton_event): Don't add > offset twice if HAVE_WMCOMMAND is defined. > > http://www.xemacs.org/list-archives/xemacs-patches/199908/msg00080.html > > I don't pretend to understand this, but HAVE_WMCOMMAND is definitely a > 21.2'ism. This soooo stupid.. The thing is called HAVE_SESSION in 21.1.x. I could have sworn that change was between 20.4 and 21 nut it was not.. > I can fix the problem by removing the whole > #ifdef HAVE_WMCOMMAND block from 21.1.8 (of course we could then > eliminate shel[xy] altogether). I don't pretend to grok it fully either. Here is my "guesswork" on which the patch is based. The problem here is that the HAVE_SESSION/HAVE_WMCOMMAND works by making the shell window invisible and keeping a single one. It then creates a new window to wrap each frame. Each of these gets a copy of the arguments of the shell window. Thus in this case we must NOT add the offset from the shell and the frame together because then we count the initial offset twice. However if HAVE_SESSION/HAVE_WMCOMMAND is not set then the offset is only contained on the shell-window and we must copy it from there. > suggestions? Change the HAVE_WMCOMMAND to HAVE_SESSION. It works for me... > BTW: I still can't build 21.1.9pre on Irix5.3 with gcc... :-( $＠$＠#! The dumping patch was intentionally changed to ONLY affect Irix 6.x. This under the assumption that we wouldn't want to break Irix5 which worked with Alexandre Oliva's patch. You are saying that isn't the case :-(? Jan P.S. Did you see that one of the latest incoming bugs contains a reproduction recipe for a D&D crash (maybe similar to the one that has been bugging us all the time).

1 participants
0 comments

[21.1] popup menus still offset (PR#1123) 24 years, 2 months

Gunnar Evermann

Jan, sorry for interrupting the work on your thesis. Vin, we need to fix this for 21.1.9 xemacs-21.1.9pre -geometry +200+100 -vanilla click button3 and get a menu at the wrong position. for 21.1.7 the following patch was applied: 1999-08-28 Jan Vroonhof <vroonhof(a)math.ethz.ch> * menubar-x.c (make_dummy_xbutton_event): Don't add offset twice if HAVE_WMCOMMAND is defined. http://www.xemacs.org/list-archives/xemacs-patches/199908/msg00080.html I don't pretend to understand this, but HAVE_WMCOMMAND is definitely a 21.2'ism. I can fix the problem by removing the whole #ifdef HAVE_WMCOMMAND block from 21.1.8 (of course we could then eliminate shel[xy] altogether). suggestions? Gunnar BTW: I still can't build 21.1.9pre on Irix5.3 with gcc... :-(

1 participants
0 comments

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

ALTMARK＠de.ibm.com

Will do both (debug device-x.c and also try with 'Emacs.emacsVisual: PseudoColor8') on Monday back at work - unfortunately I have no AIX box here at home ... Valdis, I'm also curious about the new GXT300P (although I must say that I don't too much hope considering the latest experiences with the other cards). We might get some boxes with those cards in 2Q2000 and of course this will be the first thing I'll try on them then! I'll keep you posted. Markus

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