XEmacs Packages have been pre-released (2013-01-27-21)
11 years, 2 months
Norbert Koch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey there everyone.
I have just added the following packages to the 'Pre-Releases'
directory:
New Packages in Pre-Release:
===========================
cc-mode-1.60-pkg.tar.gz upstream version: 5.32.2
ediff-1.82-pkg.tar.gz upstream version: 2.75
pcl-cvs-1.71-pkg.tar.gz upstream version: R-2_9_9
tramp-1.41-pkg.tar.gz upstream version: 2.2.7-pre
Previously Announced Packages Still in Pre-Release:
==================================================
Sun-1.17-pkg.tar.gz upstream version: none
ede-1.04-pkg.tar.gz upstream version: 1.0pre4
eudc-1.41-pkg.tar.gz upstream version: 1.32
games-1.21-pkg.tar.gz upstream version: 2.00
gnus-1.95-pkg.tar.gz upstream version: 5.10.10
hyperbole-1.18-pkg.tar.gz upstream version: 5.0.3
leim-1.33-pkg.tar.gz upstream version: none
mh-e-1.33-pkg.tar.gz upstream version: 7.4.2
mmm-mode-1.06-pkg.tar.gz upstream version: 0.4.8
net-utils-1.57-pkg.tar.gz upstream version: N/A
pgg-1.08-pkg.tar.gz upstream version: 0.1
ruby-modes-1.05-pkg.tar.gz upstream version: 1.8.7
speedbar-1.30-pkg.tar.gz upstream version: 1.0pre4
text-modes-2.01-pkg.tar.gz upstream version: none
w3-1.38-pkg.tar.gz upstream version: 4.0pre47
x-symbol-1.13-pkg.tar.gz upstream version: 4.5.1
xemacs-base-2.32-pkg.tar.gz upstream version: none
xemacs-devel-1.82-pkg.tar.gz upstream version: none
Detailed Changes:
================
- ------- ChangeLog Entries from xemacs-packages/cc-mode/ChangeLog -------
2013-01-27 Norbert Koch <viteno(a)xemacs.org>
* Makefile (VERSION): XEmacs package 1.60 released.
- ------- ChangeLog Entries from xemacs-packages/ediff/ChangeLog -------
2013-01-27 Norbert Koch <viteno(a)xemacs.org>
* Makefile (VERSION): XEmacs package 1.82 released.
2013-01-21 Vin Shelton <acs(a)xemacs.org>
* Makefile (REQUIRES): New tramp update requires sh-script.
- ------- ChangeLog Entries from xemacs-packages/pcl-cvs/ChangeLog -------
2013-01-27 Norbert Koch <viteno(a)xemacs.org>
* Makefile (VERSION): XEmacs package 1.71 released.
2013-01-21 Vin Shelton <acs(a)xemacs.org>
* Makefile (REQUIRES): New tramp update requires sh-script.
- ------- ChangeLog Entries from xemacs-packages/tramp/ChangeLog -------
2013-01-27 Norbert Koch <viteno(a)xemacs.org>
* Makefile (VERSION): XEmacs package 1.41 released.
2013-01-23 Michael Albinus <michael.albinus(a)gmx.de>
* lisp/tramp-loaddefs.el: Remove entries for tramp-ftp, tramp-gvfs
and tramp-gw.
2013-01-22 Michael Albinus <michael.albinus(a)gmx.de>
* Makefile (ELCS): Remove lisp/tramp-ftp.elc
lisp/tramp-gw.elc lisp/tramp-loaddefs.elc.
* lisp/Makefile:
* lisp/tramp-ftp.el:
* lisp/tramp-gvfs.el:
* lisp/tramp-gw.el: Remove files from repository. They are not
needed for XEmacs.
2013-01-21 Michael Albinus <michael.albinus(a)gmx.de>
* Makefile (ELCS): Remove lisp/tramp-gvfs.elc.
2013-01-15 Michael Albinus <michael.albinus(a)gmx.de>
Sync with Tramp 2.2 upstream.
* Makefile (AUTHOR_VERSION): Bump to 2.2.7.pre.
(MAINTAINER): Change to Michael Albinus.
(ELCS): Adapt list to Tramp 2.2 structure.
(EXPLICIT_DOCS): Remove tramp_ja.texi.
Installing These:
================
Manually:
- --------
1) Download the packages that you want to install from:
/ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/
2) Unpack them to: [1]
/usr/local/lib/xemacs/xemacs-packages/
3) Re-start XEmacs.
Using XEmacs Package Tools (XEmacs 21.[245].x):
- ----------------------------------------------
1) Tools -> Packages -> Add Download Site -> Pre-Releases
2) Tools -> Packages -> List and Install
3) Select the packages you wish to install (there are brief
instructions at the bottom of the packages buffer).
4) Packages -> Install/Remove Selected
5) Re-start XEmacs.
Using XEmacs Package Tools (XEmacs 21.1.14):
- -------------------------------------------
1) Options -> Manage Packages -> Add Download Site -> Pre-Releases
2) Options -> Manage Packages -> List and Install
3 - 5) As per XEmacs 21.[245].x.
Footnotes:
[1] Note: Mule packages should be installed into:
/usr/local/lib/xemacs/mule-packages/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFRBZsJ7yJLt8ORD7cRAsMyAJ44h74Km2LvgtOCSVMsj7px7dU5ZACfX9+W
u4GtcD3XB0+filqD7kzkEmU=
=STe3
-----END PGP SIGNATURE-----
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
compiling init.el
11 years, 2 months
Lynn David Newton
What is the general opinion about byte-compiling init.el? Do most people do it?
Not do it?
My general policy is to byte compile it, but I'll remove the .elc when
I'm dinking
around with it to eliminate error messages about their being out of sync. But
when I'm done, then I'll byte-compile it again.
Actually, my init is in large part a control file that loads also the files
initd, initl, initm, and inito. I write a function to byte-compile all
my startups
at once.
Of course, I understand that one should not byte-compile custom.el because
the customization software doesn't byte-compile it, and if someone byte-compiled
it, later option changes would produce a .el file that's out of sync
with its .elc.
I doubt there would be much performance improvement from doing so anyhow.
--
Lynn David Newton
Columbus, Ohio
neologisticsediting.com
lynndavidnewton.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: finding the elisp underpinning a menu choice
11 years, 3 months
Lynn David Newton
> So my question, a general one with a specific case in mind is: Is there a way
> to find out, even if it means prowling around in source somewhere, what
> elisp is executed when a user selects a given menu choice?
Never mind this. I think I found the answer to the application side of
my question
in the config.texi file, which says that the Options => Font Sizes
menus are broken
by design because with Xft it's illogical for them to work. Or
something like that.
Therefore, I guess my only choice to make things look razzle-dazzlingly snazzy
(to my eyes) when I come up is to simply go to that menu choice and to let it
do *whatever* it is that it does, which for whatever reason fixes it.
It's not an ideal solution, but it's a small inconvenience given that
in practice I
don't have to restart XEmacs more than once every two or three days on average,
unless I'm horsing around with configs, which I may be about done with doing for
another five years or so.
What I still don't know is how to determine what underlying code is executed in
a given menu choice. Not that it's all that important.
--
Lynn David Newton
Columbus, Ohio
neologisticsediting.com
lynndavidnewton.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Customizations info file?
11 years, 3 months
Lynn David Newton
I went to info (C-h i) and wanted to read the Customizations
section, but when I try to go it, I get an error message
that says "Info file custom does not exist". Which is true,
as I look for it in the installed directory.
Is this an error? Sure looks like it to me.
One of the things I need to resolve yet in migrating from
21.4 to beta has to do with options and customizations. I
figure before I ask this list of esteemed experts question
that border on beginnerish, I ought to review some stuff so
that I at least have the right terminology.
The combination and fonts and colors that I have long used I
more-or-less inherited long ago. I mentioned earlier that I
used to use hyperbole and communicated with Bob Weiner while
he was developing it. During that time period he developed a
pair of font and color options schemes that users of his
integrated tool could adopt. One was a standard black text
on light background, and the other was lighter text (gray67)
on black background. Having a blinding white background
screen has always bugged me, so I started using the
gray-on-black and use it to this day.
I think it was all set up before the tools were added to
xemacs to customize faces, fonts, and the like, but of
course this stuff all wound up in options.el and/or
custom.el.
However -- and I know (now) one oughtn't to do this --
somewhere along the line I began prowling around in the
custom.el and options.el files and started tweaking things
by hand.
As a result, I don't really know how to change some things.
For instance, when I first come up, some of the fonts are
too small, including the default. At moment I have to go to
the Options menu, select Font Size, and select <x> 014.
(Yes, I like things nice and big, and I like courier font.)
But even if I save the options, that's not the size I get
the next time I restart xemacs.
The point is not exactly what colors et al. I'm using, but
that I can't reliably figure out how to change them. For one
thing, I don't know how to determine the face name and
properties of something I'm looking at on screen. For
example, I use flyspell mode. Currently, when I'm typing
along and it finds what it thinks is a misspelled word, the
highlighting it does is in a completely different font that
is so scrunched up I can barely read it. Also, the shell
prompt I use in shell mode is the right color, but the wrong
font and size, but I don't know what to look for to change
that.
As you can see, I'm struggling to the point I'm not even
sure what questions to ask, which is why I wanted to
review the Info manual on this in order to get my bearings.
--
Lynn David Newton
Columbus, Ohio
neologisticsediting.com
lynndavidnewton.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
check for unibyte strings
11 years, 3 months
Michael Albinus
Hi,
in Tramp, I must check whether filenames are encoded with unibyte
characters. GNU Emacs has `string-as-unibyte' for this.
What would be the respective function in XEmacs? Or can I assume that
strings consists always of unibyte characters in XEmacs?
TIA, and best regards, Michael.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
updating packages
11 years, 3 months
Lynn David Newton
I'm making progress toward resolving the cleanup problems I have
moving from 21.4 to the 21.5 beta. To avoid having to dig through
several e-mails with different subject headers and to deal with
one thing at a time, I'm starting a new thread.
Thanks to the several who gave suggestions regarding getting my
packages updated. Someone suggested doing this:
(setq efs-ftp-program-args (append efs-ftp-program-args '("-p")))
I've never really understood what passive mode is in FTP. I went
out and read an explanation and still don't. Doesn't matter. I
seem to recall from previous experience that it doesn't hurt to
have it running. Nonetheless, I eval'ed that and stuck it in my
init.el in case I need it again, but commented out.
More importantly, I think, is the clue that ftp.xemacs.org is
broken. As per Stephen's suggestion, I selected ca.xemacs.org,
which I guess is the "nearest" mirror -- probably closer than
wherever ftp.xemacs.org is (I'm in central Ohio) -- and that
enabled me to get an index, which I put in ~/.xemacs.
The first time I tried to update packages, it gave me an error
that it couldn't write the directory. This makes sense, given
that the packages are now in /usr/local space and I installed
them using sudo.
To get around this, I had to go to a command line and simply did
chown -R lnewton: on /usr/local. (There's nothing else there but
xemacs stuff.)
Although it apparently works right that way, it strikes me as
philosophically wrong and broken to go into /usr-land and start
changing ownerships and permissions. Isn't there or shouldn't
there be a way for the elisp to detect that when a directory tree
exists but is unwritable it almost certainly means that it needs
to be updated by root, and so should prompt for a password?
And while I'm at it, I had to answer some questions about where
to put the package index, which is now in my .xemacs directory.
I didn't look closely enough at what all it was telling me, but in
retrospect I suspect it's the same problem, that it wanted to put
the index with the packages but couldn't -- but intelligently
allowed me to put it in .xemacs. I should remove it out of there
and do the process again to see where it puts the thing.
(I hate having stuff in my face in a directory that I don't use.)
As far as I can tell, based on the dates that now exist in
/usr/local/share/xemacs/xemacs-packages/lisp, everything worked.
And it looks like only about a dozen packages have been updated
since the sumo was last created. (July 27, 2010)
Apparently it's not something I have to worry about very often.
Off to slay the next dragon.
--
Lynn David Newton
Columbus, Ohio
neologisticsediting.com
lynndavidnewton.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
keymaps redux
11 years, 3 months
Lynn David Newton
Thanks to those who made suggestions regarding Xmodmap and
xev to figure out how to get super and hyper keys. I'll play
with that when I get time to experiment. Surely there's a
way.
Meanwhile, I posted a question about the following matter a
few days ago and no one ventured a reply. Here's a repeat in
the simplest terms.
o I start xemacs -q in both 21.4 and 21.5
o I do M-x insert-file to read the following code into the *scratch* buffer
(defvar ctl-z-map (make-keymap) "Keymap on C-z")
(defvar ctl-z-ctl-z-map (make-keymap) "Keymap on C-z C-z")
(define-key global-map "\C-z" ctl-z-map)
(define-key global-map "\C-z\C-z" ctl-z-ctl-z-map)
(define-key global-map "\C-zs" 'sort-lines)
(define-key global-map "\C-z\C-zf" 'free-notebook-entry)
(I know free-notebook-entry is not defined at this point,
but that doesn't matter.)
o I eval the code one line at a time to be sure there are no
errors.
o I do C-h t to get the TUTORIAL for some scratch text.
o I mark the first full multi-line paragraph
o In xemacs 21.4 I run C-z s and the lines sort.
o In xemacs 21.5 I get as far as C-z and it prompts me for a
character for zap-to-char, which is the default binding
for C-z.
Clearly something has changed between versions. I don't know
that my understanding of the elisp I use to define keymaps
is the canonical way, but this code has worked for me for at
least six years.
Does anyone have a clue what's wrong?
--
Lynn David Newton
Columbus, Ohio
neologisticsediting.com
lynndavidnewton.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Meta and Super on the Mac under X11 (XQuartz)
11 years, 3 months
Lynn David Newton
For those running XEmacs on a Mac under X11 (currently under XQuartz).
you know what to set in order to get Hyper and Super keys, but
without doing something that hoses up other stuff on the Mac?
BTW, on the Mac side I also have my keyboard Preference configured in
the Modifier Keys section to map Caps Lock to Control (WHERE *GOD SAID*
IT SHOULD BE!! :-) ) and Control to No Action. Any emacer is using the
Control key constantly, and I hate having to fish for the second of four
buttons not in convenient reach on the bottom row. (I even tried to
force myself to learn for a couple of weeks a few years ago, but
couldn't do it.)
I *know* I had at least some of that at one time on a Mac, in fact I
think maybe even *both* Super and Hyper, but I can no longer intuit how
to do that. And yes, I'm looking at the X11 Preferences, but this is not
sufficiently informative to move me to experiment. So I thought I'd ask
this group, figuring surely someone has been down this road before.
--
Lynn David Newton
Columbus, Ohio
neologisticsediting.com
lynndavidnewton.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
minor points regarding initialization files
11 years, 3 months
Lynn David Newton
Question batch 2 has to do with start-ups.
The installed directory /usr/local/share/xemacs/site-lisp is empty,
which I gather is reserved for stuff that may be locally needed:
original and customized packages, etc.
I guess that was be a question. Be patient with me while I relearn all
this stuff.
Typically Macs are used by only one user, so having stuff out in
/usr-land so others can see it is not usually necessary. Come to think
of it, I could probably use a configure option to install somewhere
beneath my home directory. I think I used to do that, but haven't for a
long time.
My way of dealing with site-lisp that has long been to put all that
stuff either in ~/.xemacs or ~/.xemacs/site-packages, which I discovered
by experimentation automatically becomes included in load-path.
I tried to rename this directory site-lisp, but found that xemacs can't
find it -- unless I add it to load-path. Really?? Why would that be
true? Not that it matters. I renamed it back to site-packages and it
works fine again.
Another advantage of having it in ~/.xemacs is that the stuff doesn't
disappear. When my previous main system, a MacBook Pro, bit the dust, it
did so bigtime. I had careful backups of everything in my home
directory, and lost not a thing, but kept nothing outside of there, so
it's been a job creating a new working environment -- a task that's been
not unenjoyable because it's good to clean house once in a while. But if
all my customized elisp stuff existed only outside my home directory, I
would have lost it all.
So question 2b has to do with site-start.el. I seem to remember that at
least in ancient times xemacs would look (first?) for a file
site-start.el(c) in its load-path, and would run that stuff first. There
is no such file in the default installation, so I guess it's up to users
who want one to create one.
I do, because I use it to put some defuns that are extremely useful
during initialization, and also to declare some global properties up
front, also key bindings for eval-region and eval-print-last-sexp,
useful in debugging startups.
Is site-start.el(c) automatically loaded -- first -- if I don't
explicitly load it? I gather it is *not* -- otherwise xemacs -q would be
prone to frequent failures.
My brute force way of dealing with that has in the past been to put the
following as the first form in my init.el:
(load-library "site-start")
I also use a load a module I picked up from somewhere called safe-load
(author said to be Lawrence Juja, dated way back in 1992), which
prevents initialization from blowing up after every error. It just
creates a list of the failing packages to look up after it comes up.
This has saved me endless headaches, and I wish it were in the default
distribution.
At the end of my init.el I also prepend nil to load-path to make the
current directory a place to look, a trick I picked up long ago. Is
there anyone here who thinks that having the CWD searched first is
philosophically a bad idea? I know people who think that about $PATH,
though I've always (for maybe 25 years) had my $PATH variable prefixed
with a colon for the current directory.
BTW, I don't use only init.el for startups. I use that mainly as a
control file to load another of other files that give me home brewed
defuns, key bindings, mode-specific stuff like hooks and one that I
needed because certain stuff could only be done *after* loading
hyperbole (that's another question for a later post), also a handful of
saved keyboard macros I never turned into defuns, and so on. A total of
over 3100 lines in those files (according to wc), most of it still stuff
I use.
Still more to follow.
--
Lynn David Newton
Columbus, Ohio
neologisticsediting.com
lynndavidnewton.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
how to use define-minor-mode
11 years, 3 months
Mike Kupfer
I am finally getting back to packaging a recent version of MH-E, and
I've run into a problem. I get the following error when trying to
compile the package tree with the new MH-E:
...
!! Wrong type argument ((char-or-string-p nil))
backtrace(nil t)
# bind (error-info)
byte-compile-report-error((wrong-type-argument char-or-string-p nil))
# bind (error-info)
#<compiled-function (error-info) "...(4)" [error-info byte-compile-report-error] 2>((wrong-type-argument char-or-string-p nil))
capitalize(nil)
# bind (case-fold-search lighter mode)
easy-mmode-pretty-mode-name(mh-showing-mode nil)
# bind (mode-name body keymap lighter init-value doc mode)
#<compiled-function (mode doc &optional init-value lighter keymap &rest body) "...(660)" [lighter group mode-name keymap mode body keywordp nil symbol-name easy-mmode-pretty-mode-name t intern "-map" "-hook" "-on-hook" "-off-hook" :init-value :lighter :global :extra-args :group :require quote replace-regexp-in-string "-mode\\'" "" progn defvar format "Non-nil if %s is enabled.\nUse the command `%s' to change this variable." make-variable-buffer-local boundp byte-compile-current-file defcustom "Non-nil if %s is enabled.\nSee the command `%s' for a description of this minor-mode.\nSetting this variable directly does not take effect;\nuse either \\[customize] or the function `%s'." :set (lambda ... ...) :initialize (quote custom-initialize-default) append :type (quote boolean) file-name-nondirectory file-name-sans-extension defun &optional arg "Toggle %s on or off.\nInteractively, with no prefix argument, toggle the mode.\nWith universal prefix ARG turn mode on.\nWith zero or!
negative ARG turn mode off.\n\\{%s}" (interactive ...) let old-mode setq cond (eq arg ...) not (arg ...) if null message "Toggling %s off; better pass an explicit argument." (nil) and equal run-hooks init-value keymap-sym G67102 pretty-name require globalp hook hook-on hook-off extra-args curfile load-file-name doc (interactive-p) "%s %%sabled" ("en" "dis") (force-mode-line-update) "Hook run at the end of function `%s'." (:type ...) "Hook to run when entering %s." (:type ...) "Hook to run when exiting %s." (:type ...) m (... m) (... ...) error "Invalid keymap %S" "Keymap for `%s'." add-minor-mode symbol-value (...) eval-after-load (1 -1)] 23 ("/home/kupfer/xemacs/ws/packages.mhe83.old/xemacs-packages/xemacs-base/easy-mmode.elc" . 2632)>(mh-showing-mode "Minor mode to show the message in a separate window." :lighter " Show")
(define-minor-mode mh-showing-mode "Minor mode to show the message in a separate window." :lighter " Show")
# bind (current-load-list)
# (unwind-protect ...)
# bind (load-file-name)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
load-internal("mh-e" nil t nil nil nil)
# bind (nosuffix nomessage noerror file)
load("mh-e" nil t nil)
# (unwind-protect ...)
require(mh-e)
eval((require (quote mh-e)))
...
I don't understand what's going on here.
mh-e.el has
(define-minor-mode mh-showing-mode
"Minor mode to show the message in a separate window."
;; FIXME: maybe this should be moved to mh-show.el.
:lighter " Show")
which seems a lot like other invocations of define-minor-mode.
If I'm reading the backtrace properly (and if my meager knowledge of
Lisp isn't leading me astray), I should be able to reproduce the failure
by starting XEmacs 21.4.22 with -vanilla, doing
M-x load-lib RET easy-mmode RET
and then evaluating
(easy-mmode-pretty-mode-name 'mh-showing-mode nil)
Yet this produces "Mh-Showing mode", rather than an error.
Help!
OS is Xubuntu 12.04, x86_64, FWIW.
thanks,
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta