Is this a bug of cc-mode?

SES local variables to define printers

Hello,

I have come across a ``regression'' in SES --- well I am not sure that
one can call it a ``regression'', let us rather say that one year ago it
was possible to play some borderline trick which is now no longer
possible with a recent EMACS.

That sort of trick was to define a file local variable foo to a lambda
expression defining a printer function, and then use the foo symbol as a
printer when setting the printer for a cell.

I wrote that this is a ``borderline trick'' because when you do that you
set the symbol-value of foo to the printer, and not its
symbol-function. But that was working --- I don't know why.

By the way, that kind of things was a security breach because you allow
to call a function defined in the file without any control. I suspect
that the root cause why this is no longer working is that EMACS has been
made more secure on that respect --- sorry I am not a regular lurker of
what is going on on this forum, so indeed I have no idea.

Now, I would like to have again the same sort of feature in SES, so I
did a quick hack herein attached --- there is a defcustom, so that the
user who re-enables this, does it at his/her own perils. But I am not
really satisfied with that patch --- so I did not commit it --- because
I think I should do more security checks if possible on the printer
function that is defined as a buffer local lambda expression.

So, I have a few questions to you experts:

- is that possible to check that a function do no border effect, like a
  SES printer function should do --- well, I presume, at least for
  buffer locally defined function --- anyway I would create some
  defcustom to deactivate that security check.

- is that possible to check that when a function is executing, that
  takes a reasonable time, and if not to interact with the use and ask
  whether he/she would like to double that time

VBR,
    Vincent.

[PATCH 2/2] Set comment variables in ielm.

This allows the use of `hs-minor-mode'.

* lisp/ielm.el: Set `comment-start' and `comment-use-global-state'
  variables in ielm-mode.

Signed-off-by: Rüdiger Sonderfeld <ruediger <at> c-plusplus.de>
---
 lisp/ielm.el | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lisp/ielm.el b/lisp/ielm.el
