March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

the Athena trick vs. the Sound trick 24 years, 8 months

Didier Verna

My recent patch regarding the postgresql headers location problem as triggered a short thread on xemacs-review on the way to achieve the desired effect. In short, there are currently two different tricks used in XEmacs for including headers which location is not fixed: the Athena trick and the Sound trick. I'm in favor of the Athena trick while Martin is in favor of the Sound trick. However, the more I think about it, the more I dislike Martin's solution. I'd like to have more opinions on this. Assume you have to include some foo headers which location might change from system to system. With an agreement on the idea of not polluting all command lines with random -I flags, here are the two ways XEmacs currently handles this: The Athena trick ================ In short, define a macro FOO_INCLUDE which would expand this: | #include FOO_INCLUDE(file) => #include <path/to/foo/file> The following code appears in XEmacs: ,---- | /* For use in #include statements. | You can't use macros directly within the <> of a #include statement. | The multiply nested macros are necessary to make old gcc's happy. | However, those nested macros are too much for AIX xlc to deal with. */ | #if defined(_AIX) && !defined(__GNUC__) | #define ATHENA_INCLUDE(header_file) <ATHENA_H_PATH/header_file> | #else | #define INCLUDE_GLUE_2(dirname,basename) <##dirname##/##basename##> | #define INCLUDE_GLUE_1(dirname,basename) INCLUDE_GLUE_2(dirname,basename) | #define ATHENA_INCLUDE(header_file) INCLUDE_GLUE_1(ATHENA_H_PATH,header_file) | #endif `----- The Sound trick =============== In short, for each file that needs such a header, rewrite its compilation rule in order to add the proper -I flag. The following code appears in XEmacs: ,---- | #ifdef HAVE_NATIVE_SOUND | sound_cflags=＠sound_cflags＠ | #endif | | ... | | #ifdef HAVE_NATIVE_SOUND | sunplay.o: ${srcdir}/sunplay.c | $(CC) -c $(sound_cflags) $(cflags) ${srcdir}/sunplay.c | hpplay.o: ${srcdir}/hpplay.c | $(CC) -c -Demacs $(sound_cflags) $(cflags) ${srcdir}/hpplay.c | #endif /* HAVE_NATIVE_SOUND */ `----- Here are the pros and cons _I_ see in both solutions. Let me say again that I'm *strongly* in favor of the Athena trick. The Athena trick ================ Pros: ----- * It can be easily generalized (that's what I did in my patch): globally define the GLUE macros, define a new FOO_INCLUDE each time it is needed, and use it for the concerned headers. * You don't need to add random -I flags anywhere. * When a new file suddenly needs such a header, there's nothing special to do, just be aware that the inclusion macro must be used. Cons: ----- * The GLUE macros are ugly, but this not our fault. * Each time a new inclusion macro needs to be written, you have to redo the AIX test. I concede that this is not very satisfactory. The Sound trick =============== Pros: ----- * People don't have to be aware of any inclusion macro, just #include the concerned file. Cons: ----- * Each time a new header location problem is encountered, you have to add special code in Makefile.in.in for each file requiring the header. * This code duplicates the normal compilation rule, which means that if one day the rule has to be changed, you have to remember to do the same change in all special cases that were added. * When a single file depends on several features that might or might not be present, the Makefile.in.in hackery will increase in complexity. * The position (in the command line) where the -I flag will be added *is* relevant. For instance: - if you put it first (this is currently the case for the sound support), it will appear *before* -I., hence the risk of including the wrong config.h file. This just happened to me as my postgresql header directory contains one such config.h file. - if you put it last, you take the risk of including wrong headers of the same name that could be present in the other include directives. - any other place (the best one would be after -I. and before anything else) will require even more trickery in Makefile.in.in as you can't use $cflags anymore. That's the current situation, as I see it. I'd like to harmonize the way it's done for the existing cases, but also in order to make our life easier in future situations. I'll follow what the majority thinks, if enough people care to express their opinion. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

1 participants
0 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 8 months

Jens Lautenbacher

