August 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: menubar bugs: can't change font and weird separator rules 24 years, 3 months

Oscar Figueiredo

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: > (1) In 21.2.35, I am unable to change the font for the menubar using the > incantation in etc/Emacs.ad: > src/xemacs -vanilla -xrm '*menubar*Font:-*-helvetica-*-*-*-*-*-240-*iso8859-1' & > or anything like it. (-xrm does work for other resources, at least > for Emacs.default.attributeFont.) > (2) I encountered this trying to magnify the pulldown menus. It looks > like there is a series of "=======" in the Tools menu; it has an > accelerator underline for the first character. It seems like this is > a bug in the eudc package which has the following kind of code > ["New Server" eudc-set-server t] > ["---" nil nil] > ["Query with Form" eudc-query-form t] > in several places (this is freshly updated from CVS). lisp/menubar-x.el > just uses the plain string "---" to generate a separator. > Is EUDC still yours, Oscar? Yes it is. Ben signalled that problem a few days ago and I fixed it in my sources which I have not commited yet because I've been testing other features I added to EUDC. I'll commit ASAP. Oscar

1 participants
0 comments

Re: More on find-file dialogue failure 24 years, 3 months

Didier Verna

Yoshiki Hayashi <yoshiki(a)xemacs.org> wrote: > I guess you are suffering from newer package-path detection > code. I think you are running XEmacs in place and probably > you have CVS xemacs-packages modules checked out parallel to > your XEmacs source tree. For example, there are ~/xemacs > and ~/xemacs-packages directories and you're running XEmacs > with ~/xemacs/src/xemacs. Then your XEmacs will wrongly > pick up ~/xemacs-packages as a package directory. That's > why you don't get debug-on-entry. > > The best solution for now is to rename ~/xemacs-packages to > something different. I think package detection code should > use better heuristics like checking existence of lisp > directory, though. I got a similar problem today, after upgrading (I hadn't done so for quite a while). My setup is the following: /usr/local/src/XEmacs-21.2 -> xemacs cvs archive /usr/local/src/xemacs-packages -> packages cvs archive / compilation directory /usr/local/src/xemacs -> compilation directory /usr/local/lib/xemacs -> package installation directory (by symlinks) When running the latest XEmacs in place, it doesn't find /usr/local/lib/xemacs/xemacs-packages. I get the following at startup: emacs-roots: ("/usr/local/src/dxemacs/" "/usr/local/") configure-package-path: nil early-packages and early-package-load-path: nil nil late-packages and late-package-load-path: ("/usr/local/lib/xemacs/site-packages/" "/usr/local/lib/xemacs/mule-packages/" <no /usr/local/lib/xemacs/xemacs-packages here> "/usr/local/src/xemacs-packages/" --> this is wrong ... and all stuff below this directory. Obviously, XEmacs took my package source directory for what it is not. After renaming it to XEmacs-Packages (note the uppercase) and reinstalling in order to update the symlinks, everything went fine again. BTW, I'd like someone to clearly and slowly explain to me what means "running the packages in place" after all. I still don't understand what this means. What was not possible before, and is possible now ? To me, running in place would mean the ability to find the packages in my compiled cvs source tree withtout having to install them (whether by symlinks or not). But that's not that hey ? -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.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

menubar bugs: can't change font and weird separator rules 24 years, 3 months

Stephen J. Turnbull

(1) In 21.2.35, I am unable to change the font for the menubar using the incantation in etc/Emacs.ad: src/xemacs -vanilla -xrm '*menubar*Font:-*-helvetica-*-*-*-*-*-240-*iso8859-1' & or anything like it. (-xrm does work for other resources, at least for Emacs.default.attributeFont.) (2) I encountered this trying to magnify the pulldown menus. It looks like there is a series of "=======" in the Tools menu; it has an accelerator underline for the first character. It seems like this is a bug in the eudc package which has the following kind of code ["New Server" eudc-set-server t] ["---" nil nil] ["Query with Form" eudc-query-form t] in several places (this is freshly updated from CVS). lisp/menubar-x.el just uses the plain string "---" to generate a separator. Is EUDC still yours, Oscar?

1 participants
0 comments

Autorecognition of "coding systems" 24 years, 3 months

Stephen J. Turnbull

Sorry for the duplication if you are on both lists. The mule-coding, file-coding, and planned general coding features all will be most convenient if they auto-recognize the coding systems. Even with native languages, autorecognition can be done with a high degree of accuracy in most environments. However, there remains some probability of error, and errors in coding recognition will definitely produce substantial probability of data corruption. Ben has proposed arranging that all coding transformations be invertible (except near user changes to the buffer). This could involve storing large portions of the original file. It also (in principle) need not let the user know about the potential data loss. An alternative lighter-weight possibility would be to simply to mark any positions where potentially non-invertible transformations were made, and set the buffer read-only. (Of course, the latter action would be configurable by the user.) A command would be provided so that the user could traverse the positions where potential problems were identified, and check for data corruption. I think we would probably want something like this even if we did provide for full invertibility. Comments? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

