This page describes the Emacs-Lisp libraries by DrewAdams that you can find on the EmacsWiki (at http://www.emacswiki.org/elisp) and how to use them. It includes a brief list of recent changes to the list of files. For information on changes to individual files, see the change logs in the files.

All of my libraries that are on EmacsWiki are also obtainable from MELPA. What’s more, you can be pretty sure that they are untampered with, because their wiki pages are locked except to EmacsWiki administrators.

This page has the following sections:

Cette page est aussi disponible en franglais ;-) : PackagesElispDeDrew, mais cette page ci est plus a jour.

The Libraries

My libraries on EmacsWiki are presented here in several lists, depending on which GnuEmacs releases they support.

Most of the libraries that work with Emacs 20 also work with Emacs versions older than Emacs 20 (but don’t ask me which!). Library sort+.el is needed only for Emacs older than version 20. It redefines function ‘sort-reorder-buffer’ so that it preserves text properties.

A list of deprecated libraries is also provided. These are generally older versions of libraries, with old names.

At the bottom of the page (see AllLibraries), there is a complete list of all of my libraries on the wiki, without descriptions. This is mainly for EmacsWiki search-indexing purposes (it uses format Lisp:icicles.el instead of [[icicles.el]]).

Which Emacs Version?

I use several Emacs versions, including (yes) Emacs 20. If a particular feature in one of my libraries doesn’t seem to work right for the Emacs version you use, please let me know.

Also, check the source code for conditional tests like these:

   (< emacs-major-version 24)
   (>= emacs-major-version 21)

You can try to juggle the branches of such tests yourself – that is, try different branches to see what works in your Emacs version. Let me know what works and what doesn’t. – Thanks.

What's New?

The newest of my libraries are these (in alphabetical order):

I make minor changes to some libraries often, so check for the latest versions.

Tip: The best way to know what files have recently been uploaded to the ElispArea is to consult the recent uploads list: Recent uploads.

Emacs 24 or Later (will not work in older versions)

Emacs 23 or Later (will not work in older versions)

Emacs 26 (and 25 (and 24 (and 23 (and 22 (and 21 (and 20 (and ...)))))))

Emacs 22 or later (will not work in older versions)

Emacs 21 and later (will not work in Emacs 20)

Emacs 20 (some are just not yet tested with Emacs 21 and later)

Deprecated Libraries

These libraries have been deprecated. In many cases, they have simply been renamed (for various reasons, including adherence to GNU naming standards).

Library Names

