> "Jay" == Jay Belanger <[EMAIL PROTECTED]> writes:
>> P.S.: The patch also removes the "degree" for "Kelvin".
Jay> Why?
There is no such thing as degrees Kelvin, there are only Kelvins.
(As an aside, I also agree that pt should remain pints.)
-JimC
--
James H. Cloos, Jr. <[EMAIL PROTECTE
Given the recent thread referencing keysyms, this seem apropos:
A patch was added to xorg today adding some more keysyms. The list is
available at:
https://bugs.freedesktop.org/attachment.cgi?id=3487
It adds #define XK_MATHEMATICAL to cvs/xorg/xc/include/keysym.h,v and
these lines to cvs/xorg/x
[This is probably emacs-unicode-2 specific. If there is a better list
to post this on, please let me know. -JimC]
Wanting to see what a given unicode char looked like, I tried to view
it in emacs (I am running emacs 23 at the moment.) The font was
missing a glyph, so I got an empty box. But is
>>>>> "JimC" == James Cloos <[EMAIL PROTECTED]> writes:
JimC> Perhaps the symbol could
JimC> be a synonym for the keycode 0x1XX, for all XX?
[SIGH] Seems X already has as a synonym for 0x100,
and pr
> "Kenichi" == Kenichi Handa <[EMAIL PROTECTED]> writes:
Kenichi> Thank you for the info, but, oops, it doesn't have these
Kenichi> lines (they exist in my debian): ...
Kenichi> What's going on here?
The diff between revisions 1.2 and 1.3 of that file as seen at:
http://cvs.freedesktop.org
> "Kenichi" == Kenichi Handa <[EMAIL PROTECTED]> writes:
Kenichi> It seems that these X11 keysyms (in
Kenichi> /usr/include/X11/keysymdefs.h, perhaps newly added) are not
Kenichi> registered in x-keysym-table (in lisp/term/x-win.el).
For the Cyrillic, see /usr/include/X11/keysymdef.h on a cur
> "Reiner" == Reiner Steib <[EMAIL PROTECTED]> writes:
> good question - i wasn't aware of pgg. can you tell me more about it?
Reiner> If you have Emacs 22 (CVS) or Gnus 5.10 installed, you should
Reiner> also have the manual: (info "(pgg)Top").
For gentoo, that means any of the app-editors
For the archives, src/xfaces.c is a good example to look at after
reading the relevant sections of the elisp manual.
I browsed through all of src; of all of the .c files, xfaces.c
deals with an api most similar to what I asked about.
-JimC
--
James H. Cloos, Jr. <[EMAIL PROTECTED]>
_
Can anyone point me to a good example in the emacs codebase of a lisp
api that closely matches an existing external c api? So far I've only
hacked the elisp part of emacs, not the C
I presume I'll need to create some read-only lisp integers matching
the names of the various enum values, lisp
> "David" == David Reitter <[EMAIL PROTECTED]> writes:
David> I want to stress that the default binding of the
David> space bar should be too insert a space.
Just to be clear, and since I was among the first to reply, I do
agree that the default should be self-insert.
-JimC
___
> "Lennart" == Lennart Borgman <[EMAIL PROTECTED]> writes:
Lennart> And some of those use Tab for file name completion - in the
Lennart> "shell" too ;-)
Yup. It is just hard to even /contemplate/ changing a 19 year old
habit. :)
-JimC
___
Emacs-
> "David" == David Reitter <[EMAIL PROTECTED]> writes:
David> IIRC, people seemed to agree and some said that they wouldn't
David> use minibuffer- complete-word anyways - especially for
David> filenames it seems to be clear that minibuffer-complete-word
David> makes no sense. Inputting a spac
2001 Free Software Foundation, Inc.
;; Author: Dave Love <[EMAIL PROTECTED]>
+ ;; James Cloos <[EMAIL PROTECTED]>
;; Keywords: i18n
;; This file is part of GNU Emacs.
***
*** 166,203
;; ("&!)" ?\})
;; ("&'?&qu
> "Dan" == Dan Nicolaescu <[EMAIL PROTECTED]> writes:
Dan> The problem occurs in Fedora Core 4. On a FC4 system:
Dan> echo 0 >/proc/sys/kernel/randomize_va_space is required
Dan> in order to be able to dump Emacs.
I've not had any problems dumping emacs with Linus' and Andrew's
recent kernel
> "Miles" == Miles Bader <[EMAIL PROTECTED]> writes:
Miles> If the terminfo entry is most likely wrong, and we know it,
Miles> then it doesn't make sense to follow it.
One issue with this, btw, that I forgot at first is logging in to
another box from the shell. There is no guarantee that the
> "Miles" == Miles Bader <[EMAIL PROTECTED]> writes:
Miles> If it's impossible to tell whether there's correct underlining
Miles> support, it seems safer to assume there's not -- or at the
Miles> least don't _advertise_ that there is. In other words,
Miles> probably the right thing to do is s
RMS> --color=no does cause underlining to "work"--namely, to display
RMS> as bold.
RMS> This doesn't alter the conclusions I sent in the previous
RMS> message: on this terminal, and on xterm, Emacs should say that
RMS> underlining is NOT supported.
In that case, at least when --color=yes I suppos
> "Eli" == Eli Zaretskii <[EMAIL PROTECTED]> writes:
Eli> But James just wrote that turning off colors causes underlining
Eli> to work correctly. That means the Linux console is in fact
Eli> capable of underlining.
What I meant is that is displays what a user of the linux consoles
expects fo
> "Eli" == Eli Zaretskii <[EMAIL PROTECTED]> writes:
Eli> you can try "emacs --color=no" to see if that causes underlining
Eli> to work.
Yes, that does change emacs' output. With TERM=linux underlining
works iff --color=no.
I presume infocmp -d linux xterm should show the relevant differenc
> "Eli" == Eli Zaretskii <[EMAIL PROTECTED]> writes:
Eli> How did you test that? If you type "M-x list-faces-display RET",
Eli> don't you see the face names underlined?
I just gave that a test in gnome-terminal and at a virtual console:
Using:
env TERM=linux emacs -nw
the underlines do
> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes:
Richard> According to display-supports-face-attributes-p, the console
Richard> implemented by Linux supports underline. But underlining is
Richard> not visible.
Richard> Is display-supports-face-attributes-p wrong, or is there a
Ric
> "KH" == Kenichi Handa <[EMAIL PROTECTED]> writes:
> "RMS" == Richard Stallman <[EMAIL PROTECTED]> writes:
KH> someone ...
It may have been Primoz Peterlin.
Roman Czyborra also has http://czyborra.com/unifont, but I believe
that only has a 16 pixel high font.
KH> compiled those files
I've noticed several places in the latin-ltx.el, sgml-input.el and
rfc1345.el files that I believe should be updated.
The changes are mostly due to characters that were added to unicode/
iso10646 since the .el files were written. Or in the case of 1345
since the rfc itself was written. (I suppos
> "David" == David Kastrup <[EMAIL PROTECTED]> writes:
David> Actually, it does not make sense to scale in that way. #3a7
David> really should be the same as #, so that #fff is the
David> same as #, pure white.
David> Somebody should tell the X people to do that.
I b
> "Miles" == Miles Bader <[EMAIL PROTECTED]> writes:
Miles> [I didn't change anything in the fontconfig setup so it seems
Miles> the default settings -- which are presumably aimed at white
Miles> backgrounds -- deals pretty well with black backgrounds too.]
It does depend on the font and whet
> "David" == David Kastrup <[EMAIL PROTECTED]> writes:
>>> So where do we get copyright-free flag icons?
>> KDE has a whole gallery.
David> Are you sure that those are in the public domain?
The openclipart project at freedesktop.org has flag images, and all
of their stuff is public domain.
> "Miles" == Miles Bader <[EMAIL PROTECTED]> writes:
Miles> I think this is not true -- it seems to be exactly this
Miles> behavior which -deferglyphs stops.
Iâve now found deferglyphs in Xserver(1). As I said, it is
new to me, but it does seem to address that one issue.
Miles> Can xft stil
> âMilesâ == Miles Bader <[EMAIL PROTECTED]> writes:
>> The other benefits are just as important. Control and installation
>> of fonts are easier for most users
Miles> Can you explain in more detail? I use debian, and Emacs
Miles> already seems able to use the same fonts as xft-using progra
It should be pointed out that antialiasing and sub-pixel rendering are
just two of the benefits of the client-side font system brought by Xft
and friends.
The other benefits are just as important. Control and installation of
fonts are easier for most users, fonts with large encodings -- such as
C
> "Stefan" == Stefan Monnier <[EMAIL PROTECTED]> writes:
Stefan> A Cairo port will probably make sense at some point, but I
Stefan> think that anti-aliasing support for X11 (using xft) is more
Stefan> urgent.
I suspect that the amount of work to get fontconfig/xft support on top
of the curren
There have been various pleas and debates on this posted on and off
over at least the past several months.
There are several options for doing this, but I beleive Cairo (cf
http://cairographics.org) is the best choice.
This would not be on top of the current X11 support, but parallel to
it (and t
I'm running cvs head updated w/in the last 8 hours.
I've been getting backtraces whenever gnus tries to display an html
mail which tries to dl stuff such as images.
The root cause is is url/url-history.el:
First it has:
|> (defvar url-history-hash-table nil
|> "Hash table for global history c
> "Miles" == Miles Bader <[EMAIL PROTECTED]> writes:
> "Lennart" == Lennart Borgman <[EMAIL PROTECTED]> writes:
Miles> Note that this can also be typed using `ESC TAB', which is pretty
Miles> convenient (the ESC and TAB keys are almost next to one another).
Lennart> Unfortunately this d
33 matches
Mail list logo
