Alan Mackenzie | 31 Mar 20:00 2015

A protest against pcase, pcase-let, pcase-let*

Hello, Emacs.

Can we please have a moratorium on the use of pcase, etc.?  Their use is
gradually proliferating through Emacs, yet they are not documented.

OK, maybe pcase itself has a page in the elisp manual, but this page is
very difficult to understand, certainly for me.  I have attempted quite
a lot of times to make sense of it, and failed.

There are two possibilities here: (i) the page is difficult because
pcase is itself difficult.  In this case we should stop using pcase and
systematically remove it from Emacs source.  (ii) The page is difficult
because it is not well written.  In this case it should be improved.
Personally, I think (ii) is more likely to be true than (i).

pcase-let and pcase-let* are totally absent from the elisp manual.
Their doc strings say nothing more than "Like `let' but where you can
use `pcase' patterns for bindings.", without giving any clue as to what
"`pcase' patterns" are, or what the syntax and semantics of their
"use" of them for bindings look like.

Recently, jit-lock.el was changed to include a pcase-let and a
pcase-let*.  The pertinent code is, to me, completely obscure.  As these
forms encroach on an ever increasing portion of Emacs, the part of Emacs
in which I can usefully hack diminishes correspondingly.  I suspect I am
not alone here.

As an aside, I suspect that edebug will not be useful in (possibly
large) uses of these forms, given that they are implemented as macros
rather than special forms.
(Continue reading)

Rostislav Svoboda | 31 Mar 19:34 2015

jcl-mode nonexistant? (Job Control Language - Mainframes)

The only JCL relevant thing I found is

Could you point me to the right direction please? (Or do I have to
write my own major mode?)



Oleh Krehel | 31 Mar 13:53 2015

[PATCH] update the behavior of highlight-nonselected-windows

Hi all,

