Re: full-screen in menus like firefox
>>>>> "Dan" == Dan Jacobson <[EMAIL PROTECTED]> writes: Dan> "full screen" is missing from emacs' menus. Dan> firefox's F11 turns on fullscreen and is in firefox's menus. The fullscreen atom to set/clear is "_NET_WM_STATE_FULLSCREEN". -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [want a bug fix for old fonts with emacs xft]
>>>>> "G" == [EMAIL PROTECTED] com <[EMAIL PROTECTED]> writes:
G> I compiled emacs 23.0.0 from CVS and installed on on my
G> centos 4.2 box. The default face looks very nice, but
G> bold, italic, and some menu faces use old fonts
I presume from this that you compiled and are running with
the --enable-font-backend flag and would like to have just
client-side fonts (which can be anti-aliased) and not any
of the server-side fonts (which can only be bitmaps)?
I also presume you are on an X11 platform, such as linux
or bsd.
If so, either add:
-xrm '*FontBackend: xft'
to your invocation of emacs, or add:
emacs.FontBackend: xft
to whichever of ~/.Xdefaults or ~/.Xresources you use.
Either way, that will limit the font-backend code to using
libfontconfig and libXft for fonts. You can also use x to
limit it to server-side fonts, xft,x to prefer xft but allow
either, of x,xft to prefer server-side but allow either.
If there are specific fonts you prefer for some scripts, this
is the syntax to use in your .emacs:
(set-fontset-font (frame-parameter nil 'font)
'han '("SimHei" . "unicode-bmp"))
The script names you can use where I have 'han above can be
found near the end of lisp/international/characters.el.
-JimC
--
James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 'woman' can't format the ssh man page
>>>>> "RMS" == Richard Stallman <[EMAIL PROTECTED]> writes: RMS> Can we make woman detect use of the doc macros RMS> and give a meaningful error message? Grog(1) (part of groff) uses this logic to guess -man macros: if: any line matches /^\.SH[\s\n]/ and if any (other) line matches /^\.TH[\s\n]/ and if no line matches /^\.([pnil]p|sh)[\s\n]/ then: it uses an It should be enough for woman to check for those (perl-style) regexps. At least for now. For doc, if it is not an, e, om, s or m, and if any line matches /^\.Dd/, then it is either doc or doc-old. For after the 22 release, it would seem a good idea to convert the full grog logic to elisp; I'm sure it would be useful to more than just woman. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 'woman' can't format the ssh man page
That man page is written in doc rather than in an. With modern groff you have to pass -man-old to get the old an macros w/o also supporting the newer doc macros. If you do that with ssh.1 you see the same results as woman shows. This means that what woman needs is support for the doc macro set. (Sometimes AKA the mdoc macro set.) -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: calendar gets wrong end for Daylight Savings Time
>>>>> "GM" == Glenn Morris <[EMAIL PROTECTED]> writes: GM> So what in that output tells me that the DST transition date changes GM> in 2007? As you can see from that output America/Phoenix has not done daylight time since 1944 (US wartime national Mandate). Try America/Chicago, America/New_York, America/Los_Angeles or America/Denver for a lengthier output that does show the 2007 change. (Denver shows this: , | . | . | . | America/Denver Sun Apr 3 08:59:59 2005 UTC = Sun Apr 3 01:59:59 2005 MST isdst=0 | America/Denver Sun Apr 3 09:00:00 2005 UTC = Sun Apr 3 03:00:00 2005 MDT isdst=1 | America/Denver Sun Oct 30 07:59:59 2005 UTC = Sun Oct 30 01:59:59 2005 MDT isdst=1 | America/Denver Sun Oct 30 08:00:00 2005 UTC = Sun Oct 30 01:00:00 2005 MST isdst=0 | America/Denver Sun Apr 2 08:59:59 2006 UTC = Sun Apr 2 01:59:59 2006 MST isdst=0 | America/Denver Sun Apr 2 09:00:00 2006 UTC = Sun Apr 2 03:00:00 2006 MDT isdst=1 | America/Denver Sun Oct 29 07:59:59 2006 UTC = Sun Oct 29 01:59:59 2006 MDT isdst=1 | America/Denver Sun Oct 29 08:00:00 2006 UTC = Sun Oct 29 01:00:00 2006 MST isdst=0 | America/Denver Sun Mar 11 08:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 MST isdst=0 | America/Denver Sun Mar 11 09:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 MDT isdst=1 | America/Denver Sun Nov 4 07:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 MDT isdst=1 | America/Denver Sun Nov 4 08:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 MST isdst=0 | America/Denver Sun Mar 9 08:59:59 2008 UTC = Sun Mar 9 01:59:59 2008 MST isdst=0 | America/Denver Sun Mar 9 09:00:00 2008 UTC = Sun Mar 9 03:00:00 2008 MDT isdst=1 | America/Denver Sun Nov 2 07:59:59 2008 UTC = Sun Nov 2 01:59:59 2008 MDT isdst=1 | America/Denver Sun Nov 2 08:00:00 2008 UTC = Sun Nov 2 01:00:00 2008 MST isdst=0 | . | . | . ` (I had quoted Phoenix jsut because it is short and I could include the whole output) GM> On a 64-bit system, the last two entries in the above output are GM> replaced by the less enlightening: GM> America/Phoenix 9223372036854689407 = NULL GM> America/Phoenix 9223372036854775807 = NULL That would be a bug. [EMAIL PROTECTED] is the list discussing the package and would be a good place to report that bug. GM> Since I have a method that (I think) should work well on all platforms GM> in the style that the calendar currently uses, I'm tempted to install GM> the patch I already have, and file switching to this method as a TODO GM> item for some future date. Your plan has reason. (Now if I could just remember where that (almost-) quote is from ;-) -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 0xED7DAEA6 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: calendar gets wrong end for Daylight Savings Time
>>>>> "GM" == Glenn Morris <[EMAIL PROTECTED]> writes: GM> Extracting the information directly from the tz database (which must GM> contain it, in some format) would require less CPU, but more of my CPU GM> to figure out how to do it (especially in a system-portable way). zdump(8) gives a textual dump of a given timezone when passed the -v flag. If that is available on all platforms it should do. As an example, this is what it outputs for America/Phoenix: , | :; zdump -v America/Phoenix | America/Phoenix Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 13:45:52 1901 MST isdst=0 | America/Phoenix Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 13:45:52 1901 MST isdst=0 | America/Phoenix Sun Mar 31 08:59:59 1918 UTC = Sun Mar 31 01:59:59 1918 MST isdst=0 | America/Phoenix Sun Mar 31 09:00:00 1918 UTC = Sun Mar 31 03:00:00 1918 MDT isdst=1 | America/Phoenix Sun Oct 27 07:59:59 1918 UTC = Sun Oct 27 01:59:59 1918 MDT isdst=1 | America/Phoenix Sun Oct 27 08:00:00 1918 UTC = Sun Oct 27 01:00:00 1918 MST isdst=0 | America/Phoenix Sun Mar 30 08:59:59 1919 UTC = Sun Mar 30 01:59:59 1919 MST isdst=0 | America/Phoenix Sun Mar 30 09:00:00 1919 UTC = Sun Mar 30 03:00:00 1919 MDT isdst=1 | America/Phoenix Sun Oct 26 07:59:59 1919 UTC = Sun Oct 26 01:59:59 1919 MDT isdst=1 | America/Phoenix Sun Oct 26 08:00:00 1919 UTC = Sun Oct 26 01:00:00 1919 MST isdst=0 | America/Phoenix Mon Feb 9 08:59:59 1942 UTC = Mon Feb 9 01:59:59 1942 MST isdst=0 | America/Phoenix Mon Feb 9 09:00:00 1942 UTC = Mon Feb 9 03:00:00 1942 MWT isdst=1 | America/Phoenix Sat Jan 1 06:00:59 1944 UTC = Sat Jan 1 00:00:59 1944 MWT isdst=1 | America/Phoenix Sat Jan 1 06:01:00 1944 UTC = Fri Dec 31 23:01:00 1943 MST isdst=0 | America/Phoenix Sat Apr 1 07:00:59 1944 UTC = Sat Apr 1 00:00:59 1944 MST isdst=0 | America/Phoenix Sat Apr 1 07:01:00 1944 UTC = Sat Apr 1 01:01:00 1944 MWT isdst=1 | America/Phoenix Sun Oct 1 06:00:59 1944 UTC = Sun Oct 1 00:00:59 1944 MWT isdst=1 | America/Phoenix Sun Oct 1 06:01:00 1944 UTC = Sat Sep 30 23:01:00 1944 MST isdst=0 | America/Phoenix Sun Apr 30 08:59:59 1967 UTC = Sun Apr 30 01:59:59 1967 MST isdst=0 | America/Phoenix Sun Apr 30 09:00:00 1967 UTC = Sun Apr 30 03:00:00 1967 MDT isdst=1 | America/Phoenix Sun Oct 29 07:59:59 1967 UTC = Sun Oct 29 01:59:59 1967 MDT isdst=1 | America/Phoenix Sun Oct 29 08:00:00 1967 UTC = Sun Oct 29 01:00:00 1967 MST isdst=0 | America/Phoenix Mon Jan 18 03:14:07 2038 UTC = Sun Jan 17 20:14:07 2038 MST isdst=0 | America/Phoenix Tue Jan 19 03:14:07 2038 UTC = Mon Jan 18 20:14:07 2038 MST isdst=0 ` -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 0xED7DAEA6 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2: #xFF01 .. #xFF60 should be set double width in char-width-table
>>>>> "Kenichi" == Kenichi Handa <[EMAIL PROTECTED]> writes: Kenichi> They are ambiguous according to EastAsianWidth.txt of Kenichi> Unicode. I think the right thing is to set them to the Kenichi> symbol `ambiguous', and make display routine (and column Kenichi> calculation routine) to resolve it to 1 or 2 by checking a Kenichi> font (or a capability of terminal). In a case that such Kenichi> information is not available, perhaps, we should resolve Kenichi> according to the current locale. Does the current locale influence the current font? Modulus that issue I agree that the above is exactly what any app ought to do with the ambiguous-width chars. (Another related -- and I presume mostly theoretical -- question is what should be done when such a character is part of a combining or variation sequence) -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 0xED7DAEA6 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: calendar gets wrong end for Daylight Savings Time
>>>>> "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes: Richard> It seems that the Emacs calendar should have a data base of Richard> history of daylight savings time for various named regions. Richard> But maybe that is too much work to be feasible. tzdata¹, used by glibc and others, does exactly this. And most of the linux and bsd -based dists have unbundled it from the libc packages to make it easier to keep up to date. (As an example, in Gentoo it is called sys-libs/timezone-data.) The zonefiles have full historical data for each zone, and the api should allow access to that data. Ie, tzdata's zonefiles will not have waited until the first Sunday in November to turn off DST in the US this year, but will use the new dates starting in 2007. -JimC 1) The primary distribution site is: ftp://elsie.nci.nih.gov/pub/ and they are updated regularly whenever changes are made by the various jurisdictions. I believe 2006n is the current version. -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 0xED7DAEA6 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File names with accented Latin characters are not displayed correctly
> "Miles" == Miles Bader <[EMAIL PROTECTED]> writes: Miles> If you're using the CVS emacs-unicode-2 branch, you will get Miles> the same thing because that CVS branch is updated via my arch Miles> branch. Is there a list that tracks changes applied to either the emacs-unicode-2 branch in CVS or the corresponding arch branch, ala emacs-commit@gnu.org for CVS HEAD? -JimC -- James H. Cloos, Jr. <[EMAIL PROTECTED]> ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: woman case sensitive
> "Roland" == Roland Winkler <[EMAIL PROTECTED]> writes: Roland> I have no idea what is causing this inconsistent behavior. Roland> (I wish that at least emacs would give me a consistent Roland> behavior on different platforms.) There are two competing implementations of man(1) in use on Linux based systems. I'm not sure whether one of those two is also used on (any of) the BSDs. The two each have a page at freshmeat: http://freshmeat.net/projects/man http://freshmeat.net/projects/man-db Debian (currently, at least) uses the latter, which does do case-insensitive searches. It also can use db files to store the indices for improved search speed. Gentoo and my old rh 7.3 uml have the former. -JimC -- James H. Cloos, Jr. <[EMAIL PROTECTED]> ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: adding sender
> "fouvry" == Frederik Fouvry <[EMAIL PROTECTED]> writes: fouvry> but given that RFC 2822 specifies that fouvry> it MUST (RFC capitalisation) be added when From does not fouvry> contain only the local user/user's mailbox, it seems to me fouvry> that it is sensible to try to add it as early as possible. For many reasons it is best to ignore Sender. It serves no value and screws things up when you need to communicate with people who use certains brain-dead MUAs. (Yes, this is a bug with those stupid (and closed source of course) MUAs, but they are prevalent and Sender does not provide any benefit to anyone, so it is just *easier* -- and completely safe -- to forget it entirely.) -JimC -- James H. Cloos, Jr. <[EMAIL PROTECTED]> ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: iconify-frame and make-frame-visible messages in echo area
> "Stephen" == Stephen Berman <[EMAIL PROTECTED]> writes: >>> (make-frame-visible (# *scratch* 0x570a00> )) >>> [...] Stephen> The messages were indeed caused by an external package loaded Stephen> in my init-file (php-mode from sourceforge FWIW). I've also been getting these messages for several months. I don't see anything in php-mode.el itself that is relevant to this, but it does require some other packages. A quick test shows that a (require 'speedbar) causes the messages to start. I have a version of speedbar in site-lisp (from gentoo's app-emacs/ speedbar ebuild; the ebuild refs http://cedet.sourceforge.net/speedbar.shtml). The version of speedbar that comes with 22.0.50 does not cause the message. -JimC -- James H. Cloos, Jr. <[EMAIL PROTECTED]> ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