index e63c11d..bc16f4b 100644
--- a/lisp/ielm.el
+++ b/lisp/ielm.el
 <at>  <at>  -507,6 +507,8  <at>  <at>  Customized bindings may be defined in `ielm-map', which currently contains:
   (setq comint-get-old-input 'ielm-get-old-input)
   (set (make-local-variable 'comint-completion-addsuffix) '("/" . ""))
   (setq mode-line-process '(":%s on " (:eval (buffer-name ielm-working-buffer))))
+  (set (make-local-variable 'comment-start) ";")
+  (set (make-local-variable 'comment-use-global-state) t)

   (set (make-local-variable 'indent-line-function) 'ielm-indent-line)
   (set (make-local-variable 'ielm-working-buffer) (current-buffer))
--

-- 
1.8.2.3

[PATCH 1/2] Add menu for ielm.

* lisp/ielm.el (ielm-menu): Add menu for ielm.

Signed-off-by: Rüdiger Sonderfeld <ruediger <at> c-plusplus.de>
---
 lisp/ielm.el | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/lisp/ielm.el b/lisp/ielm.el
index d908008..e63c11d 100644
--- a/lisp/ielm.el
+++ b/lisp/ielm.el
 <at>  <at>  -184,6 +184,14  <at>  <at>  This variable is buffer-local.")
   "Keymap for IELM mode.")
 (defvaralias 'inferior-emacs-lisp-mode-map 'ielm-map)

+(require 'easymenu)
+(easy-menu-define ielm-menu ielm-map
+  "IELM mode menu."
+  '("IELM"
+    ["Change Working Buffer" ielm-change-working-buffer t]
+    ["Display Working Buffer" ielm-display-working-buffer t]
+    ["Print Working Buffer" ielm-print-working-buffer t]))
+
 (defvar ielm-font-lock-keywords
   '(("\\(^\\*\\*\\*[^*]+\\*\\*\\*\\)\\(.*$\\)"
      (1 font-lock-comment-face)
--

-- 
1.8.2.3

[PATCH] Desktop mode saves mark-ring too verbosely

You can (add-to-list 'desktop-locals-to-save 'mark-ring) and it works, so long as you have the fix for bug
13951 applied. But it's very verbose; for each element of mark-ring for each buffer, it writes an entry like

(let ((mk (make-marker))) (add-hook 'desktop-delay-hook (list 'lambda '() (list 'set-marker mk 123
'(get-buffer "init.el")))) mk)

The result is about 2kB of text to record a standard 16-element mark-ring. The file name is redundant, since
it's already written as the first argument for desktop-create-buffer, and the rest of the line could be
eliminated by special-casing saving of mark-ring, leaving just a list of marker positions to write into
the desktop file, which will typically be less than 100 bytes of text. If you have dozens of file-visiting
buffers, this can make the difference between a desktop file that's over 100kB and one that's just a few kB.

The attached patch does this. Surely this qualifies as a tiny change, since it only changes about 5
significant lines.

The "&rest _unsupported" is unnecessary; it just enables forward compatibility with files of version
greater than 207. If it were already there, then version 206 code would be able to read version 207 files,
and just ignore the mark ring.

Returning result from desktop-create-buffer is unnecessary for desktop mode, but it does no harm, and I
need it in some of my other code, so please allow it.

Re: Any posibility get non-dw2 libiconv2-dll and libintl-8.dll for gnutls/libxml2 emacs-compatible

> Date: Tue, 21 May 2013 08:52:42 +0200
> From: Miguel Ruiz <rbenit68 <at> gmail.com>
> 
> Based on
> 
> http://gcc.gnu.org/wiki/WindowsGCCImprovements

The small print near the end of that page says "last edited
2011-03-23".  So this is more than 2 years old now, and clearly
outdated, as the name of the libgcc_s_dw2-1.dll tells you (that "dw2"
part does stand for DWARF 2").

> I am not aware of the very internals of emacs, but, as a conservative
> behaviour, I build my w32 emacs production binaries with tdm-gcc-4.7.1-2
> (MinGW/sjlj) (http://tdm-gcc.tdragon.net/) and the crashes have completely
> disappeared.

I'm glad you solved your problem, but that cannot be the solution for
everyone else.  There are at least 3 different chains of GCC and
related tools ported to Windows; supporting only one of them, and not
the main one at that, cannot be good enough.  FWIW, that's the first
time I heard from anyone that they build Emacs with TDM; most use the
tools provided by mingw.org, and a few reported they use MinGW64
tools.  I have nothing against supporting TDM as well, but forcing
users to use only that is a non-starter.

> I follow the recent mails to the list and to gcc list (
> http://gcc.gnu.org/ml/gcc/2013-05/msg00180.html) about the problems in
> relation to libgcc_s_dw2-1.dll.

If you follow that, you already know that there are no firm
conclusions reached in that discussion yet.  Until the upstream GCC
maintainers say their definitive word on this, raising the issue here
is not very useful.

> At this moment
> 
> - libiconv-2.dll (in gnutls-3.0.9-w32-bin.zip)
> - libintl-8.dll  (in gnutls-3.0.9-w32-bin.zip)
> 
> - libiconv-2.dll (in libxml2-2.7.8-w32-bin.zip)
> 
> depend on libgcc_s_dw2-1.dll

That's not true, at least not with the GnuTLS and libxml2 distros from
my ports (on http://sourceforge.net/projects/ezwinports/files/).  I'm
quite sure that if you have those dependencies, you got libintl and
libiconv from some other place, not from those zip files.  Please
double check.  With the DLLs that I provided in the zip files, there's
no dependency on libgcc DLL, and no crashes at all.  (I will never
ever produce any port that depends on libgcc as a shared library, for
reasons that have nothing to do with the issue at hand here.)

> Is there any possibility that you provide the gnutls and libxml2 packages,
> and by extension, the named libraries, based on non-dw2 binaries, i.e.,
> built with a non-dw2 compiler like
> tdm-gcc-4.7.1-2, for example, as I do in a regular basis with emacs builds?

Sorry, but I will only use one toolchain, and currently that is the
toolchain distributed by mingw.org.  I cannot afford to have more than
one development environment, and I cannot invest more effort I already
do in porting optional libraries.  Moreover, since the problem with
libgcc_s_dw2-1.dll doesn't happen with my ports, I see no reason to
switch to TDM toolchain in the first place.

The problem which I'm trying to solve, and which prompted me to start
a discussion on the GCC list, is that I'd like this to work with any
GCC-based toolchain.  So switching to TDM, even if I wanted to, is not
the solution at all.

Eventually, with help from the GCC maintainers, we will crack this
problem, and find how to solve it.  I really suggest that people wait
for a little bit more; in the meantime, as already written in the
other thread here that raised the issue, using the DLLs from my ports
is a much easier work-around than switching to a completely different
development environment.

global-auto-revert-mode and file time stamps

Hi, I have sent this message to help-gnu-emacs, but I thought maybe 
development list is better, because I am using a development version. 
Here it goes:

When a file's timestamp has been changed, but the contents are still the
same, what should be the behavior of emacs be? With the emacs that I am
using (development version):

GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.6.3)
  of 2013-05-01 on bonsai

It thinks the file is changed. Here is what I do:

- Open a file, edit it and then save.

- use the "touch" command to update the time stamp of this file.

- Wait way more than the auto revert interval (which is set to 5 seconds
in my case).

- Try to make a change to the buffer corresponding to this file.

At this point, emacs says that the file has changed and asks whether I
really want to edit it. I was expecting emacs to auto revert this buffer
and allow me to edit it without further questions. So my question is, am
I looking at a bug, or a feature?

--

-- 
Timur Aydin

Any posibility get non-dw2 libiconv2-dll and libintl-8.dll for gnutls/libxml2 emacs-compatible

[PATCH] Make `C-x {' and `C-x }' repeatable

Ever since I started using emacs and tried to say good bye to my
mouse, I have felt that the resizing of windows with `C-x }' and
`C-x {' is too cumbersome to use.

- Typing `C-x }' several times in a row is not practical.
- I always undershoot when using things of the form `M-10 C-x }'
- I alway overshoot when using `C-x } C-x zzzzz'

This branch makes `C-x {' and `C-x }' behave similarly to `C-x
C-+' (text-scale-adjust).  After the original `C-x }' (or `C-x
{'), additional `{' and `}' continue to resize the window, until
the user enters another character.

The change is in lisp/window.el, which has dynamic scoping.  I
understand that this new function would be better with lexical
binding, allowing for a clean closure.  However I do not feel
confident enough (yet) with dynamic scoping to change the file's
binding mode by myself.

Please tell me if I should have done that differently, and I'll
try to implement it.  I'd be happy to see window.el get lexical
binding, and use a closure instead of a macro.   If the patch is
acceptable as is, it would be very nice to see it integrated.

Note that this is my first patch to GNU Emacs and with bzr.  I
might for example have missed indentation conventions (no tabs in
the new function, only spaces), but I could not find info about
tabbing conventions on the wiki or gnu.org (a link would be
welcome, if available).  Please guide me if I missed other
standard things.

https://code.launchpad.net/~gauthier-i/emacs/resize-window-repeat
lp:~gauthier-i/emacs/resize-window-repeat
Launchpad says that the branch is "Updating" and "empty", and has
been saying so for days.  Weeks, really.  The code seems to be
there though.  Tell me if it's not reachable for you, and if you
have suggestions for how to fix it, it'd be nice.

Otherwise, here's the bundle:

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: gauthier <at> ostervall.se-20130520193632-fm01gjdl38ux3egc
# target_branch: file:///media/sf_prog/emacs/trunk/
# testament_sha1: 6d88925597179e2c8c55153d5f9c62703d6ecd68
# timestamp: 2013-05-20 21:51:05 +0200
# base_revision_id: rgm <at> gnu.org-20130430101735-ccy06l3ndx4vrj18
#
# Begin patch
=== modified file 'lisp/ChangeLog' (properties changed: -x to +x)
--- lisp/ChangeLog	2013-04-29 20:09:18 +0000
+++ lisp/ChangeLog	2013-05-20 19:36:32 +0000
 <at>  <at>  -1,3 +1,7  <at>  <at> 
+2013-05-20  Gauthier Ostervall  <gauthier <at> ostervall.se>
+
+	* window.el (window-size-adjust): New function.
+
 2013-04-29  Leo Liu  <sdl.web <at> gmail.com>

 	* progmodes/octave.el (octave-font-lock-keywords): Handle 'end' in

=== modified file 'lisp/window.el' (properties changed: -x to +x)
--- lisp/window.el	2013-04-13 14:37:20 +0000
+++ lisp/window.el	2013-05-07 12:13:36 +0000
 <at>  <at>  -6025,6 +6025,48  <at>  <at> 
   (interactive "p")
   (shrink-window delta t))

+;;;###autoload (define-key ctl-x-map [(?{)] 'window-size-adjust)
+;;;###autoload (define-key ctl-x-map [(?})] 'window-size-adjust)
+;;;###autoload
+(defun window-size-adjust (inc)
+  "Adjust the width or height of the current window by INC.
+
+INC may be passed as a numeric prefix argument.
+
+The actual adjustment made depends on the final component of the
+key-binding used to invoke the command, with all modifiers removed:
+
+   {      Decrease the window width by one step
+   }      Increase the window width by one step
+
+When adjusting with `{' or `}', continue to read input events and
+further adjust the windows width as long as the input event read
+\(with all modifiers removed) is `{' or `}'.
+
+This command is a special-purpose wrapper around the
+`enlarge-window-horizontally' command which makes repetition convenient
+even when it is bound in a non-top-level keymap.  For binding in
+a top-level keymap, `enlarge-window-horzontally' or
+`shrink-window-horizontally' may be more appropriate."
+  (interactive "p")
+  (let ((ev last-command-event)
+        (echo-keystrokes nil))
+    (let* ((base (event-basic-type ev))
+           (step
+            (pcase base
+              (?{ (- inc))
+              (?} inc)
+              (t inc))))
+      (enlarge-window-horizontally step)
+      (message "Use {,} for further adjustment")
+      (set-temporary-overlay-map
+       (let ((map (make-sparse-keymap)))
+         (dolist (mods '(()))
+           (dolist (key '(?{ ?}))
+             (define-key map (vector (append mods (list key)))
+               `(lambda () (interactive) (window-size-adjust (abs ,inc))))))
+         map)))))
+
 (defun count-screen-lines (&optional beg end count-final-newline window)
   "Return the number of screen lines in the region.
 The number of screen lines may be different from the number of actual lines,
 <at>  <at>  -6734,8 +6776,8  <at>  <at> 
 (define-key ctl-x-map "3" 'split-window-right)
 (define-key ctl-x-map "o" 'other-window)
 (define-key ctl-x-map "^" 'enlarge-window)
-(define-key ctl-x-map "}" 'enlarge-window-horizontally)
-(define-key ctl-x-map "{" 'shrink-window-horizontally)
+(define-key ctl-x-map "}" 'window-size-adjust)
+(define-key ctl-x-map "{" 'window-size-adjust)
 (define-key ctl-x-map "-" 'shrink-window-if-larger-than-buffer)
 (define-key ctl-x-map "+" 'balance-windows)
 (define-key ctl-x-4-map "0" 'kill-buffer-and-window)

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWUR/XcIAA/JfgH74WPf///+n
ho7////6YAkK7fS3YOIhVusmxkEqACmjWEiiJkxDKPTRppPVHpPU/VGQZI0GRoMIMCB5QSiJk0MS
aegonoQ0NDQNAAaAAGQGg5hNAaA0aMI0GI0xMmJoMI0DIBkwEpoUKaNT1N6gGpg0hgABqZkIwhoZ
oTAOYTQGgNGjCNBiNMTJiaDCNAyAZMBJEEyCMJNT01PJpMmNQT0k2EnpkgNAAabRK6mNCpOOvNw/
OIe/dNMDz+/5GP6nDKPHn45+VmllrIPBUm1m4uQt3tbOqpYhDglwOvchbLk+9SIm0crpRhHhgZOW
rUZ5CqssSQoh2dsEB87ObMs5sMOy89x49p/GqG68xIs5uTEfC1Corm0aJWgQjKwBYkxGVuVmTJKS
Cpdmy+RTBmujjTpNTI7nJnUYsLmtuZuvHyK+Z838rpjofnMsh9ll/PXruCQbxjgNl+MjHWYjPbrL
PfdaRrhyhImt5hzK2llPVWWRxFs3y0ZYWaKXZWFm/hatpRXPCLCOFQTb+nLm+VmkqxarFbdAZB0I
FUBRx02V7TN3ZYrYWwO/bn3ddT0w34eo85PfOmnZ8xSnlBmSZgY+S+IuCyJKxBcQX1txgdQTA5fe
9evXaqhvFX+RyaH5XsYcr6davd/jjFG5uMV56sspl3mea+iIUz4SRdObCF8uEtVk1vb+Z8u8tMjD
6RWiSsPDocggnpan18xfNB7A9hIoL24lviHuPqFDS0rAcCsLfLA+1l8AoEnnTg88Gx6Mq24BjsUE
g8pjPVc7v7PjhYl8m6XdMQf4cYIPI6JQQhkwsuIva5snJkML4ugoScTa11II9VPfjSCVwsAvGpjC
wgx+T0KFhJ7sgla6InM+TrcF/oIiREy0HDyRNA+Ntk1dAqQQc60TBAkVREUzMOPnl5bRMo4E0vjn
rpWO4/6kUTatEV4UM7XOHGlCoTHSlw1EszoojGHE0EJCVvE4DOaBazVGTqVgb2Nca7GLEuBkZnOk
Myd6ouiAIrUciQE6SxVarDNBUiKapYWRN4q7ETV1pZ5jjs5P2iwnetEGrOTvqfhHJJ9OozFSUI7R
lBXJxW57DOcSOhsg4NAfXrY15lpkkNWF80VAvUuVEmmsfBG6mriy1pDHbe/mEy0Ez1alQJ5TGK0z
UR8l0JHPtITWDcWPoYoMLijXpuZoFUJxFvlmbB1qBeQ3ihcqVC4xY2vhQGXUMBHb287GZvCbtbYm
M61heaWle3OzKhK6swKvQbIc4kFpMVyCFYtjAV+0lDC2wVk3wk1eGVgkimCvnllleNlQ1Ka4j8oN
JsOLHixuMgtaZtLC4vJkkPYZjhYOJgsJKyE0USpEY+YuxHBM6S+kZq8LbUG1ce0gdQZ3umyWIgnq
naYmP/eOGC0KeOmgkqeZJ7yQoalOLNKbJjDgbnDAdlU7YWtQwjmAv04lJgSHbPUtvXsNPloY734F
IxNYXvsVErPV+Lj+3c/g3gqjCDJHomOUtJjjMbkMkaRj6NgioQHi6yMNB5Tqo79bkD/q8RB+CgWe
Ns3k6r3pIkm/ph5OTXzc/l26LJjCj6tB1GCDNVQoVEMRRDaZAYQNCIQrMi2tZG2zrlNZ3+Epyqnj
ogc+qsfV4rC6T5ZTWcwcLFSaogIdxzRaCUKGTpnQkXLeOdCvJIlIXKBuI0mJ5bdLtr8TkLHqnYHM
1EF/thGfvFUkkiY2sT4iguzupzXV54e6OMHXXlQgvIzea8rQhJDlrJL1gUsRCy9SPUTO8nu1WHhD
frnzhwVLy0qJljc9THA0ko0oFxay5Y8Pu6Oisxm+m/7TkqphIaRZZFRaLYYTwLh1oqd4u4XUdGoa
orrNG+Bzd/4EQ4LEz1GDbh+n8Dv69kqkHHHYdJhVBltZ5q0thLRvNAmIGI1rlIoTQjzn3ES8KI7V
qurj6ZHU/ri9QKfbAnqS1Arz0nXkcTgNz7TvFI7errfmdwWi3i/0ZmiqLcLbAPEvYlBTaaCYaMMt
y1oPrPrGtBhxnvVwr7ExUZJh8NBOv+IbeLyMy5AfkQMJF/rE2jTb2dfelINCM0+xTOnpvSmVpvhP
WpuiGsoO0TNIRlQjEznSKqW+UUZQrCLyZ88ku6XpImjSl/qZ65MrlA5G8oSitgzC6YLRvUB6UeaN
auz4jOSkFO60t4vOg5RLfQzcZNu7eivXCA3FLVxYsTjjediGYQiIMJAML0rMCJEC/WrzPjaXsOMT
Wo8DIhMBZHw2EESWBfqTsiG0XD0blY175dIYqMXPH/LE0RNWjHSZFeskHVeZCqTY0LSgShrqDwZh
rXQ7BNiNh9ToifssTjNY7hEAIeKoQQy91YQZEw0LJRHTudgmgJTQ4w4nZK9OSi6XkzDz26ILhdK2
B0XH0IndHtLl3AaijLsZJzwOVromq0GU3ZfTN4JU7Ne5bAsRKYoP7BBt7r6nRoZMhHTuYYXc7rvL
R6GfmGGFJ+zrkHbVTydrRyHxmSxvKtxvLcCzLiBFYJhkyo6UubgiKWw7HxQMXHE5VgYlwh8BtQ0n
OJAKqYRTYTb0eWYZqI6OBKas2KY7jk2QhkWjiYFtkroahNLYQjbbEzqeK5ZCyZFXb3UlTQOq64DU
4NcybM+F+QEQNRIbWZMmaRLbv+SCwK4FgzMk7QJ4MYfotggpYopcmuqZhdMupEmb04mSQVDujVh4
whyQfCIYkgkR8YY+tZSQQjFHaXrQICW4vQi4znEyCpaR5LFhRLQtTa4xSsSZqsKhGXlFFa9TnWgy
OcHDEww5XkiJ0iUSJoAvuFofZohHrFsN+omtbJhM7APlOpJBiRw1CNgp4H7hCHh+9wIvITnvFYg1
UAejiKS3INafigcC7aOG05PEdmTkYqDG5ZFDaCptDM4mpVfsJqtQiGuu8yQR7i7kinChIIj+u4Q=

"unexec: not enough room for load commands ..." on OSX

About every third or fourth day when I build the HEAD on OSX, I get
something that looks like this:

    Writing LC_DYLD_INFO_ONLY command
    Writing LC_SYMTAB command
    Writing LC_DYSYMTAB command
    Writing LC_LOAD_DYLINKER  command
    Writing LC_UUID           command
    Writing LC_VERSION_MIN_MACOSX command
    Writing LC_SOURCE_VERSION command
    Writing LC_MAIN           command
    Writing LC_LOAD_DYLIB     command
    Writing LC_LOAD_DYLIB     command
    Writing LC_LOAD_DYLIB     command
    Writing LC_LOAD_DYLIB     command
    Writing LC_LOAD_DYLIB     command
    Writing LC_LOAD_DYLIB     command
    Writing LC_LOAD_DYLIB     command
    Writing LC_LOAD_DYLIB     command
    Writing LC_LOAD_DYLIB     command
    Writing LC_FUNCTION_STARTS command
    Writing LC_DATA_IN_CODE   command
    Writing LC_DYLIB_CODE_SIGN_DRS command
    unexec: not enough room for load commands for new __DATA segments
    make[1]: *** [bootstrap-emacs] Error 1
    make: *** [src] Error 2

Even resetting the workdir to a fresh checkout, and following the
instructions in INSTALL.BZR, doesn't fix it.

But then, a couple of days later, on a later daily HEAD, it just "works
again".

Is someone fixing this by setting some value to a higher number?  If so,
can I do that myself too?

--

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn <at> stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

emacs takes exhorbitantly long to read long, one-line files.

I have a file (a matlab .m file of a vector of data) that is all on
one line and about 2 MB:

  http://www.digitalsignallabs.com/dspin.m

emacs takes a very long time (6 minutes?) to read this in, and
practically becomes unusable in the mean time.

I'm thinking of looking into the code to get an idea of why this happens
and of course look for a fix. If anyone has any pointers or other info
on the problem, please inform me. 
--

-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com