I run an email client in a separate emacs window (usually connecting to gnuserv), for example,
emacs -f wl
(the email client being Wanderlust, which probably doesn't matter much).
Is it possible to make emacs remember my preferred
window layout,
main window dimensions,
fonts, colours, etc.,
to set these up only when wl is called? Roughly speaking, if I want to have black background in the email client but white otherwise?
I'm especially interested in keeping the window layout because the default one has to be manually adjusted every time wl is loaded.
There is default-frame-alist variable that allows you to specify the default appearance and behavior for a new frame (frame is what you call a seperate Emacs window). Though it overrides the settings for all frame, you can advise your function to mask its global value and set it yours. Something like this:
(defadvice wl (around wl-frame-settings activate)
(let ((default-frame-alist (append
'((width . 82) (height . 36)
(cursor-color . "#ffa200")
(tool-bar-lines . 0)
;; ...
)
default-frame-alist)))
ad-do-it))
As TJ pointed out, this solution might have a drawback that it gets invoked too late. TJ's wlwrapper may be a better way.
Building on Török Gábor's answer, you can use any of a number of packages to store and restore window/frame configurations, many are listed here. The various window layout packages all have their quirks, so you'll have to find which one you like (there are so many packages b/c everyone finds something they don't like about the existing packages and roll their own).
With respect to fonts and colors, some can be customized on a frame-by-frame basis, see the info page for frame parameters.
With respect to how to hook it to the function 'wl, you can use advice if you want (I love using it), but it might be much more straight-forward to just either customize 'wl itself, or write a wrapper which does the frame/window configuration loading and then calls 'wl. Then your invocation might have to change to:
emacs -f wlwrapper
The way your emacsclient is configured (or, for older Emacsen, gnuclient) may be what's causing TG's solution not work. I'd probably use the 'wlwrapper solution, customizing emacsclient to re-use an existing frame, then inside 'wlwrapper modify the 'default-frame-parameters and then call 'wl. That way you ensure you create the frame after the parameters are set.
Something like this untested:
(defun wlwrapper ()
"wrapper for 'wl which sets up window/frame configurations"
(let ((default-frame-alist (append
'((width . 82) (height . 36)
(cursor-color . "#ffa200")
(tool-bar-lines . 0)
;; ...
)
default-frame-alist)))
;; if 'wl doesn't create a frame
(select-frame (make-frame))
(wl)
;; now use which ever window saving package you want
))
Related
I use below code to setup emacs using fullscreen:
(setq initial-frame-alist '( (fullscreen . maximized)))
(setq default-frame-alist '( (fullscreen . fullheight)))
I wish it startup with maximized window, the behavior is almost as expected but the window size firstly with default size, then I can see it changed to maximum size obviously.
How can emacs startup to fullscreen in one step?
Look at the documentation for initial-frame-alist (C-h v initial-frame-alist). In particular, Emacs creates the first frame before reading init.el, so you need to specify these things somewhere other than init.el. Two common ways are to give the --maximized command line option, or to set the X11 resource Emacs.Fullscreen: maximized; either of these are applied before init.el is read and evaluated.
It looks like you're on OS X, which I don't have, and it may be different there.
Update for Emacs 27:
You can set these things in early-init.el, which loads before the GUI starts.
When I start emacs without an x-server running, some of the things in my init.el fail, eg:
(require 'sr-speedbar)
is inappropriate without a graphical server, where I should rather start
(require 'speedbar)
What do emacs experts recommend as an appropriate init.el configuration in instances where emacs can be called as often from no-x modes as x-based modes? Is there an established way to provide a general, parallel experience under either regime or graceful fallback?
A lot depends on what environments you typically run in and what level of
control you need. For example, if you are just wanting to distinguish between
running under a full graphics capable environment, you can use display-graphic-p
e.g.
(when (display-graphic-p)
;; do stuff which needs a graphic display)
However, if you need to distinguish between different platforms, such as when
running under OSX, you would need something like
(when (eq system-type 'darwin)
;; do stuff which should only run when on OSX'))
Finally, for situations where you need to only configure something when running
under a specific window system, you can use something like
(when (eq window-system 'x)
;; only under X window frame))
However, there are some subtleties to be aware of. Some of these variables, such
as window-system are a test of the current frame. So, you need to think about
when the code is executed. For example, if you run emacs as a daemon, what would
be the value of window-system at the time your init is loaded? Likewise, if you
use emacs as a daemon or use emacsclient to open a new 'frame' it may be opened
a either a graphic or a text frame. Sometimes, you may need to create a new
command which wraps around what you want to do and does the test at the point
you execute the command so that it can respond to the specific frame you are in
when you execute the command.
In CEDET, the minor mode semantic-idle-summary-mode displays information about the symbol under point in the echo area. I really like this mode, as it helps me remember, for instance, which arguments the function I'm calling needs.
The problem is, it's a little buggy about displaying in the echo area. Since it automatically activates whenever there's a symbol under point, it sometimes hides useful information that is being displayed in the echo area (after all, that's the area that emacs uses to tell you stuff).
Is there a way to display the summary information somewhere else? A tooltip would be ideal, but one of the ecb frames is acceptable as well.
The first thing that comes to mind is the variable tooltip-use-echo-area which controls where / how tooltips are displayed. When set to t, all tooltips are displayed in the echo area. What is its value on your system? Maybe it would be possible to force cedet to use actual (pop-up) tooltips by setting that variable to nil.
semantic-idle-summary-mode uses the function eldoc-message and a few other eldoc queries to determine when to display messages. This means it should be pretty good at not covering up useful information.
Since eldoc is the preferred mode for providing similar summary information in Emacs Lisp buffers, the best thing would be to configure eldoc, but I didn't see a way to do it since eldoc-message appears configured to always call message.
Anyway, what that means is you can use defadvice to override eldoc-message to use a tooltip, and you will have your solution.
The below snippit is a guess at how to use defadvice, but I didn't give it a try.
(defadvice eldoc-message (around bruce-mode activate)
"Make eldoc display messages as a tooltip."
(if (some condition that means I want to use a tooltip)
(bruce-eldoc-message (ad-get-arg 0))
ad-do-it))
(require 'tooltip)
(defun bruce-eldoc-message (&rest args)
"My version of displaying a message for eldoc."
(if (null (cdr args))
;; One argument
(tooltip-show (car args))
;; Else, use format
(tooltip-show (apply 'format args)))
)
I had a similar need as you,
and I addressed it with this extension.
As you can see on this screenshot,
it shows the function arguments at the point of its invocation, without altering the echo area.
Some neat features are:
Shows you all overloaded functions, including constructors where appropriate.
Highlights in bold the current argument.
Jump to definition functionality for the current function variant.
I've started coding on a 30 inch monitor and am wondering if it's possible to move the minibuffer to the top of the screen in emacs? google searches aren't showing up anything.
Cheers
Nimai Etheridge
Have a look at the documentation for the default-minibuffer-frame and initial-frame-alist vars. It sounds like you may be able to have a separate frame for your minibuffer (which you could position at the top of the screen), and then generate minibufferless frames which utilise it.
Note that in initial-frame-alist it states that "If the value calls for a frame without a minibuffer, and you have not created a minibuffer frame on your own, a minibuffer frame is created according to minibuffer-frame-alist", which sounds like exactly what would be needed.
There are ways of saving and restoring frame configurations, so if this worked you could probably recreate the layout automatically when emacs starts.
Edit:
Very basic example/proof-of-concept below for using this frame arrangement. The minibuffer frame can't be deleted until the frames utilising it have been deleted. You'll run into trouble when you do things like maximising the editor frame, of course, so there would certainly be some work to do to try to make this system work in a more seamless fashion.
(setq default-minibuffer-frame
(make-frame
'((name . "minibuffer")
(width . 80)
(height . 1)
(minibuffer . only)
(top . 0)
(left . 0)
)))
(setq new-frame
(make-frame
'((name . "editor")
(width . 80)
(height . 30)
(minibuffer . nil)
(top . 50)
(left . 0)
)))
Naturally, you can also combine this with scottfrazer's method of moving the modeline to the top.
This could possibly be handled in the window-setup-hook?
You should also look at the built-in frame.el and dframe.el libraries. Functions like dframe-reposition-frame may provide a convenient way of keeping the minibuffer frame 'attached' to the top of the active editing frame.
The variable minibuffer-auto-raise can also be configured to raise the minibuffer frame whenever the minibuffer is activated, which may mitigate the need to have it visible the rest of the time.
I'm pretty sure you can't move the minibuffer itself, but you can sort-of-ish make the mode line be on top:
(setq-default header-line-format mode-line-format) ; Copy mode-line
(setq-default mode-line-format nil) ; Remove mode-line
This will override things like Info that use the header line, but it's probably as close as you'll get without hacking C source.
Use a standalone minibuffer frame. This shows how:
http://www.emacswiki.org/emacs/Dedicated_Minibuffer_Frame
http://www.emacswiki.org/emacs/oneonone.el
Either look at that code to get an idea or just use it directly. You need only customize the minibuffer frame position settings:
1on1-minibuffer-frame-left -- Position of left edge of minibuffer frame, in pixels.
1on1-minibuffer-frame-top/bottom -- Position of top (or bottom) of minibuffer frame, in pixels.
After being stuck on these answers for a good while, I discovered clemera's answer for emacs 26+ to be useful:
For Emacs 26 and later you can use emacs-maple-minibuffer or ivy-posframe if your are using ivy.
Those packages let you configure to popup a minibuffer frame at any position, including the current window top/bottom. The docs of those packages describe how to set them up.
I have created an emacs-23 custom theme using customize-create-theme. It works fine under X (Linux gnome desktop). However, when running under a tty (within gnome-terminal) some of the colors are wrong.
It is not the accuracy of the colors which are a problem (although it would be nice to match them under both situations) but the fact that some are so off as to be unworkable. For example, function names which appear green under X are invisible under the tty, although keywords which appear gold under X also appear gold (or at least some kind of yellow) under the tty.
Perhaps under the tty colors can't be matched exactly and so something similar is being substituted? If so, this doesn't seem to work all the time.
How can I fix this? Is it possible to specify, either in the 'customize' GUI or in the ~/.emacs.d/my-theme.el file, that certain faces only apply to frames displayed on X and others are only for the tty, or something similar?
(I'm interested in getting this, the built-in emacs theming system working rather than using some external color theme system.)
If a color is unavailable on a frame, emacs should try and pick something "close", but that's often very wrong on limited color displays. You should ask emacs how many colors it thinks it has in gnome-terminal either using M-x list-colors-display (to actually view the colors) or run (display-color-cells) in the scratch buffer. If it says you only have 8, you might want to consider changing your TERM environment variable to something like xterm-256color before you start emacs (though I'm not sure how well this actually works in gnome-terminal; I use xterm).
So that might help emacs be able to find a color that's closer, but if it's still wrong, you'll want to do something more drastic, like set the colors based on the window system.
If you're not using daemon mode, you can use something like
(if window-system (set-face-foreground 'font-lock-function-name-face "LightSkyBlue"))
If you use M-x describe-face, it will ask which face you want to describe, defaulting to the one currently at point. You can get the name (and usually the color) from there.
If you are using daemon mode, then you'll want different colors for each frame, in which case you'll need to set the color for the frame in the new frame hook, something more like:
(defun set-new-frame-colors (frame)
"Set colors based on frame type."
(if (window-system frame)
(set-face-forgeground 'font-lock-function-name-face "LightSkyBlue" frame)
(set-face-forgeground 'font-lock-function-name-face "blue" frame)))
(add-hook 'after-make-frame-functions 'set-new-frame-colors)
Alternatively, instead of checking (window-system frame), you could check (length (defined-colors frame)) and base it on how many colors are supported by the system, so that you can have different colors for 8-color vs. 256-color terminals.
You can tell whether or not the current frame is associated with a graphical window by examining the variable window-system. The link has the documentation, but it looks like:
window-system is a variable defined in `C source code'.
Its value is nil
Documentation:
Name of window system through which the selected frame is displayed.
The value is a symbol--for instance, `x' for X windows.
The value is nil if the selected frame is on a text-only-terminal.
So, you can wrap the current theme inside an
(if window-system
;; current theme configuration
)
and then when in an xterm, create a new one that you like, and put that in the else (or another if statement, or unless and when)