28.6 Frame Titles
Every frame has a parameter; this serves as the default for the frame title which window systems typically display at the top of the frame. You can specify a name explicitly by setting the frame property.
Normally you don't specify the name explicitly, and Emacs computes the frame name automatically based on a template stored in the variable . Emacs recomputes the name each time the frame is redisplayed.
This variable specifies how to compute a name for a frame when you have not explicitly specified one. The variable's value is actually a mode line construct, just like , except that the ‘’ and ‘’ constructs are ignored. See Mode Line Data.
This variable specifies how to compute the name for an iconified frame, when you have not explicitly specified the frame title. This title appears in the icon itself.
This variable is set automatically by Emacs. Its value is when there are two or more frames (not counting minibuffer-only frames or invisible frames). The default value of uses so as to put the buffer name in the frame title only when there is more than one frame.
The value of this variable is not guaranteed to be accurate except while processing or .
The 'frame title' (window title) that emacs uses in graphical environments defaults to something like .
Of course emacs lets us customize this, by changing the value of . Emacs accepts many different things there, (see the documentation for and for that), but let's look at an example.
Instead of the default , I find it more useful to include the name of the file I'm working on instead, or, in case of non-file buffers, the buffer name. To do this, I have something like the following in my :(setq frame-title-format '("" invocation-name ": "(:eval (if (buffer-file-name) (abbreviate-file-name (buffer-file-name)) "%b"))))
As you see, is a template for the items that are present in the title bar; i.e.. emacs concatenates the items in the list, and it supports various -constructs, which are replaced with actual values; see below.
In addition to the -constructs, you can use to make emacs evaluate the expression whenever it wants to update the title bar.
is the name of the emacs binary.
replaces the home directory part in file names with ; for very deep paths it might be nice to do some abbreviation as well as some shells do; this is left as an exercise to the reader :)
You can experiment with some other things to put in ; use the construct as above to use emacs-lisp functions, and the various -specifiers which are replaced by certain values; the emacs documentation lists the following:%b -- print buffer name. %f -- print visited file name. %F -- print frame name. %* -- print %, * or hyphen. %+ -- print *, % or hyphen. %& is like %*, but ignore read-only-ness. % means buffer is read-only and * means it is modified. For a modified read-only buffer, %* gives % and %+ gives *. %s -- print process status. %i -- print the size of the buffer. %I -- like %i, but use k, M, G, etc., to abbreviate. %p -- print percent of buffer above top of window, or Top, Bot or All. %P -- print percent of buffer above bottom of window, perhaps plus Top, or print Bottom or All. %n -- print Narrow if appropriate. %t -- visited file is text or binary (if OS supports this distinction). %z -- print mnemonics of keyboard, terminal, and buffer coding systems. %Z -- like %z, but including the end-of-line format. %e -- print error message about full memory. %@ -- print @ or hyphen. @ means that default-directory is on a remote machine. %[ -- print one [ for each recursive editing level. %] similar. %% -- print %. %- -- print infinitely many dashes. Decimal digits after the % specify field width to which to pad.
So, if we'd like to include the host (system) name and some indication of the status of this buffer, we could do something like:(setq frame-title-format '("emacs%@" (:eval (system-name)) ": " (:eval (if (buffer-file-name) (abbreviate-file-name (buffer-file-name)) "%b")) " [%*]"))
Of course, some of the information is available elsewhere already, but it might be clearer in the frame-title. Or not – there's a lot of room for tweaking and experimentation here.