>>>>> David Kastrup <dak(a)gnu.org> writes:
David> Let's not forget that this has taken _XEmacs_ developers two
David> years. So it seems complicated enough
David> [...]
I'm afraid that lead times in hobby projects don't say much about
whether things are complicated or not. Sometimes, always!?, the
complicated and interesting stuff gets solved long before the boring
maintenance jobs. This is a maintenance job.
David> [...]
David> I mean, it is nice that something is happening after all, but it is
David> clearly lunatic to claim that it somehow has been my fault for not
David> seeing how simple everything is under XEmacs and solving this with a
David> limp shake of a wrist.
I'm sorry if you take it that way. It was not my intention to imply
anything about you. I just felt that your list of obstacles was way to
long to describe the problem.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Pete> Colors are set by a command line option to ipython. I used
Pete> customize to set `py-python-command-args':
Pete> Value: ("-pylab" "-colors" "LightBG")
Pete> I think that the options for -colors are NoColor, Linux, and LightBG.
My last input on this (maybe this is mostly for the XEmacs folks and
Alexander Schmolck - author of ipython.el - but I don't have an email for
him handy). I looked at the color-option-setting code in ipython.el and
found this:
(setq py-python-command-args
(nconc py-python-command-args
(list "-colors"
(cond
((eq frame-background-mode 'dark)
"Linux")
((eq frame-background-mode 'light)
"LightBG")
(t ; default (backg-mode isn't always set by XEmacs)
"LightBG"))))))
Then I ran "xemacs -rv" and evaluated frame-background-mode. It was still
'light. I don't know what the right variable to test is, but on XEmacs it
doesn't appear that the -rv command line flag causes frame-background-mode
to be set differently (this is in 21.5b28).
Skip
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Hi all,
set out to fix a bug occuring in all Emacsen, reported at
http://tracker.xemacs.org/XEmacs/its/issue232
I wrote an alternative comment.el, as announced
already. It's designed to be more simple.
The bug of `indent-new-comment-line' should be gone
with the following:
(global-set-key [(meta j)] 'comment-indent-new-line-lor)
After evaluating both files, M-x `comment-all-test-lor'
will let you watch some tests with dummy textes.
Comment.el should not disturb newcomment.el; it's
suffix `-lor' means `line-or-region':
- If no active region exists, it operates from current line.
Other main diffs to newcomment.el are:
- Styles will not be chosen by customization, but
called with respective functions. Thus you may insert
indented, plain, boxed or multiline comments without
hesitation.
- If a style offers more than one comment
end-start-set, as "//" or "/* */" in C, it's up to
the mode to deliver the callers, which have to set
starts and ends. (That remains to do in the modes.)
- No use of syntax-tables.
- Deliberate limited use of regexps.
- Check if a comment-char is found inside a string no
longer relies on fontifying.
Suggestions welcome.
Andreas Röhler
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
I'm having trouble figuring out what face is used to render a particular bit
of text. See the attached PNG. I'm particularly interested in the
hard-to-read green text. (This was clipped from an ipython comint buffer.)
Given a random bit of text is there some way to determine the face used to
render it?
Thanks,
Skip
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Giacomo> have you tried to pass to embedded ipython the switch "-colors
Giacomo> LightBG"?
Nope. I'm not actually much of an ipython user. I was just trying to help
out a colleague who is. I'll suggest that to him.
Thanks,
Skip
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Aidan Kehoe writes:
> 2008-01-21 Aidan Kehoe <kehoea(a)parhasard.net>
>
> * info.el (Info-suffix-list):
> Support LZMA compression, as used--oddly--by Mandriva Linux.
In many cases it can give up to 20% better compression than bzip2, I
hear. That's not odd, that's way cool!
True, the software is as yet unproved in the way that bzip2 and gzip
are, but still, for Info files that is hardly a big deal.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
>>>>> "Reiner" == Reiner Steib <reinersteib+gmane(a)imap.cc> writes:
Reiner> I suppose this is this patch?
Reiner> 2004-01-27 Jerry James <james(a)xemacs.org> (tiny change)
Reiner> * gnus-spec.el (gnus-parse-simple-format): Fix setq value
Reiner> omission.
Right (sorry for not providing a more precise reference).
Reiner> Hm, (setq dontinsert) is the same as (setq dontinsert nil) in
Reiner> Emacs. OTOH, setting dontinsert to nil is a no-op here.
Hmm. I didn't try to verify correctness, so I can't comment on what the
right value should be.
MikeK> I don't see this one, either. I don't know if Aidan has approached
MikeK> someone on the Gnus team about it yet.
Reiner> No. In the form discussed in
Reiner> <http://thread.gmane.org/gmane.emacs.xemacs.patches/8878> it's
Reiner> not suitable for inclusion since it would break on Emacs.
Okay. I don't have time to pursue this right now, but I've added a note
to myself about it. Or maybe Aidan will get to it first.
MikeK> I didn't look in CVS, but Katsumi Yamaoka said the third patch (or
MikeK> something equivalent) is in the v5-10 branch (see
MikeK> http://calypso.tux.org/pipermail/xemacs-patches/2008-March/001531.html).
Reiner> I don't know how you solved the problem in XEmacs, but I'd
Reiner> suggest to check if you can use Katsumi Yamaoka's approach
Reiner> instead of a different one.
Yes, I'm planning to look into that when I do update to 5.10.10. (My
goal for all the packages I maintain is zero local patches.)
MikeK> Though I keep forgetting about that pesky issue of compatible GPL
MikeK> versions. That could delay things. :-(
Reiner> Didn't you (XEmacs) decide to switch to GPLv3 as well? I seem
Reiner> to recall Steven wrote something like this recently.
I've seen discussion of it, but I'll have to let Stephen explain what
the current status is.
Reiner> On a second thought, if you only sync with upstream releases, we
Reiner> don't really need xemacs-pkg-* tags because it would be the same
Reiner> as the v5-10-* release tag.
Okay. If for some reason I need to sync with a non-release snapshot,
I'll mail ding to work out getting it tagged appropriately.
cheers,
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
>>>>> "Reiner" == Reiner Steib <reinersteib+gmane(a)imap.cc> writes:
Reiner> Please accept my apologies for getting it all wrong.
You're forgiven. :-) Thanks for all your work on Gnus!
Reiner> Are the patches you mention already integrated upstream in the
Reiner> v5-10 branch?
Ah, good question. It doesn't look like this one is:
2007-03-05 Mike Kupfer <mike.kupfer(a)xemacs.org>
* lisp/gnus-spec.el (gnus-parse-simple-format): Add required 2nd
argument to (setq dontinsert), using the fix from the HEAD
branch at gnus.org.
I don't see this one, either. I don't know if Aidan has approached
someone on the Gnus team about it yet.
2007-12-24 Aidan Kehoe <kehoea(a)parhasard.net>
* lisp/gnus-sum.el:
* lisp/gnus-sum.el (put-display-table): New.
* lisp/gnus-sum.el (get-display-table): New.
Provide with #'defun-when-void, so as to not override the 21.5
implementation.
* lisp/gnus-sum.el (gnus-summary-set-display-table):
* lisp/gnus-xmas.el (gnus-xmas-summary-set-display-table):
Use #'put-display-table, not #'aref, to deal with the case where
the display table is a char table and not a vector.
I didn't look in CVS, but Katsumi Yamaoka said the third patch (or
something equivalent) is in the v5-10 branch (see
http://calypso.tux.org/pipermail/xemacs-patches/2008-March/001531.html).
MikeK> When 5.10.10 is released, I'll start work to update the XEmacs
MikeK> package.
Reiner> Thank you.
My pleasure. Though I keep forgetting about that pesky issue of
compatible GPL versions. That could delay things. :-(
Reiner> So the answer to your question [1] is "yes".
Okay, great! I guess this means I ought to get on the ding list.
http://gnus.org/distribution.html says I should mail Lars to get write
access to CVS; is that still the right thing for me to do?
Reiner> E.g. announcing the availability of new Gnus XEmacs
Reiner> (pre-release) package on ding and/or gnu.emacs.gnus is fine with
Reiner> me.
Good to know; thanks.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta