(Accepting Output): accept-process-output

[gnu-emacs] / lispref / functions.texi

diff --git a/lispref/functions.texi b/lispref/functions.texi
index 6222ea4c8a5d54f10cb37eefde0726bfe198a014..eedfa8c124f9f97b5112955067f4d3ee754192c3 100644 (file)
--- a/lispref/functions.texi
+++ b/lispref/functions.texi
@@ -1,7 +1,7 @@
 @c -*-texinfo-*-
 @c This is part of the GNU Emacs Lisp Reference Manual.
-@c Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1998, 1999, 2002, 2003,
-@c   2004, 2005, 2006 Free Software Foundation, Inc.
+@c Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1998, 1999, 2001,
+@c   2002, 2003, 2004, 2005, 2006, 2007  Free Software Foundation, Inc.
 @c See the file elisp.texi for copying conditions.
 @setfilename ../info/functions
 @node Functions, Macros, Variables, Top
@@ -293,6 +293,7 @@ variables.
 @kindex wrong-number-of-arguments
 @cindex argument binding
 @cindex binding arguments
+@cindex argument lists, features
 
   Our simple sample function, @code{(lambda (a b c) (+ a b c))},
 specifies three argument variables, so it must be called with three
@@ -583,6 +584,7 @@ defined is often done deliberately, and there is no way to distinguish
 deliberate redefinition from unintentional redefinition.
 @end defspec
 
+@cindex function aliases
 @defun defalias name definition &optional docstring
 @anchor{Definition of defalias}
 This special form defines the symbol @var{name} as a function, with
@@ -766,12 +768,10 @@ in turn, and returns a list of the results.
 The argument @var{sequence} can be any kind of sequence except a
 char-table; that is, a list, a vector, a bool-vector, or a string.  The
 result is always a list.  The length of the result is the same as the
-length of @var{sequence}.
+length of @var{sequence}.  For example:
 
 @smallexample
 @group
-@exdent @r{For example:}
-
 (mapcar 'car '((a b) (c d) (e f)))
      @result{} (a c e)
 (mapcar '1+ [1 2 3])
@@ -1193,17 +1193,22 @@ function except for one thing: when you compile a call to the function,
 the function's definition is open-coded into the caller.
 
 Making a function inline makes explicit calls run faster.  But it also
-has disadvantages.  For one thing, it reduces flexibility; if you change
-the definition of the function, calls already inlined still use the old
-definition until you recompile them.  Since the flexibility of
-redefining functions is an important feature of Emacs, you should not
-make a function inline unless its speed is really crucial.
+has disadvantages.  For one thing, it reduces flexibility; if you
+change the definition of the function, calls already inlined still use
+the old definition until you recompile them.
 
 Another disadvantage is that making a large function inline can increase
 the size of compiled code both in files and in memory.  Since the speed
 advantage of inline functions is greatest for small functions, you
 generally should not make large functions inline.
 
+Also, inline functions do not behave well with respect to debugging,
+tracing, and advising (@pxref{Advising Functions}).  Since ease of
+debugging and the flexibility of redefining functions are important
+features of Emacs, you should not make a function inline, even if it's
+small, unless its speed is really crucial, and you've timed the code
+to verify that using @code{defun} actually has performance problems.
+
 It's possible to define a macro to expand into the same code that an
 inline function would execute.  (@xref{Macros}.)  But the macro would be
 limited to direct use in expressions---a macro cannot be called with