1 participants
0 comments

Re: Athena widgets 24 years, 3 months

Steve Youngs

* Ben Wing <ben(a)666.com> writes: > i already have a patch in my latest set of patches, which should go in shortly. Great! Thanks for saving me the effort. -- |---<Regards, Steve Youngs>-----------[GnuPG KeyID: EFD82ED2]---| | It's a funny thing about life; if you refuse to accept | | anything but the best, you very often get it | |-----------------------------<mailto:youngs_s＠ozlinx.com.au>---|

1 participants
0 comments

FontSet for XIM, dynamically changeable? 24 years, 3 months

Mike FABIAN

The FontSet, which is used while inputting Japanese using XIM and which is also used for the menu bar, can be selected using something like !! FontSet for menus when you use --with-xfs or --with-xim=xlib. XEmacs*fontSet: -*-fixed-medium-r-normal--16-* in .Xresources. Is it also possible to change this FontSet later, after XEmacs has been started? Currently, if I change the fonts used for normal text within XEmacs at runtime (using 'set-face-font'), the font used for XIM doesn't change. For example if I change to a bigger font to be able to read Japanese better, the font used for XIM still stays tiny and difficult to read. I.e. while typing a Japanese word or phrase, pressing SPC to convert to Kanji and selecting　the correct Kanji, the characters are small. After the conversion to Kanji is finished, the characters jump to the size of the surrounding characters. If the FontSet used for XIM could be changed at runtime too, this annoying behaviour could be avoided. -- Mike Fabian <mfabian(a)suse.de>

3 participants
3 comments

updates to man/xemacs-faq.texi 24 years, 3 months

Sandra Wambold

Please remember that if you change either the 21.1.* or 21.2.* man/xemacs-faq.texi source, you need to make sure you commit the changes to both brances. If do make a change, drop me a note so I can update the website. Your friendly FAQ maintainer, -sew

1 participants
0 comments

[comp.emacs.xemacs] Where is Completion-list code for buffers and M-x? 24 years, 3 months

Vin Shelton

The problem this person is attempting to solve is having the window split vertically (a la C-x 3) and generating a completion list. The list is always generated for the width of the entire frame. It is an annoying problem. Does anyone have any spare cycles to fix this? - vin

2 participants
1 comments

Fix tab lossage 24 years, 3 months

Andy Piper

This should resume normal service. I have also fixed the elhash stuff. andy 2000-07-31 Andy Piper <andy(a)xemacs.org> * buffer.c (Frecord_buffer): make absolutely sure that redisplay will acknowledge the change. * glyphs.h: declare tab_control_order_only_changed. * glyphs-x.c (x_tab_control_redisplay): use tab_control_order_only_changed. * glyphs-widget.c (tab_control_order_only_changed): new function. * glyphs-msw.c (mswindows_tab_control_redisplay): use tab_control_order_only_changed. * gui.c (gui_item_equal_sans_selected): new function. (gui_item_equal): use it. * glyphs-msw.c (mswindows_combo_box_instantiate): deprecate :properties in favor of :items.. * glyphs-widget.c (check_valid_item_list): rename from check_valid_item_list_1. (check_valid_item_list_1): renamed. (combo_box_validate): deprecate :properties in favor of :items. (widget_instantiate): ditto. (tab_control_update): ditto. (image_instantiator_combo_box): ditto. (image_instantiator_tree_view): ditto. (image_instantiator_tab_control): ditto. (layout_post_instantiate): remove dead code. * print.c (debug_print_no_newline): only write to debugger if in WIN32_NATIVE. * elhash.c (Fmake_hash_table): update doc string. * event-msw.c (mswindows_wnd_proc): don't allow processing of messages whilst in GC. This at least stops XEmacs crashing but has the potential for wierd behaviour. 2000-07-31 Andy Piper <andy(a)xemacs.org> * gutter-items.el (update-tab-in-gutter): deprecate :properties. 2000-07-27 Andy Piper <andy(a)xemacs.org> * lispref/hash-tables.texi: add new hash table type. -------------------------------------------------------------- Dr Andy Piper Principal Consultant, BEA Systems Ltd

3 participants
3 comments

Error with makeinfo 24 years, 3 months

Norbert Koch

Hi! After updating from CVS (which took about an hour...) I see the following error makeinfo -P lispref -o ../info/lispref.info lispref/lispref.texi makeinfo: invalid option -- P Try `makeinfo --help' for more information. nk＠lamia:xemacs$ makeinfo --version GNU Makeinfo (Texinfo 3.9) 1.67 Copyright (C) 1996 Free Software Foundation, Inc. There is NO warranty. You may redistribute this software under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. Is this a makeinfo version problem which'll go away after updating or is this a typo? Thanks, norbert -- Two LITTLE black dots and one BIG black dot...nice 'n' FLUFFY!!

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