el-rcfiles v1.0
10 years, 11 months
Didier Verna
Didier Verna
Hello,
I've been using this for years, but never got to make it public until
recently. It's a very small and simple library for providing Unix-like
rc files to Emacs Lisp libraries.
All the details are here:
http://www.lrde.epita.fr/~didier/software/elisp/#el-rcfiles
and this is the commentary section, for quick reference:
;;; Commentary:
;; The purpose of el-rcfiles is to provide the equivalent of traditional
;; Unix rc files (i.e. configuration files) for Emacs Lisp
;; libraries. The advantages of using configuration files are the
;; following:
;; - your initialization file is less bloated,
;; - since configuration files are lazily loaded, your Emacs session
;; is (or begins) lighter. That is unless you already use lots of
;; EVAL-AFTER-LOAD forms...
;; Usage:
;; 1. Load the library, go to the rcfiles Custom group and tweak (or not).
;; 2. Put a call to (rcfiles-register-rc-files) in your initialization
;; file. This function can also be called interactively anytime you
;; add, remove or modify a configuration file.
;; 3. Put your configuration code for a library `foo' in a file called
;; `<rcfiles-directory>/foo<rcfiles-pseudo-extension>.el'.
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 3 participants
- 6 comments
Spate of old mail + about HTML mail
10 years, 11 months
Stephen J. Turnbull
Stephen J. Turnbull
Hi,
I'm sorry about the spate of old mail just issued, mostly on this list
but also affecting xemacs-patches at least. I hadn't looked at the
spamtraps for a *very* long time. I'll try to be better in the
future.
Most of the affected posts were HTML mail. If people really can't
help sending HTML, let me know, and I'll see about changing the ML
configs to pass it. But for now, at least, sending HTML mail is
likely to cause your post to not appear, at least for a while.
Also, I don't really want to disable that filter, because it catches
about a hundred spams a day. I will if it's really inconvenient for
people to disable HTML mail, so let me know.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 2 participants
- 1 comments
Re: patch against leim-list.el coding
10 years, 11 months
Stephen J. Turnbull
Stephen J. Turnbull
Uwe Brauer writes:
> >> "Stephen" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
> >>
> >> I sent them to xemacs-patches(a)xemacs.org
>
> > Your <oub(a)mat.ucm.es> address is not subscribed to xemacs-patches, so
> > they get held for moderation.
>
>
> Oops. I did this now and will resend the patches.
Don't resend, I released the HOLD so they've already been sent (and
received). (You probably figured that out already, but just in case. :-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 2 participants
- 1 comments
[issue] Representing nonterminating binary float results
10 years, 11 months
Stephen J. Turnbull
Stephen J. Turnbull
Hey, what a great idea! We should do this too. :-)
I believe that the Python license is sufficient flexible that we can
Steal This Code! if anybody wants to work on it.
P.S. If I set up the subject correctly, this should appear on the
tracker shortly.
Nick Coghlan writes:
> On 2 December 2013 11:45, Mark Lawrence <breamoreboy(a)yahoo.co.uk> wrote:
> > The newbie says it should be 4.5 but gets 4.499999999999999999999 so raises
> > issue on bug tracker stating that Python can't do arithmetic properly.
> >
> > In [5]: 9/2
> > Out[5]: 4.5
> >
> > Blast, lousy example :)
>
> Getting a modern Python to fall into that trap at all is actually
> quite difficult - the way str.__repr__ works was changed a while ago
> to favour the nearest terminating approximation that is represented
> using the same IEEE754 bit pattern :)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 3 participants
- 2 comments
Re: patch against leim-list.el coding
10 years, 11 months
Aidan Kehoe
Aidan Kehoe
Ar an chéad lá de mí na Nollaig, scríobh Uwe Brauer:
> Hm, when I open my hebrew.el file, which contains niqqud and was saved
> in iso-2022-jp, I can see the niqqud without any problem.
I imagine they’ll fail on XEmacs 21.4.
> In any case, I have sent the file in 2 encodings UTF8 and
> iso-2022-jp. So please chose the file which is best suited.
If you meant to attach them to that email, they didn’t arrive!
--
‘Liston operated so fast that he once accidentally amputated an assistant’s
fingers along with a patient’s leg, […] The patient and the assistant both
died of sepsis, and a spectator reportedly died of shock, resulting in the
only known procedure with a 300% mortality.’ (Atul Gawande, NEJM, 2012)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 1 participants
- 0 comments
patch against leim-list.el coding
10 years, 11 months
Uwe Brauer
Uwe Brauer
Hello
Sorry to repeat the question.
I finished a modified leim-list.el which contains the new hebrew input
method.
However I am unsure about the coding. Should I save the new leim-list.el
in iso-2022 or utf8. I am asking because I have to provide a patch and
do not want to screw up the encoding with the patch.
The original coding is described as
Coding system for saving this buffer:
CText -- ctext-unix
is this correct?
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 3 participants
- 5 comments
Re: [Bug: 21.5-b34] Hang with gnuserv on Mavericks
10 years, 11 months
Aidan Kehoe
Aidan Kehoe
Ar an chéad lá de mí na Nollaig, scríobh Stephen J. Turnbull:
> Aidan Kehoe writes:
>
> > Attaching with lldb I see that XEmacs is waiting in
> > XtAppProcessEvent, as it should;
>
> Are you sure it is "as it should"? In particular, the bug I reported
> (described in http://tracker.xemacs.org/issue565,
> http://trac.macports.org/ticket/18491, and
> https://bugs.freedesktop.org/show_bug.cgi?format=multiple&id=20048)
> was never fixed properly, although it seems they did apply my patch
> "Patch to prevent reentering...". The symptom I had was an infloop in
> _XtWaitForSomething, which is fixed by that patch. But maybe the real
> bug also affects something else in XtAppPending.
It *may* be inflooping, now you mention it. We were seeing XEmacs taking 94%
of the CPU at random, but more often without -vanilla. At that point lldb
wasn’t working for me because I wasn’t in the admin group, so I couldn’t
work out exactly where it was.
Jeremy Huddleston, in that bug, says he backed out your patch in March 2012.
It might well be that this is the first Apple X11 release I’ve seen since
that was done.
> > when I call p Feval (Fcar (Fread_from_string (build_ascstring
> > ("(gnuserv-start)"), Qnil, Qnil))) within lldb, gnuserv restarts and the
> > screen TTY becomes reactive again.
>
> Is the original gnuserv process dead at that point, or does restarting
> gnuserv kill it? Is screen itself dead, or just the XEmacs screen?
Restarting gnuserv kills it. Screen is not dead, rather the XEmacs process
running within it is not responsive, neither to TTY input via screen, nor to
GNUserv input, until I execute the above code within the debugger. The
XEmacs within the TTY wakes up immediately when i do that.
I’ll rebuild without X11 support (my big project at the moment is editing an
OCRed scan of a Persian-English dictionary, so the TTY is where I’m spending
most of my time) and see if it goes away, which is what your bug suggests it
should do.
--
‘Liston operated so fast that he once accidentally amputated an assistant’s
fingers along with a patient’s leg, […] The patient and the assistant both
died of sepsis, and a spectator reportedly died of shock, resulting in the
only known procedure with a 300% mortality.’ (Atul Gawande, NEJM, 2012)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 1 participants
- 0 comments