In many cases, I wrote an extension of a standard GNU library (or sometimes an external library) that was called, say, foo.el. I named the extension library foo+.el. The `+’ generally means that the library should be loaded after the standard library.

In a couple of cases, I wrote a library to be loaded before a standard library; these libraries are named with a ‘-’, as in foo-.el.

How To Use My Libraries

See Also: LibraryNames for information on the library naming conventions used.

Try It All!

You can of course use pieces of my code. But to get the best idea of it, try it all together:

Copy, then open emacs-init.el in Emacs, and read it: it explains everything (let me know, if it doesn’t). Skip most of the intro-to-emacs stuff, and read the instructions before each piece of code.

In particular:

Note: Library emacs-init.el is not 100% up-to-date, but it should get you started. Let me know of any problems you have with it.

Try Some Of It

See TryItAll, then uncomment or comment-out blocks of code in emacs-init.el. Really, that’s the best way to go.

For finer tuning, change other user variables, besides those in emacs-init.el. You’ll find them in the various library files (see DrewsLibraries).

Library Dependencies

In the file header of each of my libraries, you will see a statement like this one from oneonone.el:

;; Features that might be required by this library:
     ;;   `avoid', `cl', `files+', `frame-cmds', `frame-fns', `hexrgb',
     ;;   `misc-fns', `oneonone', `strings', `thingatpt', `thingatpt+',
     ;;   `zoom-frm'.

This does not mean that the library in question strictly requires that you also load all of those libraries. The operative word here is “might”. This is a statement of maximum possible use, not a statement of strict requirement. It says that there are at most 11 other libraries that this library (oneonone.el) can take advantage of. It flattens the maximal ‘require’ tree for you, to let you know what other features you might want to add to this library – features that it was specifically designed to exploit.

This file-header statement is derived automatically by unraveling ‘require’s from a fully-loaded Emacs, when I save the file. It is based on my own use of all of the optional, or “soft”, ‘require’s in the library in question and, recursively, on the files that they in turn soft-‘require’. The code that generates that file-header statement is in lib-requires.el and header2.el.

To determine the libraries that are strictly required by a given library, you must follow its ‘require’ tree yourself, ignoring any soft ‘require’s, that is, ‘require’s that have a non-‘nil’ third argument: (require 'foo nil t).

One way to do that is to load the library and see what missing-feature errors you get, load those libraries, and iterate until you get no more load errors. In this case, the only library strictly required by the library in question, oneonone.el, is hexrgb.el. So, loading just oneonone.el will give you a missing-feature error for hexrgb.el, and loading hexrgb.el and then oneonone.el raises no errors.

That said, I encourage you to try the fully-loaded versions of my libraries. I think you’ll find that the time you spend downloading the additional libraries that are not strictly required was time well spent.

Your Feedback (Discussion)

This space is for ongoing discussion.

See also: OldDiscussionDrewsLibraries for older discussions.

Hi Drew!

I could not byte-compile replace+.el. Here is the error:

Compiling file /home/pasja/.emacs.d/el-get/replace+/replace+.el at Wed Aug 24 09:50:28 2011 replace+.el:410:1:Error: Wrong number of arguments: #[(name variable doc message help &rest body) "\306\307 \310\311 \312\313O\227 \313\314O\315R\316\317 \203

Thanks for your quick replies!

regards, PasJa

Should be OK now. Let me know. Thx – DrewAdams

It compiles correctly! Thanks – PasJa


Here is a comment and rough code snippet that I think are in the spirit of your emacs browse-kill-ring extensions:

It seems to me that inserting a string using ‘browse-kill-ring should be equivalent to a simple ‘yank . But it in fact leaves point and mark in quite a different state: - ‘yank sets a mark before the insertion and leaves point after it, so the region contains the newly inserted text. - But ‘browse-kill-ring does neither so it is very difficult to keep track of the effect of the operation.

Here’s what I have added to my .emacs to fix this for just the one entry to this module that I think I’m going to use. This code can certainly be made more general, and probably more elegant, but I still hope you find it interesting.

Thanks much for browse-kill-ring+.el , -LenW

(defun XX-browse-kill-ring-insert-and-quit ()
  "Like standard `browse-kill-ring-insert-and-quit', but sets mark first and leaves point at end of insert - as does yank"
  (let ( (kill-ring-buffer (current-buffer))
    (set-buffer (window-buffer browse-kill-ring-original-window))
    (setq old-buffer-size (buffer-size))
    (set-buffer kill-ring-buffer)
    (browse-kill-ring-insert t)
    (set-buffer (window-buffer browse-kill-ring-original-window))
    (forward-char (- (buffer-size) old-buffer-size))
    (set-buffer kill-ring-buffer) ))

