A frame is a screen object that contains one or more Emacs windows (see Windows). It is the kind of object called a “window” in the terminology of graphical environments; but we can’t call it a “window” here, because Emacs uses that word in a different way. In Emacs Lisp, a frame object is a Lisp object that represents a frame on the screen. See Frame Type.
A frame initially contains a single main window and/or a minibuffer window; you can subdivide the main window vertically or horizontally into smaller windows. See Splitting Windows.
A terminal is a display device capable of displaying one or more Emacs frames. In Emacs Lisp, a terminal object is a Lisp object that represents a terminal. See Terminal Type.
There are two classes of terminals: text terminals and
graphical terminals. Text terminals are non-graphics-capable
displays, including xterm and other terminal emulators. On a
text terminal, each Emacs frame occupies the terminal’s entire screen;
although you can create additional frames and switch between them, the
terminal only shows one non-child frame at a time. This frame is
referred to as the top frame of that terminal and can be retrieved
with the function tty-top-frame described below. A top frame may
have child frames (see Child Frames), which will be shown together
with it, but it cannot be a child frame itself.
Graphical terminals, on the other hand, are managed by graphical display systems such as the X Window System, which allow Emacs to show multiple frames simultaneously on the same display.
On GNU and Unix systems, you can create additional frames on any available terminal, within a single Emacs session, regardless of whether Emacs was started on a text or graphical terminal. Emacs can display on both, graphical and text terminals, simultaneously. This comes in handy, for instance, when you connect to the same session from several remote locations. See Multiple Terminals.
This predicate returns a non-nil value if object is a
frame, and nil otherwise. For a frame, the value indicates which
kind of display the frame uses:
tThe frame is displayed on a text terminal.
xThe frame is displayed on an X graphical terminal.
w32The frame is displayed on a MS-Windows graphical terminal.
nsThe frame is displayed on a GNUstep or Macintosh Cocoa graphical terminal.
pcThe frame is displayed on an MS-DOS terminal.
haikuThe frame is displayed using the Haiku Application Kit.
pgtkThe frame is displayed using pure GTK facilities.
androidThe frame is displayed on an Android device.
This function returns the terminal object that displays frame. If
frame is nil or unspecified, it defaults to the selected
frame (see Input Focus).
This predicate returns a non-nil value if object is a
terminal that is live (i.e., not deleted), and nil otherwise.
For live terminals, the return value indicates what kind of frames are
displayed on that terminal; the list of possible values is the same as
for framep above.
This predicate returns non-nil if frame is or holds the
initial text frame that is used internally during daemon mode
(see daemon in The GNU Emacs Manual), batch
mode (see Batch Mode), and the early stages of startup
(see Summary: Sequence of Actions at Startup). Interactive and graphical programs, for
instance, can use this predicate to avoid operating on the initial
frame, which is never displayed.
If frame is a terminal, this function returns non-nil if
frame holds the initial frame. If frame is omitted or
nil, it defaults to the selected one.
On a graphical terminal we distinguish two types of frames: A normal top-level frame is a frame whose window-system window is a child of the window-system’s root window for that terminal. A child frame is a frame whose window-system window is the child of the window-system window of another Emacs frame. See Child Frames.
On a text terminal you can get its top frame with the following function:
This function returns the top frame on terminal. terminal
should be a terminal object, a frame (meaning that frame’s terminal), or
nil (meaning the selected frame’s terminal). If it does not
refer to a text terminal, the return value is nil. A top frame
must be a root frame, which means it cannot be a child frame itself
(see Child Frames), but may have an arbitrary number of child frames
descending from it.
This function returns the unique identifier of a frame, an integer,
assigned to frame. If frame is nil or unspecified,
it defaults to the selected frame (see Input Focus). This can be
used to unambiguously identify a frame in a context where you do not or
cannot use a frame object.
A frame undeleted using undelete-frame will retain its
identifier. A frame cloned using clone-frame will not retain
its original identifier. See Frame Commands in the Emacs
Manual.
Frame identifiers are not persisted using the desktop library
(see Desktop Save Mode), frameset-to-register, or
frameset-save, and each of their restored frames will bear a new
unique id.
To create a new frame, call the function make-frame.
This function creates and returns a new frame, displaying the current buffer.
The parameters argument is an alist that specifies frame
parameters for the new frame. See Frame Parameters. If you specify
the terminal parameter in parameters, the new frame is
created on that terminal. Otherwise, if you specify the
window-system frame parameter in parameters, that
determines whether the frame should be displayed on a text terminal or a
graphical terminal. See Window Systems. If neither is specified,
the new frame is created in the same terminal as the selected frame.
Any parameters not mentioned in parameters default to the values
in the alist default-frame-alist (see Initial Frame Parameters);
parameters not specified there default from the X resources or its
equivalent on your operating system (see X Resources in The GNU Emacs Manual). After the frame is created, this
function applies any parameters specified in
frame-inherited-parameters (see below) it has no assigned yet,
taking the values from the frame that was selected when
make-frame was called.
Note that on multi-monitor displays (see Multiple Terminals), the window manager might position the frame differently than specified by the positional parameters in parameters (see Position Parameters). For example, some window managers have a policy of displaying the frame on the monitor that contains the largest part of the window (a.k.a. the dominating monitor).
This function itself does not make the new frame the selected frame. See Input Focus. The previously selected frame remains selected. On graphical terminals, however, the window system may select the new frame for its own reasons.
By default this function does not display the current buffer in the new
frame if the buffer is hidden, that is, if its name starts with a space.
In this case it will show another buffer—one that could be returned by
the function other-buffer (see The Buffer List)—instead.
However, if the variable expose-hidden-buffer is non-nil,
this function will display the current buffer even if it is hidden.
A normal hook run by make-frame before it creates the frame.
An abnormal hook run by make-frame after it created the frame.
Each function in after-make-frame-functions receives one
argument, the frame just created.
You can consult the frame parameters cloned-from and
undeleted in your function to determine if a frame was cloned
using clone-frame, or if it was undeleted using
undelete-frame. See Frame Parameters.
Note that any functions added to these hooks by your initial file are usually not run for the initial frame, since Emacs reads the initial file only after creating that frame. However, if the initial frame is specified to use a separate minibuffer frame (see Minibuffers and Frames), the functions will be run for both, the minibuffer-less and the minibuffer frame. Alternatively, you can add functions to these hooks in your “early init file” (see The Init File), in which case they will be in effect for the initial frame as well.
This variable specifies the list of frame parameters that a newly
created frame inherits from the currently selected frame. For each
parameter (a symbol) that is an element in this list and has not been
assigned earlier when processing make-frame, the function sets
the value of that parameter in the created frame to its value in the
selected frame.
A normal hook run when the Emacs server starts using a client frame.
When this hook is called, the client frame is the selected one. Note
that, depending on how emacsclient was invoked
(see Invoking emacsclient in The GNU Emacs Manual), this
client frame could be a new frame created for the client, or it could
be an existing frame that the server reused for handling the client
commands. See Emacs Server in The GNU Emacs Manual.
Emacs represents each terminal as a terminal object data type (see Terminal Type). On GNU and Unix systems, Emacs can use multiple terminals simultaneously in each session. On other systems, it can only use a single terminal. Each terminal object has the following attributes:
terminal-live-p (i.e., x,
t, w32, ns, pc, haiku, pgtk,
or android). See Frames.
There is no primitive for creating terminal objects. Emacs creates
them as needed, such as when you call make-frame-on-display
(described below).
This function returns the file name of the device used by
terminal. If terminal is omitted or nil, it
defaults to the selected frame’s terminal. terminal can also be
a frame, meaning that frame’s terminal.
This function returns a list of all live terminal objects.
This function returns a terminal whose device name is given by
device. If device is a string, it can be either the file
name of a terminal device, or the name of an X display of the form
‘host:server.screen’. If device is a
frame, this function returns that frame’s terminal; nil means
the selected frame. Finally, if device is a terminal object
that represents a live terminal, that terminal is returned. The
function signals an error if its argument is none of the above.
This function deletes all frames on terminal and frees the
resources used by it. It runs the abnormal hook
delete-terminal-functions, passing terminal as the
argument to each function.
If terminal is omitted or nil, it defaults to the
selected frame’s terminal. terminal can also be a frame,
meaning that frame’s terminal.
Normally, this function signals an error if you attempt to delete the
sole active terminal, but if force is non-nil, you are
allowed to do so. Emacs automatically calls this function when the
last frame on a terminal is deleted (see Deleting Frames).
An abnormal hook run by delete-terminal. Each function
receives one argument, the terminal argument passed to
delete-terminal. Due to technical details, the functions may
be called either just before the terminal is deleted, or just
afterwards.
A few Lisp variables are terminal-local; that is, they have a
separate binding for each terminal. The binding in effect at any time
is the one for the terminal that the currently selected frame belongs
to. These variables include default-minibuffer-frame,
defining-kbd-macro, last-kbd-macro, and
system-key-alist. They are always terminal-local, and can
never be buffer-local (see Buffer-Local Variables).
On GNU and Unix systems, each X display is a separate graphical
terminal. When Emacs is started from within the X window system, it
uses the X display specified by the DISPLAY environment
variable, or by the ‘--display’ option (see Initial Options in The GNU Emacs Manual). Emacs can connect to other X displays
via the command make-frame-on-display. Each X display has its
own selected frame and its own minibuffer windows; however, only one
of those frames is the selected frame at any given moment
(see Input Focus). Emacs can even connect to other text
terminals, by interacting with the emacsclient program.
See Emacs Server in The GNU Emacs Manual.
A single X server can handle more than one display. Each X display has a three-part name, ‘hostname:displaynumber.screennumber’. The first part, hostname, specifies the name of the machine to which the display is physically connected. The second part, displaynumber, is a zero-based number that identifies one or more monitors connected to that machine that share a common keyboard and pointing device (mouse, tablet, etc.). The third part, screennumber, identifies a zero-based screen number (a separate monitor) that is part of a single monitor collection on that X server. When you use two or more screens belonging to one server, Emacs knows by the similarity in their names that they share a single keyboard.
Systems that don’t use the X window system, such as MS-Windows, don’t support the notion of X displays, and have only one display on each host. The display name on these systems doesn’t follow the above 3-part format; for example, the display name on MS-Windows systems is a constant string ‘w32’, and exists for compatibility, so that you could pass it to functions that expect a display name.
This function creates and returns a new frame on display, taking the other frame parameters from the alist parameters. display should be the name of an X display (a string).
Before creating the frame, this function ensures that Emacs is set
up to display graphics. For instance, if Emacs has not processed X
resources (e.g., if it was started on a text terminal), it does so at
this time. In all other respects, this function behaves like
make-frame (see Creating Frames).
This function returns a list that indicates which X displays Emacs has a connection to. The elements of the list are strings, and each one is a display name.
This function opens a connection to the X display display,
without creating a frame on that display. Normally, Emacs Lisp
programs need not call this function, as make-frame-on-display
calls it automatically. The only reason for calling it is to check
whether communication can be established with a given X display.
The optional argument xrm-string, if not nil, is a string
of resource names and values, in the same format used in the
.Xresources file. See X Resources in The
GNU Emacs Manual. These values apply to all Emacs frames created on
this display, overriding the resource values recorded in the X server.
Here’s an example of what this string might look like:
"*BorderWidth: 3\n*InternalBorder: 2\n"
If must-succeed is non-nil, failure to open the connection
terminates Emacs. Otherwise, it is an ordinary Lisp error.
This function closes the connection to display display. Before you can do this, you must first delete all the frames that were open on that display (see Deleting Frames).
On some multi-monitor setups, a single X display outputs to more
than one physical monitor. You can use the functions
display-monitor-attributes-list and frame-monitor-attributes
to obtain information about such setups.
This function returns a list of physical monitor attributes on
display, which can be a display name (a string), a terminal, or
a frame; if omitted or nil, it defaults to the selected frame’s
display. Each element of the list is an association list,
representing the attributes of a physical monitor. The first element
corresponds to the primary monitor. The attribute keys and values
are:
Position of the top-left corner of the monitor’s screen and its size, in pixels, as ‘(x y width height)’. Note that, if the monitor is not the primary monitor, some of the coordinates might be negative.
Position of the top-left corner and size of the work area (usable space) in pixels as ‘(x y width height)’. This may be different from ‘geometry’ in that space occupied by various window manager features (docks, taskbars, etc.) may be excluded from the work area. Whether or not such features actually subtract from the work area depends on the platform and environment. Again, if the monitor is not the primary monitor, some of the coordinates might be negative.
Width and height in millimeters as ‘(width height)’
List of frames that this physical monitor dominates (see below).
Name of the physical monitor as string.
Source of the multi-monitor information as string; on X, it could be ‘XRandR 1.5’, ‘XRandr’, ‘Xinerama’, ‘Gdk’, or ‘fallback’. The last value of ‘source’ means that Emacs was built without GTK and without XRandR or Xinerama extensions, in which case the information about multiple physical monitors will be provided as if they all as a whole formed a single monitor.
x, y, width, and height are integers. ‘name’ and ‘source’ may be absent.
A frame is dominated by a physical monitor when either the largest area of the frame resides in that monitor, or (if the frame does not intersect any physical monitors) that monitor is the closest to the frame. Every (non-tooltip) frame (whether visible or not) in a graphical display is dominated by exactly one physical monitor at a time, though the frame can span multiple (or no) physical monitors.
Here’s an example of the data produced by this function on a 2-monitor display:
(display-monitor-attributes-list) ⇒ (((geometry 0 0 1920 1080) ;; Left-hand, primary monitor (workarea 0 0 1920 1050) ;; A taskbar occupies some of the height (mm-size 677 381) (name . "DISPLAY1") (frames #<frame emacs@host *Messages* 0x11578c0> #<frame emacs@host *scratch* 0x114b838>)) ((geometry 1920 0 1680 1050) ;; Right-hand monitor (workarea 1920 0 1680 1050) ;; Whole screen can be used (mm-size 593 370) (name . "DISPLAY2") (frames)))
This function returns the attributes of the physical monitor dominating (see above) frame, which defaults to the selected frame.
On multi-monitor displays it is possible to use the command
make-frame-on-monitor to make frames on the specified monitor.
This function creates and returns a new frame on monitor located
on display, taking the other frame parameters from the alist
parameters. monitor should be the name of the physical
monitor, the same string as returned by the function
display-monitor-attributes-list in the attribute name.
display should be the name of an X display (a string).
This variable is an abnormal hook run when the monitor configuration
changes, which can happen if a monitor is rotated, moved, added or
removed from a multiple-monitor setup, if the primary monitor changes,
or if the resolution of a monitor changes. It is called with a single
argument consisting of the terminal on which the monitor configuration
changed. Programs should call display-monitor-attributes-list
with the terminal as the argument to retrieve the new monitor
configuration on that terminal.
The geometry of a frame depends on the toolkit that was used to build
this instance of Emacs and the terminal that displays the frame. This
chapter describes these dependencies and some of the functions to deal
with them. Note that the frame argument of all of these functions
has to specify a live frame (see Deleting Frames). If omitted or
nil, it specifies the selected frame (see Input Focus).
A visible frame occupies a rectangular area on its terminal’s display. This area may contain a number of nested rectangles, each serving a different purpose. The drawing below sketches the layout of a frame on a graphical terminal:
<------------ Outer Frame Width ----------->
____________________________________________
^(0) ________ External/Outer Border _______ |
| | |_____________ Title Bar ______________| |
| | (1)_____________ Menu Bar ______________| | ^
| | (2)_____________ Tool Bar ______________| | ^
| | (3)_____________ Tab Bar _______________| | ^
| | | _________ Internal Border ________ | | ^
| | | | ^ | | | |
| | | | | | | | |
Outer | | | Inner | | | Native
Frame | | | Frame | | | Frame
Height | | | Height | | | Height
| | | | | | | | |
| | | |<--+--- Inner Frame Width ------->| | | |
| | | | | | | | |
| | | |___v______________________________| | | |
| | |___________ Internal Border __________| | |
| | (4)__________ Bottom Tool Bar __________| | v
v |___________ External/Outer Border __________|
<-------- Native Frame Width -------->
In practice not all of the areas shown in the drawing will or may be present. The meaning of these areas is described below.
The outer frame is a rectangle comprising all areas shown in the drawing. The edges of that rectangle are called the outer edges of the frame. Together, the outer width and outer height of the frame specify the outer size of that rectangle.
Knowing the outer size of a frame is useful for fitting a frame into the working area of its display (see Multiple Terminals) or for placing two frames adjacent to each other on the screen. Usually, the outer size of a frame is available only after the frame has been mapped (made visible, see Visibility of Frames) at least once. For the initial frame or a frame that has not been created yet, the outer size can be only estimated or must be calculated from the window-system’s or window manager’s defaults. One workaround is to obtain the differences of the outer and native (see below) sizes of a mapped frame and use them for calculating the outer size of the new frame.
The position of the upper left corner of the outer frame (indicated by ‘(0)’ in the drawing above) is the outer position of the frame. The outer position of a graphical frame is also referred to as “the position” of the frame because it usually remains unchanged on its display whenever the frame is resized or its layout is changed.
The outer position is specified by and can be set via the left
and top frame parameters (see Position Parameters). For a
normal, top-level frame these parameters usually represent its absolute
position (see below) with respect to its display’s origin. For a child
frame (see Child Frames) these parameters represent its position
relative to the native position (see below) of its parent frame. For
root frames (see Child Frames) on text terminals the values of these
parameters are meaningless and always zero.
The external border is part of the decorations supplied by the window manager. It is typically used for resizing the frame with the mouse and is therefore not shown on “fullboth” and maximized frames (see Size Parameters). Its width is determined by the window manager and cannot be changed by Emacs’s functions.
External borders don’t exist on text terminal frames. For graphical
frames, their display can be suppressed by setting the
override-redirect or undecorated frame parameter
(see Window Management Parameters).
The outer border is a separate border whose width can be specified
with the border-width frame parameter (see Layout Parameters). In practice, either the external or the outer border of a
frame are displayed but never both at the same time. Usually, the outer
border is shown only for special frames that are not (fully) controlled
by the window manager like tooltip frames (see Tooltips), child
frames (see Child Frames) and undecorated or
override-redirect frames (see Window Management Parameters).
As a rule, outer borders are never shown on text terminal frames and on
frames generated by GTK+ routines. For a child frame on a text terminal
you can emulate the outer border by setting the undecorated
parameter of that frame to nil (see Layout Parameters). On
MS-Windows, the outer border is emulated with the help of a one pixel
wide external border. Non-toolkit builds on X allow changing the color
of the outer border by setting the border-color frame parameter
(see Layout Parameters).
The title bar, a.k.a. caption bar, is also part of the
window manager’s decorations and typically displays the title of the
frame (see Frame Titles) as well as buttons for minimizing,
maximizing and deleting the frame. It can be also used for dragging
the frame with the mouse. The title bar is usually not displayed for
fullboth (see Size Parameters), tooltip (see Tooltips) and
child frames (see Child Frames) and doesn’t exist for terminal
frames. Display of the title bar can be suppressed by setting the
override-redirect or the undecorated frame parameters
(see Window Management Parameters).
The menu bar (see The Menu Bar) can be either internal (drawn by Emacs
itself) or external (drawn by the toolkit). Most builds (GTK+, Lucid,
Motif and MS-Windows) rely on an external menu bar. NS also uses an
external menu bar which, however, is not part of the outer frame.
Non-toolkit builds can provide an internal menu bar. On text terminal
frames, the menu bar is part of the frame’s root window (see Windows and Frames). As a rule, menu bars are never shown on child frames
(see Child Frames). Display of the menu bar can be suppressed by
setting the menu-bar-lines parameter (see Layout Parameters)
to zero.
Whether the menu bar is wrapped or truncated whenever its width becomes too large to fit on its frame depends on the toolkit . Usually, only Motif and MS-Windows builds can wrap the menu bar. When they (un-)wrap the menu bar, they try to keep the outer height of the frame unchanged, so the native height of the frame (see below) will change instead.
Like the menu bar, the tool bar (see Tool bars) can be either
internal (drawn by Emacs itself) or external (drawn by a toolkit). The
GTK+ and NS builds have the tool bar drawn by the toolkit. The
remaining builds use internal tool bars. With GTK+ the tool bar can be
located on either side of the frame, immediately outside the internal
border, see below. Tool bars are usually not shown for child frames
(see Child Frames). Display of the tool bar can be suppressed by
setting the tool-bar-lines parameter (see Layout Parameters) to zero.
If the variable auto-resize-tool-bars is non-nil, Emacs
wraps the internal tool bar when its width becomes too large for its
frame. If and when Emacs (un-)wraps the internal tool bar, it by
default keeps the outer height of the frame unchanged, so the native
height of the frame (see below) will change instead. Emacs built with
GTK+, on the other hand, never wraps the tool bar but may
automatically increase the outer width of a frame in order to
accommodate an overlong tool bar.
The tab bar (see Tab Bars in The GNU Emacs Manual) is always
drawn by Emacs itself. The tab bar appears above the tool bar in
Emacs built with an internal tool bar, and below the tool bar in
builds with an external tool bar.
Display of the tab bar can be suppressed by setting the
tab-bar-lines parameter (see Layout Parameters) to zero.
The native frame is a rectangle located entirely within the outer frame. It excludes the areas occupied by an external or outer border, the title bar and any external menu or tool bar. The edges of the native frame are called the native edges of the frame. Together, the native width and native height of a frame specify the native size of the frame.
The native size of a frame is the size Emacs passes to the window-system or window manager when creating or resizing the frame from within Emacs. It is also the size Emacs receives from the window-system or window manager whenever these resize the frame’s window-system window, for example, after maximizing the frame by clicking on the corresponding button in the title bar or when dragging its external border with the mouse.
The position of the top left corner of the native frame specifies the native position of the frame. (1)–(3) in the drawing above indicate that position for the various builds:
Accordingly, the native height of a frame may include the height of the tool bar but not that of the menu bar (Lucid, Motif, MS-Windows) or those of the menu bar and the tool bar (non-toolkit and text terminal frames).
If the native position would otherwise be (2), but the tool bar is placed at the bottom of the frame as depicted in (4), the native position of the frame becomes that of the tab bar.
The native position of a frame is the reference position for functions
that set or return the current position of the mouse (see Mouse Position) and for functions dealing with the position of windows like
window-edges, window-at or coordinates-in-window-p
(see Coordinates and Windows). It also specifies the (0, 0) origin
for locating and positioning child frames within this frame
(see Child Frames).
Note also that the native position of a frame usually remains unaltered
on its display when removing or adding the window manager decorations by
changing the frame’s override-redirect or undecorated
parameter (see Window Management Parameters).
The internal border is a border drawn by Emacs around the inner frame (see below). The specification of its appearance depends on whether or not the given frame is a child frame (see Child Frames).
For normal frames its width is specified by the internal-border-width
frame parameter (see Layout Parameters), and its color is specified by the
background of the internal-border face.
For child frames its width is specified by the child-frame-border-width
frame parameter (but will use the internal-border-width parameter as
fallback), and its color is specified by the background of the
child-frame-border face.
The inner frame is the rectangle reserved for the frame’s windows. It’s enclosed by the internal border which, however, is not part of the inner frame. Its edges are called the inner edges of the frame. The inner width and inner height specify the inner size of the rectangle. The inner frame is sometimes also referred to as the display area of the frame.
As a rule, the inner frame is subdivided into the frame’s root window (see Windows and Frames) and the frame’s minibuffer window (see Minibuffer Windows). There are two notable exceptions to this rule: A minibuffer-less frame contains a root window only and does not contain a minibuffer window. A minibuffer-only frame contains only a minibuffer window which also serves as that frame’s root window. See Initial Frame Parameters, for how to create such frame configurations.
The text area of a frame is a somewhat fictitious area that can be embedded in the native frame. Its position is unspecified. Its width can be obtained by removing from that of the native width the widths of the internal border, one vertical scroll bar, and one left and one right fringe if they are specified for this frame, see Layout Parameters. Its height can be obtained by removing from that of the native height the widths of the internal border and the heights of the frame’s internal menu and tool bars, the tab bar and one horizontal scroll bar if specified for this frame.
The absolute position of a frame is given as a pair (X, Y) of horizontal and vertical pixel offsets relative to an origin (0, 0) of the frame’s display. Correspondingly, the absolute edges of a frame are given as pixel offsets from that origin.
Note that with multiple monitors, the origin of the display does not necessarily coincide with the top-left corner of the entire usable display area of the terminal. Hence the absolute position of a frame can be negative in such an environment even when that frame is completely visible.
By convention, vertical offsets increase “downwards”. This means that the height of a frame is obtained by subtracting the offset of its top edge from that of its bottom edge. Horizontal offsets increase “rightwards”, as expected, so a frame’s width is calculated by subtracting the offset of its left edge from that of its right edge.
For a frame on a graphical terminal the following function returns the sizes of the areas described above:
This function returns geometric attributes of frame. The return value is an association list of the attributes listed below. All coordinate, height and width values are integers counting pixels. Note that if frame has not been mapped yet, (see Visibility of Frames) some of the return values may only represent approximations of the actual values—those that can be seen after the frame has been mapped.
outer-positionA cons representing the absolute position of the outer frame, relative to the origin at position (0, 0) of frame’s display.
outer-sizeA cons of the outer width and height of frame.
external-border-sizeA cons of the horizontal and vertical width of frame’s external borders as supplied by the window manager. If the window manager doesn’t supply these values, Emacs will try to guess them from the coordinates of the outer and inner frame.
outer-border-widthThe width of the outer border of frame. The value is meaningful for non-GTK+ X builds only.
title-bar-sizeA cons of the width and height of the title bar of frame as supplied by the window manager or operating system. If both of them are zero, the frame has no title bar. If only the width is zero, Emacs was not able to retrieve the width information.
menu-bar-externalIf non-nil, this means the menu bar is external (not part of the
native frame of frame).
menu-bar-sizeA cons of the width and height of the menu bar of frame.
tool-bar-externalIf non-nil, this means the tool bar is external (not part of the
native frame of frame).
tool-bar-positionThis tells on which side the tool bar on frame is and can be one
of left, top, right or bottom.
The values left and right are only supported on builds
using the GTK+ toolkit; bottom is supported on all builds other
than NS, and top is supported everywhere.
tool-bar-sizeA cons of the width and height of the tool bar of frame.
internal-border-widthThe width of the internal border of frame.
The following function can be used to retrieve the edges of the outer, native and inner frame.
This function returns the absolute edges of the outer, native or inner
frame of frame. frame must be a live frame and defaults to
the selected one. The returned list has the form (left top right bottom) where all values are in pixels
relative to the origin of frame’s display. For terminal frames
the values returned for left and top are always zero.
Optional argument type specifies the type of the edges to return:
outer-edges means to return the outer edges of frame,
native-edges (or nil) means to return its native edges and
inner-edges means to return its inner edges.
By convention, the pixels of the display at the values returned for left and top are considered to be inside (part of) frame. Hence, if left and top are both zero, the pixel at the display’s origin is part of frame. The pixels at bottom and right, on the other hand, are considered to lie immediately outside frame. This means that if you have, for example, two side-by-side frames positioned such that the right outer edge of the frame on the left equals the left outer edge of the frame on the right, the pixels at that edge show a part of the frame on the right.
Each frame has a default font which specifies the default character size for that frame. This size is meant when retrieving or changing the size of a frame in terms of columns or lines (see Size Parameters). It is also used when resizing (see Window Sizes) or splitting (see Splitting Windows) windows.
The terms line height and canonical character height are sometimes used instead of “default character height”. Similarly, the terms column width and canonical character width are used instead of “default character width”.
These functions return the default height and width of a character in frame, measured in pixels. Together, these values establish the size of the default font on frame. The values depend on the choice of font for frame, see Font and Color Parameters.
The default font can be also set directly with the following function:
This sets the default font to font. When called interactively, it prompts for the name of a font, and uses that font on the selected frame. When called from Lisp, font should be a font name (a string), a font object, font entity, or a font spec.
If the optional argument keep-size is nil, this keeps the
number of frame lines and columns fixed. (If non-nil, the option
frame-inhibit-implied-resize described in the next section will
override this.) If keep-size is non-nil (or with a prefix
argument), it tries to keep the size of the display area of the current
frame fixed by adjusting the number of lines and columns.
If the optional argument frames is nil, this applies the
font to the selected frame only. If frames is non-nil, it
should be a list of frames to act upon, or t meaning all existing
and all future graphical frames.
On graphical systems, the position of a normal top-level frame is specified as the absolute position of its outer frame (see Frame Geometry). The position of a child frame (see Child Frames) is specified via pixel offsets of its outer edges relative to the native position of its parent frame.
You can access or change the position of a frame using the frame
parameters left and top (see Position Parameters).
Here are two additional functions for working with the positions of an
existing, visible frame. For both functions, the argument frame
must denote a live frame and defaults to the selected frame.
For a normal, non-child frame this function returns a cons of the pixel
coordinates of its outer position (see Frame Layout) with respect to
the origin (0, 0) of its display. For a child frame
(see Child Frames) this function returns the pixel coordinates of
its outer position with respect to an origin (0, 0) at the native
position of frame’s parent.
Negative values never indicate an offset from the right or bottom edge of frame’s display or parent frame. Rather, they mean that frame’s outer position is on the left and/or above the origin of its display or the native position of its parent frame. This usually means that frame is only partially visible (or completely invisible). However, on systems where the display’s origin does not coincide with its top-left corner, the frame may be visible on a secondary monitor.
On a text terminal frame both values are zero for root frames (see Child Frames).
This function sets the outer frame position of frame to (x, y). The latter arguments specify pixels and normally count from the origin at the position (0, 0) of frame’s display. For child frames, they count from the native position of frame’s parent frame.
Negative parameter values position the right edge of the outer frame by -x pixels left from the right edge of the screen (or the parent frame’s native rectangle) and the bottom edge by -y pixels up from the bottom edge of the screen (or the parent frame’s native rectangle).
Note that negative values do not permit aligning the right or bottom
edge of frame exactly at the right or bottom edge of its display
or parent frame. Neither do they allow specifying a position that does
not lie within the edges of the display or parent frame. The frame
parameters left and top (see Position Parameters)
allow doing that, but may still fail to provide good results for the
initial or a new frame.
This function has no effect on text terminal frames.
This hook specifies the functions that are run when an Emacs frame is moved (assigned a new position) by the window-system or window manager. The functions are run with one argument, the frame that moved. For a child frame (see Child Frames), the functions are run only when the position of the frame changes in relation to that of its parent frame.
The canonical way to specify the size of a frame from within Emacs is by specifying its text size—a tuple of the width and height of the frame’s text area (see Frame Layout). It can be measured either in pixels or in terms of the frame’s canonical character size (see Frame Font).
For frames with an internal menu or tool bar, the frame’s native
height cannot be told exactly before the frame has been actually drawn.
This means that in general you cannot use the native size to specify the
initial size of a frame. As soon as you know the native size of a
visible frame, you can calculate its outer size (see Frame Layout)
by adding in the remaining components from the return value of
frame-geometry. For invisible frames or for frames that have
yet to be created, however, the outer size can only be estimated. This
also means that calculating an exact initial position of a frame
specified via offsets from the right or bottom edge of the screen
(see Frame Position) is impossible.
The text size of any frame can be set and retrieved with the help of
the height and width frame parameters (see Size Parameters). The text size of the initial frame can be also set with
the help of an X-style geometry specification. See Command Line Arguments for Emacs Invocation in The GNU Emacs
Manual. Below we list some functions to access and set the size of an
existing, visible frame, by default the selected one.
These functions return the height and width of the text area of
frame, measured in units of the default font height and width of
frame (see Frame Font). These functions are plain shorthands
for writing (frame-parameter frame 'height) and
(frame-parameter frame 'width).
If the text area of frame measured in pixels is not a multiple of its default font size, the values returned by these functions are rounded down to the number of characters of the default font that fully fit into the text area.
The functions following next return the pixel widths and heights of the native, outer and inner frame and the text area (see Frame Layout) of a given frame. For a text terminal, the results are in characters rather than pixels.
These functions return the outer width and height of frame in pixels.
These functions return the native width and height of frame in pixels.
These functions return the inner width and height of frame in pixels.
These functions return the width and height of the text area of frame in pixels.
On window systems that support it, Emacs tries by default to make the text size of a frame measured in pixels a multiple of the frame’s character size. This, however, usually means that a frame can be resized only in character size increments when dragging its external borders. It also may break attempts to truly maximize the frame or making it “fullheight” or “fullwidth” (see Size Parameters) leaving some empty space below and/or on the right of the frame. The following option may help in that case.
If this option is nil (the default), a frame’s text pixel size is
usually rounded to a multiple of the current values of that frame’s
frame-char-height and frame-char-width whenever the frame
is resized. If this is non-nil, no rounding occurs, hence frame
sizes can increase/decrease by one pixel.
Setting this variable usually causes the next resize operation to pass the corresponding size hints to the window manager. This means that this variable should be set only in a user’s initial file; applications should never bind it temporarily.
The precise meaning of a value of nil for this option depends on
the toolkit used. Dragging the external border with the mouse is done
character-wise provided the window manager is willing to process the
corresponding size hints. Calling set-frame-size (see below)
with arguments that do not specify the frame size as an integer multiple
of its character size, however, may: be ignored, cause a rounding
(GTK+), or be accepted (Lucid, Motif, MS-Windows).
With some window managers you may have to set this to non-nil in
order to make a frame appear truly maximized or full-screen.
This function sets the size of the text area of frame, measured in terms of the canonical height and width of a character on frame (see Frame Font).
The optional argument pixelwise non-nil means to measure
the new width and height in units of pixels instead. Note that if
frame-resize-pixelwise is nil, some toolkits may refuse to
truly honor the request if it does not increase/decrease the frame size
to a multiple of its character size.
This function resizes the text area of frame to a height of height lines. The sizes of existing windows in frame are altered proportionally to fit.
If pretend is non-nil, then Emacs displays height
lines of output in frame, but does not change its value for the
actual height of the frame. This is only useful on text terminals.
Using a smaller height than the terminal actually implements may be
useful to reproduce behavior observed on a smaller screen, or if the
terminal malfunctions when using its whole screen. Setting the frame
height directly does not always work, because knowing the correct
actual size may be necessary for correct cursor positioning on
text terminals.
The optional fourth argument pixelwise non-nil means that
frame should be height pixels high. Note that if
frame-resize-pixelwise is nil, some window managers may
refuse to truly honor the request if it does not increase/decrease the
frame height to a multiple of its character height.
When used interactively, this command will ask the user for the number of lines to set the height of the currently selected frame. You can also provide this value with a numeric prefix.
This function sets the width of the text area of frame, measured
in characters. The argument pretend has the same meaning as in
set-frame-height.
The optional fourth argument pixelwise non-nil means that
frame should be width pixels wide. Note that if
frame-resize-pixelwise is nil, some window managers may
refuse to fully honor the request if it does not increase/decrease the
frame width to a multiple of its character width.
When used interactively, this command will ask the user for the number of columns to set the width of the currently selected frame. You can also provide this value with a numeric prefix.
None of these three functions will make a frame smaller than needed to
display all of its windows together with their scroll bars, fringes,
margins, dividers, mode and header lines. This contrasts with requests
by the window manager triggered, for example, by dragging the external
border of a frame with the mouse. Such requests are always honored by
clipping, if necessary, portions that cannot be displayed at the right,
bottom corner of the frame. The parameters min-width and
min-height (see Size Parameters) can be used to obtain a
similar behavior when changing the frame size from within Emacs.
When a frame is in a fullscreen state (see Size Parameters), requests to change the frame size via one of these functions may be supported or refused either by Emacs itself or by the window manager. The following variable provides more control of the resulting behavior.
This options controls how to handle requests to alter fullscreen frames.
Emacs consults it when asked to resize a fullscreen frame via functions
like set-frame-size or when setting the width or
height parameter of a frame. The following values are provided:
nilThis will forward the resize request to the window manager and leave it to the latter how to proceed.
tThis will first reset the fullscreen status and then forward the resize request on to the window manager.
inhibitThis will reject the resize request and leave the fullscreen status unchanged.
The default is inhibit on NS builds and nil everywhere
else.
This function sets the new size and position of frame in a single
step; frame defaults to the selected frame. The size and position
are specified as with the corresponding frame parameters width,
height, left, and top (see Size Parameters, and
see Position Parameters). If any of these 4 arguments is omitted or
nil, that means not to change the corresponding parameter of
frame.
This function sets the new size and position of a frame, similarly to
set-frame-size-and-position, but in pixel units. The optional
argument gravity specifies the new gravity of frame
and must be a value between 0 and 10; it defaults to 1. Gravity is
window-system dependent and conceptually determines which corner of a
frame retains its position relative to that of its parent frame when the
size of that frame or its parent changes. (Top-level frames have no
parent frame, the window-system root window will be considered their
parent in this regard.) The value 1 specifies NorthWest gravity and
means that the top-left corner of the frame should keep its relative
position. Many window managers seem to ignore gravity.
The abnormal hook window-size-change-functions (see Hooks for Window Scrolling and Changes) tracks all changes of the inner size of a frame including those
induced by request of the window-system or window manager. To rule out
false positives that might occur when changing only the sizes of a
frame’s windows without actually changing the size of the inner frame,
use the following function.
This function returns non-nil when the inner width or height of
frame has changed since window-size-change-functions was
run the last time for frame. It always returns nil
immediately after running window-size-change-functions for
frame.
By default, Emacs tries to keep the number of lines and columns of a frame’s text area (see Frame Layout) unaltered when, for example, toggling the menu or tool bar, changing the default font or setting the default width of scroll bars on that frame. When any of these decorations is drawn by a toolkit, this usually means that Emacs has to work against that toolkit because the latter usually tries to keep the outer frame size unaltered when the size of a decoration changes, thus implicitly changing the size of the frame’s text area.
In practice this means that whenever Emacs issues a request to add or remove such a decoration, it will issue a second request with the intention to restore the original size of the frame’s text area. When any of these decorations is drawn by Emacs itself (like the tool bar with the Lucid or MS-Windows builds or the tab bar), Emacs may still have to alter the size of the native frame accordingly and issue a resize request because these decorations should not be accounted for by the text area of the frame.
Occasionally, such implied frame resizing may be unwanted, for example, when a frame has been maximized or made full-screen (where it’s turned off by default). In general, users can disable implied resizing with the following option:
If this option is nil, changing a frame’s font, menu bar, tool
bar, internal borders, fringes or scroll bars may resize its outer frame
in order to keep the number of columns or lines of its text area
unaltered.
If this option is t, Emacs will not resize a frame in any of
these cases once it has agreed with the window manager on the final
initial size of that frame. More precisely, this means that Emacs may
resize a frame implicitly until all of its decorations have been taken
into account and it has been given the initial size requested by the
user. Any further changes of decorations will not cause an implied
resizing of the frame.
If this option equals the symbol force, Emacs will not perform
any implied resizing of a frame even before it has agreed with the
window manager on the final initial size of that frame. As a
consequence, the initial size of a frame’s text area may not necessarily
reflect the one specified by the user. This value can be useful with
tiling window managers where the initial size of a frame is determined
by external means.
The value of this option can be also a list of frame parameters. In
that case, implied resizing of a frame is inhibited for the change of
any parameters that appears in this list once Emacs has agreed with the
window manager on the final initial size of that frame. Parameters
currently handled by this option are font, font-backend,
internal-border-width, menu-bar-lines and
tool-bar-lines.
Changing any of the scroll-bar-width, scroll-bar-height,
vertical-scroll-bars, horizontal-scroll-bars,
left-fringe and right-fringe frame parameters is handled
as if the frame contained just one live window. This means, for
example, that removing vertical scroll bars on a frame containing
several side by side windows will shrink the outer frame width by the
width of one scroll bar provided this option is nil and keep it
unchanged if this option is t or a list containing
vertical-scroll-bars.
The default value is (tab-bar-lines tool-bar-lines) for Lucid,
Motif and MS-Windows (which means that adding/removing a tool or tab
bar there does not change the outer frame height),
(tab-bar-lines) on all other window systems including GTK+
(which means that changing any of the parameters listed above with the
exception of tab-bar-lines may change the size of the outer
frame), and t otherwise (which means the outer frame size never
changes implicitly when there’s no window system support).
Note that when a frame is not large enough to accommodate a change of
any of the parameters listed above, Emacs may try to enlarge the frame
even if this option is non-nil.
Note also that window managers usually do not ask for resizing a frame when they change the number of lines occupied by an external menu or tool bar. Typically, such “wrappings” occur when a user shrinks a frame horizontally, making it impossible to display all elements of its menu or tool bar. They may also result from a change of the major mode altering the number of items of a menu or tool bar. Any such wrappings may implicitly alter the number of lines of a frame’s text area and are unaffected by the setting of this option.
A frame has many parameters that control its appearance and behavior. Just what parameters are meaningful for a frame depends on what display mechanism it uses. Many frame parameters exist mostly for the sake of graphical displays and have no effect when applied to the top frame (see Frames) of a text terminal.
By default, frame parameters are saved and restored by the desktop
library functions (see Desktop Save Mode) when the variable
desktop-restore-frames is non-nil. It’s the
responsibility of applications that their parameters are included in
frameset-persistent-filter-alist to avoid that they get
meaningless or even harmful values in restored sessions.
These functions let you read and change the parameter values of a frame.
This function returns the value of the parameter parameter (a
symbol) of frame. If frame is nil, it returns the
selected frame’s parameter. If frame has no setting for
parameter, this function returns nil.
The function frame-parameters returns an alist listing all the
parameters of frame and their values. If frame is
nil or omitted, this returns the selected frame’s parameters
This function alters the frame frame based on the elements of
alist. Each element of alist has the form
(parm . value), where parm is a symbol naming
a parameter. If you don’t mention a parameter in alist, its
value doesn’t change. If frame is nil, it defaults to
the selected frame.
Some parameters are only meaningful for frames on certain kinds of display (see Frames). If alist includes parameters that are not meaningful for the frame’s display, this function will change its value in the frame’s parameter list, but will otherwise ignore it.
When alist specifies more than one parameter whose value can affect the new size of frame, the final size of the frame may differ according to the toolkit used. For example, specifying that a frame should from now on have a menu and/or tool bar instead of none and simultaneously specifying the new height of the frame will inevitably lead to a recalculation of the frame’s height. Conceptually, in such case, this function will try to have the explicit height specification prevail. It cannot be excluded, however, that the addition (or removal) of the menu or tool bar, when eventually performed by the toolkit, will defeat this intention.
Sometimes, binding frame-inhibit-implied-resize (see Implied Frame Resizing) to a non-nil value around calls to this function
may fix the problem sketched here. Sometimes, however, exactly such
binding may be hit by the problem.
This function sets the frame parameter parm to the specified
value. If frame is nil, it defaults to the selected
frame.
This function alters the frame parameters of all existing frames
according to alist, then modifies default-frame-alist
(and, if necessary, initial-frame-alist) to apply the same
parameter values to frames that will be created henceforth.
You can specify the parameters for the initial startup frame by
setting initial-frame-alist in your init file (see The Init File).
This variable’s value is an alist of parameter values used when creating the initial frame. You can set this variable to specify the appearance of the initial frame without altering subsequent frames. Each element has the form:
(parameter . value)
Emacs creates the initial frame before it reads your init
file. After reading that file, Emacs checks initial-frame-alist,
and applies the parameter settings in the altered value to the already
created initial frame.
If these settings affect the frame geometry and appearance, you’ll see the frame appear with the wrong ones and then change to the specified ones. If that bothers you, you can specify the same geometry and appearance with X resources; those do take effect before the frame is created. See X Resources in The GNU Emacs Manual.
X resource settings typically apply to all frames. If you want to
specify some X resources solely for the sake of the initial frame, and
you don’t want them to apply to subsequent frames, here’s how to achieve
this. Specify parameters in default-frame-alist to override the
X resources for subsequent frames; then, to prevent these from affecting
the initial frame, specify the same parameters in
initial-frame-alist with values that match the X resources.
If these parameters include (minibuffer . nil), that indicates
that the initial frame should have no minibuffer. In this case, Emacs
creates a separate minibuffer-only frame as well.
This variable’s value is an alist of parameter values used when
creating an initial minibuffer-only frame (i.e., the minibuffer-only
frame that Emacs creates if initial-frame-alist specifies a
frame with no minibuffer).
This is an alist specifying default values of frame parameters for all Emacs frames—the first frame, and subsequent frames. When using the X Window System, you can get the same results by means of X resources in many cases.
Setting this variable does not affect existing frames. Furthermore, functions that display a buffer in a separate frame may override the default parameters by supplying their own parameters.
If you invoke Emacs with command-line options that specify frame
appearance, those options take effect by adding elements to either
initial-frame-alist or default-frame-alist. Options
which affect just the initial frame, such as ‘--geometry’ and
‘--maximized’, add to initial-frame-alist; the others add
to default-frame-alist. see Command Line
Arguments for Emacs Invocation in The GNU Emacs Manual.
Just what parameters a frame has depends on what display mechanism it uses. This section describes the parameters that have special meanings on some or all kinds of terminals.
These frame parameters give the most basic information about the
frame. title and name are meaningful on all terminals.
display ¶The display on which to open this frame. It should be a string of the
form ‘host:dpy.screen’, just like the
DISPLAY environment variable. See Multiple Terminals, for
more details about display names.
display-type ¶This parameter describes the range of possible colors that can be used
in this frame. Its value is color, grayscale or
mono.
title ¶If a frame has a non-nil title, that title appears in the window
system’s title bar at the top of the frame, and also in the mode line
of windows in that frame if mode-line-frame-identification uses
‘%F’ (see %-Constructs in the Mode Line). This is normally the case when
Emacs is not using a window system, and can only display one frame at
a time. When Emacs is using a window system, this parameter, if
non-nil, overrides the title determined by the name
parameter and the implicit title calculated according to
frame-title-format. It also overrides the title determined by
icon-title-format for iconified frames. See Frame Titles.
name ¶The name of the frame. If you don’t specify a name via this
parameter, Emacs sets the frame name automatically, as specified by
frame-title-format and icon-title-format, and that is
the frame’s title that will appear on display when Emacs uses a window
system (unless the title parameter overrides it).
If you specify the frame name explicitly when you create the frame, the name is also used (instead of the name of the Emacs executable) when looking up X resources for the frame.
explicit-name ¶If the frame name was specified explicitly when the frame was created,
this parameter will be that name. If the frame wasn’t explicitly
named, this parameter will be nil.
environment ¶The list of strings, each one describing one environment variable. This
list is similar to the one in process-environment (see Operating System Environment), but it lists variables and values specific to the frame.
Parameters describing the X- and Y-offsets of a frame are always measured in pixels. For a normal, non-child frame they specify the frame’s outer position (see Frame Geometry) relative to its display’s origin. For a child frame (see Child Frames) they specify the frame’s outer position relative to the native position of the frame’s parent frame. On a text terminal these parameters are meaningful for child frames only.
left ¶The position, in pixels, of the left outer edge of the frame with respect to the left edge of the frame’s display or parent frame. It can be specified in one of the following ways.
A positive integer always relates the left edge of the frame to the left edge of its display or parent frame. A negative integer relates the right frame edge to the right edge of the display or parent frame.
(+ pos)This specifies the position of the left frame edge relative to the left edge of its display or parent frame. The integer pos may be positive or negative; a negative value specifies a position outside the screen or parent frame or on a monitor other than the primary one (for multi-monitor displays).
(- pos)This specifies the position of the right frame edge relative to the right edge of the display or parent frame. The integer pos may be positive or negative; a negative value specifies a position outside the screen or parent frame or on a monitor other than the primary one (for multi-monitor displays).
A floating-point value in the range 0.0 to 1.0 specifies the left edge’s offset via the left position ratio of the frame—the ratio of the left edge of its outer frame to the width of the frame’s workarea (see Multiple Terminals) or its parent’s native frame (see Child Frames) minus the width of the outer frame. Thus, a left position ratio of 0.0 flushes a frame to the left, a ratio of 0.5 centers it and a ratio of 1.0 flushes it to the right of its display or parent frame. Similarly, the top position ratio of a frame is the ratio of the frame’s top position to the height of its workarea or parent frame minus the height of the frame.
Emacs will try to keep the position ratios of a child frame unaltered if
that frame has a non-nil keep-ratio parameter
(see Frame Interaction Parameters) and its parent frame is resized.
Since the outer size of a frame (see Frame Geometry) is usually unavailable before a frame has been made visible, it is generally not advisable to use floating-point values when creating decorated frames. Floating-point values are more suited for ensuring that an (undecorated) child frame is positioned nicely within the area of its parent frame.
Floating-point values are currently not handled on text terminal frames.
Some window managers ignore program-specified positions. If you want to
be sure the position you specify is not ignored, specify a
non-nil value for the user-position parameter as in the
following example:
(modify-frame-parameters nil '((user-position . t) (left . (+ -4))))
In general, it is not a good idea to position a frame relative to the right or bottom edge of its display. Positioning the initial or a new frame is either not accurate (because the size of the outer frame is not yet fully known before the frame has been made visible) or will cause additional flicker (if the frame has to be repositioned after becoming visible).
Note also, that positions specified relative to the right/bottom edge
of a display, workarea or parent frame as well as floating-point offsets
are stored internally as integer offsets relative to the left/top edge
of the display, workarea or parent frame edge. They are also returned
as such by functions like frame-parameters and restored as such
by the desktop saving routines.
top ¶The screen position of the top (or bottom) edge, in pixels, with respect
to the top (or bottom) edge of the display or parent frame. It works
just like left, except vertically instead of horizontally.
icon-left ¶The screen position of the left edge of the frame’s icon, in pixels,
counting from the left edge of the screen. This takes effect when the
frame is iconified, if the window manager supports this feature. If you
specify a value for this parameter, then you must also specify a value
for icon-top and vice versa. This parameter has no meaning on a
text terminal.
icon-top ¶The screen position of the top edge of the frame’s icon, in pixels, counting from the top edge of the screen. This takes effect when the frame is iconified, if the window manager supports this feature. This parameter has no meaning on a text terminal.
user-position ¶When you create a frame and specify its screen position with the
left and top parameters, use this parameter to say whether
the specified position was user-specified (explicitly requested in some
way by a human user) or merely program-specified (chosen by a program).
A non-nil value says the position was user-specified. This
parameter has no meaning on a text terminal.
Window managers generally heed user-specified positions, and some heed
program-specified positions too. But many ignore program-specified
positions, placing the window in a default fashion or letting the user
place it with the mouse. Some window managers, including twm,
let the user specify whether to obey program-specified positions or
ignore them.
When you call make-frame, you should specify a non-nil
value for this parameter if the values of the left and top
parameters represent the user’s stated preference; otherwise, use
nil.
z-group ¶This parameter specifies a relative position of the frame’s window-system window in the stacking (Z-) order of the frame’s display. It has not been implemented yet on text terminals.
If this is above, the window-system will display the window
that corresponds to the frame above all other window-system windows
that do not have the above property set. If this is
nil, the frame’s window is displayed below all windows that
have the above property set and above all windows that have the
below property set. If this is below, the frame’s
window is displayed below all windows that do not have the
below property set.
To position the frame above or below a specific other frame use the
function frame-restack (see Raising, Lowering and Restacking Frames).
Frame parameters usually specify frame sizes in character units. On
graphical displays, the default face determines the actual pixel
sizes of these character units (see Face Attributes). On text
terminals size parameters affect child frames only.
width ¶This parameter specifies the width of the frame. It can be specified as in the following ways:
A positive integer specifies the width of the frame’s text area (see Frame Geometry) in characters.
If this is a cons cell with the symbol text-pixels in its
CAR, the CDR of that cell specifies the width of the frame’s
text area in pixels.
A floating-point number between 0.0 and 1.0 can be used to specify the width of a frame via its width ratio—the ratio of its outer width (see Frame Geometry) to the width of the frame’s workarea (see Multiple Terminals) or its parent frame’s (see Child Frames) native frame. Thus, a value of 0.5 makes the frame occupy half of the width of its workarea or parent frame, a value of 1.0 the full width. Similarly, the height ratio of a frame is the ratio of its outer height to the height of its workarea or its parent’s native frame.
Emacs will try to keep the width and height ratio of a child frame
unaltered if that frame has a non-nil keep-ratio parameter
(see Frame Interaction Parameters) and its parent frame is resized.
Since the outer size of a frame is usually unavailable before a frame
has been made visible, it is generally not advisable to use
floating-point values when creating decorated frames. Floating-point
values are more suited to ensure that a child frame always fits within
the area of its parent frame as, for example, when customizing
display-buffer-alist (see Choosing a Window for Displaying a Buffer) via
display-buffer-in-child-frame.
Regardless of how this parameter was specified, functions reporting the
value of this parameter like frame-parameters always report the
width of the frame’s text area in characters as an integer rounded, if
necessary, to a multiple of the frame’s default character width. That
value is also used by the desktop saving routines.
height ¶This parameter specifies the height of the frame. It works just like
width, except vertically instead of horizontally.
user-size ¶This does for the size parameters height and width what
the user-position parameter (see user-position) does for the position parameters top and
left. This parameter has no meaning on a text terminal.
min-width ¶This parameter specifies the minimum native width (see Frame Geometry) of the frame, in characters. Normally, the functions that
establish a frame’s initial width or resize a frame horizontally make
sure that all the frame’s windows, vertical scroll bars, fringes,
margins and vertical dividers can be displayed. This parameter, if
non-nil enables making a frame narrower than that with the
consequence that any components that do not fit will be clipped by the
window manager.
min-height ¶This parameter specifies the minimum native height (see Frame Geometry) of the frame, in characters. Normally, the functions that
establish a frame’s initial size or resize a frame make sure that all
the frame’s windows, horizontal scroll bars and dividers, mode and
header lines, the echo area and the internal menu and tool bar can be
displayed. This parameter, if non-nil enables making a frame
smaller than that with the consequence that any components that do not
fit will be clipped by the window manager.
fullscreen ¶This parameter specifies whether to maximize the frame’s width, height
or both. It has no meaning on a text terminal. Its value can be
fullwidth, fullheight, fullboth, or
maximized.24 A
fullwidth frame is as wide as possible, a fullheight frame
is as tall as possible, and a fullboth frame is both as wide and
as tall as possible. A maximized frame is like a “fullboth”
frame, except that it usually keeps its title bar and the buttons for
resizing and closing the frame. Also, maximized frames typically avoid
hiding any task bar or panels displayed on the desktop. A “fullboth”
frame, on the other hand, usually omits the title bar and occupies the
entire available screen space.
Full-height and full-width frames are more similar to maximized frames in this regard. However, these typically display an external border which might be absent with maximized frames. Hence the heights of maximized and full-height frames and the widths of maximized and full-width frames often differ by a few pixels.
With some window managers you may have to customize the variable
frame-resize-pixelwise (see Frame Size) in order to make a
frame truly appear maximized or full-screen. Moreover, some window
managers might not support smooth transition between the various
full-screen or maximization states. Customizing the variable
x-frame-normalize-before-maximize can help to overcome that.
Full-screen on macOS hides both the tool-bar and the menu-bar, however both will be displayed if the mouse pointer is moved to the top of the screen.
fullscreen-restore ¶This parameter specifies the desired fullscreen state of the frame
after invoking the toggle-frame-fullscreen command (see Frame
Commands in The GNU Emacs Manual) in the “fullboth” state.
Normally this parameter is installed automatically by that command when
toggling the state to fullboth. If, however, you start Emacs in the
“fullboth” state, you have to specify the desired behavior in your initial
file as, for example
(setq default-frame-alist
'((fullscreen . fullboth)
(fullscreen-restore . fullheight)))
This will give a new frame full height after typing in it F11 for the first time. This parameter has no meaning on a text terminal.
fit-frame-to-buffer-margins ¶This parameter enables overriding the value of the option
fit-frame-to-buffer-margins when fitting this frame to the
buffer of its root window with fit-frame-to-buffer
(see Resizing Windows).
fit-frame-to-buffer-sizes ¶This parameter enables overriding the value of the option
fit-frame-to-buffer-sizes when fitting this frame to the buffer
of its root window with fit-frame-to-buffer (see Resizing Windows).
These frame parameters enable or disable various parts of the frame, or control their sizes. Unless stated otherwise, these parameters have no meaning on text terminals.
undecorated ¶If non-nil, then on a graphical system this frame’s window-system
window is drawn without decorations, like the title, minimize/maximize
boxes and external borders. This usually means that the window cannot
be dragged, resized, iconified, maximized or deleted with the mouse. If
nil, the frame’s window is usually drawn with all the elements
listed above unless their display has been suspended via window manager
settings.
Under X, Emacs uses the Motif window manager hints to turn off decorations. Some window managers may not honor these hints.
NS builds consider the tool bar to be a decoration, and therefore hide it on an undecorated frame.
On a text terminal, this parameter, if non-nil, will make a child
frame show an outer border, which allows to resize that frame via mouse
dragging (see Mouse Dragging Parameters).
border-width ¶The width in pixels of the frame’s outer border (see Frame Geometry).
internal-border-width ¶The width in pixels of the frame’s internal border (see Frame Geometry).
child-frame-border-width ¶The width in pixels of the frame’s internal border (see Frame Geometry) if the given frame is a child frame (see Child Frames).
If this is nil, the value specified by the
internal-border-width parameter is used instead.
vertical-scroll-bars ¶Whether the frame has scroll bars (see Scroll Bars) for vertical
scrolling, and which side of the frame they should be on. The possible
values are left, right, and nil for no scroll bars.
horizontal-scroll-bars ¶Whether the frame has scroll bars for horizontal scrolling (t and
bottom mean yes, nil means no).
scroll-bar-width ¶The width of vertical scroll bars, in pixels, or nil meaning to
use the default width.
scroll-bar-height ¶The height of horizontal scroll bars, in pixels, or nil meaning
to use the default height.
left-fringe ¶right-fringeThe default width of the left and right fringes of windows in this frame (see Fringes). If either of these is zero, that effectively removes the corresponding fringe.
When you use frame-parameter to query the value of either of
these two frame parameters, the return value is always an integer.
When using set-frame-parameter, passing a nil value
imposes an actual default value of 8 pixels.
right-divider-width ¶The width (thickness) reserved for the right divider (see Window Dividers) of any window on the frame, in pixels. A value of zero means to not draw right dividers.
bottom-divider-width ¶The width (thickness) reserved for the bottom divider (see Window Dividers) of any window on the frame, in pixels. A value of zero means to not draw bottom dividers.
menu-bar-lines ¶The number of lines to allocate at the top of the frame for a menu bar
(see The Menu Bar). The default is 1 if Menu Bar mode is enabled and 0
otherwise. See Menu Bars in The GNU Emacs Manual. For an
external menu bar (see Frame Layout), this value remains unchanged
even when the menu bar wraps to two or more lines. In that case, the
menu-bar-size value returned by frame-geometry
(see Frame Geometry) can be used to establish whether the menu bar
actually occupies one or more lines. This parameter affects the
presence of a menu bar on the root frame (see Child Frames) of a
text terminal too. On a text terminal the value may be only 0 or 1.
tool-bar-lines ¶The number of lines to use for the tool bar (see Tool bars). The default is one if Tool Bar mode is enabled and zero otherwise. See Tool Bars in The GNU Emacs Manual. This value may change whenever the tool bar wraps (see Frame Layout).
tool-bar-position ¶The position of the tool bar. Its value can be one of top,
bottom left, right. The default is top.
It can be set to bottom on Emacs built with any toolkit other
than Nextstep, and left or right on builds using GTK+.
tab-bar-lines ¶The number of lines to use for the tab bar (see Tab Bars in The GNU Emacs Manual). The default is one if Tab Bar mode is enabled and zero otherwise. This value may change whenever the tab bar wraps (see Frame Layout). This parameter affects the presence of a tab bar on the root frame (see Child Frames) of a text terminal too.
line-spacing ¶Additional space to leave below each text line, in pixels (a positive integer). See Line Height, for more information.
no-special-glyphs ¶If this is non-nil, it suppresses the display of any truncation
(see Truncation) and continuation glyphs for all the buffers
displayed by this frame. This is useful to eliminate such glyphs when
fitting a frame to its buffer via fit-frame-to-buffer
(see Resizing Windows). This frame parameter has effect only for
GUI frames shown on graphical displays, and only if the fringes are
disabled. This parameter is intended as a purely-presentation feature,
and in particular should not be used for frames where the user can
interactively insert text, or more generally where the cursor is shown.
A notable example of frames where this is used is tooltip frames
(see Tooltips). This parameter affects text terminals as well.
These frame parameters, meaningful on all kinds of terminals, deal with which buffers have been, or should, be displayed in the frame.
minibuffer ¶Whether this frame has its own minibuffer. The value t means
yes, nil means no, only means this frame is just a
minibuffer. If the value is a minibuffer window (in some other
frame), the frame uses that minibuffer.
This parameter takes effect when the frame is created. If specified as
nil, Emacs will try to set it to the minibuffer window of
default-minibuffer-frame (see Minibuffers and Frames). For
an existing frame, this parameter can be used exclusively to specify
another minibuffer window. It is not allowed to change it from a
minibuffer window to t and vice-versa, or from t to
nil. If the parameter specifies a minibuffer window already,
setting it to nil has no effect.
The special value child-frame means to make a minibuffer-only
child frame (see Child Frames) whose parent becomes the frame
created. As if specified as nil, Emacs will set this parameter
to the minibuffer window of the child frame but will not select the
child frame after its creation. The value child-frame has no
effect on text terminals where you have to create a minibuffer-only
frame manually (see Child Frame Peculiarities).
buffer-predicate ¶The buffer-predicate function for this frame. The function
other-buffer uses this predicate (from the selected frame) to
decide which buffers it should consider, if the predicate is not
nil. It calls the predicate with one argument, a buffer, once for
each buffer; if the predicate returns a non-nil value, it
considers that buffer.
buffer-list ¶A list of buffers that have been selected in this frame, ordered most-recently-selected first.
unsplittable ¶If non-nil, this frame’s window is never split automatically.
These parameters supply forms of interactions between different frames.
visibility ¶The state of visibility of the frame. There are three possibilities:
nil for invisible, t for visible, and icon for
iconified. See Visibility of Frames.
parent-frame ¶If non-nil, this means that this frame is a child frame
(see Child Frames), and this parameter specifies its parent frame.
If nil, this means that this frame is a normal, top-level frame.
delete-before ¶If non-nil, this parameter specifies another frame whose deletion
will automatically trigger the deletion of this frame. See Deleting Frames.
mouse-wheel-frame ¶If non-nil, this parameter specifies the frame whose windows will
be scrolled whenever the mouse wheel is scrolled with the mouse pointer
hovering over this frame, see Mouse Commands in The GNU
Emacs Manual. This parameter has no meaning on a text terminal.
no-other-frame ¶If this is non-nil, then this frame is not eligible as candidate
for the functions next-frame, previous-frame
(see Finding All Frames) and other-frame, see Frame
Commands in The GNU Emacs Manual.
auto-hide-function ¶When this parameter specifies a function, that function will be called
instead of the function specified by the variable
frame-auto-hide-function when quitting the frame’s only window
(see Quitting Windows) and there are other frames left. This
parameter has not been yet implemented on text terminals.
minibuffer-exit ¶When this parameter is non-nil, Emacs will by default make this
frame invisible whenever the minibuffer (see Minibuffers) is exited.
Alternatively, it can specify the functions iconify-frame and
delete-frame. This parameter is useful to make a child frame
disappear automatically (similar to how Emacs deals with a window) when
exiting the minibuffer. This parameter has not been yet implemented on
text terminals.
keep-ratio ¶This parameter is currently meaningful for child frames (see Child Frames) only. If it is non-nil, then Emacs will try to keep the
frame’s size (width and height) ratios (see Size Parameters) as well
as its left and right position ratios (see Position Parameters)
unaltered whenever its parent frame is resized.
If the value of this parameter is nil, the frame’s position and
size remain unaltered when the parent frame is resized, so the position
and size ratios may change. If the value of this parameter is t,
Emacs will try to preserve the frame’s size and position ratios, hence
the frame’s size and position relative to its parent frame may change.
More individual control is possible by using a cons cell: In that case
the frame’s width ratio is preserved if the CAR of the cell is
either t or width-only. The height ratio is preserved if
the CAR of the cell is either t or height-only. The
left position ratio is preserved if the CDR of the cell is either
t or left-only. The top position ratio is preserved if
the CDR of the cell is either t or top-only. This
parameter has not been yet implemented on text terminals.
cloned-from ¶The original frame if this frame was made via clone-frame
(see Creating Frames in the Emacs Manual).
undeleted ¶This is non-nil if this frame was undeleted using the command
undelete-frame (see Frame Commands in the Emacs
Manual).
The parameters described below provide support for resizing a frame by dragging its internal borders with the mouse. They also allow moving a frame with the mouse by dragging the header or tab line of its topmost or the mode line of its bottommost window.
These parameters are mostly useful for child frames (see Child Frames) that come without window manager decorations. If necessary, they can be used for undecorated top-level frames as well. On text terminals these parameters affect child frames only.
drag-internal-border ¶If non-nil, the frame can be resized by dragging its internal
borders, if present, with the mouse. On text terminals, the decoration
of a child frame must be dragged instead.
drag-with-header-line ¶If non-nil, the frame can be moved with the mouse by dragging the
header line of its topmost window.
drag-with-tab-line ¶If non-nil, the frame can be moved with the mouse by dragging the
tab line of its topmost window.
drag-with-mode-line ¶If non-nil, the frame can be moved with the mouse by dragging the
mode line of its bottommost window. Note that such a frame is not
allowed to have its own minibuffer window.
snap-width ¶A frame that is moved with the mouse will “snap” at the border(s) of the display or its parent frame whenever it is dragged as near to such an edge as the number of pixels specified by this parameter.
top-visible ¶If this parameter is a number, the top edge of the frame never appears
above the top edge of its display or parent frame. Moreover, as many
pixels of the frame as specified by that number will remain visible when
the frame is moved against any of the remaining edges of its display or
parent frame. Setting this parameter is useful to guard against
dragging a child frame with a non-nil
drag-with-header-line parameter completely out of the area
of its parent frame.
bottom-visible ¶If this parameter is a number, the bottom edge of the frame never
appears below the bottom edge of its display or parent frame. Moreover,
as many pixels of the frame as specified by that number will remain
visible when the frame is moved against any of the remaining edges of
its display or parent frame. Setting this parameter is useful to guard
against dragging a child frame with a non-nil
drag-with-mode-line parameter completely out of the area of
its parent frame.
The following frame parameters control various aspects of the frame’s interaction with the window manager or window system. They have no effect on text terminals.
auto-raise ¶If non-nil, Emacs automatically raises the frame when it is
selected. Some window managers do not allow this.
auto-lower ¶If non-nil, Emacs automatically lowers the frame when it is
deselected. Some window managers do not allow this.
icon-type ¶The type of icon to use for this frame. If the value is a string,
that specifies a file containing a bitmap to use; nil specifies
no icon (in which case the window manager decides what to show); any
other non-nil value specifies the default Emacs icon.
icon-name ¶The name to use in the icon for this frame, when and if the icon
appears. If this is nil, the frame’s title is used.
window-id ¶The ID number which the graphical display uses for this frame. Emacs assigns this parameter when the frame is created; changing the parameter has no effect on the actual ID number.
outer-window-id ¶The ID number of the outermost window-system window in which the frame
exists. As with window-id, changing this parameter has no
actual effect.
wait-for-wm ¶If non-nil, tell Xt to wait for the window manager to confirm
geometry changes. Some window managers, including versions of Fvwm2
and KDE, fail to confirm, so Xt hangs. Set this to nil to
prevent hanging with those window managers.
sticky ¶If non-nil, the frame is visible on all virtual desktops on systems
with virtual desktops.
shaded ¶If non-nil, tell the window manager to display the frame in a
way that its contents are hidden, leaving only the title bar.
use-frame-synchronization ¶If non-nil, synchronize the frame redisplay with the refresh
rate of the monitor to avoid graphics tearing. At present, this is
only implemented on Haiku and the X window system inside no-toolkit
and X toolkit builds, does not work correctly with toolkit scroll
bars, and requires a compositing manager supporting the relevant
display synchronization protocols. The synchronizeResize X
resource must also be set to the string "extended".
inhibit-double-buffering ¶If non-nil, the frame is drawn to the screen without double
buffering. Emacs normally attempts to use double buffering, where
available, to reduce flicker; nevertheless, this parameter is provided
for circumstances where double-buffering induces display corruption,
and for those eccentrics wistful for the immemorial flicker that once
beset Emacs.
skip-taskbar ¶If non-nil, this tells the window manager to remove the frame’s
icon from the taskbar associated with the frame’s display and inhibit
switching to the frame’s window via the combination Alt-TAB.
On MS-Windows, iconifying such a frame will "roll in" its window-system
window at the bottom of the desktop. Some window managers may not honor
this parameter.
no-focus-on-map ¶If non-nil, this means that the frame does not want to receive
input focus when it is mapped (see Visibility of Frames). Some
window managers may not honor this parameter.
no-accept-focus ¶If non-nil, this means that the frame does not want to receive
input focus via explicit mouse clicks or when moving the mouse into it
either via focus-follows-mouse (see Input Focus) or
mouse-autoselect-window (see Mouse Window Auto-selection).
This may have the unwanted side-effect that a user cannot scroll a
non-selected frame with the mouse. Some window managers may not honor
this parameter. On Haiku, it also has the side-effect that the window
will not be able to receive any keyboard input from the user, not even
if the user switches to the frame using the key combination
Alt-TAB.
override-redirect ¶If non-nil, this means that this is an override redirect
frame—a frame not handled by window managers under X. Override
redirect frames have no window manager decorations, can be positioned
and resized only via Emacs’s positioning and resizing functions and are
usually drawn on top of all other frames. Setting this parameter has
no effect on MS-Windows.
ns-appearance ¶Only available on macOS, if set to dark draw this frame’s
window-system window using the “vibrant dark” theme, and if set to
light use the “aqua” theme, otherwise use the system default.
The “vibrant dark” theme can be used to set the toolbar and
scrollbars to a dark appearance when using an Emacs theme with a dark
background.
ns-transparent-titlebar ¶Only available on macOS, if non-nil, set the titlebar and
toolbar to be transparent. This effectively sets the background color
of both to match the Emacs background color.
This frame parameter controls the way the cursor looks.
cursor-type ¶How to display the cursor. Legitimate values are:
boxDisplay a filled box. (This is the default.)
(box . size)Display a filled box. However, display it as a hollow box if point is under masked image larger than size pixels in either dimension.
hollowDisplay a hollow box.
nilDon’t display a cursor.
barDisplay a vertical bar between characters.
(bar . width)Display a vertical bar width pixels wide between characters.
hbarDisplay a horizontal bar.
(hbar . height)Display a horizontal bar height pixels high.
The cursor-type frame parameter may be overridden by
set-window-cursor-type (see Windows and Point), and by the
variables cursor-type and cursor-in-non-selected-windows:
This buffer-local variable controls how the cursor looks in a selected
window showing the buffer. If its value is t, that means to
use the cursor specified by the cursor-type frame parameter.
Otherwise, the value should be one of the cursor types listed above,
and it overrides the cursor-type frame parameter.
This buffer-local variable controls how the cursor looks in a window
that is not selected. It supports the same values as the
cursor-type frame parameter; also, nil means don’t
display a cursor in nonselected windows, and t (the default)
means use a standard modification of the usual cursor type (solid box
becomes hollow box, and bar becomes a narrower bar).
This variable controls the width of the block cursor displayed on
extra-wide glyphs such as a tab or a stretch of white space. By
default, the block cursor is only as wide as the font’s default
character, and will not cover all of the width of the glyph under it
if that glyph is extra-wide. A non-nil value of this variable
means draw the block cursor as wide as the glyph under it. The
default value is nil.
This variable has no effect on text-mode frames, since the text-mode cursor is drawn by the terminal out of Emacs’s control.
This variable specifies how to blink the cursor. Each element has the
form (on-state . off-state). Whenever the cursor
type equals on-state (comparing using equal), the
corresponding off-state specifies what the cursor looks like
when it blinks off. Both on-state and off-state
should be suitable values for the cursor-type frame parameter.
There are various defaults for how to blink each type of cursor, if
the type is not mentioned as an on-state here. Changes in this
variable do not take effect immediately, only when you specify the
cursor-type frame parameter.
These frame parameters control the use of fonts and colors.
font-backend ¶A list of symbols, specifying the font backends to use for
drawing characters on the frame, in order of priority. In Emacs built
without Cairo drawing on X, there are currently three potentially
available font backends: x (the X core font driver), xft
(the Xft font driver), and xfthb (the Xft font driver with
HarfBuzz text shaping). If built with Cairo drawing, there are also
three potentially available font backends on X: x, ftcr
(the FreeType font driver on Cairo), and ftcrhb (the FreeType
font driver on Cairo with HarfBuzz text shaping). When Emacs is built
with HarfBuzz, the default font driver is ftcrhb, although use
of the ftcr driver is still possible, but not recommended. On
MS-Windows, there are currently three available font backends:
gdi (the core MS-Windows font driver), uniscribe (font
driver for OTF and TTF fonts with text shaping by the Uniscribe
engine), and harfbuzz (font driver for OTF and TTF fonts with
HarfBuzz text shaping) (see Windows Fonts in The GNU Emacs
Manual). The harfbuzz driver is similarly recommended. On
Haiku, there can be several font drivers (see Haiku Fonts in The GNU Emacs Manual), as on Android (see Android Fonts in The GNU Emacs Manual).
On other systems, there is only one available font backend, so it does not make sense to modify this frame parameter.
background-mode ¶This parameter is either dark or light, according
to whether the background color is a light one or a dark one.
tty-color-mode ¶This parameter overrides the terminal’s color support as given by the
system’s terminal capabilities database in that this parameter’s value
specifies the color mode to use on a text terminal. The value can be
either a symbol or a number. A number specifies the number of colors
to use (and, indirectly, what commands to issue to produce each
color). For example, (tty-color-mode . 8) specifies use of the
ANSI escape sequences for 8 standard text colors. A value of −1 turns
off color support.
If the parameter’s value is a symbol, it specifies a number through
the value of tty-color-mode-alist, and the associated number is
used instead. This parameter supports dynamic changes during a running
Emacs session (but not on MS-Windows and MS-DOS).
screen-gamma ¶If this is a number, Emacs performs gamma correction which adjusts the brightness of all colors. The value should be the screen gamma of your display.
Usual PC monitors have a screen gamma of 2.2, so color values in
Emacs, and in X windows generally, are calibrated to display properly
on a monitor with that gamma value. If you specify 2.2 for
screen-gamma, that means no correction is needed. Other values
request correction, designed to make the corrected colors appear on
your screen the way they would have appeared without correction on an
ordinary monitor with a gamma value of 2.2.
If your monitor displays colors too light, you should specify a
screen-gamma value smaller than 2.2. This requests correction
that makes colors darker. A screen gamma value of 1.5 may give good
results for LCD color displays.
alpha ¶This parameter specifies the opacity of the frame, on graphical
displays that support variable opacity. It should be an integer
between 0 and 100, where 0 means completely transparent and 100 means
completely opaque. It can also have a nil value, which tells
Emacs not to set the frame opacity (leaving it to the window manager).
To prevent the frame from disappearing completely from view, the
variable frame-alpha-lower-limit defines a lower opacity limit.
If the value of the frame parameter is less than the value of this
variable, Emacs uses the latter. By default,
frame-alpha-lower-limit is 20.
The alpha frame parameter can also be a cons cell
(active . inactive), where active is the
opacity of the frame when it is selected, and inactive is the
opacity when it is not selected.
Some window systems do not support the alpha parameter for child
frames (see Child Frames).
alpha-background ¶Sets the background transparency of the frame. Unlike the alpha
frame parameter, this only controls the transparency of the background
while keeping foreground elements such as text fully opaque. It
should be an integer between 0 and 100, where 0 means
completely transparent and 100 means completely opaque (default). The
value can also be a float between 0 and 1.0, where 1.0 means completely
opaque.
borders-respect-alpha-background ¶When non-nil, internal borders and window dividers are
transparent according to alpha-background.
The following frame parameters are semi-obsolete in that they are automatically equivalent to particular face attributes of particular faces (see Standard Faces in The Emacs Manual):
font ¶The name of the font for displaying text in the frame. This is a
string, either a valid font name for your system or the name of an Emacs
fontset (see Fontsets). It is equivalent to the font
attribute of the default face.
foreground-color ¶The color to use for characters. It is equivalent to
the :foreground attribute of the default face.
background-color ¶The color to use for the background of characters. It is equivalent to
the :background attribute of the default face.
mouse-color ¶The color for the mouse pointer. It is equivalent to the :background
attribute of the mouse face (see Basic Faces).
cursor-color ¶The color for the cursor that shows point. It is equivalent to the
:background attribute of the cursor face.
border-color ¶The color for the border of the frame. It is equivalent to the
:background attribute of the border face.
scroll-bar-foreground ¶If non-nil, the color for the foreground of scroll bars. It is
equivalent to the :foreground attribute of the
scroll-bar face.
scroll-bar-background ¶If non-nil, the color for the background of scroll bars. It is
equivalent to the :background attribute of the
scroll-bar face.
Here’s how to examine the data in an X-style window geometry specification:
The function x-parse-geometry converts a standard X window
geometry string to an alist that you can use as part of the argument to
make-frame.
The alist describes which parameters were specified in geom, and
gives the values specified for them. Each element looks like
(parameter . value). The possible parameter
values are left, top, width, and height.
For the size parameters, the value must be an integer. The position
parameter names left and top are not totally accurate,
because some values indicate the position of the right or bottom edges
instead. The value possibilities for the position parameters are:
an integer, a list (+ pos), or a list (- pos);
as previously described (see Position Parameters).
Here is an example:
(x-parse-geometry "35x70+0-0")
⇒ ((height . 70) (width . 35)
(top - 0) (left . 0))
Each terminal has a list of associated parameters. These terminal parameters are mostly a convenient way of storage for terminal-local variables, but some terminal parameters have a special meaning.
This section describes functions to read and change the parameter values
of a terminal. They all accept as their argument either a terminal or
a frame; the latter means use that frame’s terminal. An argument of
nil means the selected frame’s terminal.
This function returns an alist listing all the parameters of terminal and their values.
This function returns the value of the parameter parameter (a
symbol) of terminal. If terminal has no setting for
parameter, this function returns nil.
This function sets the parameter parameter of terminal to the specified value, and returns the previous value of that parameter.
Here’s a list of a few terminal parameters that have a special meaning:
background-modeThe classification of the terminal’s background color, either
light or dark.
normal-erase-is-backspaceValue is either 1 or 0, depending on whether
normal-erase-is-backspace-mode is turned on or off on this
terminal. See DEL Does Not Delete in The Emacs Manual.
terminal-inittedAfter the terminal is initialized, this is set to the terminal-specific initialization function.
tty-mode-set-stringsWhen present, a list of strings containing escape sequences that Emacs
will output while configuring a tty for rendering. Emacs emits these
strings only when configuring a terminal: if you want to enable a mode
on a terminal that is already active (for example, while in
tty-setup-hook), explicitly output the necessary escape
sequence using send-string-to-terminal in addition to adding
the sequence to tty-mode-set-strings.
tty-mode-reset-stringsWhen present, a list of strings that undo the effects of the strings
in tty-mode-set-strings. Emacs emits these strings when
exiting, deleting a terminal, or suspending itself.
Every frame has a name 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 name
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
frame-title-format. 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 (via the frame’s parameters;
see Basic Parameters). The variable’s value is actually a mode
line construct, just like mode-line-format, except that the
‘%c’, ‘%C’, and ‘%l’ constructs are ignored.
See The Data Structure of the Mode Line.
This variable specifies how to compute the name for an iconified frame
when you have not explicitly specified the frame’s name via the
frame’s parameters. The resulting title appears in the frame’s icon
itself. If the value is a string, is should be a mode line construct
like that of frame-title-format. The value can also be
t, which means to use frame-title-format instead; this
avoids problems with some window managers and desktop environments,
where a change in a frame’s title (when a frame is iconified) is
interpreted as a request to raise the frame and/or give it input
focus. It is also useful if you want the frame’s title to be the same
no matter if the frame is iconified or not. The default value is a
string identical to the default value of frame-title-format.
This variable is set automatically by Emacs. Its value is t when
there are two or more frames (not counting minibuffer-only frames or
invisible frames). The default value of frame-title-format uses
multiple-frames 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 frame-title-format or
icon-title-format.
A live frame is one that has not been deleted. When a frame is deleted, it is removed from its terminal display, although it may continue to exist as a Lisp object until there are no more references to it.
This function deletes the frame frame. The argument frame must specify a live frame (see below) and defaults to the selected frame.
It first deletes any child frame of frame (see Child Frames)
and any frame whose delete-before frame parameter (see Frame Interaction Parameters) specifies frame. All such deletions are
performed recursively; so this step makes sure that no other frames with
frame as their ancestor will exist. Then, unless frame
specifies a tooltip, this function runs the hook
delete-frame-functions (each function getting one argument,
frame) before actually killing the frame. After actually killing
the frame and removing the frame from the frame list, delete-frame
runs after-delete-frame-functions.
Note that a frame cannot be deleted as long as its minibuffer serves as
surrogate minibuffer for another frame (see Minibuffers and Frames).
Normally, you cannot delete a frame if all other frames are invisible,
but if force is non-nil, then you are allowed to do so.
Also, the initial terminal frame of an Emacs process running as daemon
(see daemon in The GNU Emacs Manual) can be
deleted if and only if force is non-nil.
This function returns non-nil if the frame frame has not
been deleted. The possible non-nil return values are like those
of framep. See Frames.
Some window managers provide a command to delete a window. These work
by sending a special message to the program that operates the window.
When Emacs gets one of these commands, it generates a
delete-frame event, whose normal definition is a command that
calls the function delete-frame. See Miscellaneous System Events.
This command deletes all frames on frame’s terminal, except
frame. If frame uses another frame’s minibuffer, that
minibuffer frame is left untouched. The argument frame must
specify a live frame and defaults to the selected frame. Internally,
this command works by calling delete-frame with force
nil for all frames that shall be deleted.
This function does not delete any of frame’s child frames (see Child Frames). If frame is a child frame, it deletes frame’s siblings only.
With the prefix argument iconify, the frames are iconified rather than deleted.
The following function checks whether a frame can be safely deleted. It
is useful for avoiding the situation whereby a subsequent call of
delete-frame fails to delete its argument frame and/or
signals an error. To that end, your Lisp program should call
delete-frame only if the following function returns
non-nil.
This function returns non-nil if the frame specified by
frame can be safely deleted. frame must be a live frame and
defaults to the selected frame.
A frame cannot be safely deleted in the following cases:
nil
delete-before parameter.
These conditions cover most cases where delete-frame might fail
when called from top-level. They do not catch some special cases like,
for example, deleting a frame during a drag-and-drop operation
(see Drag and Drop). In any such case, it will be better to wrap
the delete-frame call in a condition-case form.
When the selected frame gets deleted Emacs has to select another frame instead. The following option lets you choose which one.
This variable specifies which frame to select after deleting the
selected frame. The default value mru means delete-frame
should try to select the most recently used frame as returned by
get-mru-frame (see Input Focus) on the same terminal. The
value nil means that delete-frame will try to select the
oldest visible frame on the same terminal as the deleted one.
This function returns a list of all the live frames, i.e., those that
have not been deleted. It is analogous to buffer-list for
buffers, and includes frames on all terminals with the exception of
tooltip frames (see Tooltips). The list that you get is newly
created, so modifying the list doesn’t have any effect on the internals
of Emacs.
This function returns a list of just the currently visible frames. See Visibility of Frames. Frames on text terminals will count as visible even though only the selected one is actually displayed.
This function returns a list of Emacs’s frames, in Z (stacking) order
(see Raising, Lowering and Restacking Frames). The optional argument display
specifies which display to poll. display should be either a frame
or a display name (a string). If omitted or nil, that stands for
the selected frame’s display. It returns nil if display
contains no Emacs frame.
Frames are listed from topmost (first) to bottommost (last). As a
special case, if display is non-nil and specifies a live
frame, it returns the child frames of that frame in Z (stacking) order.
This function is not meaningful on text terminals.
This function lets you cycle conveniently through all the frames on a
specific terminal from an arbitrary starting point. It returns the
frame following frame, in the list of all live frames, on
frame’s terminal. The argument frame must specify a live
frame and defaults to the selected frame. It does not return a frame
whose no-other-frame parameter (see Frame Interaction Parameters) is non-nil.
The second argument, minibuf, says which frames to consider when deciding what the next frame should be:
nilConsider all frames except minibuffer-only frames.
visibleConsider only visible frames.
Consider only visible or iconified frames.
Consider only the frames using that particular window as their minibuffer window.
Consider all frames.
If this function does not find a suitable frame, it returns frame
even if it would not qualify according to the minibuf argument or
its no-other-frame parameter.
Like next-frame, but cycles through all frames in the opposite
direction.
See also next-window and previous-window, in Cyclic Ordering of Windows.
Some Lisp programs need to find one or more frames that satisfy
given criteria. The function filtered-frame-list is provided for
this purpose.
This function returns the list of all the live frames which satisfy the
specified predicate. The argument predicate must be a
function of one argument, a frame to be tested against the filtering
criteria, and should return non-nil if the frame satisfies the
criteria.
The following two functions are useful to transfer parts of the window layout (see Basic Concepts of Emacs Windows) of one frame to two separate frames and to merge the window layouts of two separate frames into one frame.
This command transfers some windows of the specified frame to a new frame and subsequently deletes them on frame. frame must be a live frame and defaults to the selected frame. arg specifies the number of windows to transfer and defaults to 1. Interactively, arg is the prefix argument.
In a first step, it divides the child windows (see Windows and Frames) of frame’s main window (see Side Windows) into two parts. The first part includes the first arg child windows if arg is positive, and the −arg last child windows if arg is negative. The second part includes the remaining child windows of frame’s main window.
In a second step, it clones (see Window Configurations) into a newly created frame each of the windows of the part which does not include frame’s selected window (see Selecting Windows) and removes those windows from frame. Note that the original identity (see Basic Concepts of Emacs Windows) of the cloned windows is lost in this step. The identity of the windows retained on frame is preserved, however. In a final step, it deletes the windows that have been cloned from frame and returns the newly created frame.
This function signals an error if arg is either zero or not a number, or if frame’s main window is either live or does not have more child windows than specified by the absolute value of arg.
This command transfers the main window (see Side Windows) of frame2 to frame1. Both frame1 and frame2 must specify live frames.
In the first step it splits the main window of frame1. If
vertical is non-nil, it makes the new window below the old
main window of frame1. Otherwise, it makes the new window on the
right of frame1’s main window.
In the second step it makes the new window a clone (see Window Configurations) of the main window of frame2. The original identity (see Basic Concepts of Emacs Windows) of the cloned windows is lost in that step. In the final step, it deletes frame2 if the merge completed successfully and returns frame1.
Interactively, vertical is the prefix argument, frame1 is
the selected frame and frame2 is the frame following frame1
in the list of all frames (see Finding All Frames). If frame1
and frame2 are omitted or nil in calls from Lisp, they
default to the above values.
In general you cannot “undo” a split-frame call with a
subsequent merge-frames call for the following reasons: In its
second step merge-frame puts the main window of frame2 into
an internal window split off in the first step. No such window was
present in the configuration of frame1 before calling
split-frame. Also, after merging is complete, the window cloned
from the main window of frame2 will occupy as much space as the
main window of frame1 before merging. This might not match the
space distribution of the original layout.
Hence, if your preferred workflow is to temporarily split off windows
for working on them in a separate frame and later continue with the
original layout of the original frame, you should proceed as follows:
Save the configuration (see Window Configurations) of the original
frame, call split-frame to create the separate frame and finally
restore the saved configuration of the original frame and delete the
separate frame.
Normally, each frame has its own minibuffer window at the bottom, which
is used whenever that frame is selected. You can get that window with
the function minibuffer-window (see Minibuffer Windows).
However, you can also create a frame without a minibuffer. Such a frame
must use the minibuffer window of some other frame. That other frame
will serve as surrogate minibuffer frame for this frame and cannot
be deleted via delete-frame (see Deleting Frames) as long as
this frame is live.
When you create the frame, you can explicitly specify its minibuffer
window (in some other frame) with the minibuffer frame parameter
(see Buffer Parameters). If you don’t, then the minibuffer is found
in the frame which is the value of the variable
default-minibuffer-frame. Its value should be a frame that does
have a minibuffer.
If you use a minibuffer-only frame, you might want that frame to raise
when you enter the minibuffer. If so, set the variable
minibuffer-auto-raise to t. See Raising, Lowering and Restacking Frames.
This variable specifies the frame to use for the minibuffer window, by default. It does not affect existing frames. It is always local to the current terminal and cannot be buffer-local. See Multiple Terminals.
At any time, one frame in Emacs is the selected frame. The selected window (see Selecting Windows) always resides on the selected frame.
When Emacs displays its frames on several terminals (see Multiple Terminals), each terminal has its own selected frame. But only one of these is the selected frame: it’s the frame that belongs to the terminal from which the most recent input came. That is, when Emacs runs a command that came from a certain terminal, the selected frame is the one of that terminal. Since Emacs runs only a single command at any given time, it needs to consider only one selected frame at a time; this frame is what we call the selected frame in this manual. The display on which the selected frame is shown is the selected frame’s display.
This function returns the selected frame.
Some window systems and window managers direct keyboard input to the
window object that the mouse is in; others require explicit clicks or
commands to shift the focus to various window objects. Either
way, Emacs automatically keeps track of which frames have focus. To
explicitly switch to a different frame from a Lisp function, call
select-frame-set-input-focus.
The plural “frames” in the previous paragraph is deliberate: while Emacs itself has only one selected frame, Emacs can have frames on many different terminals (recall that a connection to a window system counts as a terminal), and each terminal has its own idea of which frame has input focus. Under the X Window System, where user input is organized into individual “seats” of input, each seat in turn can have its own specific input focus. When you set the input focus to a frame, you set the focus for that frame’s terminal on the last seat which interacted with Emacs, but frames on other terminals and seats may still remain focused.
If the input focus is set before any user interaction has occurred on the specified terminal, then the X server picks a random seat (normally the one with the lowest number) and sets the input focus there.
Lisp programs can switch frames temporarily by calling the function
select-frame. This does not alter the window system’s concept
of focus; rather, it escapes from the window manager’s control until
that control is somehow reasserted.
When using a text terminal, only one frame can be displayed at a time
on the terminal, so after a call to select-frame, the next
redisplay actually displays the newly selected frame. This frame
remains selected until a subsequent call to select-frame. Each
frame on a text terminal has a number which appears in the mode line
before the buffer name (see Variables Used in the Mode Line).
This function selects frame, raises it (should it happen to be
obscured by other frames) and tries to give it the window system’s
focus. On a text terminal, the next redisplay displays the new frame
on the entire terminal screen. The optional argument norecord
has the same meaning as for select-frame (see below).
The return value of this function is not significant.
Ideally, the function described next should focus a frame without also raising it above other frames. Unfortunately, many window-systems or window managers may refuse to comply.
This function gives frame the focus of the X server without
necessarily raising it. frame nil means use the selected
frame. Under X, the optional argument noactivate, if
non-nil, means to avoid making frame’s window-system window
the “active” window which should insist a bit more on avoiding to
raise frame above other frames.
On MS-Windows the noactivate argument has no effect. However, if frame is a child frame (see Child Frames), this function usually focuses frame without raising it above other child frames.
If there is no window system support, this function does nothing.
This function selects frame frame, temporarily disregarding the focus of the X server if any. The selection of frame lasts until the next time the user does something to select a different frame, or until the next time this function is called. (If you are using a window system, the previously selected frame may be restored as the selected frame after return to the command loop, because it still may have the window system’s input focus.)
The specified frame becomes the selected frame, and its terminal
becomes the selected terminal. This function then calls
select-window as a subroutine, passing the window selected
within frame as its first argument and norecord as its
second argument (hence, if norecord is non-nil, this
avoids changing the order of recently selected windows and the buffer
list). See Selecting Windows.
This function returns frame, or nil if frame has
been deleted.
In general, you should never use select-frame in a way that
could switch to a different terminal without switching back when
you’re done.
This function returns the use time of frame frame. frame must be a live frame and defaults to the selected one.
The use time of a frame is the highest use time as reported by
window-use-time of any window on frame.
This function returns the frame with the highest use time as reported by
frame-use-time. It returns nil if no candidate frames are
found which usually happens if frames are excluded with the help of the
optional arguments.
By default, tooltip and minibuffer-only frames are never candidates. If
the optional argument exclude-child-frames is non-nil, child
frames are excluded too. The exclude-frame argument, if present,
excludes the frame it specifies too. Since in practice the most
recently used frame is always the selected one, it usually makes sense
to call this function with a non-nil exclude-frame argument
specifying the selected frame.
The optional argument all-frames specifies which frames to consider:
visible
means to consider all visible frames on the current terminal or
exclude-frame’s terminal.
This function returns a list of frames sorted by highest use time as
reported by frame-use-time which is computed using each frame’s
most recently used window.
By default, tooltip and minibuffer-only frames are never candidates. If the optional argument exclude-child-frames is non-nil, child frames are excluded too. The exclude-frame argument, if present, excludes the frame it specifies too.
It can return nil which can happen if frames are excluded with
the help of the optional arguments, for example, if there is a single
frame and exclude-frame is the selected frame.
The optional argument all-frames specifies which frames to consider:
visible
means to consider all visible frames on the current terminal or
exclude-frame’s terminal.
This function searches open and undeletable frames for a matching frame identifier id (see Frames). If found, its frame is undeleted, if necessary, then raised, given focus, and made the selected frame. On a text terminal, raising a frame causes it to occupy the entire terminal display.
This function returns the selected frame or signals an error if id
is not found, unless noerror is non-nil, in which case it
returns nil.
This function searches undeletable frames for a matching frame identifier id (see Frames). If found, its frame is undeleted, raised, given focus, and made the selected frame. On a text terminal, raising a frame causes it to occupy the entire terminal display.
This function returns the undeleted frame or signals an error if
id is not found, unless noerror is non-nil, in which
case it returns nil.
Emacs cooperates with the window system by arranging to select frames
as the server and window manager request. When a window system
informs Emacs that one of its frames has been selected, Emacs
internally generates a focus-in event. When an Emacs frame is
displayed on a text-terminal emulator, such as xterm, which
supports reporting of focus-change notification, the focus-in and
focus-out events are available even for text-mode frames. Focus
events are normally handled by handle-focus-in.
This function handles focus-in events from window systems and
terminals that support explicit focus notifications. It updates the
per-frame focus flags that frame-focus-state queries and calls
after-focus-change-function. In addition, it generates a
switch-frame event in order to switch the Emacs notion of the
selected frame to the frame most recently focused in some terminal.
It’s important to note that this switching of the Emacs selected frame
to the most recently focused frame does not mean that other frames do
not continue to have the focus in their respective terminals. Do not
invoke this function yourself: instead, attach logic to
after-focus-change-function.
This function handles a switch-frame event, which Emacs generates for itself upon focus notification or under various other circumstances involving an input event arriving at a different frame from the last event. Do not invoke this function yourself.
This function redirects focus from frame to focus-frame.
This means that focus-frame will receive subsequent keystrokes and
events intended for frame. After such an event, the value of
last-event-frame will be focus-frame. Also, switch-frame
events specifying frame will instead select focus-frame.
If focus-frame is omitted or nil, that cancels any existing
redirection for frame, which therefore once again receives its own
events.
One use of focus redirection is for frames that don’t have minibuffers. These frames use minibuffers on other frames. Activating a minibuffer on another frame redirects focus to that frame. This puts the focus on the minibuffer’s frame, where it belongs, even though the mouse remains in the frame that activated the minibuffer.
Selecting a frame can also change focus redirections. Selecting frame
bar, when foo had been selected, changes any redirections
pointing to foo so that they point to bar instead. This
allows focus redirection to work properly when the user switches from
one frame to another using select-window.
This means that a frame whose focus is redirected to itself is treated
differently from a frame whose focus is not redirected.
select-frame affects the former but not the latter.
The redirection lasts until redirect-frame-focus is called to
change it.
This function retrieves the last known focus state of frame. frame defaults to the selected frame.
It returns nil if the frame is known not to be focused,
t if the frame is known to be focused, or unknown if
Emacs does not know the focus state of the frame. (You may see this
last state in TTY frames running on terminals that do not support
explicit focus notifications.)
This function is called with no arguments when Emacs notices that a frame may have gotten or lost focus. Focus events are delivered asynchronously, and may not be delivered in the expected order, so code that wants to do something depending on the state of focused frames have go through all the frames and check.
For instance, here’s a simple example function that sets the background color based on whether the frame has focus or not:
(add-function :after after-focus-change-function
#'my-change-background)
(defun my-change-background ()
(dolist (frame (frame-list))
(pcase (frame-focus-state frame)
(`t (set-face-background 'default "black" frame))
(`nil (set-face-background 'default "#404040" frame)))))
Multiple frames may appear to have input focus simultaneously due to focus event delivery differences, the presence of multiple Emacs terminals, and other factors, and code should be robust in the face of this situation.
Depending on window system, focus events may also be delivered repeatedly and with different focus states before settling to the expected values. Code relying on focus notifications should “debounce” any user-visible updates arising from focus changes, perhaps by deferring work until redisplay.
This function may be called in arbitrary contexts, including from
inside read-event, so take the same care as you might when
writing a process filter.
This option informs Emacs whether and how the window manager transfers focus when you move the mouse pointer into a frame. It can have three meaningful values:
nilThe default value nil should be used when your window manager
follows a “click-to-focus” policy where you have to click the mouse
inside of a frame in order for that frame to gain focus.
tThe value t should be used when your window manager has the focus
automatically follow the position of the mouse pointer but a frame that
gains focus is not raised automatically and may even remain occluded by
other window-system windows.
auto-raiseThe value auto-raise should be used when your window manager has
the focus automatically follow the position of the mouse pointer and a
frame that gains focus is raised automatically.
If this option is non-nil, Emacs moves the mouse pointer to the
frame selected by select-frame-set-input-focus. That function is
used by a number of commands like, for example, other-frame and
pop-to-buffer.
The distinction between the values t and auto-raise is not
needed for “normal” frames because the window manager usually takes
care of raising them. It is useful to automatically raise child frames
via mouse-autoselect-window (see Mouse Window Auto-selection).
Note that this option does not distinguish “sloppy” focus (where the frame that previously had focus retains focus as long as the mouse pointer does not move into another window-system window) from “strict” focus (where a frame immediately loses focus when it’s left by the mouse pointer). Neither does it recognize whether your window manager supports delayed focusing or auto-raising where you can explicitly specify the time until a new frame gets focus or is auto-raised.
You can supply a “focus follows mouse” policy for individual Emacs
windows by customizing the variable mouse-autoselect-window
(see Mouse Window Auto-selection).
A frame on a graphical display may be visible, invisible, or iconified. If it is visible, its contents are displayed in the usual manner. If it is iconified, its contents are not displayed, but there is a little icon somewhere to bring the frame back into view (some window managers refer to this state as minimized rather than iconified, but from Emacs’s point of view they are the same thing). If a frame is invisible, it is not displayed at all.
On a text terminal a frame may be only visible or invisible. The top frame (see Frames) of a terminal cannot be invisible.
On graphical displays the concept of visibility is strongly related to
that of (un-)mapped frames. A frame (or, more precisely, its
window-system window) is and becomes mapped when it is displayed
for the first time and whenever it changes its state of visibility from
iconified or invisible to visible. Conversely, a
frame is and becomes unmapped whenever it changes its status from
visible to iconified or invisible.
This function returns the visibility status of frame frame. The
value is t if frame is visible, nil if it is
invisible, and icon if it is iconified.
Note that the visibility status of a frame as reported by this function
(and by the visibility frame parameter, see Frame Interaction Parameters) does not necessarily tell whether the frame is actually
seen on display. Any such frame can be partially or completely obscured
by other window manager windows on the same graphical terminal. Whether
that completely hides the frame may then depend on the transparency of
the obscuring window. A frame may also reside on a virtual desktop
different from the current one and can be seen only when making that
desktop the current one. One notable restriction holds for child frames
(see Child Frames): A child frame can be seen if and only if this
function returns true for all its ancestors including the frame itself
and its root frame.
On a text terminal only that terminal’s top frame and its child frames can be actually seen. Other root frames and their child frames cannot be seen even if they are considered visible by this function.
This function iconifies frame frame. If you omit frame, it
iconifies the selected frame. This function also removes any child
frames (see Child Frames) of frame and their descendants from
display. If frame is a child frame itself, the behavior depends
on the value of the variable iconify-child-frame. If frame
is the top frame of a text terminal (see Frames), this function has
no effect.
This function makes frame frame visible. If you omit frame,
it makes the selected frame visible. This does not raise the frame, but
you can do that with raise-frame if you wish (see Raising, Lowering and Restacking Frames).
Making a frame visible makes all its child frames with visible ancestors appear on display again (see Child Frames).
This function makes frame frame invisible. If you omit frame, it makes the selected frame invisible. Usually, this makes all child frames of frame (and their descendants) invisible too (see Child Frames).
Unless force is non-nil, this function refuses to make
frame invisible if all other frames are invisible. On a text
terminal this will make frame invisible if and only if it is a
child frame (see Child Frames). In this case, if frame is
selected, it will select the first visible ancestor of frame
instead. In addition, it will remove all child frames with frame
as their ancestor from display.
The visibility status of a frame is also available as a frame parameter. You can read or change it as such. See Frame Interaction Parameters. The user can also iconify and deiconify frames with the window manager. This happens below the level at which Emacs can exert any control, but Emacs does provide events that you can use to keep track of such changes. See Miscellaneous System Events.
This function returns non-nil if frame is currently
being rendered with double buffering. frame defaults to the
selected frame.
Most window systems use a desktop metaphor. Part of this metaphor is the idea that system-level windows (representing, e.g., Emacs frames) are stacked in a notional third dimension perpendicular to the screen surface. The order induced by stacking is total and usually referred to as stacking (or Z-) order. Where the areas of two windows overlap, the one higher up in that order will (partially) cover the one underneath.
You can raise a frame to the top of that order or lower a
frame to its bottom by using the functions raise-frame and
lower-frame. You can restack a frame directly above or
below another frame using the function frame-restack.
Note that all functions described below will respect the adherence of
frames (and all other window-system windows) to their respective z-group
(see Position Parameters). For example, you usually cannot lower a
frame below that of the desktop window and you cannot raise a frame
whose z-group parameter is nil above the window-system’s
taskbar or tooltip window.
This function raises frame frame (default, the selected frame) above all other frames belonging to the same or a lower z-group as frame. If frame is invisible or iconified, this makes it visible. If frame is a child frame (see Child Frames), this raises frame above all other child frames of its parent. For non-child frames on a text terminal this function has no effect.
This function lowers frame frame (default, the selected frame) below all other frames belonging to the same or a higher z-group as frame. If frame is a child frame (see Child Frames), this lowers frame below all other child frames of its parent. For non-child frames on a text terminal this function has no effect.
This function restacks frame1 below frame2. This implies
that if both frames are visible and their display areas overlap,
frame2 will (partially) obscure frame1. If the optional
third argument above is non-nil, this function restacks
frame1 above frame2. This means that if both frames are
visible and their display areas overlap, frame1 will (partially)
obscure frame2.
Technically, this function may be thought of as an atomic action performed in two steps: The first step removes frame1’s window-system window from the display. The second step reinserts frame1’s window into the display below (above if above is true) that of frame2. Hence the position of frame2 in its display’s Z (stacking) order relative to all other frames excluding frame1 remains unaltered.
Some window managers may refuse to restack windows. This function has not been implemented on text terminals yet.
Note that the effect of restacking will only hold as long as neither of
the involved frames is iconified or made invisible. You can use the
z-group (see Position Parameters) frame parameter to add a
frame to a group of frames permanently shown above or below other
frames. As long as a frame belongs to one of these groups, restacking
it will only affect its relative stacking position within that group.
The effect of restacking frames belonging to different z-groups is
undefined. You can list frames in their current stacking order with the
function frame-list-z-order (see Finding All Frames).
If this is non-nil, activation of the minibuffer raises the frame
that the minibuffer window is in. This variable has no effect on text
terminals.
On window systems, you can also enable auto-raising (on frame selection) or auto-lowering (on frame deselection) using frame parameters. See Window Management Parameters.
A frame configuration records the current arrangement of frames, all their properties, and the window configuration of each one. (See Window Configurations.)
This function returns a frame configuration list that describes the current arrangement of frames and their contents.
This function restores the state of frames described in configuration. However, this function does not restore deleted frames.
Ordinarily, this function deletes all existing frames not listed in
configuration. But if nodelete is non-nil, the
unwanted frames are iconified instead.
Child frames are objects halfway between windows (see Windows) and “normal” frames. Like windows, they are attached to an owning frame. Unlike windows, they may overlap each other—changing the size or position of one child frame does not change the size or position of any of its sibling child frames.
By design, operations to make or modify child frames are implemented with the help of frame parameters (see Frame Parameters) without any specialized functions or customizable variables. Child frames are meaningful on graphical and text terminals.
To create a new child frame or to convert a normal frame into a child
frame, set that frame’s parent-frame parameter (see Frame Interaction Parameters) to that of an already existing frame. The
frame specified by that parameter will then be the frame’s parent frame
as long as the parameter is not changed or reset. Technically, on a GUI
this makes the child frame’s window-system window a child window of the
parent frame’s window-system window. On a text terminal, this makes the
frame usually appear on the same terminal as its parent frame, obscuring
some part of it.
The parent-frame parameter can be changed at any time. Setting
it to another frame reparents the child frame. Setting it to
another child frame makes the frame a nested child frame. Setting
it to nil restores the frame’s status as a top-level frame—a
frame whose window-system window is a child of its display’s root
window.25 On text terminals,
top-level frames are called root frames (see below).
Since child frames can be arbitrarily nested, a frame can be both a child and a parent frame. Also, the relative roles of child and parent frame may be reversed at any time (though it’s usually a good idea to keep the size of a child frame sufficiently smaller than that of its parent). An error will be signaled for the attempt to make a frame an ancestor of itself.
When a parent frame is about to be deleted (see Deleting Frames), its child frames are recursively deleted before it. There is one exception to this rule: When the child frame serves as a surrogate minibuffer frame (see Minibuffers and Frames) for another frame, it is retained until the parent frame has been deleted. If, at this time, no remaining frame uses the child frame as its minibuffer frame, Emacs will try to delete the child frame too. If that deletion fails for whatever reason, the child frame is made a top-level frame. Since on text terminals no such conversion is possible, deleting a frame may throw an error if a surrogate minibuffer frame to be deleted is used by a frame that will not be deleted too.
The following three functions help to understand how parent and child frames related to each other.
This function returns the parent frame of frame. It returns
nil if frame has no parent frame.
This functions returns non-nil if ancestor is an ancestor
of descendant. ancestor is an ancestor of descendant
when it is either descendant’s parent frame or it is an ancestor
of descendant’s parent frame. Both, ancestor and
descendant must specify live frames.
This function returns the root frame of the specified frame. frame must be a live frame and defaults to the selected one. The root frame of frame is the frame obtained by following the chain of parent frames starting with frame until a frame is reached that has no parent. If frame has no parent, its root frame is frame itself.
On a text terminal, a root frame is always positioned at the top left edge of its terminal and always occupies the full size of its terminal.
Most window-systems clip child frames at the native edges (see Frame Geometry) of their parent frame—everything outside these edges is
usually invisible. A child frame’s left and top
parameters specify a position relative to the top-left corner of its
parent’s native frame. When the parent frame is resized, this position
remains conceptually unaltered.
NS builds and text terminals do not clip child frames at the parent frame’s edges, allowing them to be positioned so they do not obscure the parent frame while still being visible themselves.
Note also the function window-largest-empty-rectangle
(see Coordinates and Windows) which can be used to inscribe a child
frame in the largest empty area of an existing window. This can be
useful to avoid that a child frame obscures any text shown in that
window.
Usually, moving a parent frame moves along all its child frames and
their descendants as well, keeping their relative positions unaltered.
Note that the hook move-frame-functions (see Frame Position)
is run for a child frame only when the position of the child frame
relative to its parent frame changes.
When a parent frame is resized, its child frames conceptually retain
their previous sizes and their positions relative to the left upper
corner of the parent. This means that a child frame may become
(partially) invisible when its parent frame shrinks. The parameter
keep-ratio (see Frame Interaction Parameters) can be used to
resize and reposition a child frame proportionally whenever its parent
frame is resized. This may avoid obscuring parts of a frame when its
parent frame is shrunk.
A visible child frame always appears on top of its parent frame thus
obscuring parts of it, except on NS builds where it may be positioned
beneath the parent. This is comparable to the window-system window of a
top-level frame which also always appears on top of its parent
window—the desktop’s root window. When a parent frame is iconified or
made invisible (see Visibility of Frames), any child frames
descending from it will not be shown either even if
frame-visible-p returns t for them. When a parent frame
is deiconified or made visible, any child frames descending from it will
be shown again (provided they and all their ancestor frames are visible
too). If a child frame is used as surrogate minibuffer frame
(see Minibuffers and Frames), it’s up to the application to
guarantee the frame’s visibility whenever the minibuffer is activated.
Whether a child frame can have a menu or tool bar is window-system or window manager dependent. Most window-systems explicitly disallow menu bars for child frames. It seems advisable to disable both, menu and tool bars, via the frame’s initial parameters settings. On a text terminal, child frames use the menu bar of their root frame (provided it has one).
Usually, child frames do not exhibit window manager decorations like a title bar or external borders (see Frame Geometry). When the child frame does not show a menu or tool bar, any other of the frame’s borders (see Layout Parameters) can be used instead of the external borders.
In particular, under X (but not when building with GTK+), the frame’s
outer border can be used. On MS-Windows, specifying a non-zero outer
border width will show a one-pixel wide external border. Under all
window-systems, the internal border can be used. In either case, it’s
advisable to disable a child frame’s window manager decorations with the
undecorated frame parameter (see Window Management Parameters). On
a text terminal, on the other hand, it’s better to leave that parameter
alone so your child frame will be drawn with an outer border.
To resize or move a border-less child frame with the mouse, special
frame parameters (see Mouse Dragging Parameters) have to be used.
The internal border of a child frame, if present, can be used to resize
the frame with the mouse, provided that frame has a non-nil
drag-internal-border parameter. If set, the snap-width
parameter indicates the number of pixels where the frame snaps at
the respective edge or corner of its parent frame. On a text terminal,
the outer border can used for resizing.
There are three ways to drag an entire child frame with the mouse: The
drag-with-mode-line parameter, if non-nil, enables
dragging a frame without minibuffer window (see Minibuffer Windows)
via the mode line area of its bottommost window. The
drag-with-header-line and the drag-with-tab-line
parameters, if non-nil, enable dragging the frame via the header
or tab line area of its topmost window (dragging with the tab line is
possible only when there’s no header line above the tab line).
In order to give a child frame a draggable header or mode line, the
window parameters mode-line-format and header-line-format
are handy (see Window Parameters). These allow removing an
unwanted mode line (when drag-with-header-line is chosen) and to
remove mouse-sensitive areas which might interfere with frame dragging.
When the user drags a frame with a mouse and overshoots, it’s easy
to drag a frame out of the screen area of its parent. Retrieving such
a frame can be hairy once the mouse button has been released. To
prevent such a situation, it is advisable to set the frame’s
top-visible or bottom-visible parameter (see Mouse Dragging Parameters).
Set the top-visible parameter of a child frame to a number when
you intend to allow dragging that frame by its header or tab
line. Setting top-visible to a number inhibits dragging the top
edge of the child frame above the top edge of its parent. Set the
bottom-visible parameter to a number when you intend to drag that
frame via its mode line; this inhibits dragging the bottom edge of the
child frame beneath the bottom edge of its parent. In either case, that
number also specifies width and height (in pixels) of the area of the
child frame that remains visible during dragging.
When a child frame is used for displaying a buffer via
display-buffer-in-child-frame (see Action Functions for Buffer Display), the frame’s auto-hide-function parameter
(see Frame Interaction Parameters) can be set to a function, in
order to appropriately deal with the frame when the window displaying
the buffer shall be quit.
When a child frame is used during minibuffer interaction, for example,
to display completions in a separate window, the minibuffer-exit
parameter (see Frame Interaction Parameters) is useful in order to
deal with the frame when the minibuffer is exited.
The behavior of child frames deviates from that of normal frames in a number of peculiar ways. Here we sketch a few of them:
iconify-frame on a child frame will try to iconify the top-level
frame corresponding to that child frame instead. To obtain a different
behavior, users may customize the option iconify-child-frame
described below.
z-group (see Position Parameters)
of a child frame changes only the stacking order of child frames with
the same parent. Restacking has not been implemented on text terminals.
mouse-autoselect-window can
help in this regard (see Mouse Window Auto-selection).
Customizing the following option can be useful to tweak the behavior of
iconify-frame for child frames.
This option tells Emacs how to proceed when it is asked to iconify a
child frame. If it is nil, iconify-frame will do nothing
when invoked on a child frame. If it is iconify-top-level, Emacs
will try to iconify the root frame of this child frame instead. If it
is make-invisible, Emacs will try to make this child frame
invisible instead of iconifying it.
Any other value means to try iconifying the child frame. Since such an attempt may not be honored by all window managers and can even lead to making the child frame unresponsive to user actions, the default is to iconify the root frame instead.
On a text terminal the only feasible values are nil and
make-invisible.
On text terminals exist a few restrictions with respect to reparenting: One is that a top frame (see Frames) cannot be directly made a child frame—you first have to make another root frame the new top frame of its terminal. If, on the other hand, you want a child frame to become the new top frame of its terminal, you have to make it a root frame first.
Also, the surrogate minibuffer window of any frame on a text terminal
must reside on a frame with the same root frame. Reparenting will throw
an error whenever it violates this restriction. It also means that it’s
more tricky to make a minibuffer-less frame whose minibuffer window
resides on a minibuffer-only child frame. On a GUI, Emacs proceeds as
follows when a user has specified the value child-frame for the
minibuffer parameter in initial-frame-alist
(see Initial Frame Parameters):
minibuffer parameter set
to the window of the minibuffer-only frame.
On a text terminal you have to perform these operations manually as sketched in the following snippet:
(let* ((selected (selected-frame))
(mini-only
(make-frame
`((parent-frame . ,selected)
(minibuffer . only)
(left . 1) (top . -1) (width . 20) (height . 1))))
(mini-less
(make-frame
(append `((parent-frame . ,selected)
(minibuffer . ,(minibuffer-window mini-only)))))))
(set-frame-parameter mini-only 'parent-frame mini-less)
(set-frame-parameter mini-less 'parent-frame nil)
(select-frame mini-less)
(delete-frame selected))
This means that you first have to install the minibuffer-less and the
minibuffer-only frames both as child frames of the selected frame with
the minibuffer parameter of the minibuffer-less frame set to the
minibuffer window of the minibuffer-only frame. Then make the
minibuffer-only frame a child frame of the minibuffer-less frame and
make the minibuffer-less frame a new root frame. Finally, select the
minibuffer-less frame and delete the originally selected frame.
Sometimes it is useful to track the mouse, which means to display something to indicate where the mouse is and move the indicator as the mouse moves. For efficient mouse tracking, you need a way to wait until the mouse actually moves.
The convenient way to track the mouse is to ask for events to represent mouse motion. Then you can wait for motion by waiting for an event. In addition, you can easily handle any other sorts of events that may occur. That is useful, because normally you don’t want to track the mouse forever—only until some other event, such as the release of a button.
This macro executes body, with generation of mouse motion events
enabled. Typically, body would use read-event to read
the motion events and modify the display accordingly. See Motion Events, for the format of mouse motion events.
The value of track-mouse is that of the last form in
body. You should design body to return when it sees the
up-event that indicates the release of the button, or whatever kind of
event means it is time to stop tracking. Its value also controls how
mouse events are reported while a mouse button is held down: if it is
dropping or drag-source, the motion events are reported
relative to the frame underneath the pointer. If there is no such
frame, the events will be reported relative to the frame the mouse
buttons were first pressed on. In addition, the posn-window of
the mouse position list will be nil if the value is
drag-source. This is useful to determine if a frame is not
directly visible underneath the mouse pointer.
The track-mouse macro causes Emacs to generate mouse motion
events by binding the variable track-mouse to a
non-nil value. If that variable has the special value
dragging, it additionally instructs the display engine to
refrain from changing the shape of the mouse pointer. This is
desirable in Lisp programs that require mouse dragging across large
portions of Emacs display, which might otherwise cause the mouse
pointer to change its shape according to the display portion it hovers
on (see Pointer Shape). Therefore, Lisp programs that need the
mouse pointer to retain its original shape during dragging should bind
track-mouse to the value dragging at the beginning of
their body.
The usual purpose of tracking mouse motion is to indicate on the screen the consequences of pushing or releasing a button at the current position.
In many cases, you can avoid the need to track the mouse by using
the mouse-face text property (see Properties with Special Meanings).
That works at a much lower level and runs more smoothly than
Lisp-level mouse tracking.
The functions mouse-position and set-mouse-position
give access to the current position of the mouse.
This function returns a description of the position of the mouse. The
value looks like (frame x . y), where x
and y are integers giving the (possibly rounded) position in
multiples of the default character size of frame (see Frame Font) relative to the native position of frame (see Frame Geometry).
If non-nil, the value of this variable is a function for
mouse-position to call. mouse-position calls this
function just before returning, with its normal return value as the
sole argument, and it returns whatever this function returns to it.
This abnormal hook exists for the benefit of packages like xt-mouse.el that need to do mouse handling at the Lisp level.
If non-nil, TTY menus will call mouse-position-function
as described above. This exists for cases where
mouse-position-function is not safe to be called by the TTY
menus, such as if it could trigger redisplay.
This function warps the mouse to position x, y in frame frame. The arguments x and y are integers, giving the position in multiples of the default character size of frame (see Frame Font) relative to the native position of frame (see Frame Geometry).
The resulting mouse position is constrained to the native frame of frame. If frame is not visible, this function does nothing. The return value is not significant.
This function is like mouse-position except that it returns
coordinates in units of pixels rather than units of characters.
This function warps the mouse like set-mouse-position except that
x and y are in units of pixels rather than units of
characters.
The resulting mouse position is not constrained to the native frame of frame. If frame is not visible, this function does nothing. The return value is not significant.
On a graphical terminal the following two functions allow the absolute position of the mouse cursor to be retrieved and set.
This function returns a cons cell (x . y) of the coordinates of the mouse cursor position in pixels, relative to a position (0, 0) of the selected frame’s display.
This function moves the mouse cursor to the position (x, y). The coordinates x and y are interpreted in pixels relative to a position (0, 0) of the selected frame’s display.
The following function can tell whether the mouse cursor is currently visible on a frame:
This predicate function returns non-nil if the mouse pointer
displayed on frame is visible; otherwise it returns nil.
frame omitted or nil means the selected frame. This is
useful when make-pointer-invisible is set to t: it
allows you to know if the pointer has been hidden.
See Mouse Avoidance in The Emacs Manual.
A Lisp program can pop up a menu so that the user can choose an alternative with the mouse. On a text terminal, if the mouse is not available, the user can choose an alternative using the keyboard motion keys—C-n, C-p, or up- and down-arrow keys.
This function displays a pop-up menu and returns an indication of what selection the user makes.
The argument position specifies where on the screen to put the
top left corner of the menu. It can be either a mouse button or
touchscreen-begin event (which says to put the menu where the
user actuated the button) or a list of this form:
((xoffset yoffset) window)
where xoffset and yoffset are coordinates, measured in pixels, counting from the top left corner of window. window may be a window or a frame.
If position is t, it means to use the current mouse
position (or the top-left corner of the frame if the mouse is not
available on a text terminal). If position is nil, it
means to precompute the key binding equivalents for the keymaps
specified in menu, without actually displaying or popping up the
menu.
The argument menu says what to display in the menu. It can be a
keymap or a list of keymaps (see Menu Keymaps). In this case, the
return value is the list of events corresponding to the user’s choice.
This list has more than one element if the choice occurred in a
submenu. (Note that x-popup-menu does not actually execute the
command bound to that sequence of events.) On text terminals and
toolkits that support menu titles, the title is taken from the prompt
string of menu if menu is a keymap, or from the prompt
string of the first keymap in menu if it is a list of keymaps
(see Defining Menus).
Alternatively, menu can have the following form:
(title pane1 pane2...)
where each pane is a list of form
(title item1 item2...)
Each item should be a cons cell, (line . value),
where line is a string and value is the value to return if
that line is chosen. Unlike in a menu keymap, a nil
value does not make the menu item non-selectable.
Alternatively, each item can be a string rather than a cons
cell; this makes a non-selectable menu item.
If the user gets rid of the menu without making a valid choice, for
instance by clicking the mouse away from a valid choice or by typing
C-g, then this normally results in a quit and
x-popup-menu does not return. But if position is a mouse
button event (indicating that the user invoked the menu with the
mouse) then no quit occurs and x-popup-menu returns nil.
Usage note: Don’t use x-popup-menu to display a menu
if you could do the job with a prefix key defined with a menu keymap.
If you use a menu keymap to implement a menu, C-h c and C-h
a can see the individual items in that menu and provide help for them.
If instead you implement the menu by defining a command that calls
x-popup-menu, the help facilities cannot know what happens inside
that command, so they cannot give any help for the menu’s items.
The menu bar mechanism, which lets you switch between submenus by
moving the mouse, cannot look within the definition of a command to see
that it calls x-popup-menu. Therefore, if you try to implement a
submenu using x-popup-menu, it cannot work with the menu bar in
an integrated fashion. This is why all menu bar submenus are
implemented with menu keymaps within the parent menu, and never with
x-popup-menu. See The Menu Bar.
If you want a menu bar submenu to have contents that vary, you should
still use a menu keymap to implement it. To make the contents vary, add
a hook function to menu-bar-update-hook to update the contents of
the menu keymap as necessary.
A normal hook run immediately before a pop-up menu is displayed,
either directly by calling x-popup-menu, or through a menu
keymap. It won’t be called if x-popup-menu returns for some
other reason without displaying a pop-up menu.
An on-screen keyboard is a special kind of pop up provided by the system, with rows of clickable buttons that act as a real keyboard.
On certain systems (see On-Screen Keyboards in The Emacs Manual), Emacs is supposed to display and hide the on screen keyboard depending on whether or not the user is about to type something.
This function displays or hides the on-screen keyboard on behalf of
the frame frame. If hide is non-nil, then the
on-screen keyboard is hidden; otherwise, it is displayed.
It returns whether or not the on screen keyboard may have been displayed, which should be used to determine whether or not to hide the on-screen keyboard later.
This has no effect if the system automatically detects when to display the on-screen keyboard, or when it does not provide any on-screen keyboard.
A dialog box is a variant of a pop-up menu—it looks a little
different, it always appears in the center of a frame, and it has just
one level and one or more buttons. The main use of dialog boxes is
for asking questions that the user can answer with “yes”, “no”,
and a few other alternatives. With a single button, they can also
force the user to acknowledge important information. The functions
y-or-n-p and yes-or-no-p use dialog boxes instead of the
keyboard, when called from commands invoked by mouse clicks.
This function displays a pop-up dialog box and returns an indication of what selection the user makes. The argument contents specifies the alternatives to offer; it has this format:
(title (string . value)...)
which looks like the list that specifies a single pane for
x-popup-menu.
The return value is value from the chosen alternative.
As for x-popup-menu, an element of the list may be just a
string instead of a cons cell (string . value).
That makes a box that cannot be selected.
If nil appears in the list, it separates the left-hand items from
the right-hand items; items that precede the nil appear on the
left, and items that follow the nil appear on the right. If you
don’t include a nil in the list, then approximately half the
items appear on each side.
Dialog boxes always appear in the center of a frame; the argument
position specifies which frame. The possible values are as in
x-popup-menu, but the precise coordinates or the individual
window don’t matter; only the frame matters.
If header is non-nil, the frame title for the box is
‘Information’, otherwise it is ‘Question’. The former is used
for message-box (see message-box). (On text terminals, the
box title is not displayed.)
In some configurations, Emacs cannot display a real dialog box; so instead it displays the same items in a pop-up menu in the center of the frame.
If the user gets rid of the dialog box without making a valid choice,
for instance using the window manager, then this produces a quit and
x-popup-dialog does not return.
You can specify the mouse pointer style for particular text or
images using the pointer text property, and for images with the
:pointer and :map image properties. The values you can
use in these properties are in the table below. The actual shapes
may vary between systems; the descriptions are examples.
textnilThe usual mouse pointer style used over text (an “I”-like shape).
arrowvdragmodelineAn arrow that points north-west.
handA hand that points upwards.
hdragA right-left arrow.
nhdragAn up-down arrow.
hourglassA rotating ring.
Over void parts of the window (parts that do not correspond to any
of the buffer contents), the mouse pointer usually uses the
arrow style, but you can specify a different style (one of
those above) by setting void-text-area-pointer.
This variable specifies the mouse pointer style for void text areas.
These include the areas after the end of a line or below the last line
in the buffer. The default is to use the arrow (non-text)
pointer style.
When using some window systems, you can specify what the text
pointer style really looks like by setting the variable
x-pointer-shape.
This variable specifies the pointer shape to use ordinarily in the
Emacs frame, for the text pointer style.
This variable specifies the pointer shape to use when the mouse is over mouse-sensitive text.
These variables affect newly created frames. They do not normally affect existing frames; however, if you set the mouse color of a frame, that also installs the current value of those two variables. See Font and Color Parameters.
The values you can use, to specify either of these pointer shapes, are defined in the file lisp/term/x-win.el. Use M-x apropos RET x-pointer RET to see a list of them.
In window systems, such as X, data can be transferred between different applications by means of selections. Each window system defines an arbitrary number of selection types, all storing their own data; however, only three are commonly used: the clipboard, primary selection, and secondary selection. See Cut and Paste in The GNU Emacs Manual, for Emacs commands that make use of these selections. This section documents the low-level functions for reading and setting window-system selections; See Accessing Selections, for documentation concerning selection types and data formats under particular window systems.
This function sets a window-system selection. It takes two arguments: a selection type type, and the value to assign to it, data.
type should be a symbol; it is usually one of PRIMARY,
SECONDARY or CLIPBOARD. These are generally symbols
with upper-case names, in accord with X Window System conventions. If
type is nil, that stands for PRIMARY.
If data is nil, it means to clear out the selection.
Otherwise, data may be a string, a symbol, an integer, an
overlay, or a cons of two markers pointing to the same buffer. An
overlay or a pair of markers stands for text in the overlay or between
the markers. The argument data may also be a vector of valid
non-vector selection values.
If data is a string, then its text properties can specify values
used for individual data types. For example, if data has a
property named text/uri-list, then a call to
gui-get-selection with the data type text/uri-list will
result in the value of that property being used instead of data
itself.
This function returns data.
This function accesses selections set up by Emacs or by other
programs. It takes two optional arguments, type and
data-type. The default for type, the selection type, is
PRIMARY.
The data-type argument specifies the form of data conversion to
use, to convert the raw data obtained from another program into Lisp
data. It defaults to STRING. See X Selections, for an
enumeration of data types valid on X, and see Other Selections for
those elsewhere. On X Window system, we recommend to always specify a
particular data-type, especially if the selection is expected to
be non-ASCII text (in which case Lisp programs should prefer
UTF8_STRING as the value of data-type). This is because
the default data-type value, STRING, can only support
Latin-1 text, which in many cases is nowadays inadequate.
This variable provides a coding system (see Coding Systems) which is used to encode selection data, and takes effect on MS-Windows and X. It is also used in the MS-DOS port when it runs on MS-Windows and can access the Windows clipboard text.
On X, the value of this variable provides the coding system which
gui-get-selection will use to decode selection data for a
subset of text data types, and also forces replies to selection
requests for the polymorphic TEXT data type to be encoded by
the compound-text-with-extensions coding system rather than
Unicode.
On MS-Windows, this variable is generally ignored, as the MS-Windows clipboard provides the information about decoding as part of the clipboard data, and uses either UTF-16 or locale-specific encoding automatically as appropriate. We recommend to set the value of this variable only on the older Windows 9X, as it is otherwise used only in the very rare cases when the information provided by the clipboard data is unusable for some reason.
The default value of this variable is the system code page under
MS-Windows 98 or Me, utf-16le-dos on Windows
NT/W2K/XP/Vista/7/8/10/11, iso-latin-1-dos on MS-DOS, and
nil elsewhere.
For backward compatibility, there are obsolete aliases
x-get-selection and x-set-selection, which were the
names of gui-get-selection and gui-set-selection before
Emacs 25.1.
The data types and selections that gui-get-selection and
gui-set-selection understand are not precisely specified and
differ subject to the window system on which Emacs is running.
At the same time, gui-set-selection abstracts over plenty of
complexity: its data argument is given verbatim to
system-specific code to be rendered suitable for transfer to the
window system or requesting clients.
The most comprehensive implementation of selections exists under the X Window System. This is both an artifact of history (X was the first window system supported by Emacs) and one occasioned by technical considerations: X selections are not merely an expedient for the transfer of text and multimedia content between clients, but a general inter-client communication system, a design that has yielded a proliferation of selection and data types.
Compounding this confusion, there is another inter-client communication mechanism under X: the Inter-Client Exchange. ICE is only used by Emacs to communicate with session managers, and is a separate topic.
X refrains from defining fixed data types for selection data or a fixed number of selections. Selections are identified by X “atoms”, which are unique 29-bit identifiers issued by the X server for string names. This complexity is hidden by Emacs: when Lisp provides a symbol whose name is that of the atom, Emacs will request these identifiers without further intervention.
When a program “sets” a selection under X, it actually makes itself the “owner” of the selection—the X server will then deliver selection requests to the program, which is obliged to respond to the requesting client with the selection data.
Similarly, a program does not “get” selection data from the X server. Instead, its selection requests are sent to the client with the window which last asserted ownership over the selection, which is expected to respond with the requested data.
Each selection request incorporates three parameters:
gui-get-selection.
The selection owner responds by transferring to the requestor a
series of bytes, 16 bit words, or 32 bit words, along with another
atom identifying the type of those words. After requesting a
selection, Emacs then applies its own interpretation of the data
format and data type to convert the data transferred by the selection
owner to a Lisp representation, which gui-get-selection
returns.
Emacs converts selection data consisting of any series of bytes to a unibyte string holding those bytes, that consisting of a single 16-bit or 32-bit word as an unsigned number, and that consisting of multiple such words as a vector of unsigned numbers. The exceptions to this general pattern are that Emacs applies special treatment for data from the following conversion targets:
INTEGER16-bit or 32-bit words of this type are treated as signed rather than unsigned integers. If there are multiple words in the selection data, a vector is returned; otherwise, the integer is returned by itself.
ATOM32-bit words of this type are treated as X atoms, and returned (either
alone or as vectors) as Lisp symbols by the names they identify.
Invalid atoms are replaced by nil.
COMPOUND_TEXTUTF8_STRINGSTRINGA single foreign-selection text property set to the type of the
selection data will be placed in unibyte strings derived from a
request for these data types.
Each selection owner must return at least two selection targets:
TARGETS, which returns a number of atoms describing the
selection targets that the owner supports, and MULTIPLE, used
for internal purposes by X clients. A selection owner may support any
number of other targets, some of which may be standardized by the X
Consortium’s
Inter-Client Communication Conventions Manual, while others, such as
UTF8_STRING, were meant to be standardized by the XFree86
Project, but their standardization was never completed.
Requests for a given selection target may, by convention, return data in a specific type, or it may return data in one of several types, whichever is most convenient for the selection owner; the latter type of selection target is dubbed a polymorphic target. In response to a request, a selection target may also return no data at all, whereafter the selection owner executes some action as a side effect. Targets that are thus replied to are termed side-effect targets.
Here are some selection targets whose behavior is generally
consistent with a standard when requested from the CLIPBOARD,
PRIMARY, or SECONDARY selections.
ADOBE_PORTABLE_DOCUMENT_FORMATThis target returns data in Adobe System’s “Portable Document Format” format, as a string.
APPLE_PICTThis target returns data in the “PICT” image format used on Macintosh computers, as a string.
BACKGROUNDBITMAPCOLORMAPFOREGROUNDTogether, these four targets return integer data necessary to make use of a bitmap image stored on the X server: the pixel value of the bitmap’s background color, the X identifier of the bitmap, the colormap inside which the background and foreground are allocated, and the pixel value of the bitmap’s foreground color.
CHARACTER_POSITIONThis target returns two unsigned 32-bit integers of type SPAN
describing the start and end positions of the selection data in the
text field containing it, in bytes.
COMPOUND_TEXTThis target returns a string of type COMPOUND_TEXT in the X
Consortium’s multi-byte text encoding system.
DELETEThis target returns nothing, but as a side-effect deletes the selection contents from any text field containing them.
DRAWABLEPIXMAPThis target returns a list of unsigned 32-bit integers, each of which corresponds to an X server drawable or pixmap.
ENCAPSULATED_POSTSCRIPT_ADOBE_EPSThis target returns a string containing encapsulated Postscript code.
FILE_NAMEThis target returns a string containing one or more file names, separated by NULL characters.
HOST_NAMEThis target returns a string containing the fully-qualified domain name of the machine on which the selection owner is running.
USERThis target returns a string containing the user name of the machine on which the selection owner is running.
LENGTHThis target returns an unsigned 32-bit or 16-bit integer containing the length of the selection data.
LINE_NUMBERThis target returns two unsigned 32-bit integers of type SPAN
describing the line numbers corresponding to the start and end
positions of the selection data in the text field containing it.
MODULEThis target returns the name of any function containing the selection data. It is principally requested by text editors.
STRINGThis target returns the selection data as a string of type
STRING, encoded in ISO Latin-1 format, with Unix newline
characters.
C_STRINGThis target returns the selection data as a “C string”. This has been interpreted as meaning the raw selection data in whatever encoding used by the owner, either terminated with a NULL byte or not at all, or an ASCII string which may or may not be terminated.
UTF8_STRINGThis returns the selection data as a string of type
UTF8_STRING, encoded in UTF-8, with unspecified EOL format.
TIMESTAMPThis target returns the X server time at which the selection owner
took ownership over the selection as a 16-bit or 32-bit word of type
CARDINAL.
TEXTThis polymorphic target returns selection data as a string, either
COMPOUND_TEXT, STRING, C_STRING, or
UTF8_STRING, whichever data type is convenient for the
selection owner.
When a request for the targets STRING, COMPOUND_TEXT,
or UTF8_STRING is made using the function
gui-get-selection, and neither selection-coding-system
nor next-selection-coding-system is set, the resultant strings
are decoded by the proper coding systems for those targets:
iso-8859-1, compound-text-with-extensions and
utf-8 respectively.
In addition to the targets specified above (and the many targets
used by various programs for their own purposes), several popular
programs and toolkits have defined selection data types of their own,
without consulting the appropriate X standards bodies. These targets
are generally named after such MIME types as text/html or
image/jpeg; they have been witnessed returning the following
forms of data:
file:// URIs (or conceivably newline or NUL terminated lists of
URIs) identifying files in the appropriate format.
These selection targets were first used by Netscape, but are now proffered by all kinds of programs, especially those based on recent versions of the GTK+ or Qt toolkits.
Emacs is also capable of serving as a selection owner. When
gui-set-selection is called, the selection data provided is
recorded internally and Emacs obtains ownership of the selection being
set.
Alist of selection targets to “selection converter” functions. When a selection request is received, Emacs looks up the selection converter pertaining to the requested selection target.
Selection converters are called with three arguments: the symbol
corresponding to the atom identifying the selection being requested,
the selection target that is being requested, and the value set with
gui-set-selection. The values which they must return are
either conses of symbols designating the data type and numbers,
symbols, vectors of numbers or symbols, or the cdrs of such conses by
themselves.
If a selection converter’s value is the special symbol NULL,
the data type returned to its requestor is set to NULL, and no
data is sent in response.
If such a value is a string, it must be a unibyte string; should no
data type be explicitly specified, the data is transferred to its
requestor with the type STRING.
If it is a symbol, its “atom” is retrieved, and it is transferred to
its requestor as a 32-bit value—if no data type is specified, its
type is ATOM.
If it is a number between -32769 and 32768, it is
transferred to its requestor as a 16 bit value—if no data type is
specified, its type is INTEGER.
If it is any other number, it is accounted a 32 bit value. Even if
the number returned is unsigned, its requestor will treat words of
type INTEGER as signed. To return an unsigned value, specify
the type CARDINAL in its place.
If it is a vector of symbols or numbers, the response to its requestor will be a list of multiple atoms or numbers. The data type returned when not expressly set is that of the list’s first element.
By default, Emacs is configured with selection converters for the following selection targets:
TEXTThis selection converter returns selection data as:
C_STRING, if the selection contents contain no
multibyte characters, or contain “raw 8-bit bytes” (see Text Representations).
STRING, if the selection contents can be
represented as ISO-Latin-1 text.
COMPOUND_TEXT, if the selection contents can
be encoded in the X Consortium’s Compound Text Encoding, and
selection-coding-system or next-selection-coding-system
is set to a coding system whose :mime-charset property is
x-ctext.
UTF8_STRING otherwise.
COMPOUND_TEXTThis selection converter returns selection data as a string of type
COMPOUND_TEXT.
STRINGThis selection converter returns selection data as a string of type
STRING, encoded in ISO-Latin-1 format.
UTF8_STRINGThis selection converter returns selection data in UTF-8 format.
text/plaintext/plain;charset=utf-8text/uri-listtext/x-xdnd-usernameXmTRANSFER_SUCCESSXmTRANSFER_FAILUREFILE_DT_NETFILEThese selection converters are used for internal purposes during
drag-and-drop operations and are not available for selections other
than XdndSelection.
TARGETSThis selection converter returns a list of atoms, one for each selection target understood by Emacs.
MULTIPLEThis selection converter is implemented in C code and is used to implement efficient transfer of selection requests which specify multiple selection targets at the same time.
LENGTHThis selection converter returns the length of the selection data, in bytes.
DELETEThis selection converter is used for internal purposes during drag-and-drop operations.
FILE_NAMEThis selection converter returns the file name of the buffer containing the selection data.
CHARACTER_POSITIONThis selection converter returns the character positions of each end of the selection in the buffer containing the selection data.
LINE_NUMBERCOLUMN_NUMBERThis selection converter returns the line and column numbers of each end of the selection in the buffer containing the selection data.
OWNER_OSThis selection converter returns the name of the operating system on which Emacs is running.
HOST_NAMEThis selection converter returns the fully-qualified domain name of the machine on which Emacs is running.
USERThis selection converter returns the username of the user account under which Emacs is running.
CLASSNAMEThese selection converters return the resource class and name used by Emacs.
INTEGERThis selection converter returns an integer value verbatim.
SAVE_TARGETS_EMACS_INTERNALThese selection converters are used for internal purposes.
With the exception of INTEGER, all selection converters
expect the data provided to gui-set-selection to be one of the
following:
(beg end buf), where
beg and end are two markers or overlays describing the
bounds of the selection data in the buffer buf.
Selections under such window systems as MS-Windows, Nextstep, Haiku
and Android are not aligned with those under X. Each of these window
system improvises its own selection mechanism without employing the
“selection converter” mechanism illustrated in the preceding node.
Only the PRIMARY, CLIPBOARD, and SECONDARY
selections are generally supported, with the XdndSelection
selection that records drag-and-drop data also available under
Nextstep and Haiku.
GTK seeks to emulate the X selection system, but its emulations are not altogether dependable, with the overall quality of each subject to the GDK backend being used. Therefore, Emacs built with PGTK will supply the same selection interface as Emacs built with X, but many selection targets will not be useful.
Although a clipboard exists, there is no concept of primary or secondary selections within the MS-Windows operating system. On this system, Emacs simulates the presence of a primary and secondary selection, while saving to and retrieving from the clipboard when so requested.
The simulation of the primary and secondary selections is conducted
by saving values supplied to gui-set-selection within the
x-selections property of the symbol designating the pertinent
selection, namely the type argument to gui-get-selection.
Each subsequent call to gui-get-selection in turn returns its
value, which is not subject to further examination (such as type
checks and the like). Under such circumstances, data-type
argument is generally disregarded. (But see below for the
qualification regarding TARGETS.)
Where the clipboard selection is concerned (whenever type is
CLIPBOARD), gui-set-selection verifies that the value
provided is a string and saves it within the system clipboard once it
is encoded by the coding system configured in
selection-coding-system. Callers of gui-get-selection
are required to set data-type to either STRING or
TARGETS.
When data-type is set to TARGETS in a call to
gui-get-selection, a vector of symbols is returned when
selection data exists, much as it is under X. It is impossible to
request clipboard data in any format besides STRING, for the
prerequisite data conversion routines are absent. Just as strings
saved into the clipboard are encoded by the
selection-coding-system, so those read from the clipboard are
decoded by that same coding system; this variable and its cousin
next-selection-coding-system merit particular scrutiny when
difficulties are encountered with saving selection text into the
clipboard.
All three selections standard in X exist in Nextstep as well, but
Emacs is only capable of saving strings to such selections.
Restrictions imposed upon calls to gui-set-selection there are
much the same as those on MS-Windows, though text is uniformly encoded
as utf-8-unix without regard to the value of
selection-coding-system. gui-get-selection is more
charitable, and accepts requests for the following selection targets:
The XdndSelection selection is also present under Nextstep,
in the form of a repository that records values supplied to
gui-set-selection. Its sole purpose is to save such values for
the fundamental drag-and-drop function x-begin-drag
(see Drag and Drop); no guarantees exist concerning its value when
read by anything else.
Selections on Haiku systems comprise all three selections customary
under X and the XdndSelection that records drag-and-drop data.
When gui-set-selection is called for the former three
selections, the data supplied is converted into a window server
“message” by a list of selection encoder functions, which is
sent to the window server.
List of selection encoder functions. When gui-set-selection is
called, each function in this list is successively called with its
selection and value arguments. If such a function returns
non-nil, its return value must be a list of the form
(key type value). In this list,
key must be the name of the data being transferred, generally
that of a MIME type, for example ‘"text/plain"’, and type
is a symbol or a number designating the type of the data; thus also
governing the interpretation of value; following is a list of
valid data types and how each of them will cause value to be
interpreted.
stringA unibyte string. The string is NULL-terminated after being placed in the message.
refA file name. The file is located and the inode identifying the file is placed in the message.
shortA 16-bit integer value.
longA 32-bit integer value.
llongA 64-bit integer value.
bytecharAn unsigned byte between 0 and 255.
size_tA number between 0 and 1 minus two to the power of the word size of the computer Emacs is running on.
ssize_tA number which fits in the C type ssize_t.
pointA cons of two floats, specifying a coordinate on-screen.
floatdoubleA single or double-precision floating point number in an unspecified format.
(haiku-numeric-enum MIME)A unibyte string containing data in a certain MIME type.
A call to gui-get-selection generally returns the data
named data-type within the selection message, albeit with
data-type replaced by an alternative name should it be one of
the following X selection targets:
STRINGThis represents Latin-1 text under X: “text/plain;charset=iso-8859-1”
UTF8_STRINGThis represents UTF-8 text: “text/plain”
If data-type is a text type such as STRING or a MIME
type matching the pattern ‘`text/*’, the string data is decoded
with the coding system apposite for it before being returned.
Furthermore, the two data types TIMESTAMP and TARGETS
are afforded special treatment; the value returned for the first is
the number of times the selection has been modified since system
startup (not a timestamp), and that for the other is a vector
of available selection data types, as elsewhere.
Much like MS-Windows, Android provides a clipboard but no primary or
secondary selection; gui-set-selection simulates the primary
and secondary selections by saving the value supplied into a variable
subsequent calls to gui-get-selection return.
From the clipboard, gui-get-selection is capable of returning
UTF-8 string data of the type STRING, the TARGETS data
type, or image and application data of any MIME type.
gui-set-selection sets only string data, much as under
MS-Windows, although this data is not affected by the value of
selection-coding-system. By contrast, only string data can be
saved to and from the primary and secondary selections; but since this
data is not communicated to programs besides Emacs, it is not subject
to encoding or decoding by any coding system.
Data saved within window system selections and the MS-Windows
clipboard is not restricted to plain text. It is possible for selection
data to encompass images or other binary data of the like, as well as
rich text content instanced by HTML, and also PostScript. Since the
selection data types incident to this data are at variance with those
for plain text, the insertion of such data is facilitated by a set of
functions dubbed yank-media handlers, which are registered by each
major mode undertaking its insertion and called where warranted upon the
execution of the yank-media command.
Register a yank-media handler which applies to the current buffer.
types can be a symbol designating a selection data type (see Accessing Selections), a regexp against which such types are matched, or a list of these symbols and regexps. For instance:
(yank-media-handler 'text/html #'my-html-handler) (yank-media-handler "image/.*" #'my-image-handler)
When a selection offers a data type matching types, the function
handler is called to insert its data, with the symbol
designating the matching selection data type, and the data returned by
gui-get-selection.
The yank-media command auto selects the preferred MIME type
by default. The rules used for the selection can be controlled through
the variables yank-media-autoselect-function and
yank-media-preferred-types.
This variable should specify a function that will be called with the
list of MIME types available for the current major mode, and should
return a list of preferred MIME types to use. The first MIME
type in the list will always be used by the yank-media command
when auto selection is requested.
This variable changes the default selection process of
yank-media-autoselect-function. It is a list that should contain
the sole MIME type to choose in the order of their preference. It
can also contain a function in which case it is called with the list of
available MIME types and must return a list of preferred MIME
types in order of their preference. This list is passed onto the
yank-media command so the first element of the returned list is
chosen when auto selection is requested.
The yank-media-types command presents a list of selection data
types that are currently available, which is useful when implementing
yank-media handlers; for programs generally offer an eclectic and
seldom consistent medley of data types.
Data transferred by drag and drop is generally either plain text or a list of URLs designating files or other resources. When text is dropped, it is inserted at the location of the drop, with recourse to saving it into the kill ring if that is not possible.
URLs dropped are supplied to pertinent DND handler functions
in the variable dnd-protocol-alist, or alternatively “URL
handlers” as set forth by the variables browse-url-handlers
and browse-url-default-handlers; absent matching handlers of
either type, they are treated as plain text and inserted in the
buffer.
This variable is an alist between regexps against which URLs are matched and DND handler functions called on the dropping of matching URLs.
If a handler function is a symbol whose dnd-multiple-handler
property (see Symbol Properties) is set, then upon a drop it is
given a list of every URL that matches its regexp; absent this
property, it is called once for each of those URLs. Following this
first argument is one of the symbols copy, move,
link, private or ask identifying the action to be
taken.
If action is private, the program that initiated the drop
does not insist on any particular behavior on the part of its
recipient; a reasonable action to take in that case is to open the URL
or copy its contents into the current buffer. The other values of
action imply much the same as in the action argument to
dnd-begin-file-drag.
Once its work completes, a handler function must return a symbol
designating the action it took: either the action it was provided, or
the symbol private, which communicates to the source of the
drop that the action it prescribed has not been executed.
When multiple handlers match an overlapping subset of items within a drop, the handler matched against by the greatest number of items is called to open that subset. The items it is supplied are subsequently withheld from other handlers, even those they also match.
Emacs does not take measures to accept data besides text and URLs, for the window system interfaces which enable this are too far removed from each other to abstract over consistently. Nor are DND handlers accorded influence over the actions they are meant to take, as particular drag-and-drop protocols deny recipients such control. The X11 drag-and-drop implementation rests on several underlying protocols that make use of selection transfer and share much in common, to which low level access is provided through the following functions and variables:
This function is called to ascertain whether Emacs should accept a drop. It is called with three arguments:
move, copy, link or
ask, representing an action to take on the item data suggested
by the drop source. These symbols carry the same implications as in
x-begin-drag.
This function must return nil to reject the drop or a cons of
the action that will be taken (such as through transfer to a DND
handler function) and the selection data type to be requested. The
action returned in that cons may also be the symbol private,
which intimates that the action taken is as yet indeterminate.
Modifying x-dnd-test-function is generally unwarranted, for its
default set of criteria for accepting a drop can be adjusted by
changing this list of selection data types. Each element is a string,
which if found as the symbol name of an element within the list of
data types by the default “test function”, will induce that function
to accept the drop.
Introducing a new entry into this list is not useful unless a
counterpart handler function is appended to x-dnd-types-alist.
This variable is an alist between strings designating selection data types and functions which are called when things of such types are dropped.
Each such function is supplied three arguments; the first is the
window or frame below the location of the drop, as in
x-dnd-test-function; the second is the action to be taken,
which may be any of the actions returned by test functions, and third
is the selection data itself (see Accessing Selections).
Selection data types as provided by X11 drag-and-drop protocols are
sometimes distinct from those provided by the ICCCM and conforming
clipboard or primary selection owners. Frequently, the name of a MIME
type, such as "text/plain;charset=utf-8" (with discrepant
capitalization of the “utf-8”), is substituted for a standard X
selection name such as UTF8_STRING.
The X Direct Save (XDS) protocol enables programs to devolve responsibility for naming a dropped file upon the recipient. When such a drop transpires, DND handlers and the foregoing X-specific interface are largely circumvented, tasking a different function with responding to the drop.
This variable should be set to a function that registers and names files dropped using the XDS protocol in a two-step procedure. It is provided two arguments, need-name and filename.
nil, and the second argument filename
set to the basename of the file to be saved. It should return the
fully-expanded absolute file name under which to save the file. For
example, if a file is dragged to a Dired window, the natural directory
for the file is the directory of the file shown at location of the
drop. If saving the file is not possible for some reason, the
function should return nil, which will cancel the drag-and-drop
operation.
nil and the second argument filename set to the full
absolute name of the saved file. The function is then expected to do
whatever is needed given the fact that file was saved. For example,
Dired should update the directory on display by showing the new file
there.
Its default x-dnd-direct-save-function is
x-dnd-save-direct.
When called with the need-name argument non-nil, this
function prompts the user for the absolute file name under which it
should be saved. If the specified file already exists, it
additionally asks the user whether to overwrite it, and returns the
absolute file name only if the user confirms the overwriting.
When called with the need-name argument nil, it reverts
the Dired listing if the current buffer is in Dired mode or one of its
descendants, and otherwise visits the file by calling find-file
(see Functions for Visiting Files).
This function works like x-dnd-save-direct, but when called
with its need-name argument non-nil, it doesn’t prompt
the user for the full name of the file to be saved; instead, it
returns its argument filename expanded against the current
buffer’s default directory (see Functions that Expand Filenames). (It still
asks for confirmation if a file by that name already exists in the
default directory.)
It is also possible to drag content from Emacs to other programs when this is supported by the current window-system. The functions which provide for this are as follows:
This function starts a drag-and-drop operation from frame to another program (dubbed the drop target), and returns when text is dropped or the operation is canceled.
action must be one of the symbols copy or move,
where copy means that text should be inserted by the drop
target, and move means the same as copy, but the caller
must also delete text from its source as explained in the list
below.
frame is the frame where the mouse is currently held down, or
nil, which means to use the selected frame. Since this
function might return promptly if no mouse buttons are held down, it
should be only called in response to a down-mouse-1 or
analogous event (see Mouse Events), with frame set to the
frame where that event was generated (see Click Events).
If allow-same-frame is nil, drops on top of frame
will be ignored.
The return value reflects the action that the drop target actually performed, and thus also what action, if any, the caller should in turn take. It is one of the following symbols:
copyThe drop target inserted the dropped text.
moveThe drop target inserted the dropped text, and the caller should delete text from the buffer where it was extracted from, if applicable.
privateThe drop target took some other unspecified action.
nilThe drag-and-drop operation was canceled.
This function starts a drag-and-drop operation from frame to another program (dubbed the drop target), and returns when file is dropped or the operation is canceled.
If file is a remote file, then a temporary local copy will be made.
action must be one of the symbols copy, move or
link, where copy means that file should be opened
or copied by the drop target, move means the drop target should
move the file to another location, and link means the drop
target should create a symbolic link to file. It is an error to
specify link as the action if file is a remote file.
frame and allow-same-frame mean the same as they do in
calls to dnd-begin-text-drag.
The return value is the action that the drop target actually performed, which is one of the following symbols:
copyThe drop target opened or copied file to a different location.
moveThe drop target moved file to a different location.
linkThe drop target (usually a file manager) created a symbolic link to file.
privateThe drop target performed some other unspecified action.
nilThe drag-and-drop operation was canceled.
This function is like dnd-begin-file-drag, except that
files is a list of files. If the drop target doesn’t support
dropping multiple files, then the first file will be used instead.
The behavior of this function is akin to that of
dnd-begin-file-drag (when the default action copy is
used), except that it accepts a name under which the copy is meant to
be filed.
The high-level interfaces described above are implemented on top of
a lower-level primitive. The low-level interface x-begin-drag
is also available for dragging content besides text and files. It
demands detailed knowledge of the data types and actions understood by
programs on each platform its callers wish to support.
This function begins a drag from frame, and returns when the
drag-and-drop operation ends, either because the drop was successful,
or because the drop was rejected. The drop occurs when all mouse
buttons are released on top of an X window other than frame (the
drop target), or any X window if allow-current-frame is
non-nil. If no mouse buttons are held down when the
drag-and-drop operation begins, this function may immediately return
nil.
targets is a list of strings representing selection targets,
much like the data-type argument to gui-get-selection,
that the drop target can request from Emacs (see Window System Selections).
action is a symbol designating the action recommended to the
target. It can either be XdndActionCopy or
XdndActionMove; both imply copying the contents of the
selection XdndSelection to the drop target, but the latter
moreover conveys a promise to delete the contents of the selection
after the copying.
action may also be an alist which associates between symbols representing available actions, and strings that the drop target presents to the user for him to select between those actions.
If return-frame is non-nil and the mouse moves over an
Emacs frame after first moving out of frame, then the frame to
which the mouse moves will be returned immediately. If
return-frame is the symbol now, then any frame beneath
the mouse pointer will be returned without waiting for the mouse to
first move out of frame. return-frame is useful when you
want to treat dragging content from one frame to another specially,
while also dragging content to other programs, but it is not
guaranteed to function on all systems and with all window managers.
If follow-tooltip is non-nil, the position of any tooltip
(such as one displayed by tooltip-show) will follow the
location of the mouse pointer as it moves during the drag-and-drop
operation. The tooltip will be hidden once all mouse buttons are
released.
If the drop was rejected or no drop target was found, this function
returns nil. Otherwise, it returns a symbol representing the
action the target opted to take, which can differ from action if
that isn’t supported by the drop target. XdndActionPrivate is
also a valid return value in addition to XdndActionCopy and
XdndActionMove; it suggests that the drop target opted for an
indeterminate action, and no further action is required of the caller.
The caller must cooperate with the target to complete the action
selected by the target. For example, callers should delete any buffer
text that was dragged if this function returns XdndActionMove,
and likewise for other drag data where comparable criteria apply.
The function x-begin-drag leverages several drag-and-drop
protocols “behind the scenes”. When dragging content that is known
to not be supported by a specific drag-and-drop protocol, that
protocol can be disabled by changing the values of the following
variables:
When this is non-nil, the Motif drag and drop protocols are
disabled, and dropping onto programs that only understand them will
not work.
When this is nil, the OffiX (old KDE) drag and drop protocol is
disabled. When this is the symbol files, the OffiX protocol
will only be used if "FILE_NAME" is one of the targets given to
x-begin-drag. Any other value means to use the OffiX protocol
to drop all supported content.
When one of the "STRING", "UTF8_STRING",
"COMPOUND_TEXT" or "TEXT" targets is present in the list
given to x-begin-drag, Emacs will try to use synthesized mouse
events and the primary selection to insert the text if the drop target
doesn’t support any drag-and-drop protocol at all.
A side effect is that Emacs will become the owner of the primary
selection upon such a drop. Such emulation can be disabled by setting
this variable to nil.
A color name is text (usually in a string) that specifies a color. Symbolic names such as ‘black’, ‘white’, ‘red’, etc., are allowed; use M-x list-colors-display to see a list of defined names. You can also specify colors numerically in forms such as ‘#rgb’ and ‘RGB:r/g/b’, where r specifies the red level, g specifies the green level, and b specifies the blue level. You can use either one, two, three, or four hex digits for r; then you must use the same number of hex digits for all g and b as well, making either 3, 6, 9 or 12 hex digits in all. (See the documentation of the X Window System for more details about numerical RGB specification of colors.)
These functions provide a way to determine which color names are valid, and what they look like. In some cases, the value depends on the selected frame, as described below; see Input Focus, for the meaning of the term “selected frame”.
To read user input of color names with completion, use
read-color (see read-color).
This function reports whether a color name is meaningful. It returns
t if so; otherwise, nil. The argument frame says
which frame’s display to ask about; if frame is omitted or
nil, the selected frame is used.
Note that this does not tell you whether the display you are using
really supports that color. When using X, you can ask for any defined
color on any kind of display, and you will get some result—typically,
the closest it can do. To determine whether a frame can really display
a certain color, use color-supported-p (see below).
This function returns a list of the color names that are defined
and supported on frame frame (default, the selected frame).
If frame does not support colors, the value is nil.
This returns t if frame can really display the color
color (or at least something close to it). If frame is
omitted or nil, the question applies to the selected frame.
Some terminals support a different set of colors for foreground and
background. If background-p is non-nil, that means you are
asking whether color can be used as a background; otherwise you
are asking whether it can be used as a foreground.
The argument color must be a valid color name.
This returns t if color is a shade of gray, as defined on
frame’s display. If frame is omitted or nil, the
question applies to the selected frame. If color is not a valid
color name, this function returns nil.
This function returns a value that describes what color should ideally look like on frame. If color is defined, the value is a list of three integers, which give the amount of red, the amount of green, and the amount of blue. Each integer ranges in principle from 0 to 65535, but some displays may not use the full range. This three-element list is called the rgb values of the color.
If color is not defined, the value is nil.
(color-values "black")
⇒ (0 0 0)
(color-values "white")
⇒ (65535 65535 65535)
(color-values "red")
⇒ (65535 0 0)
(color-values "pink")
⇒ (65535 49344 52171)
(color-values "hungry")
⇒ nil
The color values are returned for frame’s display. If
frame is omitted or nil, the information is returned for
the selected frame’s display. If the frame cannot display colors, the
value is nil.
This function does the same as color-values, but it returns
color values as floating-point numbers between 0.0 and 1.0 inclusive.
This function returns non-nil if the color described by its RGB
triplet rgb is more readable against white background than
against dark background. The argument rgb should be a list of
the form (r g b), with each component a
floating-point number in the range 0.0 to 1.0 inclusive. You can use
color-name-to-rgb to convert a color’s name to such a list.
Text terminals usually support only a small number of colors, and the computer uses small integers to select colors on the terminal. This means that the computer cannot reliably tell what the selected color looks like; instead, you have to inform your application which small integers correspond to which colors. However, Emacs does know the standard set of colors and will try to use them automatically.
The functions described in this section control how terminal colors are used by Emacs.
Several of these functions use or return rgb values, described in Color Names.
These functions accept a display (either a frame or the name of a terminal) as an optional argument. We hope in the future to make Emacs support different colors on different text terminals; then this argument will specify which terminal to operate on (the default being the selected frame’s terminal; see Input Focus). At present, though, the frame argument has no effect.
This function associates the color name name with color number number on the terminal.
The optional argument rgb, if specified, is an rgb value, a list
of three numbers that specify what the color actually looks like.
If you do not specify rgb, then this color cannot be used by
tty-color-approximate to approximate other colors, because
Emacs will not know what it looks like.
This function clears the table of defined colors for a text terminal.
This function returns an alist recording the known colors supported by a text terminal.
Each element has the form (name number . rgb)
or (name number). Here, name is the color
name, number is the number used to specify it to the terminal.
If present, rgb is a list of three color values (for red, green,
and blue) that says what the color actually looks like.
This function finds the closest color, among the known colors
supported for display, to that described by the rgb value
rgb (a list of color values). The return value is an element of
tty-color-alist.
This function finds the closest color to color among the known
colors supported for display and returns its index (an integer).
If the name color is not defined, the value is nil.
This section describes some of the functions and variables for querying and using X resources, or their equivalent on your operating system. See X Resources in The GNU Emacs Manual, for more information about X resources.
The function x-get-resource retrieves a resource value from the X
Window defaults database.
Resources are indexed by a combination of a key and a class. This function searches using a key of the form ‘instance.attribute’ (where instance is the name under which Emacs was invoked), and using ‘Emacs.class’ as the class.
The optional arguments component and subclass add to the key and the class, respectively. You must specify both of them or neither. If you specify them, the key is ‘instance.component.attribute’, and the class is ‘Emacs.class.subclass’.
This variable specifies the application name that x-get-resource
should look up. The default value is "Emacs". You can examine X
resources for other application names by binding this
variable to some other string, around a call to x-get-resource.
This variable specifies the instance name that x-get-resource
should look up. The default value is the name Emacs was invoked with,
or the value specified with the ‘-name’ or ‘-rn’ switches.
To illustrate some of the above, suppose that you have the line:
xterm.vt100.background: yellow
in your X resources file (whose name is usually ~/.Xdefaults or ~/.Xresources). Then:
(let ((x-resource-class "XTerm") (x-resource-name "xterm"))
(x-get-resource "vt100.background" "VT100.Background"))
⇒ "yellow"
(let ((x-resource-class "XTerm") (x-resource-name "xterm"))
(x-get-resource "background" "VT100" "vt100" "Background"))
⇒ "yellow"
If this variable is non-nil, Emacs does not look up X
resources, and X resources do not have any effect when creating new
frames.
The functions in this section describe the basic capabilities of a particular display. Lisp programs can use them to adapt their behavior to what the display can do. For example, a program that ordinarily uses a popup menu could use the minibuffer if popup menus are not supported.
The optional argument display in these functions specifies which
display to ask the question about. It can be a display name, a frame
(which designates the display that frame is on), or nil (which
refers to the selected frame’s display, see Input Focus).
See Color Names, Text Terminal Colors, for other functions to obtain information about displays.
This function returns t if popup menus are supported on
display, nil if not. Support for popup menus requires
that the mouse be available, since the menu is popped up by clicking
the mouse on some portion of the Emacs display.
This function returns t if display is a graphic display
capable of displaying several frames and several different fonts at
once. This is true for displays that use a window system such as X,
and false for text terminals.
This function returns t if display has a mouse available,
nil if not.
This function returns t if the screen is a color screen.
This function returns t if the screen can display shades of gray.
(All color displays can do this.)
This function returns non-nil if all the face attributes in
attributes are supported (see Face Attributes).
The definition of “supported” is somewhat heuristic, but basically means that a face containing all the attributes in attributes, when merged with the default face for display, can be represented in a way that’s
Point (2) implies that a :weight black attribute will be
satisfied by any display that can display bold, as will
:foreground "yellow" as long as some yellowish color can be
displayed, but :slant italic will not be satisfied by
the tty display code’s automatic substitution of a dim face for
italic.
This function returns t if display supports selections.
Windowed displays normally support selections, but they may also be
supported in some other cases.
This function returns t if display can display images.
Windowed displays ought in principle to handle images, but some
systems lack the support for that. On a display that does not support
images, Emacs cannot display a tool bar.
This function returns the number of screens associated with the display.
This function returns the height of the screen in pixels. On a character terminal, it gives the height in characters.
For graphical terminals, note that on multi-monitor setups this refers to the pixel height for all physical monitors associated with display. See Multiple Terminals.
This function returns the width of the screen in pixels. On a character terminal, it gives the width in characters.
For graphical terminals, note that on multi-monitor setups this refers to the pixel width for all physical monitors associated with display. See Multiple Terminals.
This function returns the height of the screen in millimeters,
or nil if Emacs cannot get that information.
For graphical terminals, note that on multi-monitor setups this refers to the height for all physical monitors associated with display. See Multiple Terminals.
This function returns the width of the screen in millimeters,
or nil if Emacs cannot get that information.
For graphical terminals, note that on multi-monitor setups this refers to the width for all physical monitors associated with display. See Multiple Terminals.
This variable allows the user to specify the dimensions of graphical
displays returned by display-mm-height and
display-mm-width in case the system provides incorrect values.
This function returns the backing store capability of the display. Backing store means recording the pixels of windows (and parts of windows) that are not exposed, so that when exposed they can be displayed very quickly.
Values can be the symbols always, when-mapped, or
not-useful. The function can also return nil
when the question is inapplicable to a certain kind of display.
This function returns non-nil if the display supports the
SaveUnder feature. That feature is used by pop-up windows
to save the pixels they obscure, so that they can pop down
quickly.
This function returns the number of planes the display supports. This is typically the number of bits per pixel. For a tty display, it is log to base two of the number of colors supported.
This function returns the visual class for the screen. The value is
one of the symbols static-gray (a limited, unchangeable number
of grays), gray-scale (a full range of grays),
static-color (a limited, unchangeable number of colors),
pseudo-color (a limited number of colors), true-color (a
full range of colors), and direct-color (a full range of
colors).
This function returns the number of color cells the screen supports.
These functions obtain additional information about the window
system in use where Emacs shows the specified display. (Their
names begin with x- for historical reasons.)
This function returns the list of version numbers of the GUI window system running on display, such as the X server on GNU and Unix systems. The value is a list of three integers: the major and minor version numbers of the protocol, and the distributor-specific release number of the window system software itself. On GNU and Unix systems, these are normally the version of the X protocol and the distributor-specific release number of the X server software. On MS-Windows, this is the version of the Windows OS.
This function returns the vendor that provided the window system software (as a string). On GNU and Unix systems this really means whoever distributes the X server. On MS-Windows this is the vendor ID string of the Windows OS (Microsoft).
When the developers of X labeled software distributors as “vendors”, they showed their false assumption that no system could ever be developed and distributed noncommercially.
On PGTK frames, setting the values
fullheight and fullwidth has no effect.
On Haiku, child frames are only visible when a parent frame is active, owing to a limitation of the Haiku windowing system. Owing to the same limitation, child frames are only guaranteed to appear above their top-level parent; that is to say, the top-most frame in the hierarchy, which does not have a parent frame.