Artur Malabarba | 29 Jul 01:48 2015

Combining (and obsoleting) isearch-regexp and isearch-word into a new var

Currently `isearch-word' is a variable that can be a boolean
(indicating if word searching is on or off) or it can hold a function
(which is called on the search string before passing it to a regexp
Both symbol-searching and char-folding are implemented as function
values of this variable, while word-searching is implemented as a
boolean value even though it could just as well be another function

In addition to that, we also have regexp-searching, which *could* be
just another function value for that variable (the #'identity), but
instead it's implemented as a whole new boolean variable

All of these 4 functionalities are mutually exclusive, so it makes
sense for them to be implemented as different values of a single
variable in a consisten manner (all functions).

I'd like to propose that the `isearch-word' variable be aliased to
`isearch-special' (or something like this), and that its use as a
boolean also be obsoleted.
Then also obsolete `isearch-regexp', which is just a special case of

If we don't want an extra var, then we can just use one of the
existing vars for this purpose and obsolete the other.
I'd just like to condense it all in a single variable and obsolete the
boolean usage.

(Continue reading)

Eli Zaretskii | 28 Jul 19:23 2015

Two issues with stack overflow protection

The implementation of stack_overflow on sysdep.c was recently changed
so as not to use sys/resource.h and getrlimit, but still
insists on these two features in order to include the recovery code,
which I think should be fixed.

More importantly, the recovery simply longjmps to command_loop,
whereas similar features like Fthrow and Fsignal do much more in
unwind_to_catch.  Shouldn't stack overflow recovery do that as well?
Otherwise, the specpdl stack, byte_stack_list, lisp_eval_depth
etc. all stay at their values they had at stack overflow time, no?

martin rudalics | 28 Jul 14:45 2015

Tooltips GC overhead

Showing a tooltip here incurs one or two garbage collection cycles.
This is just as much as an entire `scroll-down' in a C mode buffer.

Experienced on Gtk+ and Windows builds.  Does anyone have an idea what's
causing that?


Stephen Leake | 28 Jul 14:06 2015

'head' specializer for cl-defmethod?

project.el uses a 'head' specializer in the dispatching argument of

This use of 'head' is not documented other than in the 'Added elements'
section of the cl-generic.el header comment.

I'd like to change the cl-defmethod doc
string to say:

    Other than a type, TYPE can also be one of the following:

    - `(eql VAL)' - this method will be invoked when the
      argument is `eql' to VAL.

    - `(head VAL)' - this method will be invoked when the `car' of the
      argument is `eql' to VAL

However, that still leaves out the eieio-core specializer `subclass';
I'm not clear how to handle that in the doc string.

I'm guessing the rationale for supporting the 'head' specializer is to
allow using cl-defmethod with objects that are constructed by `cons',
without any cl-defstruct or eieio defclass. That's how it is used in

Is there a manual section for cl-defmethod? I don't see one in
doc/misc/cl.texi; perhaps we should add one?

-- Stephe
(Continue reading)

Andy Moreton | 28 Jul 13:57 2015

Patch for warnings in 64bit Windows builds


The 64bit Windows builds have shown a few warnings for some time:

../../src/w32proc.c: In function 'w32_compare_strings':
../../src/w32proc.c:3526:20: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
    pCompareStringW = GetProcAddress (LoadLibrary ("Unicows.dll"),
../../src/w32fns.c: In function 'Ffile_system_info':
../../src/w32fns.c:7827:9: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
       = GetProcAddress (hKernel, "GetDiskFreeSpaceExW");
../../src/w32fns.c:7830:9: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
       = GetProcAddress (hKernel, "GetDiskFreeSpaceExA");
The following patch builds cleanly on:
  - 32bit mingw
  - 32bit mingw --with-wide-int
  - 64bit mingw64

I don't have copyright paperwork on file, so please let me know if that
is required.


diff --git a/src/w32fns.c b/src/w32fns.c
index abfa315e2a96..499450f4c927 100644
--- a/src/w32fns.c
+++ b/src/w32fns.c
(Continue reading)

Stephen Leake | 28 Jul 13:31 2015

cl-defgeneric vs random funcall in project.el

What is the rationale for having both cl-defgeneric and random funcall
in project.el?

For example, 'project-search-path' is a cl-defgeneric, which means the
various backends (elisp, etags, eventually Ada mode) can override it
with cl-defmethod.

But the default method uses 'project-search-path-function', which
elisp-mode sets to `elisp-search-function'; elisp.el does not use
cl-defmethod to override project-search-path.

Why do we need both dispatching methods?

I suggest this rationale be documented in the Commentary section of the
project.el header comment.


-- Stephe

David McMackins | 26 Jul 23:35 2015

enum indentation in GNU style in c-mode is inconsistent

As pointed out in an e-mail from last year, the GNU style C indentation
in Emacs is wrong for enumerated types. The user who wrote it said that
the bug should not be fixed because it would case creeping changes in
the GNU code base over a long period of time.

While that is true, one large problem is inconsistency. I have gotten
Emacs into a state where the enum indentation would actually be true to
GNU coding standards through some messing about with opening and closing
braces in a header file, but if I reload c-mode, it goes back to the way
it was before.

