ACTIVITY SUMMARY (2013-01-15 - 2013-01-22)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
553 open ( +0) / 294 closed ( +0) / 847 total ( +0)
Open issues with patches: 13
Average duration of open issues: 1342 days.
Median duration of open issues: 1425 days.
Open Issues Breakdown
new 233 ( +0)
deferred 6 ( +0)
napping 3 ( +0)
verified 57 ( +0)
assigned 153 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 17 ( +0)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Dieter Maurer wrote at 2013-1-13 11:10 +0100:
>================================================================
>Dear Bug Team!
>
>
>I have found a bug in the XEmacs package "vm":
>
>RFC 2047 requires in its section 5 that "encoded-words"
>must be separated from ordinary text by linear white space
>but "vm" fails to do so.
>
>The bug in in function "vm-mime-encode-words" (from "vm-mime.el").
>It can be reproduced by a call to "vm-mime-encode-words-in-string"
>(which internally calls "vm-mime-encode-words"). Example:
>
> (vm-mime-encode-words-in-string "aÄoö")
>---> "aÄoö"
>
>The correct result would be:
>
> "aÄoö"
This bug seems to be fixed in the "vm" trunk version
("http://bazaar.launchpad.net/~vm/vm/trunk/view/head:/lisp/vm-mime.el").
I have copied over "vm-mime-charset-to-coding" and
"vm-mime-encode-words" (from "vm-mime-el") and
"vm-mime-encode-headers-words-regexp" (from "vm-vars.el") into
my XEmacs installation and initial tests look promising.
--
Dieter
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
I greatly appreciate the suggestions people sent to help me get the
XEmacs 21.5 beta (horseradish) working on my new iMac after a long
absence from fiddling with such things. XEmacs is such a gigantic thing
that whenever I've moved to a new version it takes about a week for all
the pieces to stop rolling.
Most everything works fine, but it's not perfect. It's probably best for
me to address remaining issues one at a time.
My first questions have to do with configure options. This is where
things stand.
o I use a directory ~/xemacs to build and stage.
o Beneath that I extracted xemacs-21.5.33 and xemacs-packages (from the sumo).
- I know that xemacs-packages ultimately goes elsewhere. (See below.)
o I can build horseradish if I configure using --with-mule, but not if I
*don't* use --with-mule.
- Is this an error? (I think someone suggested it might be.)
- I don't actually use MULE (to my knowledge!) I've known about it
since its existence but paid little attention. That's all about
foreign character sets, right?
- Don't I need another bundle of elisp files to actually use that?
- I assume xemacs will continue to work without it, as long as I don't
try to do anything MULEish? (Like type in Japanese, which I would be
really hard, given that I wouldn't even know how to sneeze in
Japanese.)
o Someone (Raymond?) mentioned --with-xft. What's that? Do I need it?
I've read the configure --help and still can't answer that question. I
do have X11. Help says I also need Xft, Xrender, freetype, and
fontconfig. How do I know if I have those? Among my remaining problems
are inconsistencies with fonts and like.
o I was able to install with no problems using sudo make install. It put
stuff in /usr/local (in bin, lib, and share). (Yes, you veterans all
know this. I'm just reporting that it does what it's supposed to. I
have no desire to do anything unconventional at this stage. Bear with
me.)
o I unwound the packages sumo in /usr/local/share/xemacs, i.e., they're
all now in /usr/local/share/xemacs/xemacs-packages and directories
below. This seems to have been the right thing.
Other questions will follow.
--
Lynn David Newton
Columbus, Ohio
neologisticsediting.comlynndavidnewton.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
On Tue, Jan 15, 2013 at 8:44 PM, Jerry James <james(a)xemacs.org> wrote:
> I have been able to reproduce this, and am trying to figure out what
The problem is that if there is an error in a menu descriptor, we
don't recover from it gracefully. In this particular case, the ESS
code is using an Emacs menu cascade keyword that we don't support
(:visible), resulting in this backtrace:
#0 throw_or_bomb_out_unsafe (tag=..., val=val@entry=...,
bomb_out_p=bomb_out_p@entry=0, sig=..., data=...) at eval.c:1809
#1 0x00000000004a96f3 in throw_or_bomb_out (tag=..., val=...,
bomb_out_p=bomb_out_p@entry=0, sig=..., data=...) at eval.c:1865
#2 0x00000000004a975f in flagged_a_squirmer (error_conditions=..., data=...,
opaque=...) at eval.c:5749
#3 0x00000000004a354a in Fsignal (error_symbol=..., data=...) at eval.c:2489
#4 0x00000000004a5bdb in signal_error_1 (data=..., sig=...) at eval.c:2613
#5 signal_error (type=...,
reason=reason@entry=0x6599a6 "Unknown menu cascade keyword", frob=...)
at eval.c:2723
#6 0x00000000004a5d86 in invalid_argument (
reason=reason@entry=0x6599a6 "Unknown menu cascade keyword", frob=...,
frob@entry=...) at eval.c:3086
#7 0x00000000005fdd0d in menu_item_descriptor_to_widget_value_1 (desc=...,
menu_type=menu_type@entry=0, deep_p=deep_p@entry=0,
filter_p=filter_p@entry=0, depth=depth@entry=1) at menubar-x.c:196
#8 0x00000000005fd7aa in menu_item_descriptor_to_widget_value_1 (desc=...,
menu_type=<optimized out>, deep_p=0, filter_p=0, depth=25233120,
depth@entry=0) at menubar-x.c:303
#9 0x00000000005fdd5c in protected_menu_item_descriptor_to_widget_value_1 (
gack=0x7fffffff9c00) at menubar-x.c:351
#10 0x00000000004a08ef in call_trapping_problems_2 (opaque=...,
opaque@entry=...) at eval.c:5759
#11 0x00000000004a3cad in call_with_condition_handler (
handler=handler@entry=0x4a9720 <flagged_a_squirmer>, handler_arg=...,
fun=fun@entry=0x4a08e0 <call_trapping_problems_2>, arg=...) at eval.c:2327
#12 0x00000000004a3cf9 in call_trapping_problems_1 (opaque=...,
opaque@entry=...) at eval.c:5765
#13 0x00000000004a1e2c in internal_catch (tag=...,
func=func@entry=0x4a3ce0 <call_trapping_problems_1>, arg=...,
threw=threw@entry=0x7fffffff9a7c,
thrown_tag=thrown_tag@entry=0x7fffffff9a90,
backtrace_before_throw=backtrace_before_throw@entry=0x7fffffff9aa0)
at eval.c:1694
#14 0x00000000004a4766 in call_trapping_problems (warning_class=...,
warning_string=warning_string@entry=0x659808 "Error during menu
construction", flags=3, flags@entry=0, problem=problem@entry=0x0,
fun=fun@entry=0x5fdd30 <protected_menu_item_descriptor_to_widget_value_1>,
arg=arg@entry=0x7fffffff9c00) at eval.c:6038
#15 0x00000000005fd202 in menu_item_descriptor_to_widget_value (desc=...,
desc@entry=..., menu_type=menu_type@entry=0, deep_p=deep_p@entry=0,
filter_p=filter_p@entry=0) at menubar-x.c:412
#16 0x00000000005fe200 in compute_menubar_data (menubar=menubar@entry=...,
deep_p=deep_p@entry=0, f=0x1809c00) at menubar-x.c:531
#17 0x00000000005fe308 in set_frame_menubar (f=f@entry=0x1809c00,
deep_p=deep_p@entry=0, first_time_p=first_time_p@entry=0)
at menubar-x.c:575
We successfully catch the throw, but don't actually display the error
anywhere before we hit the assert in frame 17 and die. I think that
assert is wrong. A null return doesn't necessarily mean that the
XEmacs code itself has a bug, which is what an assert should be
checking. It can also mean that there is a bug in the menu
specification, and we should just refuse to show the menu and pop up
an error buffer to notify the user of the problem.
I wonder if it is as easy as changing this:
assert (data && (data->next || data->contents));
to:
if (!data || (!data->next && !data->contents))
return 0;
I'll try that later and see how it works out.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi there,
I notice that when I open a file with tramp,
e.g. /[ssh/somewhere]file.pl, it is marked as modified. The fix seems
simple by moving
(when visit
(set-buffer-modified-p nil))
to the end of tramp-handle-insert-file-contents. Wonder if that is some
problem with my config or someone else noticed it?
Cheers,
Nei
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
This is sweet. Having a break in my schedule, I've been devoting time
to looking once again at XEmacs with a view to bringing myself up to date
and cleaning out years of accumulated cruft.
So far things are going extremely well.
Re: MULE
>> - Don't I need another bundle of elisp files to actually use that?
> Grab the mule-sumo tarball from the same place you got the xemacs-sumo
> tarball. Extract in share/xemacs. You should end up with
> share/xemacs/mule-packages.
Got it. All is well again.
> Good question. I don't know, but since you can't build without mule, just
> grab the mule sumo and be done with it. Even though I'm basically
> illiterate, it is nice seeing things how other people literate people see
> it. Then I can maybe ask someone what it means. :-)
Ha! Ahem. Well, I have it now, so if I ever need it, it's there.
>> o Someone (Raymond?) mentioned --with-xft. What's that? Do I need it?
> That enables nice font rendering. It's not necessary, but does make the
> display nicer. (I notice that it really sucks if you run xemacs
> remotely.[1])
> I don't think all those extra things (Xft, freetype, fontconfig) come with
> XQuartz or OSX. I had to install them from MacPorts (or use Fink).
I have macports, did not explicitly install Xft, freetype, or
fontconfig. In fact
I've used it to install very little -- just a few things I really like and need.
So as an experiment I rebuilt xemacs using --with-mule and --with-xft, and
got no errors at all. Well and good.
I do still have some display problems, but those are the subject of an
upcoming query.
> I assume that xemacs is working out pretty well for you now.
Well enough that I've officially abandoned xemacs 21.4.whatever-it-was,
never to return. I'm an extremely pleased camper this morning.
> [1] I used to be be able to run xemacs (not tty!) over a dialup modem pretty
> well if I turned off the toolbar, menubar, and scrollbars. I can't do that
> very well anymore even over a cable modem nowadays. Bummer. Turning xft
> off helps a lot, but not really very usable. Thankfully, there's tramp.
I no longer have need ever to run it remotely, in tty mode or otherwise. I'm
semi-retired (which means I still work full time but for a whole lot
less money),
and all my work is within the confines of my home.
I'm pleased with the progress, but there's still more to follow.
--
Lynn David Newton
Columbus, Ohio
neologisticsediting.comlynndavidnewton.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Now that even desktop computers are routinely suspended to RAM, I'm
increasingly bitten by the sad fact that Linux sleep(2) and friends
appear to treat "real time" as "machine running time" instead of
"physical time".
I presume this also affects XEmacs?
Where would be the right place to address this? (For example,
something like checking the time every timeout-granularity seconds to
see if it's changed and timeouts need to happen.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hello
Using Xemacs 21.5.32 Mule
with
(setq default-process-coding-system '(utf-8))
(set-coding-priority-list '(utf-8))
(set-coding-category-system 'utf-8 'utf-8)
(setq default-network-coding-system '(utf-8 . utf-8))
From time to time, my latex files, which I use with x-symbol-mode and
are under rcs version control, get their coding screwed up, like
$[0,2?]$.
Instead of $[0,2 \pi]$
What could be the reason and how can I avoid it?
thanks
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hello
I am re sending this mail, since my previous one was smime signed and I
have the feeling it did not pass the filter:
Using Xemacs 21.5.32 Mule
with
(setq default-process-coding-system '(utf-8))
(set-coding-priority-list '(utf-8))
(set-coding-category-system 'utf-8 'utf-8)
(setq default-network-coding-system '(utf-8 . utf-8))
>From time to time, my latex files, which I use with x-symbol-mode and
are under rcs version control, get their coding screwed up, like
$[0,2?]$.
Instead of $[0,2 \pi]$
What could be the reason and how can I avoid it?
thanks
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta