February 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [21.0b63] make-face-bold is broken under CYGWIN+X... 26 years, 1 month

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Jan claimed (if I read it right) that specifiers are inefficient; > maybe they are. Not at the device tag level I think. I do remember there being a discussion about the general inefficiency of specifiers when custom was first ported to XEmacs. The problem comes when you try extend it and you have to preserve the current efficiency. Jan

1 participants
0 comments

setq-default problem? 26 years, 1 month

Eric Knudstrup

I don't know if this is a problem with cc-mode or in general, but I keep having a problem where I (setq-default c-basic-offset 4) and it doesn't hold for new buffers, or even if I switch to another buffer and back. This is with the NT version of XEmacs (installed using the installer 990105.exe). Eric

1 participants
0 comments

Re: [21.0b63] make-face-bold is broken under CYGWIN+X... 26 years, 1 month

Paul Stodghill

Stephen and Jan, thank you for the discussion. I understand the issues better than I did before. I agree with Stephen that there seems to be a deeper problem here than the one that I am trying to fix. I need to think about this some more. If nothing else, I'd like to see some consensus about "how things ought to be". Jan> No but Paul has real problems that need to be fixed. His setup might Jan> be rare now but it might not be in the future. My problems are annoying, but cosmetic. Maybe this isn't an issue that should be addressed in 21.0. Perhaps after 21.0 is released and all of the CYGWIN+X users[1] start screaming bloody murder, then it can be fixed for 21.1. Jan> This does seem the right way to fix that. You have settings that are Jan> valid only for a particular type of device so you add a tag set to Jan> reflect that. The current code is just a cop out. The current code is broken, definitely. And if tag sets do refer to devices, then I think that my patch is ok. But if tag sets involve MULE ... <shudder> Boy, this is one hell of a way to get my feet wet with XEmacs development, huh? Custom, Windows, specifiers, _and_ MULE! [1] Let's see, there's me ... Andy, I think ... and ... umm ...

2 participants
1 comments

Info bug 26 years, 1 month

Nick V. Pakoulin

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 "Artemis" [Lucid] (i686-pc-linux) of Wed Feb 10 1999 on pegas configured using `configure --external-widget --debug=yes --error-checking=none' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Studying 'abbrevs expanding' I met the following: In XEmacs Info : > - Function: define-abbrev TABLE NAME EXPANSION HOOK > This function defines an abbrev in TABLE named NAME, to expand to > EXPANSION, and call HOOK. The return value is an uninterned > symbol that represents the abbrev inside XEmacs; its name is NAME. > > The argument NAME should be a string. The argument EXPANSION > should be a string, or `nil' to undefine the abbrev. > > The argument HOOK is a function or `nil'. If HOOK is non-`nil', > then it is called with no arguments after the abbrev is replaced > with EXPANSION; point is located at the end of EXPANSION when HOOK > is called. > > The use count of the abbrev is initialized to zero. In /usr/local/lib/xemacs-21.2-b8/lisp/abbrev.el: > (defun define-abbrev (table name &optional expansion hook count) > "Define an abbrev in TABLE named NAME, to expand to EXPANSION or call HOOK. > NAME and EXPANSION are strings. Hook is a function or `nil'. > To undefine an abbrev, define it with an expansion of `nil'." Nothing definite is said about optional argument COUNT neither in Info nor in Doc string. Info version is 3.3 for 21.0

1 participants
0 comments

Re: crypt (or tar) breakage? 26 years, 1 month

SL Baur