I do think this should be fixed, since one of the primary reasons I use
Emacs is its correct indentation in many C styles.

Happy Hacking,

David E. McMackins II
Associate, Free Software Foundation (#12889)

Stephen Leake | 26 Jul 21:48 2015

new buffer display action: display-buffer-reuse-frame

I'd like to add display-buffer-reuse-frame to window.el:

(defun display-buffer-reuse-frame (buffer alist)
  "Display BUFFER in an existing frame other than the current frame.
If successful, return the window used; otherwise return nil.

If ALIST has a non-nil `inhibit-switch-frame' entry, avoid
raising the frame.

If ALIST has a non-nil `pop-up-frame-parameters' entry, the
corresponding value is an alist of frame parameters to give the
new frame.

If ALIST has a non-nil `frame-predicate' entry, the corresponding
value is a function taking one argument (a frame), returning
non-nil if the frame is a candidate."
  (let* ((predicate (or (cdr (assoc 'frame-predicate alist))
                        (lambda (frame)
                           (not (eq frame (selected-frame)))
                           (not (window-dedicated-p
                                  (get-lru-window frame)
                                  (frame-first-window frame)))))
	 (frame (car (filtered-frame-list predicate)))
	 (window (and frame (get-lru-window frame))))

    (when window
(Continue reading)

David Kastrup | 25 Jul 18:57 2015

[PATCH] ; Do not overwrite prexisting contents of unread-command-events

 lisp/comint.el               |  5 +++--
 lisp/double.el               |  8 +++++---
 lisp/ebuff-menu.el           |  6 ++++--
 lisp/ehelp.el                |  8 ++++----
 lisp/eshell/em-hist.el       |  2 +-
 lisp/gnus/gnus-art.el        | 24 ++++++++++++++----------
 lisp/info.el                 |  2 +-
 lisp/international/quail.el  |  6 ++++--
 lisp/international/robin.el  |  2 +-
 lisp/kmacro.el               |  2 +-
 lisp/language/hanja-util.el  |  4 +++-
 lisp/leim/quail/hangul.el    | 12 +++++++++---
 lisp/leim/quail/japanese.el  |  7 ++++---
 lisp/leim/quail/lao.el       |  5 +++--
 lisp/leim/quail/lrt.el       |  5 +++--
 lisp/leim/quail/tibetan.el   | 10 ++++++----
 lisp/obsolete/terminal.el    |  4 +++-
 lisp/obsolete/vip.el         |  7 ++++---
 lisp/pcomplete.el            |  2 +-
 lisp/progmodes/cperl-mode.el |  4 ++--
 lisp/progmodes/ebrowse.el    |  3 ++-
 lisp/progmodes/fortran.el    |  2 +-
 lisp/progmodes/octave.el     |  2 +-
 lisp/progmodes/vhdl-mode.el  | 17 +++++++++--------
 lisp/simple.el               |  6 ++++--
 lisp/subr.el                 |  3 ++-
 lisp/term.el                 |  6 ++++--
 lisp/vc/emerge.el            |  2 +-
 28 files changed, 100 insertions(+), 66 deletions(-)
(Continue reading)

Dmitry Gutov | 25 Jul 02:47 2015

xref and leaving "temporary" buffers open

Hi all,

The original implementation, by Helmut, didn't worry about that, and, 
for instance, used xref-buffer-location for the results of "find 
definitions" operation in the Elisp backend.

I was concerned about having opening lots of buffers, the user being 
surprised at seeing a querying operation make that change in their Emacs 
session. Then switch-to-buffer, as one example, might become more 
troublesome, for having too many options to choose from. Some Emacs 
features might slow down for having to deal with too many buffers (like 
auto-revert?). Anyway, a neat freak like yours truly might get annoyed. 
So I made the current implementations always clean up after themselves.

However, that causes a performance hit: opening a buffer takes time, 
especially when you need to syntax-propertize it (which is a requirement 
for xref--collect-match). So now even if I repeatedly search for the 
same thing, each search incurs the same performance penalty. Or, more 
practically, if a do a search and then press `r' to call 
`xref-query-replace', the latter has to reopen the killed buffers again. 
Which could be implemented, with certain amount of effort, in a deferred 
way so the user doesn't suffer too much, but even that would break if 
some xrefs from the same file appear separately in the list (and that 
might happen, for example, if etags--xref-find-definitions splits the 
results into groups by tag order).

Should we disregard this issue and say that xref doesn't have to close 
the buffers it needed to open during operation?

Another problem with that might be the contents getting out of date: 
(Continue reading)

Stephen Leake | 23 Jul 22:54 2015

need for 'dynamical-let'?

I'm switching on lexical-binding in some files.

In several cases, the byte compiler is complaining:

xgit.el:993:30:Error: add-to-list cannot use lexical var `branch-list'

So I have to change code like this:

(let (branch-list
   (add-to-list branch-list (substring branch-entry 2) t)


(defvar dvc-branch-list);; add-to-list can't use lexical var
(let (
   (add-to-list 'dvc-branch-list (substring branch-entry 2) t)

This pollutes the global name space, and disguises the local nature of

Can we define a macro 'dynamical-let' that would implement this
pattern, but with hidden variables?


-- Stephe