(setq browse-kill-ring-hook
      (lambda ()
	(define-key browse-kill-ring-mode-map (kbd "RET") 

(sorry if I didn’t do this edit correctly - first time wikier) – LenW

Thanks for your feedback, Len. I fixed this differently – please try the latest.

FYI – I don’t actually use browse-kill-ring+.el (or browse-kill-ring.el). I use Icicles instead for this kind of thing. In Icicles, ‘C-y’ yanks and ‘C-- C-y’ lets you complete against the ‘kill-ring’. IOW, ‘*Completions*’ works like a (better version of) the ‘browse-kill-ring’ buffer for choosing a kill.

Thanks to your instigation, I cleaned up quite a bit of stuff in browse-kill-ring+.el (generally browse-kill-ring.el problems). Fixed some bugs, etc.

FYI, it turns out that the fix for the bug you noticed is just to ‘set-window-point’ after inserting. Took me quite a while to figure this out, though, for some reason. – DrewAdams

Hi Drew. I notice a bug in my emacs: Gnu Emacs The ‘switch-to-buffer in autofit-frame.el (used by dired-details+) is blocked when I switch from some buffers (for example, from Customize, if I quit I get a ‘buffer is nil’ message. I did this:

(setq buffer (if buffer (get-buffer-create buffer)
                 (other-buffer))) ; If string arg, convert to buffer.

Thanks for your packages and everything you do for free software. -Martial

Thanks for your report and fix, Martial. Looks like they allowed a ‘nil’ BUFFER arg starting with Emacs 22! Better late than never. Thx – DrewAdams

dired+.el (w32):

If I use the ls switch -R the empty lines between the directories are marked with diredp-flag-mark (i.e. Blueviolet).

Should be fixed now. Actually, I looked at that as a feature, but I agree that it’s probably better without it. Thx. – DrewAdams

I gave up trying out thumb-frm.el because i got lost in the all the dependencies: doremi, ring+, hexrgb, etc. Maybe you could at some links to needed elisp files – VagnJohansen

I sympathize with you, Vagn, but I don’t know of a royal road…
I think the best approach to libraries is the one I’ve adopted: Each library indicates explicitly only the libraries it explicitly (lexically) requires. If library A requires B, which requires C, so be it. I don’t believe it makes much sense to indicate all of the recursive dependencies explicitly in each library (e.g. show in A that A ultimately requires C, as well as B).
To make things as clear and easy as possible, I do the following, in addition:
    • Use “soft” requires whenever possible. For example, library Lisp:frame-cmds.el softly requires Lisp:strings.el – if the latter is not loaded, there is no problem (you might lose some bells and whistles, but that’s all).
    • Indicate explicitly (by hand) each of the functions and variables that are actually used from the required libraries. I don’t know of others who go to this trouble, but I think it helps those who read or reuse my code (and it helps me in maintaining the code). If, for some reason, you don’t care about some such “imported” entity, you can modify the code to remove the require and do without it. Or, if you don’t want everything else in some required library, you can just copy the definitions of the indicated required entities. Emacs Lisp has no explicit module “import” feature where you can programmitically specify which entities are imported (used) from given libraries, but these code comments should help.
Let me know if you have a suggestion of how better to deal with library dependencies. And let me know if you see errors in a set of ‘require’s or in my comments regarding which imported entities are used.
FWIW, it took me all of 3 minutes, working with a virgin emacs (emacs -q), to look at the ‘require’s in the code (starting with Lisp:thumb-frm.el) and load the needed libraries. FYI, I loaded the following libraries – those in parentheses (`( )’) are optional (soft ‘require’s); those in braces (`{ }’) are standard GNU libraries:
Of course, I already had all the libraries in my ‘load-path’. It would take some time for you to download them and put them in your ‘load-path’, admittedly. Finding which libraries you need should not be difficult, however – that is my point above.
Library Lisp:setup-keys.el makes the key bindings suggested in Lisp:thumb-frm.el (along with lots of other bindings) – but you can just add them to your `.emacs’ if you don’t want the additional bindings.
There may be an Emacs Lisp function somewhere that tracks library dependencies. That would help you come up with the list of libraries ultimately needed by a given library. Otherwise, I’m afraid I can’t help you more – it doesn’t get any easier than this. – DrewAdams

Thanks to you, Vagn, I looked into programmatically deriving info on library dependencies, and came up with some code to do the trick. The result is library Lisp:lib-requires.el, which extends the functionality in standard library ‘loadhist’ – see LibraryDependencies.

One of the commands in `lib-requires.el’ is ‘insert-lib-requires-as-comment’, which inserts a comment listing all of the libraries ultimately required by the current file (that is, recursively).

Since then, I’ve used ‘insert-lib-requires-as-comment’ to add such a comment to each of my libraries. For `thumb-frm.el’ this is it:

 ;;  Library `thumb-frm' requires these libraries:
 ;;    `avoid', `doremi', `doremi-frm', `faces', `faces+', `frame-cmds',
 ;;    `frame-fns', `hexrgb', `icomplete', `icomplete+', `mwheel', `ring',
 ;;    `ring+', `strings', `thingatpt', `thingatpt+'.

I’ve corrected my previous entry, above, which was missing soft-require `thingatpt+.el’ – more proof that programs are better than I at fastidious details.

Although it’s a real help to have such a list derived programmically, keep in mind that such lists make no distinction between hard and soft ‘require’s (I know of no way to do that programmatically, due to the nature of ‘load-history’). In the case of `thumb-frm.el’, as I indicated above, these libraries are not really required: ‘avoid’, `icomplete+’, ‘icomplete’, ‘mwheel’, ‘strings’, `thingatpt+’, and ‘thingatpt’. – DrewAdams

When using your libraries it looks like the minibuffer is often raised without my doing anything. Suppose, for example, that I have three frames: the speedbar, the minibuffer, and a frame visiting an emacs lisp file. If I have selected the speedbar and then click on the frame for the emacs lisp file, the focus will automatically shift to the minibuffer, which says “Refreshing speedbar…done”. Editing commands such as ‘C-n’ are carried out within the minibuffer rather than in the frame with the emacs lisp file. Similarly, when opening a file via the “File” menu (more precisely, when opening a file using “Open recent” and selecting a recently opened file), the result is a new frame for that file, but the minibuffer frame is raised. How can I prevent the minibuffer from being so selfish? --JesseAlama

For me to track things down, I need more specific instructions, starting from emacs -q. For instance, which of my libraries did you use? How did you load them (e.g. what order)? What OS are you on? What version of Emacs?
(Frame selection is weird in Windows, for instance: each frame-creation selects the frame. I consider Emacs to be bugged in this regard, and there is no simple solution until that’s fixed.)
What you describe seems to have only to do with Speedbar, not my code (I don’t do anything like “refresh” speedbar), but I’ll need more detail to check it out.
I don’t think that my code is doing the minibuffer-frame selection, but, again, you’ll have to go slowly and tell me just what operations you do etc. Try one thing at a time. Give me specific instructions to reproduce one of the problems, and I’ll take a look.
It’s important to start from emacs -q, and not load any other libraries that you usually load, in order to isolate a problem. Especially since I’m here and you’re there. If it turns out that the problem comes from some other code you load or execute in your InitFile, I’ll have no luck finding the problem. Likewise, if it turns out to be an interaction between other code you run and my code. IOW, try to isolate each problem to a minimum set of libraries and steps to reproduce it. Otherwise, there is no hope – neither you nor I would have the time to debug a giant sack of stuff, any parts of which might interact with other parts.
Keep it simple, and we’ll make progress. At the very worst (if a problem cannot be fixed easily), you’ll at least learn which things to avoid doing or avoid using. Instead of an all-or-nothing approach, let’s find out which parts of my code you might be able to use, and which parts I might be able to fix.
Thanks for your report – I look forward to some additional and more specific observations. – DrewAdams
Sorry for the lack of detail; I should have been more specific. I’m running Mac OS X 10.4.2, emacs 22 (from cvs) as a Mac OS X app (the “carbon” port of emacs). I was using “all” your libraries in the sense that I used your Lisp:emacs-init.el as my initialization file, with the only change being that your `(require ‘gnuserv)’ was replaced by `(require ‘server)’. You’re right that it’s possible that some other libraries were messing things up, since I hadn’t disabled the loading of my site-start file. Here’s what happens with the speedbar when I start emacs with the command `emacs --no-site-file -q -l emacs-init.el’: three frames (scratch, the minibuffer, and speedbar) pop up. The frame whose sole window corresponds to the scratch buffer is raised. If I click on the “File” menu, go to “Open recent”, and select a file, the file opens up in the frame in which the scratch buffer was visible, and then the focus shifts to the minibuffer. If I then click the mouse in the frame whose sole window corresponds to the buffer visiting the file that I opened, the speedbar gets refreshed and then the minibuffer frame is raised again.
Thanks for your help and patience! --JesseAlama
Sorry, I didn’t notice your reply above before now. I don’t know what to do to reproduce this. If I can help, you will need to narrow things down a lot more – there is just too much code loaded by Lisp:emacs-init.el to determine where the problem is.
My intuition tells me that this is a Mac thing, and probably doesn’t have anything to do with my code – but my intuition has been wrong before.
Suggestions: 1) First, try without speedbar (comment out the speedbar initialization in Lisp:start-opt.el). See if that changes anything. Speedbar does weird things on timers, IIRC. 2) Second, try not loading Lisp:start-opt.el. See if that changes anything. 3) Try emacs -q, then go through Lisp:emacs-init.el, evaling sections of code (via ‘eval-region’). 4) If you get to the place in Lisp:emacs-init.el where Lisp:start.el is loaded, then go through that file the same way, eval’ing blocks of code. The idea is to determine which code (e.g which library load) causes the problem.
I don’t have the latest Emacs 22, and I’m not on Mac, so my testing is not the same as yours. Emacs 22 changes all the time, and it’s possible that either 1) some “improvement” breaks my existing code or 2) the version you have is bugged, or both ;-).
You must get to a place where loading some particular library (not Lisp:start.el) or executing some particular code makes the difference. Then I can take a closer look. And then, even if we don’t find and fix the particular bug, at least you’ll know what library to avoid.
For me to be able to help, I need more specific info. Good luck. – DrewAdams

