Ar an séiú lá de mí Lúnasa, scríobh Stephen J. Turnbull:
> Aidan Kehoe writes:
>
> > The size isn’t even that useful; XFT DPI is independent of that for
> > server side fonts, though it will often be close. I find myself also
> > forgetting to run xrdb -DXEMACS_XFT ~/.Xdefaults before starting an
> > XFT XEmacs.
>
> I don't understand what you mean by "independent of that". I perceive
> a big difference between
> -adobe-courier-medium-r-normal--17-120-100-100-m-100-iso8859-1 and
> -adobe-courier-medium-r-normal--34-240-100-100-m-200-iso8859-1. If
> the user has specified a 24pt font in .Xresources, we should respect
> that.
http://scanline.ca/dpi/ for the details. Basically, the DPI can be set for
XFT applications via an X resource and via the Gnome settings daemon, and
this setting won’t be respected by core fonts. I don’t know how common such
differentiation is on Gnome desktops, but it does mean that the DPIs for the
two are independent.
> We currently don't have a way to respect that spec on Xft AFAIK, but
> it's one of the things I work on off and on. I see no reason why we
> shouldn't allow any of the various font specs on any platform,
> although in cases of ambiguity we should prefer different defaults for
> different platforms.
XLFDs (and X server-side fonts in general) are old and broken (in terms of
size, scalable-or-not, repertoire and other reasons). GNU using them on
Carbon (and even on Windows?) was not a good idea. I am really thankful that
they are not available in XEmacs on Windows.
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Ar an ceathrú lá de mí Lúnasa, scríobh Stephen J. Turnbull:
> Aidan Kehoe writes:
>
> > Stephen, does it really bring value to also accept XLFDs on the XFT
> > build?
>
> Yes. Existing X resource specifications should continue to work under
> Xft. Even if the font family is not available, we should use them for
> hints at size.
The size isn’t even that useful; XFT DPI is independent of that for server
side fonts, though it will often be close. I find myself also forgetting to
run xrdb -DXEMACS_XFT ~/.Xdefaults before starting an XFT XEmacs.
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
Your version of XEmacs was distributed with a PROBLEMS file that may
describe
your crash, and with luck a workaround. Please check it first, but do
report
the crash anyway.
Please report this bug by invoking M-x report-emacs-bug, or by selecting
`Send Bug Report' from the Help menu. If that won't work, send ordinary
email to `xemacs-beta(a)xemacs.org'. *MAKE SURE* to include this entire
output from this crash, especially including the Lisp backtrace, as well as
the XEmacs configuration from M-x describe-installation (or equivalently,
the file `Installation' in the top of the build tree).
*Please* try *hard* to obtain a C stack backtrace; without it, we are
unlikely
to be able to analyze the problem. Locate the core file produced as a
result
of this crash (often called `core' or `core.<process-id>', and located in
the directory in which you started XEmacs or your home directory), and type
gdb /usr/bin/xemacs core
then type `where' at the debugger prompt. No GDB on your system? You may
have DBX, or XDB, or SDB. (Ask your system administrator if you need help.)
If no core file was produced, enable them (often with `ulimit -c unlimited')
in case of future recurrance of the crash.
Lisp backtrace follows:
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
specifier-instance(#<font-specifier global=<unspecified>
fallback=#<font-specifier global=<unspecified> fallback=(((tty) .
"normal") ((x) . "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*") ((x)
. "-*-fixed-medium-r-*-*-*-120-*-*-*-*-iso8859-*") ((x) .
"-*-courier-*-r-*-*-*-120-*-*-*-*-iso8859-*") ((x) .
"-*-fixed-*-r-*-*-*-120-*-*-*-*-iso8859-*") ((x) .
"-*-*-medium-r-*-*-*-120-*-*-m-*-iso8859-*") ((x) .
"-*-*-medium-r-*-*-*-120-*-*-c-*-iso8859-*") ((x) .
"-*-*-*-r-*-*-*-120-*-*-m-*-iso8859-*") ((x) .
"-*-*-*-r-*-*-*-120-*-*-c-*-iso8859-*") ((x) .
"-*-courier-medium-r-*-*-*-*-*-*-*-*-iso8859-*") ((x) .
"-*-fixed-medium-r-*-*-*-*-*-*-*-*-iso8859-*") ((x) .
"-*-courier-*-r-*-*-*-*-*-*-*-*-iso8859-*") ((x) .
"-*-fixed-*-r-*-*-*-*-*-*-*-*-iso8859-*") ((x) .
"-*-*-medium-r-*-*-*-*-*-*-m-*-iso8859-*") ((x) .
"-*-*-medium-r-*-*-*-*-*-*-c-*-iso8859-*") ((x) .
"-*-*-*-r-*-*-*-*-*-*-m-*-iso8859-*") ((x) .
"-*-*-*-r-*-*-*-*-*-*-c-*-iso8859-*") ((x) .
"-*-*-*-r-*-*-*-120-*-*-*-*-iso8859-*") ((x) .
"-*-*-*-r-*-*-*-*-*-*-*-*-iso8859-*") ((x) .
"-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-*") ((x) .
"-sun-gothic-medium-r-normal--14-120-75-75-c-60-jisx0201.1976-0") ((x) .
"-sun-gothic-medium-r-normal--14-120-75-75-c-120-jisx0208.1983-0") ((x)
. "-wadalab-gothic-medium-r-normal--14-120-75-75-c-120-jisx0212.1990-0")
((x) . "-*-fixed-medium-r-*--*-jisx0201.1976-*") ((x) .
"-*-fixed-medium-r-*--*-jisx0208.1983-*") ((x) .
"-*-fixed-medium-r-*--*-jisx0212*-*") ((x) .
"-*-*-*-r-*--*-jisx0201.1976-*") ((x) . "-*-*-*-r-*--*-jisx0208.1983-*")
((x) . "-*-*-*-r-*--*-jisx0212*-*") ((x) .
"-*-*-medium-r-*--*-gb2312.1980-*") ((x) .
"-*-fixed-medium-r-*--*-cns11643*-*") ((x) .
"-*-fixed-medium-r-*--*-big5*-*,-*-fixed-medium-r-*--*-sisheng_cwnn-0")
((x) . "-*-mincho-medium-r-*--*-ksc5601.1987-*") ((x) .
"-*-fixed-medium-r-*--*-tis620.2529-1") ((x) .
"-*-fixed-medium-r-*--*-viscii1.1-1") ((x) .
"-*-fixed-medium-r-*--*-mulearabic-*") ((x) .
"-*-fixed-medium-r-*--*-muleipa-*") ((x) .
"-*-fixed-medium-r-*--*-ethio-*") ((x) .
"-*-courier-medium-r-*-*-*-120-*-*-*-*-iso10646-1") ((x) .
"-*-fixed-medium-r-*-*-*-120-*-*-*-*-iso10646-1") ((x) .
"-*-courier-*-r-*-*-*-120-*-*-*-*-iso10646-1") ((x) .
"-*-fixed-*-r-*-*-*-120-*-*-*-*-iso10646-1") ((x) .
"-*-*-medium-r-*-*-*-120-*-*-m-*-iso10646-1") ((x) .
"-*-*-medium-r-*-*-*-120-*-*-c-*-iso10646-1") ((x) .
"-*-*-*-r-*-*-*-120-*-*-m-*-iso10646-1") ((x) .
"-*-*-*-r-*-*-*-120-*-*-c-*-iso10646-1") ((x) .
"-*-courier-medium-r-*-*-*-*-*-*-*-*-iso10646-1") ((x) .
"-*-fixed-medium-r-*-*-*-*-*-*-*-*-iso10646-1") ((x) .
"-*-courier-*-r-*-*-*-*-*-*-*-*-iso10646-1") ((x) .
"-*-fixed-*-r-*-*-*-*-*-*-*-*-iso10646-1") ((x) .
"-*-*-medium-r-*-*-*-*-*-*-m-*-iso10646-1") ...) 0x1ecf> 0x4e73e> nil
nil nil)
# bind (value no-fallback default domain property face)
face-property-instance(font-lock-string-face font nil)
# bind (charset domain face)
face-font-instance(font-lock-string-face)
# bind (--dolist-temp--21812 face new-default-face-font
face-list-to-change from-slant from-weight from-size from-family
font-data dcache size weight family)
font-menu-set-font(nil nil 130)
eval((font-menu-set-font nil nil 130))
# (condition-case ... . error)
# (catch top-level ...)
--
Med Venlig Hilsen
Randi Grøn
Institut for Folkesundhedsvidenskab
Biostatistisk Afdeling
Øster Farimagsgade 5 opg. B; Postboks 2099
1014 København K
Lokale 15.2.19
Telefon: 353-27906
Fax: 353-27907
Email: R.Groen(a)biostat.ku.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
On Thu, Aug 02, 2007 at 03:32:44PM +0100, Rob McMahon wrote:
> Paul Keusemann wrote:
> >> > Secondly linking temacs fails with:
> >> >
> >> > Undefined first referenced
> >> > symbol in file
> >> > acos floatfns.o (symbol belongs to
> >> implicit dependency /lib/libm.so.2)
> >>
> >>This is weird, too; I'm pretty sure we have people building regularly
> >>on recent Solaris. Any ideas why your environment would elicit this
> >>bug, when (AFAIK) it doesn't occur for others?
> >>
> >
> >This one I don't remember seeing.
> >
> I did compile this on Solaris Express (5.11 snv_65). I wonder if that's
> the difference. I'll investigate more.
>
I just checked my src/Makefile.in and -lm is included in the ld_libs_all
macro definition, -lm shows up in the make output, so libm is getting
included in the link. I don't believe I've done anything to change this.
My last cvs update was June 2.
Paul
--
Paul Keusemann pkeusem(a)visi.com
4266 Joppa Court (952) 894-7805
Savage, MN 55378
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
>>>>> "Michael" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes:
Michael> Aidan Kehoe <kehoea(a)parhasard.net> writes:
Michael> What does
Michael> (startup-find-load-path)
Michael> return?
$ xemacs -no-autoloads -vanilla -batch -eval '(message "%s" (startup-find-load-path))'
(/Users/malcolmp/prefix/share/xemacs/site-lisp/
/Users/malcolmp/prefix/share/xemacs-21.5-b28/lisp/mule/
/Users/malcolmp/prefix/share/xemacs-21.5-b28/lisp/)
So the directory is present when XEmacs starts, but isn't there during
package compilation.
Expanding on what I said in my last message, it looks like the offending
code is this from package-compile.el:
(let ((depth (cond
;; #### All hail Mr. Preprocessor!
;; OK, OK, his code is under development; FIXME when it's done.
((boundp 'paths-load-path-depth) ; XEmacs 21.1
paths-load-path-depth)
((boundp 'paths-core-load-path-depth) ; XEmacs > 21.2.41
paths-core-load-path-depth)
(t (error "Somebody has been messing with paths-find-*!")))))
(setq load-path (paths-find-recursive-load-path (list lisp-directory)
depth)))
What then is the right way to reset the load-path to only refer to the
core and mule directories?
Malcolm
--
Malcolm Purvis <malcolmp(a)xemacs.org>
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Ar an dara lá de mí Lúnasa, scríobh Stephen J. Turnbull:
> Mike FABIAN writes:
>
> > By the way, adding the charsets ‘latin-iso8859-13’ and
> > ‘latin-iso8859-16’ to the charset lists in the language-environments
> > gives an error during startup because these are apparently not yet
> > available when ‘finish-set-language-environment’ is called.
>
> *sigh*
>
> Just uncomment them in lisp/unicode.el. I think it unlikely that
> anything that doesn't need them will notice, while stuff like
> `finish-set-language-environment' will work better.
latin-iso8859-13 is from the packages, and is not in the autoloads.
Initialising its Unicode mapping at startup won’t work. I suspect that it in
particular is the problem, and not latin-iso8859-16.
> That strategy would not necessarily work with non-ISO-2022-conforming
> charsets such as Windows-1252, but fortunately ISO 8859 is a profile
> of ISO 2022. All that you lose by doing this is a few bytes, I think.
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Mike FABIAN wrote:
>
> If one absolutely wants to reduce confusion by reducing the number of
> choices, then I think the non-UTF-8 choices could be removed if one
> starts in an UTF-8 locale because in that case the non-UTF-8 ones are
> almost useless anyway.
I don't know exactly what set-language-environment does in total;
but it sets also the coding priority list. And using a Latin1 or
Latin9 for LaTeX in a UTF-8 locale is a very common use case.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: jschrod(a)acm.org
Roedermark, Germany
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Ar an chéad lá de mí Lúnasa, scríobh Mike FABIAN:
> Aidan Kehoe <kehoea(a)parhasard.net> さんは書きました:
>
> > The reason there isn’t a German (UTF-8) locale available when you start
> > in a Japanese UTF-8 locale, is that there is such a wide and legitimate
> > variation in the coding systems used with a given language under
> > Unix--English in ISO 8859-1 vs. English in ISO 8859-15 vs. English in
> > UTF-8 vs. English in CP1252, to pick a simple example--that it makes
> > more sense to pick one as canonical
>
> But then I would like to have the UTF-8 variants as the canonical ones
> because UTF-8 is the default on the systems I use.
Should they be the ones picked up if LANG is just "de" or "ja" ? That’s what
I meant by “canonical,” the one chosen if language information but not
character set information is available from the environment.
> Having UTF-8 only for the language I use during startup and not for the
> others makes changing the language-environment totally useless because
> it messes up the encoding for external processes (and even for the
> XEmacs menu bar when opening new frames with “C-x 5 2”!).
>
> > and create a variant if a corresponding LANG or LC_CTYPE is seen.
> > If you want a German UTF-8 locale despite not having LANG as de_??.UTF-8 in
> > your environment at startup, call:
> >
> > (set-language-environment
> > (create-variant-language-environment "German" 'utf-8))
>
> Nice, I can use this in site-start.el for the time being.
OK. But if your users start up in the appropriate locale, as most of them
will, that shouldn’t be necessary.
> > set-language-environment is supposed to be a cross-platform API, so my
> > feeling is that we shouldn’t do this automatic generation of new language
> > environments within it for what is essentially a Unix quirk;
>
> But if it is a Unix quirk, then why not do it on Unix?
For the sake of a consistent cross-platform API :-) . Unexpected behaviour
makes things harder to maintain, normally.
> > the system locales under Windows are basically fixed in the coding
> > systems they use. But if you think otherwise, say so, and I’ll think
> > about it some more.
>
> I wouldn't mind to have several possible values for language-environments
> for each language. Do you think that will confuse people?
I have 156 POSIX locales on this FreeBSD machine; but only 41 separate
languages are used in those locales. Maintaining around 40 language
environments within XEmacs is more practical than maintaining around 200
(since I’m sure FreeBSD omits plenty).
It’s not really a question of user confusion if the user gets the correct
language environment by default, which most of them should if their POSIX
locale is correctly set.
Would adding information to the set-language-environment docstring about
create-variant-language-environment make things easier?
> The confusion is already there because all these locales exist
> unter Unix, having them available in the language-environments doesn’t
> make it any worse.
It makes it worse on Windows, though. And yes, Windows isn’t your problem.
> If one absolutely wants to reduce confusion by reducing the number of
> choices, then I think the non-UTF-8 choices could be removed if one
> starts in an UTF-8 locale because in that case the non-UTF-8 ones are
> almost useless anyway.
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta