Mercurial > hg > xemacs-beta
view man/xemacs/frame.texi @ 2367:ecf1ebac70d8
[xemacs-hg @ 2004-11-04 23:05:23 by ben]
commit mega-patch
configure.in: Turn off -Winline and -Wchar-subscripts.
Use the right set of cflags when compiling modules.
Rewrite ldap configuration to separate the inclusion of lber
(needed in recent Cygwin) from the basic checks for the
needed libraries.
add a function for MAKE_JUNK_C; initially code was added to
generate xemacs.def using this, but it will need to be rewritten.
add an rm -f for junk.c to avoid weird Cygwin bug with cp -f onto
an existing file.
Sort list of auto-detected functions and eliminate unused checks for
stpcpy, setlocale and getwd.
Add autodetection of Cygwin scanf problems
BETA: Rewrite section on configure to indicate what flags are important
and what not.
digest-doc.c, make-dump-id.c, profile.c, sorted-doc.c: Add proper decls for main().
make-msgfile.c: Document that this is old junk.
Move proposal to text.c.
make-msgfile.lex: Move proposal to text.c.
make-mswin-unicode.pl: Convert error-generating code so that the entire message will
be seen as a single unrecognized token.
mule/mule-ccl.el: Update docs.
lispref/mule.texi: Update CCL docs.
ldap/eldap.c: Mule-ize.
Use EXTERNAL_LIST_LOOP_2 instead of deleted EXTERNAL_LIST_LOOP.
* XEmacs 21.5.18 "chestnut" is released.
---------------------------------------------------------------
MULE-RELATED WORK:
---------------------------------------------------------------
---------------------------
byte-char conversion
---------------------------
buffer.c, buffer.h, insdel.c, text.c: Port FSF algorithm for byte-char conversion, replacing broken
previous version. Track the char position of the gap. Add
functions to do char-byte conversion downwards as well as upwards.
Move comments about algorithm workings to internals manual.
---------------------------
work on types
---------------------------
alloc.c, console-x-impl.h, dump-data.c, dump-data.h, dumper.c, dialog-msw.c, dired-msw.c, doc.c, editfns.c, esd.c, event-gtk.h, event-msw.c, events.c, file-coding.c, file-coding.h, fns.c, glyphs-eimage.c, glyphs-gtk.c, glyphs-msw.c, glyphs-shared.c, glyphs-x.c, glyphs.c, glyphs.h, gui.c, hpplay.c, imgproc.c, intl-win32.c, lrecord.h, lstream.c, keymap.c, lisp.h, libsst.c, linuxplay.c, miscplay.c, miscplay.h, mule-coding.c, nas.c, nt.c, ntheap.c, ntplay.c, objects-msw.c, objects-tty.c, objects-x.c, print.c, process-nt.c, process.c, redisplay.h, select-common.h, select-gtk.c, select-x.c, sgiplay.c, sound.c, sound.h, sunplay.c, sysfile.h, sysdep.c, syswindows.h, text.c, unexnt.c, win32.c, xgccache.c: Further work on types. This creates a full set of types for all
the basic semantics of `char' that I have so far identified, so that
its semantics can always be identified for the purposes of proper
Mule-safe code, and the raw use of `char' always avoided.
(1) More type renaming, for consistency of naming.
Char_ASCII -> Ascbyte
UChar_ASCII -> UAscbyte
Char_Binary -> CBinbyte
UChar_Binary -> Binbyte
SChar_Binary -> SBinbyte
(2) Introduce Rawbyte, CRawbyte, Boolbyte, Chbyte, UChbyte, and
Bitbyte and use them.
(3) New types Itext, Wexttext and Textcount for separating out
the concepts of bytes and textual units (different under UTF-16
and UTF-32, which are potential internal encodings).
(4) qxestr*_c -> qxestr*_ascii.
lisp.h: New; goes with other qxe() functions. #### Maybe goes in a
different section.
lisp.h: Group generic int-type defs together with EMACS_INT defs.
lisp.h: * lisp.h (WEXTTEXT_IS_WIDE)
New defns.
lisp.h: New type to replace places where int occurs as a boolean.
It's signed because occasionally people may want to use -1 as
an error value, and because unsigned ints are viral -- see comments
in the internals manual against using them.
dynarr.c: int -> Bytecount.
---------------------------
Mule-izing
---------------------------
device-x.c: Partially Mule-ize.
dumper.c, dumper.h: Mule-ize. Use Rawbyte. Use stderr_out not printf. Use wext_*().
sysdep.c, syswindows.h, text.c: New Wexttext API for manipulation of external text that may be
Unicode (e.g. startup code under Windows).
emacs.c: Mule-ize. Properly deal with argv in external encoding.
Use wext_*() and Wexttext. Use Rawbyte.
#if 0 some old junk on SCO that is unlikely to be correct.
Rewrite allocation code in run-temacs.
emacs.c, symsinit.h, win32.c: Rename win32 init function and call it even earlier, to
initialize mswindows_9x_p even earlier, for use in startup code
(XEUNICODE_P).
process.c: Use _wenviron not environ under Windows, to get Unicode environment
variables.
event-Xt.c: Mule-ize drag-n-drop related stuff.
dragdrop.c, dragdrop.h, frame-x.c: Mule-ize.
text.h: Add some more stand-in defines for particular kinds of conversion;
use in Mule-ization work in frame-x.c etc.
---------------------------
Freshening
---------------------------
intl-auto-encap-win32.c, intl-auto-encap-win32.h: Regenerate.
---------------------------
Unicode-work
---------------------------
intl-win32.c, syswindows.h: Factor out common options to MultiByteToWideChar and
WideCharToMultiByte. Add convert_unicode_to_multibyte_malloc()
and convert_unicode_to_multibyte_dynarr() and use. Add stuff for
alloca() conversion of multibyte/unicode.
alloc.c: Use dfc_external_data_len() in case of unicode coding system.
alloc.c, mule-charset.c: Don't zero out and reinit charset Unicode tables. This fucks up
dump-time loading. Anyway, either we load them at dump time or
run time, never both.
unicode.c: Dump the blank tables as well.
---------------------------------------------------------------
DOCUMENTATION, MOSTLY MULE-RELATED:
---------------------------------------------------------------
EmacsFrame.c, emodules.c, event-Xt.c, fileio.c, input-method-xlib.c, mule-wnnfns.c, redisplay-gtk.c, redisplay-tty.c, redisplay-x.c, regex.c, sysdep.c: Add comment about Mule work needed.
text.h: Add more documentation describing why DFC routines were not written
to return their value. Add some other DFC documentation.
console-msw.c, console-msw.h: Add pointer to docs in win32.c.
emacs.c: Add comments on sources of doc info.
text.c, charset.h, unicode.c, intl-win32.c, intl-encap-win32.c, text.h, file-coding.c, mule-coding.c: Collect background comments and related to text matters and
internationalization, and proposals for work to be done, in text.c
or Internals manual, stuff related to specific textual API's in
text.h, and stuff related to internal implementation of Unicode
conversion in unicode.c. Put lots of pointers to the comments to
make them easier to find.
s/mingw32.h, s/win32-common.h, s/win32-native.h, s/windowsnt.h, win32.c: Add bunches of new documentation on the different kinds of
builds and environments under Windows and how they work.
Collect this info in win32.c. Add pointers to these docs in
the relevant s/* files.
emacs.c: Document places with long comments.
Remove comment about exiting, move to internals manual, put
in pointer.
event-stream.c: Move docs about event queues and focus to internals manual, put
in pointer.
events.h: Move docs about event stream callbacks to internals manual, put
in pointer.
profile.c, redisplay.c, signal.c: Move documentation to the Internals manual.
process-nt.c: Add pointer to comment in win32-native.el.
lisp.h: Add comments about some comment conventions.
lisp.h: Add comment about the second argument.
device-msw.c, redisplay-msw.c: @@#### comments are out-of-date.
---------------------------------------------------------------
PDUMP WORK (MOTIVATED BY UNICODE CHANGES)
---------------------------------------------------------------
alloc.c, buffer.c, bytecode.c, console-impl.h, console.c, device.c, dumper.c, lrecord.h, elhash.c, emodules.h, events.c, extents.c, frame.c, glyphs.c, glyphs.h, mule-charset.c, mule-coding.c, objects.c, profile.c, rangetab.c, redisplay.c, specifier.c, specifier.h, window.c, lstream.c, file-coding.h, file-coding.c: PDUMP:
Properly implement dump_add_root_block(), which never worked before,
and is necessary for dumping Unicode tables.
Pdump name changes for accuracy:
XD_STRUCT_PTR -> XD_BLOCK_PTR.
XD_STRUCT_ARRAY -> XD_BLOCK_ARRAY.
XD_C_STRING -> XD_ASCII_STRING.
*_structure_* -> *_block_*.
lrecord.h: some comments added about
dump_add_root_block() vs dump_add_root_block_ptr().
extents.c: remove incorrect comment about pdump problems with gap array.
---------------------------------------------------------------
ALLOCATION
---------------------------------------------------------------
abbrev.c, alloc.c, bytecode.c, casefiddle.c, device-msw.c, device-x.c, dired-msw.c, doc.c, doprnt.c, dragdrop.c, editfns.c, emodules.c, file-coding.c, fileio.c, filelock.c, fns.c, glyphs-eimage.c, glyphs-gtk.c, glyphs-msw.c, glyphs-x.c, gui-msw.c, gui-x.c, imgproc.c, intl-win32.c, lread.c, menubar-gtk.c, menubar.c, nt.c, objects-msw.c, objects-x.c, print.c, process-nt.c, process-unix.c, process.c, realpath.c, redisplay.c, search.c, select-common.c, symbols.c, sysdep.c, syswindows.h, text.c, text.h, ui-byhand.c: New macros {alloca,xnew}_{itext,{i,ext,raw,bin,asc}bytes} for
more convenient allocation of these commonly requested items.
Modify functions to use alloca_ibytes, alloca_array, alloca_extbytes,
xnew_ibytes, etc. also XREALLOC_ARRAY, xnew.
alloc.c: Rewrite the allocation functions to factor out repeated code.
Add assertions for freeing dumped data.
lisp.h: Moved down and consolidated with other allocation stuff.
lisp.h, dynarr.c: New functions for allocation that's very efficient when mostly in
LIFO order.
lisp.h, text.c, text.h: Factor out some stuff for general use by alloca()-conversion funs.
text.h, lisp.h: Fill out convenience routines for allocating various kinds of
bytes and put them in lisp.h. Use them in place of xmalloc(),
ALLOCA().
text.h: Fill out the convenience functions so the _MALLOC() kinds match
the alloca() kinds.
---------------------------------------------------------------
ERROR-CHECKING
---------------------------------------------------------------
text.h: Create ASSERT_ASCTEXT_ASCII() and ASSERT_ASCTEXT_ASCII_LEN()
from similar Eistring checkers and change the Eistring checkers to
use them instead.
---------------------------------------------------------------
MACROS IN LISP.H
---------------------------------------------------------------
lisp.h: Redo GCPRO declarations. Create a "base" set of functions that can
be used to generate any kind of gcpro sets -- regular, ngcpro,
nngcpro, private ones used in GC_EXTERNAL_LIST_LOOP_2.
buffer.c, callint.c, chartab.c, console-msw.c, device-x.c, dialog-msw.c, dired.c, extents.c, ui-gtk.c, rangetab.c, nt.c, mule-coding.c, minibuf.c, menubar-msw.c, menubar.c, menubar-gtk.c, lread.c, lisp.h, gutter.c, glyphs.c, glyphs-widget.c, fns.c, fileio.c, file-coding.c, specifier.c: Eliminate EXTERNAL_LIST_LOOP, which does not check for circularities.
Use EXTERNAL_LIST_LOOP_2 instead or EXTERNAL_LIST_LOOP_3
or EXTERNAL_PROPERTY_LIST_LOOP_3 or GC_EXTERNAL_LIST_LOOP_2
(new macro). Removed/redid comments on EXTERNAL_LIST_LOOP.
---------------------------------------------------------------
SPACING FIXES
---------------------------------------------------------------
callint.c, hftctl.c, number-gmp.c, process-unix.c: Spacing fixes.
---------------------------------------------------------------
FIX FOR GEOMETRY PROBLEM IN FIRST FRAME
---------------------------------------------------------------
unicode.c: Add workaround for newlib bug in sscanf() [should be fixed by
release 1.5.12 of Cygwin].
toolbar.c: bug fix for problem of initial frame being 77 chars wide on Windows.
will be overridden by my other ws.
---------------------------------------------------------------
FIX FOR LEAKING PROCESS HANDLES:
---------------------------------------------------------------
process-nt.c: Fixes for leaking handles. Inspired by work done by Adrian Aichner
<adrian@xemacs.org>.
---------------------------------------------------------------
FIX FOR CYGWIN BUG (Unicode-related):
---------------------------------------------------------------
unicode.c: Add workaround for newlib bug in sscanf() [should be fixed by
release 1.5.12 of Cygwin].
---------------------------------------------------------------
WARNING FIXES:
---------------------------------------------------------------
console-stream.c: `reinit' is unused.
compiler.h, event-msw.c, frame-msw.c, intl-encap-win32.c, text.h: Add stuff to deal with ANSI-aliasing warnings I got.
regex.c: Gather includes together to avoid warning.
---------------------------------------------------------------
CHANGES TO INITIALIZATION ROUTINES:
---------------------------------------------------------------
buffer.c, emacs.c, console.c, debug.c, device-x.c, device.c, dragdrop.c, emodules.c, eval.c, event-Xt.c, event-gtk.c, event-msw.c, event-stream.c, event-tty.c, events.c, extents.c, faces.c, file-coding.c, fileio.c, font-lock.c, frame-msw.c, glyphs-widget.c, glyphs.c, gui-x.c, insdel.c, lread.c, lstream.c, menubar-gtk.c, menubar-x.c, minibuf.c, mule-wnnfns.c, objects-msw.c, objects.c, print.c, scrollbar-x.c, search.c, select-x.c, text.c, undo.c, unicode.c, window.c, symsinit.h: Call reinit_*() functions directly from emacs.c, for clarity.
Factor out some redundant init code. Move disallowed stuff
that had crept into vars_of_glyphs() into complex_vars_of_glyphs().
Call init_eval_semi_early() from eval.c not in the middle of
vars_of_() in emacs.c since there should be no order dependency
in the latter calls.
---------------------------------------------------------------
ARMAGEDDON:
---------------------------------------------------------------
alloc.c, emacs.c, lisp.h, print.c: Rename inhibit_non_essential_printing_operations to
inhibit_non_essential_conversion_operations.
text.c: Assert on !inhibit_non_essential_conversion_operations.
console-msw.c, print.c: Don't do conversion in SetConsoleTitle or FindWindow to avoid
problems during armageddon. Put #errors for NON_ASCII_INTERNAL_FORMAT
in places where problems would arise.
---------------------------------------------------------------
CHANGES TO THE BUILD PROCEDURE:
---------------------------------------------------------------
config.h.in, s/cxux.h, s/usg5-4-2.h, m/powerpc.h: Add comment about correct ordering of this file.
Rearrange everything to follow this -- put all #undefs together
and before the s&m files. Add undefs for HAVE_ALLOCA, C_ALLOCA,
BROKEN_ALLOCA_IN_FUNCTION_CALLS, STACK_DIRECTION. Remove unused
HAVE_STPCPY, HAVE_GETWD, HAVE_SETLOCALE.
m/gec63.h: Deleted; totally broken, not used at all, not in FSF.
m/7300.h, m/acorn.h, m/alliant-2800.h, m/alliant.h, m/altos.h, m/amdahl.h, m/apollo.h, m/att3b.h, m/aviion.h, m/celerity.h, m/clipper.h, m/cnvrgnt.h, m/convex.h, m/cydra5.h, m/delta.h, m/delta88k.h, m/dpx2.h, m/elxsi.h, m/ews4800r.h, m/gould.h, m/hp300bsd.h, m/hp800.h, m/hp9000s300.h, m/i860.h, m/ibmps2-aix.h, m/ibmrs6000.h, m/ibmrt-aix.h, m/ibmrt.h, m/intel386.h, m/iris4d.h, m/iris5d.h, m/iris6d.h, m/irist.h, m/isi-ov.h, m/luna88k.h, m/m68k.h, m/masscomp.h, m/mg1.h, m/mips-nec.h, m/mips-siemens.h, m/mips.h, m/news.h, m/nh3000.h, m/nh4000.h, m/ns32000.h, m/orion105.h, m/pfa50.h, m/plexus.h, m/pmax.h, m/powerpc.h, m/pyrmips.h, m/sequent-ptx.h, m/sequent.h, m/sgi-challenge.h, m/symmetry.h, m/tad68k.h, m/tahoe.h, m/targon31.h, m/tekxd88.h, m/template.h, m/tower32.h, m/tower32v3.h, m/ustation.h, m/vax.h, m/wicat.h, m/xps100.h: Delete C_ALLOCA, HAVE_ALLOCA, STACK_DIRECTION,
BROKEN_ALLOCA_IN_FUNCTION_CALLS. All of this is auto-detected.
When in doubt, I followed recent FSF sources, which also have
these things deleted.
author | ben |
---|---|
date | Thu, 04 Nov 2004 23:08:28 +0000 |
parents | 6355bae896e3 |
children | 6b0000935adc |
line wrap: on
line source
@node Frame, Keystrokes, Concept Index, Top @comment node-name, next, previous, up @chapter The XEmacs Frame @cindex frame @cindex window @cindex buffer @table @asis @item Frame In many environments, such as a tty terminal, an XEmacs frame literally takes up the whole screen. If you are running XEmacs in a multi-window system like the X Window System, the XEmacs frame takes up one X window. @xref{XEmacs under X}, for more information.@refill @item Window No matter what environment you are running in, XEmacs allows you to look at several buffers at the same time by having several windows be part of the frame. Often, the whole frame is taken up by just one window, but you can split the frame into two or more subwindows. If you are running XEmacs under the X window system, that means you can have several @dfn{XEmacs windows} inside the X window that contains the XEmacs frame. You can even have multiple frames in different X windows, each with their own set of subwindows. @refill @end table Each XEmacs frame displays a variety of information: @itemize @bullet @item The biggest area usually displays the text you are editing. It may consist of one window or of two or more windows if you need to look at two buffers a the same time. @item Below each text window's last line is a @dfn{mode line} (@pxref{Mode Line}), which describes what is going on in that window. The mode line is in inverse video if the terminal supports that. If there are several XEmacs windows in one frame, each window has its own mode line. @item At the bottom of each XEmacs frame is the @dfn{echo area} or @dfn{minibuffer window}(@pxref{Echo Area}). It is used by XEmacs to exchange information with the user. There is only one echo area per XEmacs frame. @item If you are running XEmacs under a graphical windowing system, a menu bar at the top of the frame makes shortcuts to several of the commands available (@pxref{Pull-down Menus}). @item Under a graphical windowing system, a toolbar at the top of the frame, just under the menu bar if it exists, provides ``one-touch'' shortcuts to several commands. (Not yet documented.) @item Under a graphical windowing system, a gutter at the top (under the toolbar) and/or bottom of the frame provides advanced GUI facilities like tab controls for rapid switching among related windows and progress bars for time-consuming operations like downloads across the Internet. Gutters are an experimental feature introduced in XEmacs version 21.2. (Not yet documented.) @end itemize You can subdivide the XEmacs frame into multiple text windows, and use each window for a different file (@pxref{Windows}). Multiple XEmacs windows are tiled vertically on the XEmacs frame. The upper XEmacs window is separated from the lower window by its mode line. When there are multiple, tiled XEmacs windows on a single XEmacs frame, the XEmacs window receiving input from the keyboard has the @dfn{keyboard focus} and is called the @dfn{selected window}. The selected window contains the cursor, which indicates the insertion point. If you are working in an environment that permits multiple XEmacs frames, and you move the focus from one XEmacs frame into another, the selected window is the one that was last selected in that frame. The same text can be displayed simultaneously in several XEmacs windows, which can be in different XEmacs frames. If you alter the text in an XEmacs buffer by editing it in one XEmacs window, the changes are visible in all XEmacs windows containing that buffer. @menu * Point:: The place in the text where editing commands operate. * Echo Area:: Short messages appear at the bottom of the frame. * Mode Line:: Interpreting the mode line. * GUI Components:: Menubar, toolbars, gutters. * XEmacs under X:: Some information on using XEmacs under the X Window System. * XEmacs under MS Windows:: Some information on using XEmacs under Microsoft Windows. @end menu @node Point, Echo Area, Frame, Frame @comment node-name, next, previous, up @section Point @cindex point @cindex cursor When XEmacs is running, the cursor shows the location at which editing commands will take effect. This location is called @dfn{point}. You can use keystrokes or the mouse cursor to move point through the text and edit the text at different places. While the cursor appears to point @var{at} a character, you should think of point as @var{between} two characters: it points @var{before} the character on which the cursor appears. The exception is at the end of the line, where the cursor appears after the last character of the line. Where the display is capable, the cursor at the end of the line will appear differently from a cursor over whitespace at the end of the line. (In an X Windows frame, the end-of-line cursor is half the width of a within-line cursor.) Sometimes people speak of ``the cursor'' when they mean ``point,'' or speak of commands that move point as ``cursor motion'' commands. Each XEmacs frame has only one cursor. When output is in progress, the cursor must appear where the typing is being done. This does not mean that point is moving. It is only that XEmacs has no way to show you the location of point except when the terminal is idle. If you are editing several files in XEmacs, each file has its own point location. A file that is not being displayed remembers where point is. Point becomes visible at the correct location when you look at the file again. When there are multiple text windows, each window has its own point location. The cursor shows the location of point in the selected window. The visible cursor also shows you which window is selected. If the same buffer appears in more than one window, point can be moved in each window independently. The term `point' comes from the character @samp{.}, which was the command in TECO (the language in which the original Emacs was written) for accessing the value now called `point'. @node Echo Area, Mode Line, Point, Frame @section The Echo Area @cindex echo area The line at the bottom of the frame (below the mode line) is the @dfn{echo area}. XEmacs uses this area to communicate with the user: @itemize @bullet @item @dfn{Echoing} means printing out the characters that the user types. XEmacs never echoes single-character commands. Multi-character commands are echoed only if you pause while typing them: As soon as you pause for more than one second in the middle of a command, all the characters of the command so far are echoed. This is intended to @dfn{prompt} you for the rest of the command. Once echoing has started, the rest of the command is echoed immediately as you type it. This behavior is designed to give confident users fast response, while giving hesitant users maximum feedback. You can change this behavior by setting a variable (@pxref{Display Vars}). @item If you issue a command that cannot be executed, XEmacs may print an @dfn{error message} in the echo area. Error messages are accompanied by a beep or by flashing the frame. Any input you have typed ahead is thrown away when an error happens. @item Some commands print informative messages in the echo area. These messages look similar to error messages, but are not announced with a beep and do not throw away input. Sometimes a message tells you what the command has done, when this is not obvious from looking at the text being edited. Sometimes the sole purpose of a command is to print a message giving you specific information. For example, the command @kbd{C-x =} is used to print a message describing the character position of point in the text and its current column in the window. Commands that take a long time often display messages ending in @samp{...} while they are working, and add @samp{done} at the end when they are finished. @item The echo area is also used to display the @dfn{minibuffer}, a window that is used for reading arguments to commands, such as the name of a file to be edited. When the minibuffer is in use, the echo area displays with a prompt string that usually ends with a colon. The cursor appears after the prompt. You can always get out of the minibuffer by typing @kbd{C-g}. @xref{Minibuffer}. @end itemize @node Mode Line, GUI Components, Echo Area, Frame @comment node-name, next, previous, up @section The Mode Line @cindex mode line @cindex top level Each text window's last line is a @dfn{mode line} which describes what is going on in that window. When there is only one text window, the mode line appears right above the echo area. The mode line is in inverse video if the terminal supports that, starts and ends with dashes, and contains text like @samp{XEmacs:@: @var{something}}. If a mode line has something else in place of @samp{XEmacs:@: @var{something}}, the window above it is in a special subsystem such as Dired. The mode line then indicates the status of the subsystem. Normally, the mode line has the following appearance: @example --@var{ch}-XEmacs: @var{buf} (@var{major} @var{minor})----@var{pos}------ @end example @noindent This gives information about the buffer being displayed in the window: the buffer's name, what major and minor modes are in use, whether the buffer's text has been changed, and how far down the buffer you are currently looking. @var{ch} contains two stars (@samp{**}) if the text in the buffer has been edited (the buffer is ``modified''), or two dashes (@samp{--}) if the buffer has not been edited. Exception: for a read-only buffer, it is @samp{%%}. @var{buf} is the name of the window's chosen @dfn{buffer}. The chosen buffer in the selected window (the window that the cursor is in) is also XEmacs's selected buffer, the buffer in which editing takes place. When we speak of what some command does to ``the buffer'', we mean the currently selected buffer. @xref{Buffers}. @var{pos} tells you whether there is additional text above the top of the screen or below the bottom. If your file is small and it is completely visible on the screen, @var{pos} is @samp{All}. Otherwise, @var{pos} is @samp{Top} if you are looking at the beginning of the file, @samp{Bot} if you are looking at the end of the file, or @samp{@var{nn}%}, where @var{nn} is the percentage of the file above the top of the screen.@refill @var{major} is the name of the @dfn{major mode} in effect in the buffer. At any time, each buffer is in one and only one major mode. The available major modes include Fundamental mode (the least specialized), Text mode, Lisp mode, and C mode. @xref{Major Modes}, for details on how the modes differ and how you select one.@refill @var{minor} is a list of some of the @dfn{minor modes} that are turned on in the window's chosen buffer. For example, @samp{Fill} means that Auto Fill mode is on. @code{Abbrev} means that Word Abbrev mode is on. @code{Ovwrt} means that Overwrite mode is on. @xref{Minor Modes}, for more information. @samp{Narrow} means that the buffer being displayed has editing restricted to only a portion of its text. This is not really a minor mode, but is like one. @xref{Narrowing}. @code{Def} means that a keyboard macro is being defined. @xref{Keyboard Macros}. Some buffers display additional information after the minor modes. For example, Rmail buffers display the current message number and the total number of messages. Compilation buffers and Shell mode display the status of the subprocess. If XEmacs is currently inside a recursive editing level, square brackets (@samp{[@dots{}]}) appear around the parentheses that surround the modes. If XEmacs is in one recursive editing level within another, double square brackets appear, and so on. Since information on recursive editing applies to XEmacs in general and not to any one buffer, the square brackets appear in every mode line on the screen or not in any of them. @xref{Recursive Edit}.@refill @findex display-time XEmacs can optionally display the time and system load in all mode lines. To enable this feature, type @kbd{M-x display-time}. The information added to the mode line usually appears after the file name, before the mode names and their parentheses. It looks like this: @example @var{hh}:@var{mm}pm @var{l.ll} [@var{d}] @end example @noindent (Some fields may be missing if your operating system cannot support them.) @var{hh} and @var{mm} are the hour and minute, followed always by @samp{am} or @samp{pm}. @var{l.ll} is the average number of running processes in the whole system recently. @var{d} is an approximate index of the ratio of disk activity to CPU activity for all users. The word @samp{Mail} appears after the load level if there is mail for you that you have not read yet. @vindex mode-line-inverse-video Customization note: the variable @code{mode-line-inverse-video} controls whether the mode line is displayed in inverse video (assuming the terminal supports it); @code{nil} means no inverse video. The default is @code{t}. For X frames, simply set the foreground and background colors appropriately. @node GUI Components, XEmacs under X, Mode Line, Frame @comment node-name, next, previous, up @section GUI Components When executed in a graphical windowing environment such as the X Window System or Microsoft Windows, XEmacs displays several graphical user interface components such as scrollbars, menubars, toolbars, and gutters. By default there is a vertical scrollbar at the right of each frame, and at the top of the frame there is a menubar, a toolbar, and a gutter, in that order. Gutters can contain any of several widgets, but the default configuration puts a set of "notebook tabs" which you can use as a shortcut for selecting any of several related buffers in a given frame. Operating the GUI components is "obvious": click on the menubar to pull down a menu, on a button in the toolbar to invoke a function, and on a tab in the gutter to switch buffers. @menu * Menubar Basics:: How XEmacs uses the menubar. * Scrollbar Basics:: How XEmacs uses scrollbars. * Mode Line Basics:: How XEmacs uses modelines. * Toolbar Basics:: How XEmacs uses toolbars. * Gutter Basics:: How XEmacs uses gutters. * Inhibiting:: What if you don't like GUI? * Customizing:: Position, orientation, and appearance of GUI objects. @end menu @node Menubar Basics, Scrollbar Basics, , GUI Components @comment node-name, next, previous, up @section The XEmacs Menubar The XEmacs menubar is intended to be conformant to the usual conventions for menubars, although conformance is not yet perfect. The menu at the extreme right is the @samp{Help} menu, which should always be available. It provides access to all the XEmacs help facilities available through @kbd{C-h}, as well as samples of various configuration files like @samp{~/.Xresources} and @samp{~/.emacs}. At the extreme left is the @samp{Files} menu, which provides the usual file reading, writing, and printing operations, as well as operations like revert buffer from most recent save. The next menu from the left is the @samp{Edit} menu, which provides the @samp{Undo} operation as well as cutting and pasting, searching, and keyboard macro definition and execution. @c #### w3.el and VM should get cross-references here. XEmacs provides a very dynamic environment, and the Lisp language makes for highly flexible applications. The menubar reflects this: many menus (eg, the @samp{Buffers} menu, @pxref{Buffers Menu}) contain items determined by the current state of XEmacs, and most major modes and many minor modes add items to menus and even whole menus to the menubar. In fact, some applications like w3.el and VM provide so many menus that they define a whole new menubar and add a button that allows convenient switching between the ``XEmacs menubar'' and the ``application menubar''. Such applications normally bind themselves to a particular frame, and this switching only takes place on frames where such an application is active (ie, the current window of the frame is displaying a buffer in the appropriate major mode). Other menus which are typically available are the @samp{Options}, @samp{Tools}, @samp{Buffers}, @samp{Apps}, and @samp{Mule} menus. For detailed descriptions of these menus, @ref{Pull-down Menus}. (In 21.2 XEmacsen, the @samp{Mule} menu will be moved under @samp{Options}.) @node Scrollbar Basics, Mode Line Basics, Menubar Basics, GUI Components @comment node-name, next, previous, up @section XEmacs Scrollbars XEmacs scrollbars provide the usual interface. Arrow buttons at either end allow for line by line scrolling, including autorepeat. Clicking in the scrollbar itself provides scrolling by windowsfull, depending on which side of the slider is clicked. The slider itself may be dragged for smooth scrolling. The position of the slider corresponds to the position of the window in the buffer. In particular, the length of the slider is proportional to the fraction of the buffer which appears in the window. The presence of the scrollbars is under control of the application or may be customized by the user. By default a vertical scrollbar is present in all windows (except the minibuffer), and there is no horizontal scrollbar. @node Mode Line Basics, Toolbar Basics, Scrollbar Basics, GUI Components @comment node-name, next, previous, up @section XEmacs Mode Lines When used in a windowing system, the XEmacs modelines can be dragged vertically. The effect is to resize the windows above and below the modeline (this includes the minibuffer window). Additionally, a modeline can be dragged horizontally, in which case it scrolls its own text. This behavior is not enabled by default because it could be considered as disturbing when dragging vertically. When this behavior is enabled, the modeline's text can be dragged either in the same direction as the mouse, or in the opposite sense, making the modeline act as a scrollbar for its own text. You can select the behavior you want from the @samp{Display} submenu of the @samp{Options} menu. @node Toolbar Basics, Gutter Basics, Mode Line Basics, GUI Components @comment node-name, next, previous, up @section XEmacs Toolbars XEmacs has a default toolbar which provides shortcuts for some of the commonly used operations (such as opening files) and applications (such as the Info manual reader). Operations which require arguments will pop up dialogs to get them. The position of the default toolbar can be customized. Also, several toolbars may be present simultaneously (in different positions). VM, for example, provides an application toolbar which shortcuts for mail-specific operations like sending, saving, and deleting messages. @node Gutter Basics, Inhibiting, Toolbar Basics, GUI Components @comment node-name, next, previous, up @section XEmacs Gutters Gutters are the most flexible of the GUI components described in this section. In theory, the other GUI components could be implemented by customizing a gutter, but in practice the other components were introduced earlier and have their own special implementations. Gutters tend to be more transient than the other components. Buffer tabs, for example, change every time the selected buffer in the frame changes. And for progress gauges a gutter to contain the gauge is typically created on the fly when needed, then destroyed when the operation whose staus is being displayed is completed. Buffer tabs, having somewhat complex behavior, deserve a closer look. By default, a row of buffer tabs is displayed at the top of every frame. (The tabs could be placed in the bottom gutter, but would be oriented the same way and look rather odd. The horizontal orientation makes putting them in a side gutter utterly impractical.) The buffer displayed in the current window of a frame can be changed to a specific buffer by clicking [mouse-1] on the corresponding tab in the gutter. Each tab contains the name of its buffer. The tab for the current buffer in each frame is displayed in raised relief. The list of buffers chosen for display in the buffer tab row is derived by filtering the buffer list (like the @code{Buffers} menu). The list starts out with all existing buffers, with more recently selected buffers coming earlier in the list. Then "uninteresting" buffers, like internal XEmacs buffers, the @code{*Message Log*} buffer, and so on are deleted from the list. Next, the frame's selected buffer is determined. Buffers with a different major mode from the selected buffer are removed from the list. Finally, if the list is too long, the least recently used buffers are deleted from the list. By default up to 6 most recently used buffers with the same mode are displayed on tabs in the gutter. This behavior can be altered by customizing @code{buffers-tab-filter-functions}. Setting this variable to @code{nil} forces display of all buffers, up to @code{buffers-tab-max-size} (also customizable). More complex behavior may be available in 3rd party libraries. These, and some more rarely customized options, are in the @code{buffers-tab} Customize group. @node Inhibiting, Customizing, Gutter Basics, GUI Components @comment node-name, next, previous, up @section Inhibiting Display of GUI Components Use of GUI facilities is a personal thing. Almost everyone agrees that drawing via keyboard-based "turtle graphics" is acceptable to hardly anyone if a mouse is available, but conversely emulating a keyboard with a screenful of buttons is a painful experience. But between those extremes the complete novice will require a fair amount of time before toolbars and menus become dispensable, but many an "Ancien Haquer" sees them as a complete waste of precious frame space that could be filled with text. Display of all of the GUI components created by XEmacs can be inhibited through the use of Customize. Customize can be accessed through @samp{Options | Customize} in the menu bar, or via @kbd{M-x customize}. Then navigate through the Customize tree to @samp{Emacs | Environment}. Scrollbar and toolbar visibility is controlled via the @samp{Display} group, options @samp{Scrollbars visible} and @samp{Toolbar visible} respectively. Gutter visibility is controlled by group @samp{Gutter}, option @samp{Visible}. Or they can be controlled directly by @kbd{M-x customize-variable}, by changing the values of the variables @code{menubar-visible-p}, @code{scrollbars-visible-p}, @code{toolbar-visible-p}, or @code{gutter-buffers-tab-visible-p} respectively. (The strange form of the last variable is due to the fact that gutters are often used to display transient widgets like progress gauges, which you probably don't want to inhibit. It is more likely that you want to inhibit the default display of the buffers tab widget, which is what that variable controls. This interface is subject to change depending on developer experience and user feedback.) Control of frame configuration can controlled automatically according to various parameters such as buffer or frame because these are @dfn{specifiers} @ref{Specifiers, , , lispref}. Using these features requires programming in Lisp; Customize is not yet that sophisticated. Also, components that appear in various positions and orientations can have display suppressed according to position. @kbd{C-h a visible-p} gives a list of variables which can be customized. E.g., to control the visibility of specifically the left-side toolbar only, customize @code{left-toolbar-visible-p}. @node Customizing, , Inhibiting, GUI Components @comment node-name, next, previous, up @section Changing the Position, Orientation, and Appearance of GUI Components #### Not documented yet. @node XEmacs under X, XEmacs under MS Windows, GUI Components, Frame @section Using XEmacs Under the X Window System @comment node-name, next, previous, up XEmacs can be used with the X Window System and a window manager like MWM or TWM. In that case, the X window manager opens, closes, and resizes XEmacs frames. You use the window manager's mouse gestures to perform the operations. Consult your window manager guide or reference manual for information on manipulating X windows. When you are working under X, each X window (that is, each XEmacs frame) has a menu bar for mouse-controlled operations (@pxref{Pull-down Menus}). @cindex multi-frame XEmacs @findex make-frame XEmacs under X is also a multi-frame XEmacs. You can use the @b{New Frame} menu item from the @b{File} menu to create a new XEmacs frame in a new X window from the same process. The different frames will share the same buffer list, but you can look at different buffers in the different frames. @findex find-file-other-frame The function @code{find-file-other-frame} is just like @code{find-file}, but creates a new frame to display the buffer in first. This is normally bound to @kbd{C-x 5 C-f}, and is what the @b{Open File, New Frame} menu item does. @findex switch-to-buffer-other-frame The function @code{switch-to-buffer-other-frame} is just like @code{switch-to-buffer}, but creates a new frame to display the buffer in first. This is normally bound to @kbd{C-x 5 b}. @vindex default-frame-alist @vindex default-frame-plist You can specify a different default frame size other than the one provided. Use the variable @code{default-frame-plist}, which is a plist of default values for frame creation other than the first one. These may be set in your init file, like this: @example (setq default-frame-plist '(width 80 height 55)) @end example This variable has replaced @code{default-frame-alist}, which is considered obsolete. @vindex x-frame-defaults For values specific to the first XEmacs frame, you must use X resources. The variable @code{x-frame-defaults} takes an alist of default frame creation parameters for X window frames. These override what is specified in @file{~/.Xresources} but are overridden by the arguments to the particular call to @code{x-create-frame}. @vindex create-frame-hook When you create a new frame, the variable @code{create-frame-hook} is called with one argument, the frame just created. If you want to close one or more of the X windows you created using @b{New Frame}, use the @b{Delete Frame} menu item from the @b{File} menu. @vindex frame-title-format @vindex frame-icon-title-format If you are working with multiple frames, some special information applies: @itemize @bullet @item Two variables, @code{frame-title-format} and @code{frame-icon-title-format} determine the title of the frame and the title of the icon that results if you shrink the frame. @vindex auto-lower-frame @vindex auto-raise-frame @item The variables @code{auto-lower-frame} and @code{auto-raise-frame} position a frame. If true, @code{auto-lower-frame} lowers a frame to the bottom when it is no longer selected. If true, @code{auto-raise-frame} raises a frame to the top when it is selected. Under X, most ICCCM-compliant window managers will have options to do this for you, but these variables are provided in case you are using a broken window manager. @item There is a new frame/modeline format directive, %S, which expands to the name of the current frame (a frame's name is distinct from its title; the name is used for resource lookup, among other things, and the title is simply what appears above the window.) @end itemize @node XEmacs under MS Windows, , XEmacs under X, Frame @section Using XEmacs Under Microsoft Windows @comment node-name, next, previous, up Use of XEmacs under MS Windows is not separately documented here, but most operations available under the X Window System are also available with MS Windows. Where possible, native MS Windows GUI components and capabilities are used in XEmacs.