I too suspect that this is a Mac-specific problem. I just tried solution (1): not loading speedbar. That didn’t solve the problem of having the minibuffer frame raised once the file is opened, rather than the frame corresponding to that newly-opened file. More generally, I noticed that the minibuffer frame is raised apparenly whenever a message is generated. I also tried solution (2): not loading start-opt.el. The problem still exists. I tried solutions (3) and solution (4); to my surprise, I don’t see the problems when I start up a vanilla emacs with emacs -q --no-site-file and then load your emacs-init.el! So there’s some essential difference between loading your emacs-init.el after emacs has started and using it as my emacs initialization file. --JesseAlama

Yes, there is at least one difference, due to the way Emacs starts up if you have defined a standalone minibuffer – if so, it doesn’t create a minibuffer in the first frame. Try this, to see if using a standalone minibuffer is part of the problem:
1) save your InitFile (always)
2) do just this in a new InitFile (along with setting your ‘load-path’): (require 'oneonone)
That should get rid of the difference I describe above. Then, if the problem is not yet manifest, continue to eval stuff in Lisp:emacs-init.el, trying to isolate the cause of the problem.
If it is a Mac-specific problem I probably won’t be able to help much, especially since you are running with the latest CVS snapshot all around. But keep me posted; I might have some suggestions.
One other thing to try, to see if it’s a bug in recent CVS files, is to use an older version of Emacs. If you can find a Mac binary somewhere, that would be a quick thing to check.
As it is now, you are juggling far too many variables to be able to tell what the culprit is – you must reduce the number of libraries that you’re using, to eliminate background noise. Trying to test by putting everything in a giant sack and shaking is a recipe for failure. Good luck! – DrewAdams

Hello Drew, I’ve noticed apropos-fn+var is doing something bad. “C-h a” produce this output to minibuf and Messages:

Loading apropos-fn+var (source)...done
apropos-command: Wrong number of arguments: (lambda (do-keys spacing &optional text) (if (null apropos-accumulator)....
(substitute-command-keys "and type \\[apropos-follow] to get full documentation.

")) (if text (insert text "

")) (while (consp p) ....
(setq apropos-accumulator nil))), 4

I replased long lines by “….” if you need them just let me know. Emacs 22 cvs 2006-02-08 msvc build.

Thanks, AndreyZ

It looks like they’ve changed standard library `apropos.el’ again, adding another argument to function ‘apropos-print’. I’ve uploaded a new version of apropos-fn+var.el, which should work OK. Let me know if you have any problems with it. – DrewAdams

Thank you! That was fast. – Andrey Zhdanov

Hello Drew! That’s me again 😊 autofit-frame.el does not allow bookmark’s logic to work correctly if target bookmark is in the same buffer. Here is the code:

  (let ((cell (bookmark-jump-noselect bookmark)))
    (and cell
         (switch-to-buffer (car cell)) *<--- that gets nil*
         (goto-char (cdr cell))

(and (one-window-p t)
         (not (eq buffer orig-buf))     ; Don't resize if same buffer.
         *^^^^^^^ that's where nil comes from*

Thanks, AndreyZ

Wow! I’m amazed I never caught that before. There must not be much Emacs-Lisp code that depends on the return value of ‘switch-to-buffer’. Thanks very much. Great bug report – you did all the work. – DrewAdams

No Problem! Thanks for your great work of making emacs better. – Andrey Zhdanov

Drew, first thanks for all the great work you have done with your libraries.

I have tried your InitFile with two different versions of emacs. I got it to work with emacs 21.4.1 on Ubuntu GNU/Linux but had to comment out a line in setup-keys.el because I was getting an “Invalid modifier in string” error when loading that file. The offending line is:

   (global-set-key "\M-\C-\ "  'mark-thing)

When trying the same InitFile and libraries with emacs, I get a ‘wrong-type-argument.’ The relevant lines are:

Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
  aset(nil 12 [95...])
  eval-buffer(#<buffer  *load*<3>> nil "/home/fisal/elisp/setup.el" nil t)  ; Reading at buffer position 5436

I realize is the development version but I thought you would be interested in finding out that there are issues trying to use your libraries with the latest emacs. The libraries I am using were last updated by you January 19, 2007 and later. The ones I am loading are: autofit-frame.el dired+.el eyedropper.el frame+.el help-mode+.el misc-fns.el setup.el start.el~ thumb-frm.el buff-menu+.el doremi-cmd.el facemenu+.el frame-fns.el hexrgb.el mouse+.el setup-keys.el start-opt.el tmp compile-.el doremi.el faces+.el grep+.el info+.el oneonone.el setup-keys.el~ strings.el window+.el compile+.el doremi-frm.el fit-frame.el header2.el lib-requires.el replace+.el simple+.el thingatpt+.el zoom-frm.el diff-mode-.el emacs-init.el frame-cmds.el help+.el menu-bar+.el ring+.el start.el thing-cmds.el


Thanks for your clear report, Fidel. It should be OK now – let me know. I too use Emacs, but I usually compile the libraries using Emacs 20, so I didn’t notice this problem.
BTW, I can tell by the list of libraries you gave that I hadn’t updated emacs-init.el in quite a while – Icicles was missing! I updated emacs-init.el just now. Thx – DrewAdams

Drew, thanks for your fast reply. I assume from your response that things should now work with Emacs but I can’t find an updated oneone.el file. I downloaded the most recent emacs.init and setu-keys files. Thanks again. – FidelSalas

Yes, I think that the bug is fixed. Let me know if that is not the case. The latest version of oneonone.el is update #2101, dated Fri Jan 19 21:20:13 2007. – DrewAdams

I still get the wrong-type-argument error when 1on1-emacs gets called. – FidelSalas

Sorry, I misunderstood. Please try the latest version of oneonone.el. Apparently, the ‘standard-display-table’ is ‘nil’ by default! – DrewAdams

Drew, it works now. Thanks a lot. – FidelSalas

Is there any tarballs (e.g. icicles.tar.gz), so that the user can easily obtain up-to-date icicle files at once? – SeijiZenitani

Here is a script that should download all Icicles libraries: Icicles - Libraries#BulkIciclesDownload. – DrewAdams
I see. Thank you! – SeijiZenitani
zip of the Icicles libraries is up, see Icicles.zip. Be aware this is not updated automatically, so it might be out of date, but it can get you started. – leooo
However, a major problem is this: just which groups of files should be in a zip? The Icicles libraries are one obvious candidate (a natural grouping of files), but other groupings are not so obvious. And Icicles files, in particular, change often. Still, an Icicles zip archive could be useful in the same way that the download scripts can be useful. – DrewAdams

There is now an automatically generated zip archive of Icicles files from the Icicles repository on the GitHubMirror. See http://www.emacswiki.org/emacs/Icicles_-_Libraries#ZipFileDownload.

Hi Drew. I really like your library collection. But, I prefer the classic single window/multi-frame setup. Is there some way to disable all frames used in your libs? – Tennis

Hi Tennis. I’m not sure what you mean. Only a few of my libraries involve using non-‘nil’ ‘pop-up-frames’. Obviously, if you use a library designed specifically for that, it won’t fit your preference. But most of the libraries should not be a problem – they should not, in any case, impose any particular use of frames. Can you let me know which, in particular, you are having trouble with? Perhaps there is a bug. Thx – DrewAdams

Thanks for the quick reply, Drew. Apologies for not being clearer. 😊 Here’s what I’m doing:

  1. I checked out a copy of all the wiki code, which includes all your libs (see [1]).
  2. Replaced my ‘.emacs’ with your ‘emacs-init.el’ and renamed it to ‘.emacs’
  3. Edited the new .emacs to suppress all frame-related items.
  4. Restarted.

At this point, I still got separate frames for everything. I can send copies of my edits, if you like.

I am using

This is GNU Emacs 22.0.990.1 (i386-mingw-nt5.1.2600)
 of 2007-05-23 on LENNART-69DE564 (patched)


PS - If I remove all customization of any kind (.emacs/.emacs_customization, .recentf. .emacs-places, etc.) and try this on either win32 or linux fedora 7, I also get:

error: Recursive `require' for feature `icicles'

OK. We’ll need to attack it one thing at a time.

1. Wrt the Icicles recursive ‘require’ problem – Please try to debug this separately, and try this first, before tackling emacs-init.el with everything that it loads (including Icicles).

There should be no dependency problems among Icicles files. Make sure you have the latest versions of all of the files, and remove any compiled versions. (You can compile again after things are working OK.)

Then start with a .emacs that does nothing except (1) set the ‘load-path’ to a directory that contains the Icicles libraries, (2) sets ‘debug-on-error’ to ‘t’, and (3) does (require 'icicles). Let me know what the debugger backtrace shows.

2. emacs-init.el is quite old. I’ve just uploaded a more recent version, but I mainly commented out stuff that is no longer pertinent. I also added a note in the Commentary saying that it’s not a great idea to just use the file as is. It’s best to treat it as a guide.

Please read that Commentary. Among other things, it says that it loads files start.el and start-opt.el.

Each of those files loads lots of my libraries and, if available, other libraries as well. You can try them out-of-the-box. I think they will not present problems, but they might. If so, you will need to set ‘debug-on-error’ to ‘t’ and try to figure out what the problem is.

Library start.el loads library oneonone.el, which provides the one-buffer-per-frame behavior. It is library setup.el, also loaded by start.el, that actually calls command ‘1on1-emacs’, which enables the OneOnOneEmacs behavior. If you don’t load setup.el (e.g. move it out of your ‘load-path’ so start.el can’t load it) or if you comment out the call to ‘1on1-emacs’ in setup.el, then you shouldn’t get OneOnOneEmacs.

Similar comments apply to the rest of what start.el and start-opt.el load. To tailor things to your preferences, you might need to either remove some libraries from your ‘load-path’ or comment out the code that loads them.

I apologize for any inconvenience this causes. Again, it’s not a great idea to start with someone else’s .emacs and just hope for the best. Please treat emacs-init.el as a guide.

If you run into trouble, use a binary search on your .emacs, or on a library such as start.el that it loads, to locate the cause of the problem. That is, split the file in two, either by commenting half of it out or by using ‘M-x eval-region’ on only half of it (starting from emacs -Q). Then split the problematic half in two and repeat etc. Binary search is incredibly quick at locating precisely the problem code.

Good luck. Sorry for any inconvenience. You can email me if you have more questions. – DrewAdams

Thanks for the info, Drew. No worries. I’ll walk through each of your suggestions and email if anything comes up. --Tennis

Is there a way to make a frame full-screen, as in the (shell-command “wmctrl -r darkroom -badd,fullscreen”) line of http://ubuntuforums.org/showthread.php?p=1235260 ? A frame-fullscreen or frame-fullscreen-toggle function would be nice for making all your base belong to emacs. – Dave

I guess you’re asking about maximizing a frame – is that right? (I’m not familiar with wmctrl etc.)

If so, I think the answer is that there is no platform-independent answer. If you use Windows, then you can use commands ‘maximize-frame’ and ‘restore-frame’, defined in library fit-frame.el. If not, try asking LennartBorgman; I think he might have an answer for you about this. – DrewAdams

FullScreen is a little bigger than maximizing — it turns off the window decoration and handles and makes the application area match the full screen. Like windows powerpoint in slideshow mode, or a full-screen video or slideshow player. I think I found what I wanted from the page FullScreen. See WriteRoom for an application. Thanks – Dave

Hi Drew. Which, if any, of your libs will work in a text-only (i.e. “emacs -nw”) environment? Thanks. – Tennis

Sorry; I don’t know. It also probably depends on what “works” means. Non-ASCII keybindings will of course not work, and perhaps things that involve explicit frame manipulations might not work. Most of the rest should work. Icicles uses lots of non-ASCII key bindings, but it would probably work OK if you changed the bindings. You’ll just have to experiment. – DrewAdams

Thanks, Drew. I’ll let you know how it goes. -Tennis

Hi Drew,

I just ran into an interesting bug/issue. I am using your libraries (downloaded from the wiki on 9/27/11 or 9/28/11) and emacs The issue arose with my .emacs file but I tracked down the source of the problem. Here is how you can reproduce it using your .emacs (the one one may download from the wiki): - comment out the require for start-opt.el; - add the following two lines to the end (before the provide statement) of your .emacs file: (setq debug-on-error t) (desktop-save-mode 1)

You will notice that the separate minibuffer (minibuffer in its own frame) will not be used. Instead, the minibuffer of a working frame (a regular frame) will be used as the minibuffer. Both the desktop and debug lines above are required for this to happen. Note, this did not happen with your libraries of a couple of years ago.



Sorry about that, Fidel. Can you please try to narrow things down? You say that you are using my libraries, but that’s far too much to try to track this down with.

Please do this: comment out half of your init file (e.g., using ‘C-3 M-x comment-region’ – use ‘C-u M-x comment-region to uncomment’) and see if you have the problem. Then comment out only a quarter of it, then 1/8th, etc., until you locate what the problem is. Then we can try to figure out the details. It is important to eliminate as much noise as possible from the outset.

Thx – DrewAdams

Hi Drew,

I am sorry I was not clear enough the first time. I can reproduce the problem with your emacs-init.el file by doing two things:

1) commenting out the (require 'start-opt) line; and
2) adding the following two lines:
(setq debug-on-error t)
(desktop-save-mode 1)

I narrowed down the problem first using my init file by commenting out everything out except what I use from your init file and the two lines (the debugpon-error and desktop=save-mode lines) required for the problem to arise. I then took your full init file and added the two lines and got the same behavior (I do not think the start-opt has anything to do with anything but I commented out of your init file because I did not have a copy of it on my machine).

The version of your emacs-init.el is 20.0:

;; Version: 20.0
;; Last-Updated: Tue Jan  4 08:50:07 2011 (-0800)
;;           By: dradams
;;     Update #: 2145

Hope that’s clearer.



It’s clear enough, but I would still ask you to narrow it down by commenting out half, a quarter, etc. (of emacs-init.el), as I suggested.

There is just far too much stuff in emacs-init.el, and even much more stuff that is loaded by it. If you don’t do that then I would have to do the same thing, and I don’t have the time now.

It’s likely that there is some small part of that file or some file that it loads that is causing the problem you see. A binary search is the way to locate it.

You will need to do the same thing in the problematic file, once you find it. For example, emacs-init.el loads start.el, which loads tons of files. You will need to debug this a bit, to narrow it down to locate the problem. Then I will try to fix it.

Also, let me know what Emacs version you are using and the recipe you follow to start Emacs.

[One thing I can think of offhand is that if you are using oneonone.el then you need to invoke function ‘1on1-emacs’ during startup, using a command-line option or by putting (1on1-emacs) in your init file (it is invoked in setup.el, if you use that). If you instead invoke ‘1on1-emacs’ interactively it will be too late: a frame with a non-standalone minibuffer will already have been created.]

Let me know too what you have changed since things were working OK, if you remember. For example, were you using desktop already, with no problem? And what version of ##desktop.el# do you have? I’m hoping that when you locate the problem it is independent of using desktop, as that is not one of my libraries.

Another thing to try would be to move your desktop save file somewhere where it will not be read (temporarily hide it from desktop). Sometimes such files get corrupted and cause problems.

Thx – DrewAdams


Thanks for your response. I will get back to you when I get around to narrowing things down.


Thanks. Please do. I don’t mean to put you off. I will take a look when we know what we’re dealing with. Thx – DrewAdams

RFE: Please consider including in the header of each feature-enhancement file foo+.el the URL of the corresponding EmacsWiki documentation/discussion page FooPlus. It is not obvious that this is where to look unless you already know (and remember from last time you had to work it out).

I haven’t done that, but I could. I’ve just updated header2.el to add a Doc URL: field for that.

Note that for libraries that have a Customize group, I typically provide direct links in the group ‘Customize’ buffer to such wiki doc pages, as well as links to wiki code pages.

Remember too that from the wiki page for the Lisp code you can just click the page header to get links to all of the wiki pages that link to that page. That list will include any pages that discuss the library in question. That is what I do when I forget the exact page that introduces the library. It’s pretty quick.

Thx – DrewAdams

The library apropos-fn+var.el doesn’t work in Emacs 24.3 due to apropos-macrop being missing. I’m not sure when this happened but it’s definitely not in 24.3! However the file subr.el contains the function macrop which I assume does the same thing. To get it working I have temporarily added the following to my startup file:

    (defalias 'apropos-macrop 'macrop)

Thanks – Bernard Hurley

Thanks for the heads-up. Actually, it was OK for Emacs 24.3 (‘apropos-macrop’ still exists there), but not for Emacs 24+ (i.e., development snapshots after 24.3). Should be OK now. – DrewAdams

I think `palette.el’ contains a spurious “4” on this line:

    ;;     Update #: 779 4

And the version at one point went from “22.0” to “0”. – JonasBernoulli

I’ve removed the spurious ‘4’ - thanks. The version number (‘0’) is correct. The library is not versioned. – DrewAdams

All libraries referenced here:

Lisp:apropos+.el, Lisp:apropos-fn+var.el, Lisp:autofit-frame.el, Lisp:autoload+.el, Lisp:bindings+.el, Lisp:bookmark+.el, Lisp:browse-kill-ring+.el, Lisp:buff-menu+.el, Lisp:col-highlight.el, Lisp:compile-.el, Lisp:compile-20.el, Lisp:compile+.el, Lisp:compile+20.el, Lisp:crosshairs.el, Lisp:cursor-chg.el, Lisp:cus-edit+.el, Lisp:def-face-const.el, Lisp:delsel.el, Lisp:diff+.el, Lisp:diff+20.el, Lisp:diff-mode-.el, Lisp:dired+.el, Lisp:dired-details+.el, Lisp:dired-sort-menu+.el, Lisp:doremi.el, Lisp:doremi-cmd.el, Lisp:doremi-frm.el, Lisp:doremi-mac.el, Lisp:ediff+.el, Lisp:emacsbug+.el, Lisp:emacs-init.el, Lisp:eyedropper.el, Lisp:facemenu+.el, Lisp:faces+.el, Lisp:ffap-.el, Lisp:files+.el, Lisp:find-dired-.el, Lisp:find-dired+.el, Lisp:finder+.el, Lisp:find-func+.el, Lisp:fit-frame.el, Lisp:font-lock+.el, Lisp:frame-cmds.el, Lisp:frame-fns.el, Lisp:frame+.el, Lisp:grep+.el, Lisp:header2.el, Lisp:help+.el, Lisp:help-fns+.el, Lisp:help-macro+.el, Lisp:help-mode+.el, Lisp:hexrgb.el, Lisp:highlight.el, Lisp:hl-line+.el, Lisp:hl-spotlight.el, Lisp:icicles.el, Lisp:icomplete+.el, Lisp:imenu+.el, Lisp:info+.el, Lisp:isearch+.el, Lisp:keysee.el, Lisp:lib-requires.el, Lisp:line-num.el, Lisp:ls-lisp+.el, Lisp:macros+.el, Lisp:menu-bar+.el, Lisp:misc-cmds.el, Lisp:misc-fns.el, Lisp:mkhtml.el, Lisp:modeline-posn.el, Lisp:mouse+.el, Lisp:novice+.el, Lisp:oneonone.el, Lisp:options+.el, Lisp:outline+.el, Lisp:pp+.el, Lisp:pp-c-l.el, Lisp:replace+.el, Lisp:ring+.el, Lisp:savehist-20+.el, Lisp:second-sel.el, Lisp:setnu+.el, Lisp:setup.el, Lisp:setup-cygwin.el, Lisp:setup-info.el, Lisp:setup-keys.el, Lisp:highlight-chars.el, Lisp:simple+.el, Lisp:sort+.el, Lisp:start.el, Lisp:start-opt.el, Lisp:strings.el, Lisp:synonyms.el, Lisp:thingatpt+.el, Lisp:thumb-frm.el, Lisp:timer+.el, Lisp:tool-bar+.el, Lisp:ucs-cmds.el, Lisp:unaccent.el, Lisp:vc-.el, Lisp:vc-hooks+.el, Lisp:vc+.el, Lisp:w32-browser.el, Lisp:w32browser-dlgopen.el, Lisp:wimpy-del.el, Lisp:window+.el, Lisp:yes-no.el, Lisp:zones.el, Lisp:zoom-frm.el