Eli Zaretskii wrote:
I would assume that M-x calendar must use the database directly to
find out _when_ DST starts and ends to print the calendar correctly.
It can do that, but it doesn't have to: it could alternatively pass
the corresponding time_t value to the time routines and get the DST
Here's a patch that works in the manner I have tried to describe. It
works with no noticeable slow-down on my (admittedly, fairly new)
machine. I can install if desired.
*** cal-dst.el 07 Feb 2006 23:46:47 -0800 1.24
--- cal-dst.el 09 Nov 2006 01:37:31 -0800
***
***
In article [EMAIL PROTECTED], James Cloos [EMAIL PROTECTED] writes:
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
In article [EMAIL PROTECTED], Zhang Wei [EMAIL PROTECTED] writes:
Kenichi Handa [EMAIL PROTECTED] writes:
! (modify-category-entry elt ?\|)))
This is questionable. At least, shouldn't we exclude Hangul?
I don't konw korean, does Hangul has a different char break rule?
Try C-u C-h
In article [EMAIL PROTECTED], Tim Van Holder [EMAIL PROTECTED] writes:
With -g I get
(gdb) up
#1 0x0818c7ec in read_process_output (proc=142856980, channel=5) at
/home/tim/gnu/src/emacs/src/process.c:5144
5144 bcopy (chars + coding-consumed, SDATA (p-decoding_buf),
(gdb) info
I noticed the following bug after I installed the latest CVS emacs
today.
Start a fresh emacs --unibyte --no-init-file
Execute toggle-debug-on-error
Load a simple text file like
cat foo EOF
foo bar baz
EOF
On the command line execute touch foo.
Revert buffer foo.
This gives me the backtrace
Christoph Conrad [EMAIL PROTECTED] writes:
when linking temacs:
xmenu.o: In function `Fmenu_or_popup_active_p':
/var/local/cc/news/emacs/src/xmenu.c:3773: undefined reference to
`popup_activated'
collect2: ld returned 1 exit status
Is this the most recent checkout of CVS Emacs? I think
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
From: Glenn Morris [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED] (Kim F. Storm), [EMAIL PROTECTED],
emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
Date: Thu, 09 Nov 2006 03:46:51 -0500
Am I totally missing the point here? The question to be answered is:
what day of the year does Daylight
From: Glenn Morris [EMAIL PROTECTED]
Date: Thu, 09 Nov 2006 14:25:02 -0500
Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, Kim F. Storm [EMAIL
PROTECTED],
[EMAIL PROTECTED]
Oh thanks, I did not know about zdump. Can anyone confirm if
it/something equivalent exists on Windows?
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,
Eli Zaretskii wrote:
In C, you pass probe time_t values to the function localtime, until
you find the value for which the tm_isdst flag in the struct tm
returned by localtime changes from 0 to 1 or vice versa.
In Lisp, we will need some Lisp binding to localtime or its sibling
functions, to
Eli Zaretskii wrote:
No, Windows doesn't support Posix timezoneinfo data bases. It has its
own information in the Registry, which is usually (maybe always) only
for the current year.
Thanks. I'm not surprised it's different...
I guess, if Emacs needs the timezone database, we could
James Cloos wrote:
As you can see from that output America/Phoenix has not done daylight
time since 1944 (US wartime national Mandate).
Ah, thank you again for enlightenment!
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
When debug-on-error is enabled and an error occurs, a backtrace is generated.
Clicking on a function in the stack opens a buffer with the cursor at the start
of the function. It would be more useful to place the cursor at the point
of execution within that function.
--
Nick
On Nov 8, 2006, Reiner Steib [EMAIL PROTECTED] wrote:
On Tue, Nov 07 2006, Reiner Steib wrote:
Alexandre and Elias: Does this patch give good results?
Please consider this patch instead:
Thanks for the patch. It works, but it doesn't.
It works in that it does speed up entering in new
So we should simply tell whichever programs look for EMACS=t to change?
I think that is the right thing to do.
Another possibility is to switch to a different envvar name, but I
think that would make an even bigger transient.
___
On Fri Nov 10 2006 Kenichi Handa wrote:
I noticed the following bug after I installed the latest CVS emacs
today.
Thank you for the report. I've just installed a fix.
Thank you. I tested it, and now it works fine for me.
Roland
___
In article [EMAIL PROTECTED], Tim Van Holder [EMAIL PROTECTED] writes:
[...]
p-decoding_carryover and p-encoding_carryover are both 0.
I added some printfs ro read_process_output, in case they're of any help:
[...]
** (coding.c:6365) decode_coding_string() set coding-consumed to 0
**
On 11/10/06, Kenichi Handa [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED], Tim Van Holder [EMAIL PROTECTED] writes:
[...]
p-decoding_carryover and p-encoding_carryover are both 0.
I added some printfs ro read_process_output, in case they're of any help:
[...]
** (coding.c:6365)
20 matches
Mail list logo
