Daniel Colascione | 5 Jul 01:28 2015

[RFC] normalize kill-region in calc

Right now, calc binds M-w to a special version of copy-region-as-kill
than copies the entire calc value (along with the calc stack prefix)
instead of just the highlighted region. This behavior is inconsistent
with other modes. Can we apply something like this patch? I'll fix the
documentation if we apply it.

diff --git a/lisp/calc/calc-ext.el b/lisp/calc/calc-ext.el
index 67d0c27..baf4c3b 100644
--- a/lisp/calc/calc-ext.el
+++ b/lisp/calc/calc-ext.el
 <at>  <at>  -133,8 +133,8  <at>  <at> 
   (define-key calc-mode-map "\C-k" 'calc-kill)
   (define-key calc-mode-map "\M-k" 'calc-copy-as-kill)
   (define-key calc-mode-map "\C-w" 'calc-kill-region)
-  (define-key calc-mode-map "\M-w" 'calc-copy-region-as-kill)
-  (define-key calc-mode-map "\M-\C-w" 'kill-ring-save)
+  (define-key calc-mode-map "\M-w" 'kill-ring-save)
+  (define-key calc-mode-map "\M-\C-w" 'calc-copy-region-as-kill)
   (define-key calc-mode-map "\M-\C-m" 'calc-last-args)

   (define-key calc-mode-map "a" nil)

Stefan Monnier | 2 Jul 18:03 2015

HTML rendering

I don't use EWW very much, but I often use SHR via Gnus and I must say,
I really like the new proportional-font rendering.

Thanks Lars,


Glenn Morris | 30 Jun 02:35 2015

timestamp in "no autoloads" section of generated loaddefs.el

The timestamp in the "files with no autoloads" section of a generated
loaddefs.el file is set to the time that the output was generated.
This is a nuisance for reproducible builds, because it obviously means
that the output file is never the same twice, even if the inputs are.

What do you think about changing that timestamp to "most recent
modification time of any of the files with no autoloads"?

This should cause no change in the time needed to generate the output
when the inputs haven't changed (the mod times are already checked
for every input file). It will cause the maximum possible change in time
when creating the loaddefs.el file from scratch. In testing, I could not
measure any difference in generation time for lisp/loaddefs.el.

That takes care of the reproducibility issue for files like
lisp/net/tramp-loaddefs.el and others.

For lisp/loaddefs.el, the file will still differ between successive
bootstraps of identical inputs, due to varying timestamps on generated
.el files. What do you think about skipping such files altogether when
scanning files for lisp/loaddefs.el? We know they will never contain
autoloads. We already skip such files in other place (via
custom-dependencies-no-scan-regexp and finder-no-scan-regexp).

Artur Malabarba | 28 Jun 12:47 2015

Displaying the state of isearch toggles [was Re: ASCII-folded search]

2015-06-27 23:48 GMT+01:00 Juri Linkov <juri <at> linkov.net>:
> Whether to display verbose indicators (like currently are used, e.g.
> “Regexp I-search”) or 1-letter cryptic ones (e.g. “I-search(r/c/')”
> like in C-mode with its indicators such as “C/lahw”) is a matter of taste
> and could be customizable.

Here's a suggestion on how verbose toggles could be done, following
Kaushal's previous mention of multi-line echo areas.
It shows the state of all toggles on a line above the prompt. This is
given the usual `minibuffer-prompt' face and it stays fixed while the
user is typing/searching, so it's not a distraction.

-------- the usual modeline here ---------
case-fold: ON   regexp: OFF  word: ON   symbol: OFF  lax-space: ON
char-fold: OFF  invisible: ON

We can discuss which toggles to display by default, of course, this is
just an example.

 lisp/isearch.el | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 45c6d97..b0f4321 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
 <at>  <at>  -2521,6 +2521,26  <at>  <at>  If there is no completion possible, say so and
continue searching."
(Continue reading)

Jürgen Hötzel | 25 Jun 18:41 2015

BOM (byte order mark) in process stdout and stderr


I compiled  this C#/Mono program on an UTF-8 GNU/Linux System

using System;

public class Hello
    static void Main()

and used this elisp code to get the process output:

(let ((default-process-coding-system '(utf-8-with-signature . utf-8-with-signature)))
   (generate-new-buffer "*bom-test*")

This results in the following process-buffer (hexl-mode):

00000000: efbb bf53 5444 4f55 540a 5354 4445 5252  ...STDOUT.STDERR
00000010: 0a0a 5072 6f63 6573 7320 424f 4d20 6669  ..Process BOM fi
00000020: 6e69 7368 6564 0a                        nished.

The stdout BOM was correctly removed but the stderr BOM is still present.

there is now way to handle stderr separately. I made this workaround for the Emacs fsharp-mode:

Are there any better solutions?

Oleh Krehel | 25 Jun 16:59 2015

A simple solution to "Upcoming loss of usability ..."

Hi all,

It seems that even though many conservative people disagree, the
"experiment" isn't going away.

So I'm proposing the following change that could satisfy both Paul and
the conservatives (myself included):

      (match-beginning 1)
      (match-end 1)
      (match-beginning 3)
      (match-end 3)

The above code can also be made part of `prettify-symbols-mode', and
some customization can be added to turn things on or off. The above code
is only a rough draft, it may not be optimal, which the experts could
quickly fix. But it works for all Emacs versions installed on my system.

The advantages of the above approach:

1. Paul's students get to see the pretty quotes.

2. The Emacs sources need not be changed, no new syntax definitions need
to be introduced.

3. The pretty quotes are easy to input for Paul's students: they're
right there on the standard issue keyboard, available with zero modifier
keys: even the Shift modifier isn't necessary.

4. Zero problems in the terminal and with copy pasting: that part of
`prettify-symbols-mode' could be just disabled for terminals that don't
support Unicode. In addition, I can actually see the Unicode quotes fine
in GNOME Terminal. They look garbled on a TTY, but again: the minor mode
can be enabled/disabled conditionally.

5. The quotes stay what they are: markup, as they were intended to be.
The markup can be rendered in many different ways, including as Unicode
quotes, if the user prefers.


jenia.ivlev | 24 Jun 21:53 2015

dired-hide-details-mode, how to customize?


I want to customize the dired-hide-details-mode.

Or, more precisely, to customize the columns that appear when this mode
is disabled. For example, to add a column that shows the `wc -l` for
each file and so on.

Maybe someone knows where is the definition of what will appear, in
the columns in dired, when you do `M-x dired-hide-details-mode`? 

For now, I discovered that when I call `M-: (remove-from-invisibility-spec
'dired-hide-details-detail)`, the columns in dired mode appear.

But I can't find the definition of `dired-hide-details-detail`.
Can someone tell me, where can I find it?

Thanks very much in advance for your kind help.

raman | 24 Jun 17:26 2015

Feature Request: Function to quote filenames

Feature Request:

Motivated by the  increasing number of filenames that show up with spc,
"'"  and other punctuation characters in their name.

The only helper function Emacs provides today is shell-quote-argument --
which often doesn't do the trick.

As an example: Given the filename:

Alice's Adventures in Wonderland

(setq f (shell-quote-argument "Alice's Adventures in Wonderland"))
"Alice\\'s\\ Adventures\\ in\\ Wonderland"

 But invocations like 
(shell-command (format "ls %s" f))

 throw an error 

it's never obvious what quoting magic to  use to get all the cases

Would be nice if we had a shell-quote-filename elisp function that did
all of the magic quoting.



martin rudalics | 24 Jun 11:17 2015

make-pointer-invisible on Windows

I intend to apply the attached patch in order to fix this problem for
the Windows build (see Bug#6105 and Bug#12922).  Comments welcome.

Thanks, martin
--- a/src/w32fns.c
+++ b/src/w32fns.c
 <at>  <at>  -3974,11 +3974,17  <at>  <at>  w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
       if (LOWORD (lParam) == HTCLIENT)
 	  f = x_window_to_frame (dpyinfo, hwnd);
-	  if (f && f->output_data.w32->hourglass_p
-	      && !menubar_in_use && !current_popup_menu)
-	    SetCursor (f->output_data.w32->hourglass_cursor);
-	  else if (f)
-	    SetCursor (f->output_data.w32->current_cursor);
+	  if (f)
+	    {
+	      if (f->output_data.w32->hourglass_p
+		  && !menubar_in_use && !current_popup_menu)
+		SetCursor (f->output_data.w32->hourglass_cursor);
+	      else if (f->pointer_invisible)
+		SetCursor (NULL);
+	      else
+		SetCursor (f->output_data.w32->current_cursor);
+	    }
 	  return 0;
       goto dflt;
 <at>  <at>  -3991,7 +3997,12  <at>  <at>  w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
 	    f->output_data.w32->current_cursor = cursor;
 	    if (!f->output_data.w32->hourglass_p)
-	      SetCursor (cursor);
+	      {
+		if (f->pointer_invisible)
+		  SetCursor (NULL);
+		else
+		  SetCursor (cursor);
+	      }
 	return 0;
diff --git a/src/w32term.c b/src/w32term.c
index b7c6e13..7c5f2db 100644
--- a/src/w32term.c
+++ b/src/w32term.c
 <at>  <at>  -6590,7 +6590,10  <at>  <at>  w32_hide_hourglass (struct frame *f)
   struct w32_output *w32 = FRAME_X_OUTPUT (f);

   w32->hourglass_p = 0;
-  SetCursor (w32->current_cursor);
+  if (f->pointer_invisible)
+    SetCursor (NULL);
+  else
+    SetCursor (w32->current_cursor);

 /* FIXME: old code did that, but I don't know why.  Anyway,
 <at>  <at>  -6602,6 +6605,25  <at>  <at>  w32_arrow_cursor (void)
   SetCursor (w32_load_cursor (IDC_ARROW));

+static void
+w32_toggle_invisible_pointer (struct frame *f, bool invisible)
+  block_input ();
+  if (f->pointer_invisible != invisible)
+    {
+      f->pointer_invisible = invisible;
+    }
+  if (invisible)
+    SetCursor (NULL);
+  else
+    SetCursor (f->output_data.w32->current_cursor);
+  unblock_input ();
 <at>  <at>  -6741,6 +6763,7  <at>  <at>  w32_create_terminal (struct w32_display_info *dpyinfo)
   terminal->ins_del_lines_hook = x_ins_del_lines;
   terminal->delete_glyphs_hook = x_delete_glyphs;
   terminal->ring_bell_hook = w32_ring_bell;
+  terminal->toggle_invisible_pointer_hook = w32_toggle_invisible_pointer;
   terminal->update_begin_hook = x_update_begin;
   terminal->update_end_hook = x_update_end;
   terminal->read_socket_hook = w32_read_socket;

Cédric Chépied | 24 Jun 09:34 2015

Erc timestamps and buffer-invisibility-spec


I'm trying to fix bug 20468 but I need a little help. The bug is that erc
timestamps are not displayed. When starting with emacs -Q and connecting to
freenode (for example) via erc I can't see timestamps. I need to call
(erc-toggle-timestamp) twice or call (erc-hide-timestamp) and then
(erc-show-timestamp). Anyway it only works respectively for existing buffers or
current buffer. I need to do this again for each new buffer.

(erc-*-timestamp) functions only set the buffer-invisibility-spec variable. It
is set by default to t. Erc timestamps have property 'invisible set to

buffer-invisibility-spec is set to t, then I call erc-hide-timestamp. It is now
set to (timestamp t). When I call erc-show-timestamp, buffer-invisibility-spec
value is now (t) and timestamps are now displayed...

It looks like when buffer-invisibility-spec is t, text with property 'invisible
set to anything non nil (here it is 'timestamp) is not displayed (as written in
doc). But when the value is (t) only text with property 'invisible equal to t is

Is it a bug? Should the default value be (t) instead of t? Should erc timestamp
have no 'invisible property if erc-hide-timestamps is nil (but how to set the
property to all existing timestamps when user want it?)?


Cédric Chépied
<cedric.chepied <at> gmail.com>

Marcin Borkowski | 23 Jun 22:55 2015

Re: Upcoming loss of usability of Emacs source files and Emacs.

On 2015-06-23, at 22:30, Richard M. Stallman - Autoreply Message <rms-autoreply-control <at> gnu.org> wrote:

> I am not on vacation, but I am at the end of a long time delay. I am
> located somewhere on Earth, but as far as responding to email is concerned,
> I appear to be well outside the solar system.
> After your message arrives at gnu.org, I will collect it in my next batch of
> incoming mail, some time within the following 24 hours. [...]

Dr. Stallman, funny as your auto-message is, it's probably incorrect.
I'm not an astronomy buff myself, but I showed it to a friend with whom
I have a long tradition of sharing funny things found on the 'net, and
he pointed out that 24 light-hours is still within the Solar System,
somewhere in the inner Oort cloud.



Marcin Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University