Ben Wing <ben(a)666.com> writes: > You can't "simply" replace any large component of XEmacs with any component > from any other program. the word "simply" wasn't meant to be taken serious of course. What I wanted to say is if in the very long run it wouldn't make sense to move to a display engine that has no problems with proportional, different sized fonts, can display graphics with clipping them when they're partly offscreen and so on. There are people toying with the idea of enabeling xemacs to act as a wordprocessor, a task that for sure isn't possible with the current (state of the) display engine. jtl

1 participants
0 comments

Re: Accelerator I18N [was: I don't wont the f* underlinings ...] 24 years, 8 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > Hrvoje> One's desire to have things translated to his tongue > Hrvoje> should not reduce the developer's freedom to change the > Hrvoje> program. > > Gratuitous spelling changes in menu items will "unhook" the > translation (see lwlib/xlwmenu.c:massage_resource_name() for exactly > which ones). Shouldn't we restrict freedom at least that much? IMO translation should be completely orthogonal from program development. Everything else leads to disaster. It is a matter of courtesy on the side of the maintainer to avoid frequent frivolous changes to make things easier for the translators, but he is not _obliged_. The one guideline the developer is obliged to do is make sure that the plurals are formed correctly, i.e. this is forbidden: (format "%d entr%ss used" num (if (= num 1) "y" "ie")) > Hrvoje> By your standards, nothing UI-wise in XEmacs would ever > Hrvoje> change, because there's always a possibility that > Hrvoje> _someone_ in _some_ language would misunderstand/misparse > Hrvoje> _something_. I can't hope to disprove that claim. > > You needn't bother, because I didn't make it. I was probably attacking strawmen, but what you stated for the special case of Japanese certainly sounded like it could be expanded to what I wrote above. > All I ask is that _discussion_ take place. This serves to (1) warn > the translators that they are about to get a ton of hate mail (2) > give them a chance to kick up a fuss and (3) maybe cause developers > of good will to rethink some planned changes where appropriate. All of these are fine with me. See the "courtesy of the maintainer" part above. > Hrvoje> Thai, etc. without proper knowledge of English will fail > Hrvoje> to understand them. Well, that's what translations are > Hrvoje> for. If that means "fuck I18N" in your book, then you > Hrvoje> have a pretty weird notion of I18N. > > So, yes, changing the English menu without understanding how that > impacts the menus in other languages means "fuck I18N" in my book. Then we need to change how the translations are organized. The whole point of gettext is to make development and translation as orthogonal and unaware of each other as it is at all possible. If every single change to the XEmacs UI requires a consideration for Japanese, something somewhere is terribly wrong. I'll have to look at the menu translations. I thought they were done through a gettext()-like mechanism.

2 participants
1 comments

Steve's 21.2.32 crashes 24 years, 8 months

SL Baur

The problem is related to how I set X resources. (Ignoring Andy's test patch) When I `xrdb < /dev/null', XEmacs starts up. When I have the single X resource: XEmacs.modeline.attributeBackgroundPixmap: nothing XEmacs crashes. Andy, is that enough of a clue towards where the problem in the code is?

2 participants
1 comments

make-docfile 24 years, 8 months

Andy Piper

This appears to be broken by Ben's call-process changes. It explicitly uses call-process-internal andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

21.2.32: Error caught in `font-lock-pre-idle-hook' 24 years, 8 months

Jason R. Mastaler

After upgrading to beta32, forwarding large mail messages in Gnus with `S o m' gives me the following errors before giving up: (backtrace attached below) (219) (error/warning) Error in `pre-idle-hook' (setting hook to nil): (error Lisp nesting exceeds `max-lisp-eval-depth') (220) (error/warning) error: (error Lisp nesting exceeds `max-lisp-eval-depth') (221) (error/warning) error: (error Lisp nesting exceeds `max-lisp-eval-depth') (222) (error/warning) error: (error Lisp nesting exceeds `max-lisp-eval-depth') (223) (error/warning) error: (error Lisp nesting exceeds `max-lisp-eval-depth') (224) (error/warning) error: (error Lisp nesting exceeds `max-lisp-eval-depth') (225) (warning/warning) Error caught in `font-lock-pre-idle-hook' Before bombing out, the "Fontifying *mail* ..." buffer seems to take exceptionally long to finish.

2 participants
1 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 8 months

Didier Verna

wmperry(a)aventail.com (William M. Perry) wrote: > Things like scrollbars would still need to be done in the core I think > (because they go with windows not frames). Ideally, the tabs should also be attached to a window. > The basic idea would be to simplify the XEmacs window to just be an X Window > with gutters on all 4 sides. Yes. Probably even an X Window containing 4 X Windows for the gutters and one X Window for the XEmacs window. Generally, we would much benefit from using more X Windows (in terms of complexity of the calculations in redisplay). > As a side-benefit this would allow you to have multiple menubars, and > multiple toolbars visible at once. And the next step, make the modeline a real widget so that I can have only one modeline per XEmacs frame. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

2 participants
1 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 8 months

Jens Lautenbacher

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > >>>>> "Ben" == Ben Wing <ben(a)666.com> writes: > > Ben> However, one thing that you absolutely must not do is remove the Xt support. > Ben> This would be an incredibly unfriendly thing to do as it would prevent people > Ben> from using any widget set other than Qt or GTK. Keep in mind that people run > Ben> XEmacs on all sorts of different versions of X in Unix, and Xt is the standard > Ben> and the only toolkit that probably exists on all of these systems. > > Yup. We also really need X/Xt resources to work. Jamie got that one right. now I'm really not in the position to argue on technical stuff with people like Ben or Bill or Michael, but shouldn't we at least consider to remove some of the backward compatibility stuff for xemacs? gtk can be compiled on quite a big range of unix machines (and on win32, too by the way, although I don't think that this will be an option the win32 people like to consider). Now we have a growing set of features that can be used to a varying extent on various platforms, and as far as I can tell, for all the nice graphics stuff it's the win32 platform that works best. The only toolkit that is a) free b) stable enough c) available on enough platforms d) able to at least compete featurewise with the win32 toolkit is gtk. of course could everything be build from the intrinsics, but noone did it by now and I don't think anybody will ever for the sole purpose of giving XEmacs it's on gui. just IMHO jtl

7 participants
8 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 8 months

Didier Verna

wmperry(a)aventail.com (William M. Perry) wrote: > Well, I don't really see any reasonable way of integrating _any_ gtk > support with an Xt based application. NONE. There are none, indeed, but actually, this is an argument _in favor_ of gtk: this means that gtk support must provide its own even loop, just like the Xt support does, and the two will not interfere. We managed to do this once, already, for windows. There's no reason why we could not do it a second time, for gtk. Just as long as we don't try to mix gtk and Xt. > Having X/Xt resources work is in my opinion useless. XEmacs runs on other > platforms that do not have X resources (win32, macintosh, and tty spring to > mind). We should encourage people to use custom instead of X resources. Amen. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

2 participants
1 comments

Make gutter redisplay less aggressive 24 years, 8 months

Andy Piper

There were several reasons why redisplay optimisations weren't kicking in for gutters. This should fix the worst two offenders - extent changes in the buffer and having more than one gutter on a frame. This should cause the general flickering people have been seeing. I would be interested to know if it doesn't andy 2000-03-04 Andy Piper <andy(a)xemacs.org> * window.h (struct window): add gutter_extent_modiff. * window.c (allocate_window): zero out gutter_extent_modiff. * redisplay.h: declare sync_display_line_structs. * redisplay.c (add_glyph_rune): add a better comment. * redisplay-output.c (sync_display_line_structs): made non-static. (compare_runes): remove unneccesary glyph cachel access. * gutter.h: declare gutter_extent_signal_changed_region_maybe. * gutter.c (output_gutter): don't output the gutter if extent changes only involve extents in buffers. use 4 sets of display lines. (gutter_extent_signal_changed_region_maybe): new function. Mark extents in gutters as changed. (update_frame_gutters): use 4 sets of display lines. (reset_gutter_display_lines): ditto. (free_frame_gutters): ditto. (redraw_exposed_gutter): force output of gutters. * frame.h (struct frame): add 4 sets of gutter display lines. * extents.c: (extent_changed_for_redisplay): signal changes to extents in strings in the gutter as well as extents in buffers. -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

3 participants
7 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 March 2000