9:34 p.m.
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.
Please describe as succinctly as possible:
- What happened.
- What you thought should have happened.
- Precisely what you were doing at the time.
Please also include any C or lisp back-traces that you may have.
================================================================
Dear Bug Team!
When trying to get the same coloring as in GNU Emacs, I was suggested
to use the color-theme package. Using it, I found out that XEmacs
seems to support fewer face types, meaning types of elements, than GNU
Emacs. For an example illustrating what I mean, see
http://downloads.schlosser.info/sample-emacs.html with the three
samples. There was a thread in comp.emacs.xemacs, starting with my
post, ID <ar5ev7$2j4$00$1(a)news.t-online.com>. Having not found a
solution, I assume it is a bug, so does the sender of an answer within
the thread.
Thanks a lot for any help!
Joachim
================================================================
System Info to help track down your bug:
---------------------------------------
OS version:
Microsoft Windows 2000 [Version 5.00.2195]
OS: Windows_NT
XEmacs 21.4.10 "Military Intelligence (Windows)" configured for
`i586-pc-win32'.
Building XEmacs in "f:\\xemacs\\xemacs-21.4-release\\nt".
Using compiler "cl -nologo -W3 -O2 -G5 -ML".
Installing XEmacs in "c:\\Program Files\\XEmacs\\XEmacs-21.4.10".
Package path is "~\\.xemacs;;c:\\Program
Files\\XEmacs\\site-packages;c:\\Program
Files\\XEmacs\\xemacs-packages".
Compiling in support for Microsoft Windows native GUI.
Compiling in support for XPM images.
Compiling in support for GIF images.
Compiling in support for PNG images.
Compiling in support for TIFF images.
Compiling in support for JPEG images.
Compiling in support for X-Face message headers.
Compiling in support for toolbars.
Compiling in support for dialogs.
Compiling in support for widgets.
Compiling in support for native sounds.
Compiling in fast dired implementation.
Using portable dumper.
Load-Path Lisp Shadows:
----------------------
nil
Installed XEmacs Packages:
-------------------------
((zenirc:version 1.13 :type regular)
(xslt-process :version 1.11 :type regular)
(xslide :version 1.03 :type regular)
(xemacs-devel :version 1.48 :type single-file)
(xemacs-base :version 1.71 :type regular)
(w3 :version 1.26 :type regular)
(vm :version 7.07 :type regular)
(viper :version 1.35 :type regular)
(view-process :version 1.12 :type regular)
(vhdl :version 1.15 :type regular)
(vc-cc :version 1.21 :type regular)
(vc :version 1.33 :type regular)
(tramp :version 1.1 :type regular)
(tpu :version 1.12 :type regular)
(tooltalk :version 1.13 :type regular)
(tm :version 1.34 :type regular)
(time :version 1.12 :type regular)
(textools :version 1.13 :type regular)
(text-modes :version 1.55 :type single-file)
(texinfo :version 1.21 :type regular)
(supercite :version 1.19 :type regular)
(strokes :version 1.08 :type regular)
(speedbar :version 1.24 :type regular)
(sounds-wav :version 1.1 :type regular)
(sounds-au :version 1.1 :type regular)
(sml-mode :version 0.05 :type regular)
(slider :version 1.13 :type regular)
(sieve :version 1.1 :type regular)
(sh-script :version 1.16 :type regular)
(sgml :version 1.08 :type regular)
(semantic :version 1.14 :type regular)
(scheme :version 1.12 :type regular)
(sasl :version 1.12 :type regular)
(ruby-modes :version 1.0 :type single-file)
(rmail :version 1.13 :type regular)
(reftex :version 1.28 :type regular)
(python-modes :version 1.01 :type single-file)
(psgml-dtds :version 1.02 :type regular)
(psgml :version 1.35 :type regular)
(ps-print :version 1.08 :type regular)
(prog-modes
:version
1
.67
:type
single-file)
(pgg :version 1.01 :type regular)
(perl-modes :version 1.02 :type single-file)
(pcomplete :version 1.02 :type regular)
(pcl-cvs :version 1.64 :type regular)
(pc :version 1.25 :type single-file)
(os-utils :version 1.29 :type single-file)
(ocaml :version 0.03 :type regular)
(net-utils :version 1.28 :type single-file)
(mmm-mode :version 1.0 :type regular)
(misc-games :version 1.15 :type single-file)
(mine :version 1.14 :type regular)
(mh-e :version 1.16 :type regular)
(mew :version 1.17 :type regular)
(mailcrypt :version 2.12 :type regular)
(mail-lib :version 1.54 :type regular)
(liece :version 1.1 :type regular)
(jde :version 1.38 :type regular)
(ispell :version 1.24 :type regular)
(ilisp :version 1.28 :type regular)
(igrep :version 1.1 :type regular)
(idlwave :version 1.27 :type regular)
(ibuffer :version 1.08 :type regular)
(hm--html-menus :version 1.18 :type regular)
(haskell-mode :version 1.03 :type regular)
(gnus :version 1.64 :type regular)
(gnats :version 1.15 :type regular)
(games :version 1.13 :type regular)
(fsf-compat :version 1.11 :type single-file)
(frame-icon :version 1.09 :type regular)
(fortran-modes :version 1.01 :type single-file)
(forms :version 1.14 :type regular)
(footnote :version 1.15 :type regular)
(eudc :version 1.36 :type regular)
(eterm :version 1.13 :type regular)
(ess :version 1.02 :type regular)
(eshell :version 1.03 :type regular)
(emerge :version 1.09 :type regular)
(elib :version 1.1 :type single-file)
(eieio :version 1.03 :type regular)
(efs :version 1.29 :type regular)
(edt :version 1.12 :type regular)
(edit-utils :version 1.95 :type single-file)
(ediff :version 1.44 :type regular)
(edebug :version 1.14 :type regular)
(ecrypto :version 0.12 :type regular)
(docbookide :version 0.05 :type regular)
(dired :version 1.12 :type regular)
(dictionary :version 1.11 :type regular)
(debug :version 1.16 :type regular)
(crisp :version 1.12 :type regular)
(cookie :version 1.14 :type regular)
(clearcase :version 1.04 :type regular)
(cc-mode :version 1.31 :type regular)
(calendar :version 1.19 :type regular)
(calc :version 1.23 :type regular)
(c-support :version 1.16 :type single-file)
(build :version 1.07 :type regular)
(bbdb :version 1.21 :type regular)
(auctex :version 1.32 :type regular)
(apel :version 1.25 :type regular)
(ada :version 1.11 :type regular)
(Sun :version 1.13 :type regular))
Features:
--------
(mail-abbrevs xemacsbug shadow sendmail rfc822 font-latex lazy-shot
lazy-lock fast-lock font-lock cus-face paren blink-paren tex-site
tex-mik zenirc-autoloads xslt-process-autoloads xslide-autoloads
xemacs-devel-autoloads xemacs-base-autoloads w3-autoloads vm-autoloads
viper-autoloads view-process-autoloads vhdl-autoloads vc-cc-autoloads
vc-autoloads tramp-autoloads tpu-autoloads tooltalk-autoloads
tm-autoloads time-autoloads textools-autoloads text-modes-autoloads
texinfo-autoloads supercite-autoloads strokes-autoloads
speedbar-autoloads sounds-wav-autoloads sounds-au-autoloads
sml-mode-autoloads slider-autoloads sieve-autoloads
sh-script-autoloads sgml-autoloads semantic-autoloads scheme-autoloads
sasl-autoloads ruby-modes-autoloads rmail-autoloads reftex-autoloads
python-modes-autoloads psgml-dtds-autoloads psgml-autoloads
ps-print-autoloads prog-modes-autoloads pgg-autoloads
perl-modes-autoloads pcomplete-autoloads pcl-cvs-autoloads
pc-autoloads os-utils-autoloads ocaml-autoloads net-utils-autoloads
mmm-mode-autoloads misc-games-autoloads mine-autoloads mh-e-autoloads
mew-autoloads mailcrypt-autoloads mail-lib-autoloads liece-autoloads
jde-autoloads ispell-autoloads ilisp-autoloads igrep-autoloads
idlwave-autoloads ibuffer-autoloads hm--html-menus-autoloads
haskell-mode-autoloads gnus-autoloads gnats-autoloads games-autoloads
fsf-compat-autoloads frame-icon-autoloads fortran-modes-autoloads
forms-autoloads footnote-autoloads eudc-autoloads eterm-autoloads
ess-autoloads eshell-autoloads emerge-autoloads elib-autoloads
eieio-autoloads efs-autoloads edt-autoloads edit-utils-autoloads
ediff-autoloads edebug-autoloads ecrypto-autoloads
docbookide-autoloads dired-autoloads dictionary-autoloads
debug-autoloads crisp-autoloads cookie-autoloads clearcase-autoloads
cc-mode-autoloads calendar-autoloads calc-autoloads
c-support-autoloads build-autoloads bbdb-autoloads auctex-autoloads
apel-autoloads ada-autoloads Sun-autoloads lisp-autoloads loadhist
auto-show fontl-hooks code-cmds gutter-items menubar-items x-menubar
dragdrop mode-motion mouse itimer auto-save lisp-mode easymenu
iso8859-1 page buff-menu lib-complete help-nomule cus-file derived
frame text-props obsolete cus-start custom widget cl-extra mini-cl cl
cl-19 packages backquote very-early-lisp file-coding
mswindows-scrollbars mswindows toolbar native-sound scrollbar
network-streams subprocesses menu-accelerator-support menubar md5
xemacs gutter tiff png gif jpeg xface xpm xbm lisp-float-type
windows-nt dragdrop-api dialog devices window-system base64)
Recent keystrokes:
-----------------
misc-user
Recent messages (most recent first):
-----------------------------------
Loading xemacsbug...done
Loading xemacsbug...
Loading lazy-shot...done
Loading lazy-shot...
Loading lazy-lock...done
Loading lazy-lock...
Loading fast-lock...done
Loading fast-lock...
Loading cus-face...done
Loading cus-face...
Loading tex-site...done
Loading tex-site...
12:44 a.m.
>>>> "jo" == jo xemacs
<jo_xemacs(a)schlosser.info> writes:
jo> When trying to get the same coloring as in GNU Emacs, I was
jo> suggested to use the color-theme package. Using it, I found
jo> out that XEmacs seems to support fewer face types, meaning
jo> types of elements, than GNU Emacs.
AFAICT color-theme is not a supported XEmacs package. If you want
support, ask the color-theme maintainer or see if someone else wants
to support it for XEmacs.
While GNU compatibility is in general a goal, there is no need for a
100% clone---you've already got GNU Emacs. So I don't consider this a
bug, it's an RFE, and fulfilling it will depend on availability of
volunteers.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
1:40 a.m.
On Tue, 03 Dec 2002, stephen(a)xemacs.org wrote:
>>>>> "jo" == jo xemacs
<jo_xemacs(a)schlosser.info> writes:
jo> When trying to get the same coloring as in GNU Emacs, I was
jo> suggested to use the color-theme package. Using it, I found
jo> out that XEmacs seems to support fewer face types, meaning
jo> types of elements, than GNU Emacs.
What do you mean 'types of elements'? can you give an example?
AFAICT color-theme is not a supported XEmacs package. If you want
support, ask the color-theme maintainer or see if someone else wants
to support it for XEmacs.
It is not supported as an xemacs package, but it does appear to be
supported for xemacs. It seems to work ok for me.
BTW, It is available here:
http://www.emacswiki.org/cgi-bin/wiki.pl?ColorTheme
-jeff
11:38 a.m.
New subject: AW: Same coloring as GNU Emacs not possible due to fewer face types
Hi Stephen, Jeff,
first of all thanks a lot for your quick answers.
> jo> When trying to get the same coloring as in GNU Emacs,
I was
> jo> suggested to use the color-theme package. Using it, I found
> jo> out that XEmacs seems to support fewer face types, meaning
> jo> types of elements, than GNU Emacs.
What do you mean 'types of elements'? can you give an example?
Well, if you look at the samples
(http://downloads.schlosser.info/sample-emacs.html), you see some LaTeX
code. In GNU Emacs, the options and parameters to commands have a different
color to the rest of the text, whereas in XEmacs they do not, regardless of
with or without color-theme. This lead me to the conclusion that XEmacs
simply does not support as many faces as GNU. In both Emacs'es I switched on
AucTeX, of course.
> AFAICT color-theme is not a supported XEmacs package. If you
want
> support, ask the color-theme maintainer or see if someone else wants
> to support it for XEmacs.
It is not supported as an xemacs package, but it does appear to be
supported for xemacs. It seems to work ok for me.
Yes, I know, and it also works here. But, to stress it: My question is not
about usability of color-theme together with XEmacs, it is about the number
of faces.
But I agree, this could also be rated as a RFE rather than a bug.
Nevertheless, is it true that there are fewer faces or is there anything I
could configure (easily) to get the additional faces?
BTW, It is available here:
http://www.emacswiki.org/cgi-bin/wiki.pl?ColorTheme
Yes, this is where I got it from.
Anyhow, this is the only thing I do not like in XEmacs, everything else is
just great! You have done some great work and a perfect Windows port!
Sincerely,
Joachim
12:15 a.m.
New subject: AW: Same coloring as GNU Emacs not possible due to fewer face types
On Tue, 3 Dec 2002, joachim(a)schlosser.info wrote:
Hi Stephen, Jeff,
first of all thanks a lot for your quick answers.
> > jo> When trying to get the same coloring as in GNU Emacs, I was
> > jo> suggested to use the color-theme package. Using it, I found
> > jo> out that XEmacs seems to support fewer face types, meaning
> > jo> types of elements, than GNU Emacs.
> What do you mean 'types of elements'? can you give an example?
Well, if you look at the samples
(http://downloads.schlosser.info/sample-emacs.html), you see some LaTeX
code. In GNU Emacs, the options and parameters to commands have a different
color to the rest of the text, whereas in XEmacs they do not, regardless of
with or without color-theme. This lead me to the conclusion that XEmacs
simply does not support as many faces as GNU. In both Emacs'es I switched on
AucTeX, of course.
XEmacs is not generally timid about creating faces.
The latex function
\documentclass[a4paper,12pt,parskip,DIV8]{scrartcl}
should fontify with \documentclass in the keyword-face, the options in
variable-name-face and the {text} in function-name-face.
See how font-lock-function-name-face is setup in emacs and xemacs.
The faces being used are controlled by font-latex-keywords-2, so you
may need to customize other faces as well.
BTW, I use the following function to help figure out which faces need to be
fixed.
(defun describe-face-at-point (&optional point)
"Return face used at point."
(interactive)
(let ((face (get-char-property (or point (point)) 'face)))
(if (listp face)
(progn
(message (format "Full value: %s" (prin1-to-string face)))
(setq face (car face))))
(hyper-describe-face face)))
This lets you see which face is being used at a particular point.
> > AFAICT color-theme is not a supported XEmacs package. If
you want
> > support, ask the color-theme maintainer or see if someone else wants
> > to support it for XEmacs.
> It is not supported as an xemacs package, but it does appear to be
> supported for xemacs. It seems to work ok for me.
Yes, I know, and it also works here. But, to stress it: My question is not
about usability of color-theme together with XEmacs, it is about the number
of faces.
But I agree, this could also be rated as a RFE rather than a bug.
Nevertheless, is it true that there are fewer faces or is there anything I
could configure (easily) to get the additional faces?
Start with the font-lock-keywords for the particular mode.
color-theme changes the appearance of faces used within a mode, but
will not change which faces are used for different parts.
-jeff
2:37 p.m.
New subject: AW: Same coloring as GNU Emacs not possible due to fewer face types
Jeff Mincy <jeff(a)delphioutpost.com> writes:
(defun describe-face-at-point (&optional point)
"Return face used at point."
(interactive)
(let ((face (get-char-property (or point (point)) 'face)))
(if (listp face)
(progn
(message (format "Full value: %s" (prin1-to-string face)))
(setq face (car face))))
(hyper-describe-face face)))
I can't tell you how many times I've needed something like this.
Thanks!
--
(__) Doug Alcorn - Unix/Linux/Web Developing
oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543
|_/ mailto:doug＠lathi.net http://www.lathi.net
mailto:tarpit＠lathi.net is a spam trap
10:40 p.m.
Hi Jeff,
The latex function
\documentclass[a4paper,12pt,parskip,DIV8]{scrartcl}
should fontify with \documentclass in the keyword-face, the options in
variable-name-face and the {text} in function-name-face.
I hope you enjoyed Christmas. In the meantime, if you remember the issue
about options not being highlighted in LaTeX mode, I had time to test your
function
(defun describe-face-at-point (&optional point)
"Return face used at point."
(interactive)
(let ((face (get-char-property (or point (point)) 'face)))
(if (listp face)
(progn
(message (format "Full value: %s" (prin1-to-string face)))
(setq face (car face))))
(hyper-describe-face face)))
For keywords, such as "documentclass" or "usepackage", it correctly
prints
out the face name, although there is a strange warning that I cannot exactly
interpret.
`font-lock-keyword-face' (buffer: thomasevangelium.ltx, mode: LaTeX)
Variable:
value: font-lock-keyword-face
This variable should not be set.
It is present only for horrid FSF compatibility reasons.
The corresponding face should be set using `edit-faces' or the
`set-face-*' functions.
Now, when marking e.g. "a4paper", where it should print
"variable-name-face", the result is "Sorry, nothing to describe". I
have no
clue, why.
And, when marking "scrartcl", where it should be "function-name-face",
the
result ist also "Sorry, nothing to describe".
Are we now closer to the solution? Is there anything I can do about this?
Joachim
2:15 a.m.
On Fri, 27 Dec 2002, joachim(a)schlosser.info wrote:
> The latex function
> \documentclass[a4paper,12pt,parskip,DIV8]{scrartcl}
> should fontify with \documentclass in the keyword-face, the options in
> variable-name-face and the {text} in function-name-face.
I hope you enjoyed Christmas. In the meantime, if you remember the issue
about options not being highlighted in LaTeX mode, I had time to test your
function
> (defun describe-face-at-point (&optional point)
> "Return face used at point."
> (interactive)
> (let ((face (get-char-property (or point (point)) 'face)))
> (if (listp face)
> (progn
> (message (format "Full value: %s" (prin1-to-string face)))
> (setq face (car face))))
> (hyper-describe-face face)))
For keywords, such as "documentclass" or "usepackage", it correctly
prints
out the face name, although there is a strange warning that I cannot exactly
interpret.
`font-lock-keyword-face' (buffer: thomasevangelium.ltx, mode:
LaTeX)
Variable:
value: font-lock-keyword-face
This variable should not be set.
It is present only for horrid FSF compatibility reasons.
The corresponding face should be set using `edit-faces' or the
`set-face-*' functions.
for the strange warning, if you are talking about the 'horrid fsf' comment
This is nothing more than the doc string on the variable
font-lock-keyword-face, which apparently only exists for some sort of
horrid reason:
(defvar font-lock-keyword-face 'font-lock-keyword-face
"This variable should not be set.
It is present only for horrid FSF compatibility reasons.
The corresponding face should be set using `edit-faces' or the
`set-face-*' functions.")
In other words, don't set the variable if you want to customize the face.
Now, when marking e.g. "a4paper", where it should print
"variable-name-face", the result is "Sorry, nothing to describe". I
have no
clue, why.
And, when marking "scrartcl", where it should be
"function-name-face", the
result ist also "Sorry, nothing to describe".
If it says "nothing to describe" then the object is shown in
the regular old default font, and not being shown in
function-name-face.
In order to get the fancier latex font-lock handling you have to either do
(add-hook 'LaTeX-mode-hook 'font-latex-setup)
(add-hook 'latex-mode-hook 'font-latex-setup)
or just (require 'font-latex) in your .emacs.
-jeff
2:38 a.m.
New subject: AW: Same coloring as GNU Emacs not possible due to fewer face types
>>>> "Joachim" == Joachim Schlosser
<joachim(a)schlosser.info> writes:
Joachim> In GNU Emacs, the options and parameters to commands have
Joachim> a different color to the rest of the text, whereas in
Joachim> XEmacs they do not, regardless of with or without
Joachim> color-theme. This lead me to the conclusion that XEmacs
Joachim> simply does not support as many faces as GNU.
It's more likely that XEmacs supports _different_ faces from GNU, or
even the same face with different names. XEmacs most definitely
supports a more complex definition of "face". You need to find out
what faces the code is trying to use.
Second, the highlighting code typically allows different levels of
decoration. GNU may default to a higher level of decoration. See the
menu, Options -> Syntax Highlighting -> Level.
Joachim> My question is not about usability of color-theme
Joachim> together with XEmacs, it is about the number of faces.
Number of faces is not a problem. There are _far_ too _many_ faces.
The problem is that each application defines its own, even though they
could be reused (in XEmacs; it's possible that GNU Emacs doesn't
support a flexible-enough inheritance scheme). Tracking down all that
information is a massive and mostly profitless pain in the neck, which
is why neither the upstream authors nor XEmacs maintainers like to do
it.
Joachim> Nevertheless, is it true that there are fewer faces or is
Joachim> there anything I could configure (easily) to get the
Joachim> additional faces?
No, and probably. Finding out what to configure is the problem.
The other possibility is that GNU has added new font-lock highlighting
"types" that we haven't gotten around to synching yet. If somebody
would take a look and tell us what, it's probably easy enough to do.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6:04 p.m.
New subject: AW: Same coloring as GNU Emacs not possible due to fewer face types
On Wed, 04 Dec 2002, stephen(a)xemacs.org wrote:
Joachim> My question is not about usability of color-theme
Joachim> together with XEmacs, it is about the number of faces.
Number of faces is not a problem. There are _far_ too _many_ faces.
The problem is that each application defines its own, even though they
could be reused (in XEmacs; it's possible that GNU Emacs doesn't
support a flexible-enough inheritance scheme). Tracking down all that
information is a massive and mostly profitless pain in the neck, which
is why neither the upstream authors nor XEmacs maintainers like to do
it.
Each application, or class of application should be using a common set
of faces.
The problem here is that using faces across application classes
would be confusing, arbitrary, and difficult.
For example, most of the language 'applications' modes use
font-lock-comment-face for comments. Some language modes add more faces
for language specific features (cperl-array-face)
But there are other applications like dired that has sockets,
executable files, links (etc). How would you combine 'dired' faces
with the 'language' faces?
-jeff
1:39 a.m.
New subject: AW: Same coloring as GNU Emacs not possible due to fewer face types
>>>> "Jeff" == Jeff Mincy
<jeff(a)delphioutpost.com> writes:
Jeff> But there are other applications like dired that has
Jeff> sockets, executable files, links (etc). How would you
Jeff> combine 'dired' faces with the 'language' faces?
On the one hand, `set-face-parent' comes to mind. On the other, I can
imagine shell buffers using those faces, too, when ls-ing. I can even
imagine synfl (syntactic font-locking) highlighting which recognizes
"stdin" in a cc-mode buffer and colors it "FILE *".
What I would like to see is a hierarchy like this:
Physical faces Logical faces
italic emphasis
red warning
sans serif-blue-on-black socket
App-specific faces should not be created. Instead, there should be a
face registry, and apps should define a specifier tag and use buffer
locales (it should be possible to have mode locales, I think, which
would simplify things enormously) to install face specs on existing
faces wherever possible.
This is of course just dreaming, as GNU Emacs can't do this. :-(
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
3:10 a.m.
New subject: AW: Same coloring as GNU Emacs not possible due to fewer face types
On Thu, 05 Dec 2002, stephen(a)xemacs.org wrote:
>>>>> "Jeff" == Jeff Mincy
<jeff(a)delphioutpost.com> writes:
Jeff> But there are other applications like dired that has
Jeff> sockets, executable files, links (etc). How would you
Jeff> combine 'dired' faces with the 'language' faces?
On the one hand, `set-face-parent' comes to mind. On the other, I can
imagine shell buffers using those faces, too, when ls-ing. I can even
imagine synfl (syntactic font-locking) highlighting which recognizes
"stdin" in a cc-mode buffer and colors it "FILE *".
Ok, you might be on to something
But I can imagine lots of other things - like when you do sed -e
"blah" at a shell prompt that "blah" is in sed-script-mode and when
you
do (regexp "blah") that "blah" is in regexp-string-mode and (at
least)
highlights the control characters differently from the rest of the
stuff. And when you do diff, or cvs diff at a shell prompt then the
output comes out in diff-mode.
What I would like to see is a hierarchy like this:
Physical faces Logical faces
italic emphasis
red warning
sans serif-blue-on-black socket
App-specific faces should not be created. Instead, there should be a
face registry, and apps should define a specifier tag and use buffer
locales (it should be possible to have mode locales, I think, which
would simplify things enormously) to install face specs on existing
faces wherever possible.
You're losing me here. How would buffer locales, or even mode locales
simplify the rats nest proliferation of faces? Haven't you just
shifted the problem from the definition of application specific
faces to the specification of a mode-specific specifier locales? (Yow)
The examples you gave for physical faces 'italic' and 'red' are
'pure' face where you have specified just one face dimension
(font-slant vs foreground). The 'sans serif-blue-on-black' physical
face is a 'composite' face where you have specified the foreground and
background and partially specified the font.
Mapping a logical face 'warning' to 'red' is fine, and even logical,
but having physical faces like 'sans serif-blue-on-black' seems to be
going down the same path that lead to the proliferation of faces in
the first place. Maybe I don't understand specifiers and what
you mean by specifier tags. But, I'm assuming that you really mean a
multiple inheritance scheme where a logical face can inherit
attributes from multiple other logical and physical faces eg
(define-face socket (sans-serif blue on-black))
This is of course just dreaming, as GNU Emacs can't do this. :-(
What can't gnu emacs do? set-face-parent or the specifier tags?
If you come up with something that is truly a simplification, then it
could be more than just dreaming.
Speaking of dreaming, we should probably move the conversation to
a different mailing list?
-jeff
4:16 a.m.
New subject: AW: Same coloring as GNU Emacs not possible due to fewer face types
FUT xemacs-design. Moved from xemacs-beta.
Jeff> But I can imagine lots of other things - like when you do
Jeff> sed -e "blah" at a shell prompt that "blah" is in
Jeff> sed-script-mode
Modes are something else again. I've long had it in mind that modes
should attach to extents, not to buffers. But I don't know how easy
that would be to do.
Jeff> You're losing me here. How would buffer locales, or even
Jeff> mode locales simplify the rats nest proliferation of faces?
Because apps should just take the default. (This was not clear,
mostly because I'm making this up as I go along. :) What I meant was
that Gnus and VM would both use the generic "message-header-mail-from"
face. If a _user_ wanted to customize Gnus and VM to have different
appearance of that face, then Custom would attach Gnus customizations
to the face in Gnus's *Article* buffers.
Jeff> Mapping a logical face 'warning' to 'red' is fine, and even
Jeff> logical, but having physical faces like 'sans
Jeff> serif-blue-on-black' seems to be going down the same path
Jeff> that lead to the proliferation of faces in the first place.
Not really. If applications use purely logical faces (ie, they carry
no specs except parent) and we make the parent a specifier (this is an
extension to the current implementation, parent is currently just a
face), then when the user wants to use "something like the
gnus-rogue-custom-warning-color-bonanza face" they can instance the
parent (look it up in the specifier), and inherit from that physical
face elsewhere without worrying that (a) larsi's whim or (b) their own
Gnus customizations will change the second logical face.
Ie, physical faces would be created once, and they would be set up to
have some sort of commonality across devices. Then they shouldn't be
changed or customized. Logical faces would be the object for
application tweaks and user customizations.
Jeff> Maybe I don't understand specifiers
A specifier is a dictionary for values, where the keys are display
contexts: windows, buffers, frames, devices, global. I'd like to
extend to modes (collections of buffers) and maybe extents (a
subobject of a buffer). Where multiple specifications apply, they are
given precedence according to the order above.
A specifier tag is a way for an application to identify specifications
it has placed on the specifier. It has internal uses as well, but
here it just means that Gnus can add and remove specs without worrying
about trashing some other app's, or the user's, specs.
Specifiers are optimized for handling display parameters.
Jeff> But, I'm assuming that you really mean a multiple
Jeff> inheritance scheme where a logical face can inherit
Jeff> attributes from multiple other logical and physical faces eg
Jeff> (define-face socket (sans-serif blue on-black))
No, it's not multiple inheritance in that sense. More like this
(define-face socket ((display-is-x-p sans-serif-blue-on-black)
(buffer-is-*Article*-p sans-serif-blue-on-default)))
where logical face instantiation is implemented like
(catch 'found
(let ((specs (face-spec-list face))
spec)
(while specs
(let* ((spec (pop specs))
(test (car spec))
(phys-face (cadr spec)))
(when (funcall test (window-to-redisplay))
(throw 'found phys-face)))))
fallback-physical-face)
The multiple inheritance you're talking about is already more or less
implemented as "face merging". Basically, faces are merged across
extents. So using [] to mark extents, an MUA might do something like
12 3 4
[[From:][ Stephen Turnbull [<stephen(a)xemacs.org>]]]
where extent 1 would specify from-header-face, extent 2 would specify
header-tag-face, extent 3 would specify header-value-face, and extent
4 would specify address-spec-face.
Then the MUA would use some sort of orthogonal convention, like the
From header is identified by the color blue (so from-header-face
inherits from physical face 'blue), header tags are bold roman
(physical face 'bold), header values are normal weight roman (physical
face 'default), and address-specs are normal weight italic (physical
face 'italic)---this overrides the header value face, because the
extent is more specific. Note that you need at least extents 2, 3,
and 4, anyway, and quite likely your header parser has identified the
endpoints of extent 1, so it's easy to add that extent and a face for
it.
> This is of course just dreaming, as GNU Emacs can't do this.
> :-(
Jeff> What can't gnu emacs do? set-face-parent or the specifier
Jeff> tags?
Specifiers. You can't do them in Lisp, because in general you do not
want to call Lisp from redisplay (and besides, it has to be very
fast). AFAIK that goes for GNU as much as it goes for XEmacs. So
they'd have to (re)implement specifiers, as that's all Ben Wing/Sun
code. Ben has indicated willingness to sign papers, but Sun never
has.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
8002
days inactive
8028
days old
12 comments
5 participants
participants (5)
-
Doug Alcorn -
Jeff Mincy -
jo_xemacs＠schlosser.info -
Joachim Schlosser -
Stephen J. Turnbull