A project to make Emacs more frame-oriented is introduced. Discussion of the problem and suggestions of solutions are invited. An existing implementation is described.
Several major versions ago, Emacs introduced frames, which correspond to window-manager windows. A frame is tiled into one or more panes – we call them windows in Emacs-speak. See also FrameModes for more information on the relation between frames and Emacs windows.
The reason for this uncommon terminology is that Emacs itself dates from before window managers. Emacs was originally designed for tty terminals, which had no graphics, no windows, no mouse, and only one font. (Many people still find this an optimum setup for editing text.)
Emacs windows were designed for that environment – and they were a great match. They live on today in the same form they had back in the mid 1980s. You could say that that is a testament to their ongoing usefulness. Or you could say that additional Emacs features like frames and mouse support have come along to address the specific aspects of modern computer interfaces, while Emacs windows have become a vestige feature that is useful mainly for lack of a good alternative.
I (DrewAdams) tend to the latter view, but I recognize that the specific functionality of Emacs windows can sometimes be useful in a window-manager setting too. That is, it can sometimes be useful to have more than one pane (Emacs window) in the same frame.
Most Emacs users would argue that Emacs windows are indispensable, and they’re right, but I would argue that this is only because frames have not been given their due: much of Emacs is still heavily oriented toward using Emacs windows, not frames, and this bias is built-in.
This bias manifests itself in ways like the following:
*Completions*. And it automatically removes some of these windows when you’re done with them. Very handy.
‘C-x 5 f’to visit a file,
‘C-x 5 0’to delete a frame, and so on. Bindings are easily changed, of course, but other things tend to make you want to keep the simple bindings (
‘C-x 0’) for Emacs windows, not frames. As long as you have to use windows most of the time, you want windows command bindings to be short.
There are in fact several Emacs functions, some built-in, that manipulate windows and are not at all geared toward frames.
Given this state of affairs, is there any sense in trying to use Emacs in a primarily frame-oriented fashion? To me, it’s worth trying to adapt Emacs a bit, to wean it from its dependence on Emacs windows.
So, when frames first came out, I set about customizing my Emacs, to try to take advantage of window-manager windows (frames)…
First, of course, I set
‘pop-up-frames’ to non-
‘display-buffer’ would use a new frame each time. That’s when I came to know the various ways in which a window bias was built-in. Little by little, I tried to overcome this bias, and I pretty-much succeeded.
But I’d be interested in other opinions and, other, better enhancements to make Emacs more frame-oriented. What should this mean? What are the best ways to realize it?
Call this goal or project “Paneless Emacs”, or perhaps “One-On-One Emacs”. One window per frame is the basis: when a buffer is displayed in a window, that window is in its own frame (by default). The idea is not to do away with window operations, but just to make it more natural to use frames instead of Emacs windows for most things.
I describe here how I’ve approached the problem. After that (see OneOnOneEmacsLibraries), I describe the individual Emacs Lisp libraries for my implementation of One-On-One Emacs, in case you want to try it out. Enhancements and alternative approaches are invited.
In summary, I did this:
(setq pop-up-frames t)
Here are descriptions, with screenshots, of the major frame-friendly functionalities I implemented.
*Messages*etc.) are in frames with a different style.
*Completions*buffers. Redirection of frame focus from
*Completions*to the minibuffer frame.
‘mouse-tear-off-window’behave better with frames.
In addition to those major changes, I changed a few other standard Emacs functions to take better advantage of frames:
‘dired-simultaneous-find-file’: Redefined to use separate frames instead of windows if
*Help*buffer functions, like
‘locate-library’, make the
*Help*frame invisible when you’re through with it.
*Completions*window even if it is on another frame.
‘count-windows’: Only uses the optional
MINIBUFargument if the current frame has a minibuffer.
See DrewsElispLibraries for which libraries work with which Emacs versions.
Each library has
‘require’ code that lets you know which other libraries it uses. In most cases, these are soft
‘require’s: if the required library isn’t found, nothing happens.
These are the libraries for (my version of) One-On-One Emacs:
‘buff-menu’; see also BufferMenuPlus
‘grep’; see also GrepMode
‘dired-x’; see also DiredPlus
‘facemenu’– see FaceMenuPlus
‘help’; see also HelpPlus
‘info’; see also InfoMode
‘menu-bar’; see also MenuBar and HelpMenuBarPlus
No, those are not all required. They are libraries that I find help me work using frames with Emacs. If you want to start small, the minimum is
hexrgb.el. And see the setting recommendations in the file header of
After that, I strongly recommend
dired-details+.el, to save screen real estate.
All of the libraries I’ve posted at EmacsWiki are listed at DrewsElispLibraries. Putting all of them in a directory pointed to by variable
‘drews-lisp-dir’, and using emacs-init.el as is, you live Emacs more or less as I do.
This space is for chronological comments (interaction).
LiuJin?: When tiling multiple frames, wouldn’t multiple frame borders, title bars, menubars and toolbars consume too much screen space?
JodyKlymak, 2004-04-19: Looks very interesting. Why does it need its own layer of customization for frame look (i.e. default-frame-background)? This seems to override my color-themes call for the first frame. Subsequent frams seem OK. Thanks, Jody
‘default-frame-background’and such are user variables, which you can set in your init file to get the look you want. They are used to define the standard variable
‘default-frame-alist’. Perhaps you need only change the order of loading libraries [[color-theme.el.gz?]]. and oneonone.el.
‘color-theme-install-frame-params’(in [[color-theme.el.gz?]]) says that “the value of
‘initial-frame-alist’is not modified.” In oneonone.el, I do this:
(setq initial-frame-alist default-frame-alist).
Matthias, 2004-11-10: Its seems that the most popular feature of Firefox are its tabs. Don’t you feel they are a weak version of emacs windows? I say weak because an existing buffer may have no associated windows…
I see tabs as similar to the ability in Emacs to use the same frame successively for different buffers – only one “buffer” is visible at a time with tabs. What tabs offer, which is not currently available in standard Emacs, is the ability to click (rather than using, say,
‘C-x b’) to display a buffer in the frame. However, things like BufferMenuPlus and SpeedBar offer something very similar. And there are Emacs packages that apparently offer just that ability – see TabBarMode, ErcTabs, and WThreeMTabs. – DrewAdams
Is there a specific reason that files here are only available as seperate files instead of tarballs? Clicking through the dependencies including the 20sec limit for 10 pages is really annoying. In any case compressed tarballs would also cause less trafic. (This might not be the right place to mention that but i felt the need to express this SOMEWHERE after collecting files for half an hour…) – Dondy
I offer my software as a free service, with no warranty; I’m not selling anything here. If you want to download and use it, fine; I hope you find it useful. If not, have a nice day anyway :-).
If you want to make a set of files available as a tarball, feel free to do so. There is a huge number of possible tarball combinations, of course. Even for a single library such as oneonone.el, there is a large number of possible tarballs, depending on which optional libraries people might want to use with oneonone.el.
You see, oneonone.el has provisions to exploit features from multiple libraries that are not strictly required by it. This means that there are multiple possible versions of OneOnOneEmacs, from bare-bones to fully loaded. And the same is true of some of the libraries that oneonone.el can exploit. For example, frame-cmds.el offers more if you also load its option libraries. And so on. Different strokes for different folks.
I encourage people to try fully-loaded versions of my libraries. Someone could post a bare-bones tarball for each library, which included only what that library strictly needs, but that would of course annoy people who downloaded the same library in more than one tarball. My preference is to not try to package my libraries together, and thus to let people pick and choose. The downside to that is that they must then, themselves, pick and choose ;-).
Now, to your problem. What “dependencies” are you referring to? The only library required by oneonone.el is hexrgb.el.
Perhaps you are confused by this statement in the file header:
;; Features that
be required by this library:
;; `avoid', `cl', `files+', `frame-cmds', `frame-fns', `hexrgb', ;; `misc-fns', `oneonone', `strings', `thingatpt', `thingatpt+', ;; `zoom-frm'.
I was googling for “one frame per buffer” because I hate the emacs behavior, and I found your writeup and it is exactly what I want. However, I wonder if you couldn’t make it easier to download the current versions of the libraries. As far as I can tell, I’m supposed to individually click each el file and download it. SLOW! And you say check back often? Why not put all this in SVN or some other framework from which we could update? Even a tarball would be better than this point-and-click ordeal we now experience.
I’m just aiming to get the better frame management you want--let the system window manager can do that. I gather that Aquamacs does one-frame-per-buffer already. Before I found your page, I’ve tried to discourage Emacs from splitting with this:
(setq split-window-preferred-function nil)
It helps a bit, but not entirely because Emacs is biased against making separate frames, as you point out.
Thanks for sharing the code, I’ll keep downloading el files until I get emacs to start :) – [[pauljohn32?]]
Sorry for your trouble. The only library that is required by
oneonone.el is hexrgb.el. The other libraries mentioned are only soft-required, that is, suggested, and loaded if present in your
‘load-path’. See also my reply to a similar question directly before your post here.
So downloading means right-clicking and saving from only two file links, unless you choose to also use the suggested libraries.
If you are getting errors trying to start Emacs without some of the suggested files, then there is likely a bug somewhere – let me know, please.
I don’t see where I said “check back often”, but if you point it out to me I’ll remove such a statement because it is out of date. I haven’t done anything special to any of these libraries in quite a while (just the occasional bug fix – no active development). So there is no need to download lots or often. HTH. – DrewAdams
P.S. I believe that Aquamacs uses some of the libraries I mention (e.g. fit-frame.el).
Oh, I don’t mean to say there’s trouble. This whole setup is interesting.
The “check back often” comment is in this page: http://www.emacswiki.org/emacs/DrewsElispLibraries
I actually did download everything, one by one, but it ended up changing too many things about Emacs to suit my taste.
So I went back at the beginning trying to steal just the one frame fix. Actually, I also like the one that shrinks frames for those small popup “menu” windows. That’s really nice. Anyway, in my lib dir, I have just oneonone.el and hexrgb.el. Your emacs-init has (require ‘start) and (require ‘start-opt), so Emacs is not happy. I guessed and it appears (require ‘oneonone) works.
Just a couple of follow-up questions, if you don’t mind.
1. When I was running all of your libs, I learned C-MB2 let me choose colors from a lovely pallet. But I could not figure how to save those colors. Usual Emacs customize/save didn’t get it.
2. In emacs 23.1 on Ubuntu, the toolbar buttons are gone and the buttons menu item has no effect. There’s no error in message. I found I can just disable the tool-bar+ in the start file, but wondered if you know anything about this.
3. I want to put the minibuffer back onto the frame’s bottom. The Compiz window manager kept pushing it down off the bottom of the page, I couldn’t stand it. Comments in emacs-init seem to indicate this should work, but doesn’t:
(defvar 1on1-separate-minibuffer-frame-flag nil)
But I did find a change in oneonone.el that got the job done…
(defcustom 1on1-minibuffer-frame-flag nil
I notice the slight inconsistency with the word “separate” in those commands.
4. I like this option you have in the init file:
(defvar fit-frame-max-height-percent 82)
It seems to me that ought to work even after I change to use (require ‘oneonone), but it doesn’t. I kept fit-frame.el in the lib directory. What do you think?
In any case, I’m finding this to be very educational. Thanks for the help. – pj
OK, that comment about checking back often was generic. Maybe I should be clearer. I should probably also warn people about trying start.el and start-opt.el. Those are meant mainly as food for thought/experimentation, in case they help. They should not be simply used as is, especially by someone starting out. I use them, but I’m probably the only one for whom they make sense.
1. I guess you’re referring to palette.el? What do mean by “saving” a color? What is it that you want to do?
2. No, I wasn’t aware that Buttons doesn’t work in Ubuntu. Can you try to debug it a bit, if you have the time? To do that, load tool-bar+.el (not
‘M-x debug-on-entry RET show-tool-bar-for-one-command’. Step through the debugger using
‘c’ to skip descending into a given function).
But if you do want a standalone minibuffer, it should work correctly, being put by default at the bottom of your display. I’m not sure whether you’re saying that you don’t want it or you do want it but it didn’t work correctly.
4. What do you mean by it not working? Give me a recipe/description of the problem. Yes, it should work with
oneonone.el. I use both together. See the doc in fit-frame.el about
Thx – DrewAdams
Thanks for your patience.
So you understand what I’m after. I’ve got to teach people how to write programs, we need Emacs because it exists on all platforms and has some particular modes we need, but its weird behaviors really bother me. I show students how to install Emacs on Windows, but it is still very confusing. Buffer content does not “stay” where we try to put it. Emacs splits the frame to show a new buffer, and then it will hide a buffer I’m trying to work on. If I’m running Emacs with ESS, for example, Emacs compulsively wants to create horizontal split windows and then re-assign buffers among windows. As you pointed out, Emacs is very serious about keeping everything in one frame. I don’t want Emacs to try to be the window manager, I want to let X and the OS handle that. I just want Emacs to pop up a separate frame for every single buffer it spawns, and optimally, I want to use your fit frame approach as well. So I’m more or less trying to figure out what is necessary from your framework. (Well, that’s enough venting for now.)
Concerning the questions:
1. How can I save the color settings between sessions? Your palette thing works well. Fun, in fact. However, you don’t explain how to save the color assignments permanently. It’s a drag to have to re-set them every time.
2. I’m stumped on debugging Buttons.
I run “M-x load library tool-bar+” and the message buffer says Loading /home/pauljohn/DrewEmacsLibs/tool-bar+.el (source)…done
However, I never get a Backtrace buffer to open up. I click on “Buttons” in Menu, nothing happens. However, this does work to pop up the menu bar:
That toggles the bar on and off. Appears to me the problem is the mouse-click on “buttons” is not linked to the tool bar mode.
3. I do NOT want the detached minibuffer. I think I’ve got that one solved. The practical problem with the separate minibuffer is just that the Compiz window manager and the gnome bottom panel make the minibuffer hard to use. Compiz pushes the minibuffer down under the panel. Plus I think I don’t really want a detached minibuffer. If I have several code frames open, it is conceptually more clear to have the minibuffer fastened to the bottom of each one. If I’m interacting with more than one frame, it seems ambiguous to try to have just the one minibuffer.
4. I mean it has no effect--the Emacs frame’s size is still too big. If I use your whole setup, the frame is resized nicely. Emacs pops open with a large frame, but the system wrestles it back within the display. Frames stay nicely within the display. The default Emacs on this system has a bad tendency to pop open so the menu bar is forced off the bottom of the screen. I’ve used some settings to stop that in the past, but your 82% idea seems cleaner.
But that’s just a minor thing. Getting the one-frame-per-buffer thing to work with the frame fitter would be awesome.
I wonder if I’m not getting your modules running in the proper way. In the top of your el files, eg fit-frame.el, the instructions say things like:
However, I notice that when you call for that same thing in frame+.el, your command is
(require 'fit-frame nil t)
What is `nil t’ here? Should I use that in
~/.emacs when trying to activate things? – pj
1. You still haven’t said what you mean by “saving” a “color setting” or “color assignment”. I have no idea what you mean. Each face has a foreground and background color. Each frame has a foreground and background color. The frame colors are, by default, the colors of face
You can customize any face to have any colors you want. Other than this, I cannot imagine what you mean by setting or saving colors.
2. Did you do as I suggested:
M-x debug-on-entry RET show-tool-bar-for-one-command RET
If not, the debugger will not open when function `show-tool-bar-for-one-command ‘ is invoked.
3. If you did want a standalone minibuffer frame, then the problem of its positioning is easily solved. See option
‘1on1-minibuffer-frame-top/bottom’. If the option is
‘nil’ then the function of the same name is used instead, and that positions the frame just above the bottom of your display. That function knows nothing about the Gnome bottom panel (there is no way to know about it), so if you need to adjust the height then customize the option:
M-x customize-option RET 1on1-minibuffer-frame-top/bottom RET
If you in any case do not want a standalone minibuffer frame, then what is the question you have here?
4. I don’t understand the question about
‘fit-frame-max-height-percent’. I guess you are saying that when you use
‘fit-frame-max-height-percent’ has no effect. Is that correct? I don’t see how that could be true. Is
‘nil’? (It must be, for
‘fit-frame-max-height-percent’ to have any effect.)
You can follow what happens when a frame is fit, by debugging function
M-x debug-on-entry RET fit-frame-max-height RET
That should let you see the problem. The function bases the max frame height on a percentage of the display height. And the display height includes your Gnome bottom panel. Try a smaller number than 82 to see if you notice a difference.
(You can cancel debugging of a given function using command
‘C-h f RET require RET’ to learn about
(require 'foo nil t) means load library
foo if it has not already been loaded, but do not raise an error if the library is not found.
(require 'foo) is the same but raises an error if the library is not found. That’s the only difference. I call the former a “soft
‘require’”. So a library that soft-requires
fit-frame.el loads it if it is in your
‘load-path’ but raises no error if cannot be found. IOW, for that library, library
fit-frame.el is just a nice-to-have; it is not strictly required. – DrewAdams
OK, lets tackle one thing at a time. About colors. I don’t understand what you don’t understand :) Emacs does not remember the color choices I make inside your system. Your Emacs has blue background. I hate that. I do C-middle button to bring up the palette chooser, make the background white again. I try the usual menu Options /Save Options, but the color choice I make is not remembered when I close/restart Emacs. If I change background/foreground colors in Emacs in the ordinary way--without your libraries installed--I’m pretty sure Options Save Options does record the colors. As it is, Options Save Options drops this on the end of my ~/.emacs:
(custom-set-faces ;; custom-set-faces was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(diff-added ((t (:foreground "DarkGreen"))) t) '(diff-changed ((t (:foreground "MediumBlue"))) t) '(diff-context ((t (:foreground "Black"))) t) '(diff-file-header ((t (:foreground "Red" :background "White"))) t) '(diff-header ((t (:foreground "Red"))) t) '(diff-hunk-header ((t (:foreground "White" :background "Salmon"))) t) '(diff-index ((t (:foreground "Green"))) t) '(diff-nonexistent ((t (:foreground "DarkBlue"))) t) '(diff-removed ((t (:foreground "DarkMagenta"))) t))
Close, restart. Still blue background. See what I mean? Color choices not saved.
I don’t have any progress to report on the debugger thing. I’ll keep trying. I’m going to look for a local user who has done this.
Sorry, PJ, I just now noticed your reply, so this is a very late response (5 months!).
The default background color is controlled in Emacs by option
‘default-frame-alist’. If you use oneonone.el then you can customize option
If you use doremi-frm.el to change things like the background, only the current value is changed. To save the changes use
‘M-x customize-customized’ to see which options have been modified, then save any that you want to keep.
But see also this comment in
;; There is no single variable for saving changes to parameters of ;; the current frame. Instead, there are several different ;; frame-alist variables, which you can use to define different ;; kinds of frames. These include: `default-frame-alist', ;; `initial-frame-alist', and `special-display-frame-alist'. The ;; complete list of such frame alist variables is available using ;; function `frame-alist-var-names', defined in library ;; `frame-cmds.el'. ;; ;; Example: Suppose you change the background color of a frame and ;; want to make that the default background color for new frames in ;; the future. You will need to update the value of variable ;; `default-frame-alist' to use the `background-color' parameter ;; setting of the changed frame. ;; ;; You can easily copy one or all parameter values from any given ;; frame to any frame alist (such as `default-frame-alist'), by ;; using the commands `set-frame-alist-parameter-from-frame' and ;; `set-all-frame-alist-parameters-from-frame'. Those commands are ;; defined in library `frame-cmds.el'.
HTH. Again, sorry I didn’t notice your reply sooner. – DrewAdams
Drew - Long ago I evaluated Emacs’ Windows and Frames model and have revisited many times since as new things come along that cause me to feel the need to reevaluate my decisions. Your OOOE (no offense but that’s a crappy acronym :-) was another shiny new toy that made me consider how I want to use Windows and Frames.
I’ll start out by saying that your statement that Frames should be called Windows except for historical reason is absolutely correct. When Frames came out I argued for a giant renaming of about everything in Emacs (maybe it was XEmacs - think Emacs had crappy frames first but XEmacs had usable frames first). I know the rename would have been excruciating but back then the Emacs code base was considerably smaller. I’m not sure I really was for the rename. I was for some serious discussion. But nobody wanted to talk about it. As the rename would have meant a boat-load of work for the people in the discussion so it was sort of a lost cause. But the fact that you need to make clarifying statements about Frames and Windows 20 years after I said they should be renamed, yet again, makes me question that the question was summarily rejected.
I agree with your statement that Emacs treats Frames as a 2nd class citizen. Once they were added, they should have been given the attention they deserved. That you needed to rewrite some common Emacs commands to use frames is proof of the inattention they’ve been given.
But, and I recognize that this is a personal matter of taste, simply hate frames. Perhaps if they were really well integrated into Emacs I might use them — but I don’t think so. IMO, without OOOE, I see little value in frames. But with OOOE Emacs stops becoming a window manager and you just use your native desktop’s window manager to manager Emacs windows along with other windows. I frequently pop back and forth from Emacs and my browser so I see a big gain there.
That being said, I only have one browser window. At the moment it has about 30 tabs open in it, but it is only one window. The only time I create a second window is if I need to look at multiple pages at the same time. I’ve tried lots of Firefox extensions to display two tabs in one window but find them awkward and unstable. And, it is rare that I want to do that.
My personal thought is that I don’t see myself as likely to use Frames, but I think your extension is slick and wish that the core of Emacs would give Frames more attention. Back when everything was run on glass TTYs, lots of programs divided your screen up into sections (especially some good games) so Emacs’ Windows were natural. But now, virtually nothing splits the viewable space into separate Windows. Instead, they use the OS’s windows. So, IMO, out of the box, Emacs Windows should be completely disabled. You have Frames and tabs.
Many of the nerdier crowd prefer to keep more control than the OS window managers tend to give you. But nobody becomes an Emacs guru overnight.
In any case, think this is a great extension but wish you didn’t need to write it because Emacs did it out of the box.
May 25, 2011 at 04:15 ET (GMT-04:00) – NeilSmithline
PS: Ramblings like this seem much more forum oriented than the wiki can provide.
Hi Neil. Interesting read. I agree with much (most) of what you say.
Wrt use of things like tabs, windows, and frames – people are different (very!), and they use computers, and Emacs, differently and for different purposes. I don’t expect anyone in particular to want to use Emacs and its thingies the same way I do. Like many others, I just publish my own customizations in case someone finds them useful, either as is or as inspiration for their own customizations.
Wrt One-On-One-Emacs taking away from using Emacs as a window manager – I don’t see that at all. I can see that it can let you take advantage of your computer’s window manager a bit more, but I don’t see how it prevents you in any way from using Emacs itself to control things.
In addition, o-o-o-e (and some other libraries) let you do things with frames that you cannot do with ordinary window-manager windows.
For instance, I really wish I could, with regular win-mgr windows, move them around and resize them easily using the keyboard. I’m in such a habit of doing that with Emacs frames that I find myself really missing that for non-Emacs windows. I use `
C-M-(left|right|up|down)’ to resize frames incrementally, and I use `
M-(left|right|up|down)’ to move them around.
I also use thumbnail frames (FisheyeWithThumbs) a lot. I would love to be able to have such live icons also for ordinary (non-Emacs) window-manager windows.
Anyway, I enjoyed your post. – DrewAdams
Curse you Drew. Today I decided to give OneOneOneEmacs? a try. My real objection to solution such as OOOE is not that they are inherently wrong. The problem is that none of them is enough. Emacs, despite the claims of some, cannot be your window manager.
25 years ago, back when you had a single 80x24 green-on-black terminal, many people made Emacs their login shell. Didn’t seem a good idea to me then because, even after terminal emulator came out, you really couldn’t run some programs inside of Emacs (ie: NetHack?).
I would be very happy, like jumping up and clicking my heels happy, if Emacs could be my desktop/window manager. But for 25 years people are complaining about it being single-threaded. Now they have done some amazing things with a single threaded process, but I’m not going to make my desktop single-threaded.
Apple’s solution to their single-threaded OS was to buy another OS and make it look like Mac OS (albeit there was incest as Steve Jobs bought his own company).
And I can’t stomach the layers of key bindings and behaviors. Starting at the bottom, you have the BIOS with the power button and the Ctrl-Alt-Del. Then you have the basic window keyboard shortcuts and mouse actions. Then you have app specific bindings. You also have tools that sit on top of everything (eg: MacroExpress?, screen snapshot tools, copy-paste histories) that add new functionality. Everything is just a big jumble.
And, in terms of customizability, nothing really rivals Emacs.
My general feeling is that things aren’t getting better. Sure the processors are faster and the graphics sexier and “Wired Magazine” seemed cool name for about 2 years until it looked dumb not being named “Wireless”.
But there still is the fragmentation across the layers of the machine. The original Lisp machines from MIT and its spawn (where Emacs began) was a well integrated device. I used to get confused sometimes forgetting that I was in the command sell and not the editor. There was so little difference.
Just general crankiness about the lack of progress I’ve seen in OSs in general.
– NeilSmithline at July 11, 2011 at 02:03 ET (GMT-04:00)
PS: Aquamacs comes with OneBufferOneFrame? (OBOF). Never tried it but it may work.