I like to use the `highlight-nonselected-windows' option, but it
becomes very annoying for the case when I have the same buffer in a
few windows.

Please check the attached patch. Maybe there's a better way to solve
the problem, or maybe this one is good enough. If there aren't
objections, I'll apply this one.

Paul Eggert | 31 Mar 09:53 2015

April 7 cutover for generating ChangeLog automatically

Currently, each Emacs commit typically contains two copies of its ChangeLog 
entries: one copy in the commit message and one copy as an edit to one or more 
ChangeLog files.  The latter copy is largely redundant and complicates merging, 
so as discussed in Bug#19113 on April 7 we plan to revamp the Emacs master 
commit procedure to eliminate the second copy, so that ordinary commits do not 
alter ChangeLog files.  Instead, the ChangeLog file in the Emacs distribution 
will be generated automatically from recent Git commit messages.

You'll still be able to edit ChangeLog history by running 'make change-history' 
and then committing changes to a new top-level file (initially 'ChangeLog.1') 
that contains an editable copy of non-recent Git commit messages.  However, 
commits ordinarily shouldn't change ChangeLog files and this should simplify 

The suggested format for commit messages will be changed slightly:

  - File names should be relative to the top level, e.g.:

	Deactivate shifted region

	Do not silently extend an unhighlighted region;
	this can happen after a shift.
	* doc/emacs/mark.texi (Shift Selection): Document this.
	* lisp/window.el (handle-select-window):
	* src/frame.c (Fhandle_switch_frame, Fselected_frame):
	Deactivate the mark.
	Fixes: bug#19003

    (The actual commit message should not be indented.)

(Continue reading)

Artur Malabarba | 30 Mar 21:01 2015

Calling (package-initialize) sooner during initialization

On the "Customizable modes..." thread I suggested we run
(package-initialize) sooner than the way it's currently done. Right
now, it's called after loading the init file. Which means any user who
tries to customize an installed package by pasting some code into his
init file will be confronted with errors.
This happens A LOT.

Stefan kindly explains why it can't just be done before loading the init file:
> [...] the user may need/want to run some Elisp
> code of his own choosing *before* package-initialize is called.
> E.g. [...] set package-load-list and package-directory-list

But I'm asking that we try a little harder to find a better solution.
This package.el-induced "cannot find load file" error is the most
predominant issue I see people run into in the wild. Some people file
issues for this stuff on github (and waste developer time), others go
to the relevant forums, and others (I can only imagine) probably just
give up on configuring packages (or give up Emacs!) entirely.

So I hope we can try to converge on an actual solution instead of just
resigning to something that harms the majority of the users. I propose
here a couple of suggestions which still preserve the use-case outline
by Stefan, and I'm perfectly open to other ideas.
Even if we can't find an ideal solution, try to keep in mind how
absurdly unideal the current situation is.

Option 1) Check if the file `~/.emacs,d/.package-delay-init' exists.
If it does, just do it the way we currently do. If it doesn't exist,
do package-initialize first and then load the init-file. This
`.package-delay-init' file is not loaded, Emacs would only check if it
(Continue reading)

Oleh Krehel | 30 Mar 10:15 2015

Why "EMACS= (term:0.96)" in term-exec-1?

Hi all,

I've been putting up with this misfeature for quite some time.
Basically, I can't just type `make test' into ansi-term for ERT testing.
I have to either re-export the EMACS variable (by hand, since I can't
just nail it down in the Makefile), or call `make test' from outside

Turns out, the reason is in `term-exec-1', accompanied by this comment:

    ;; We are going to get rid of the binding for EMACS,
    ;; probably in Emacs 23, because it breaks
    ;; `./configure' of some packages that expect it to
    ;; say where to find EMACS.
    (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)

So I have two questions: what was the reason for setting this variable,
and can we remove it?


Daniel Colascione | 29 Mar 07:58 2015

RFC: DWIM for killing *shell* and a more process-query-on-exit

Some terminal emulators ask for confirmation when closing a window only
when that window hosts a foreground process group different from the one
originally launched.  This feature seems useful for Emacs too.

This patch 1) obsoletes the {set-,}process-query-on-exit-flag, 2) adds a
more flexible mechanism that replaces the flag with a function, and 3)
makes shell-mode use this mechanism to dynamically decide whether it's
worth asking the user to kill a process.

What do you think about the mechanism and about changing the default

diff --git a/lisp/shell.el b/lisp/shell.el
index f71d140..6eb409a 100644
--- a/lisp/shell.el
+++ b/lisp/shell.el
 <at>  <at>  -309,6 +309,19  <at>  <at>  for Shell mode only."
 		 (const :tag "on" t))
   :group 'shell)

+(defcustom shell-ask-when-killing-buffer 'when-running-job
+  "When should shell ask for confirmation when killing a buffer?
+`t' means to always ask before killing a live process.  `nil'
+means to always kill without prompting.  `when-running-job' means
+to ask for confirmation only when killing a shell process
+running a child --- that is, only when `process-running-child-p'
+returns non-nil."
+  :type '(choice
+          (const :tag "never" nil)
+          (const :tag "when running a subprocess" 'when-running-job)
(Continue reading)

Jan D. | 28 Mar 23:09 2015

Nonempty second line in commit message (??)


While commiting I got this error:

"Nonempty second line in commit message".

Why can't the second line be non-empty?  Are commit message limitied to one line now?  Or must the second be
empty and then the rest be non-empty?  Or is the error message just extraordinary bad?

	Jan D.

raman | 28 Mar 20:33 2015

symbol-file vs find-lisp-object-file-name

These two functions:
symbol-file from subr.el
find-lisp-object-file-name from  help-fns.el

are almost identical per their documentation -- except that the latter claims to also locate things
defined in  C code.

That said -- 
(find-lisp-object-file-name 'forward-line 'defun)
returns nil for me.

Should these be somehow rationalized --  



Artur Malabarba | 28 Mar 10:52 2015

Organizing package.el a bit

Hi All,
Since last time that I worked a bit on package.el, I noticed it's a
little annoying to manage due to sheer size. I understand 2600 lines
is not the largest .el file we have (hell, it's not even top 10), but
it's enough to bother me a lot.

I'd like to know whether it's ok to split it into two files,
package.el and package-menu.el?

The distinction is very logic, there's a ton of stuff that goes on in
package.el which doesn't make any use of the package-menu.
The only downside of this refactoring would be to mess up things like
`git-blame`, and that's why I'm askinghere.

Is that a reason not to do it?


Sebastian Wiesner | 28 Mar 09:58 2015

Customizable modes and package.el


I have a globalized minor mode defined as follows:

(define-globalized-minor-mode global-flycheck-mode flycheck-mode
  :init-value nil
  :group 'flycheck
  :require 'flycheck)

If my understanding is correct, users should now be able to enable
"global-flycheck-mode" through the customize interface, shouldn't
they?  After all, I can see the mode in customize, enable it, and
Emacs writes the following form to my init file:

 '(global-flycheck-mode t nil (flycheck))

Now, my users usually install my package via ELPA, and by default,
ELPA packages do not become available until *after* the init file was

Consequently, the above form fails to load, since customize tries to
load a library which isn't available yet. I read the documentation on
customize again, but I didn't find anything related to package.el at

What did I do wrong?
(Continue reading)