nbecker <nbecker(a)fred.net> writes in xemacs-beta(a)xemacs.org: > One of the coolest features of xemacs seems to be broken as of > 21.2b10. I cannot duplicate this problem on either 21.0 or 21.2. > I have (require 'crypt) > If I visit a .tar.gz, it should not only ungzip, but will put me in tar > mode. That doesn't work anymore. Instead I get > c½ÅOé =i has size -59888002 - corrupted. > parsing tar file...2% > parsing tar file...1% > parsing tar file... Are you sure you don't have a corrupted .tar.gz file?

2 participants
1 comments

Re: $PATH bug? 26 years, 1 month

SL Baur

Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes in xemacs-beta(a)xemacs.org: ... > In fact, the package binaries should not even be appended to > EXEC-PATH. If a package wants a binary, it should know what directory > to look in, rather than looking in a semi-random global path which > might actually include another binary with the same name in front of > it. mmencode is a prominent example, where we've avoided problems in > the past merely by virtue of the fact that Metamail hasn't changed > recently. > I intend to hack this in the next Great Path Overhaul which I'll get > to once 21.0 is out. Fair enough. The $PATH of least of resistance is to add the directories in 21.0 but not 21.2 and use a different solution there when you work it out.

1 participants
0 comments

Re: [21.0b63] make-face-bold is broken under CYGWIN+X... 26 years, 1 month

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > What I really don't understand is how the FSF Emacs manages to use > custom without destroying all of the Mule stuff. Their face code is wildly different from ours.

1 participants
0 comments

Re: [21.0b63] make-face-bold is broken under CYGWIN+X... 26 years, 1 month

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > I don't think this works right. It postpones the day when Custom > learns to handle mule fonts, too. :-/ I'm thinking 21.0/21.1 solutions here. Unless you think it is better to tell Mule users not use customize until it has been tamed. > FSF uses explicit fontSets (instead of specifier magic which allows > multiple fonts to coexist if they have different registries). I bet > that this is implemented in such a way as to be equivalent to not > using `reset-face'. I just looked at the FSF 20.3 source at ftp.ifi.uio.no and this part of their face-spec-set (modify-face face '(nil) '(nil) nil nil nil nil nil frame) looks almost like an reset-face to me. Note that from the look of it FSF Emacs simply does not implement the font name part of custom! (and thus do not have these problems). > Jan> Huh? Current ALL tag-sets are device tags. Some of them may > Jan> be user defined but they are related to the device. In fact > > 'mule-font and 'default are not really "user-defined" even if they are > created with `define-specifier-tag'. They aren't device tags. Currently ALL tag sets are device tags. See below > Jan> if it were possible to have efficient tags that worked at > Jan> every locale it would be a lot easier to implement Custom > Jan> atop of specifiers. > > (What do you mean by "efficient" and "work at every locale"?) What I mean is the following: a tag set is a filter. Effectively it is not the complete specifier that is used when looking for a font-instance for display but it is just those parts that have the tags associated with the device as a subset of the tag set (with a special case for nil). Therefore you can add things like 'default and 'mule-font for other uses but XEmacs thinks they are device tags. What I would like is that this mechanism is generalized as follows. I would like that not only the device locale is associated with a tag set but also the other locales. Then when matching it is not the device tags that are used as a filter, but the current locale's. For instance the customize 'dark and 'light spec-tags depend on the background of the default font in that window and are therefore window specific. This would allow complete implementation of custom-specs in terms of specifiers. The problem with this is doing it efficiently. Currently tags are aggressively cached at device level. The computation is really only done at device creation time and when defining new tags. Both of these are rare events. Creation of buffers and windows occurs much more often, therefore you need a much smarter cache. > Suppose I wanted to use a tag set? Paul's code doesn't allow for > that; his code passes and expects to receive a symbol. Sorry I missed that. He should allow passing a list (this should be easy). Just ditch the '(list func-tag) and do it at an higher level. > simple enough to change that. My point is that it is not true that > the tags are mutually exclusive, tag sets are necessary in general, > and I don't know---and neither does anyone else, right?---about this > particular code. No but Paul has real problems that need to be fixed. His setup might be rare now but it might not be in the future. This does seem the right way to fix that. You have settings that are valid only for a particular type of device so you add a tag set to reflect that. The current code is just a cop out. Jan

1 participants
0 comments

Re: [21.0b63] make-face-bold is broken under CYGWIN+X... 26 years, 1 month

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > non-ISO-8859-1 font information (using reset-face); now (if I > understand what Jan has done correctly) it saves that information, > but can't change it. Someday (soon, I hope) somebody is going to fix > this. No I proposed doing that but that is not the patch that went in. What it does now is trying to reconstruct the face after destroying it wiht reset-face. Note that currently it does not call the code that sets up the mule fonts again (It probably should). The upshot is that custom will probably still hose your Mule faces. Maybe what it should do in addition to that is use not 'reset-face' but something similar that leaves all the fonts with the 'mule-font' tag alone. What I really don't understand is how the FSF Emacs manages to use custom without destroying all of the Mule stuff. > I don't know without a careful analysis whether your patch would > interfere with this improvement or not. Many of the functions in > faces.el were once part of the Custom superstructure IIRC. His changes look correct to me. > One thing I just noticed that bothers me is that you have usurped the > TAG-SET argument of the specifier functions for just one class of > tags: the device tags. However, there are several others, including > visual and user-defined, and I think that you should allow for the > possibility that somebody (in particular, Mule programmers) will want > to pass arbitrary tag sets. Huh? Current ALL tag-sets are device tags. Some of them may be user defined but they are related to the device. In fact if it were possible to have efficient tags that worked at every locale it would be a lot easier to implement Custom atop of specifiers. > Yes. If you look at the comments in the LISP sources and Changelogs, > you'll see that nobody is yet sure what belongs to Custom and what > belongs to XEmacs. Nobody is willing to take ownership of it; I don't > have the time to get enough understanding of Custom, the people who > know Custom don't really understand Mule or in some cases specifiers, > and they don't have time to study it either. This is really the root of the problem. The specifier side of things at least has good documentation. Custom already a lot less (especially things like the exact meaning of the face specs etc) and Mule basically has/had no documentation. Jan

2 participants
1 comments

Omission in xemacs-beta welcome message 26 years, 1 month

John Whitley

At the end of the paragraph emphasizing the use of 'diff -u' is a sentence fragment, leaving out some important information : > [deletia] > please consider getting one that does (like GNU diff). Patches should > always be sent to ^^^^^^ missing address -- John

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 1999