gmane.emacs.devel

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

Stefan Monnier — 2013-05-23T16:48:41

Such situations might also just benefit from a more automatic handling,
where the increment depends on how many times you repeated the same
command in a short time interval.


        Stefan

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

Drew Adams — 2013-05-23T16:19:33

Good point.  That is indeed another use case.


I would probably prefer that the prefix arg be applied modally here.
IOW, the last prefix arg be used for subsequent repetitions until I change it.
That way, when and whether to change to a more or less fine-grained increment
is up to me, not to some hard-coded rule.

E.g., what you suggest is to always immediately revert to no prefix arg, which
means an increment of one, after the first use of the sizing key.  I would
prefer to keep the increment as I requested it, until I change it:

C-5 C-x a a a a C-2 a a a
                ^^^ Change to more fine-grained control here, not before.

Moving a frame around is probably a better example, since window resizing by
increments of a line or char at a time rarely needs repetitions with large
increments.

Or think of window resizing by pixel increments instead of line/column increments.
You might well want to start with a large increment and switch to a smaller one
when you got closer to what you wanted.  But the point

Re: [PATCH 1/2] Add menu for ielm.

Stefan Monnier — 2013-05-23T15:28:30

 

Thanks, installed (tho without the redundant require), along with the
other patch.


        Stefan

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

Stefan Monnier — 2013-05-23T13:41:28

It's in GNU ELPA.


Yes clearly, that is needed before we can consider it to make C-x
[{}^] redundant.



        Stefan

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

Gauthier Östervall — 2013-05-23T12:21:41

On Wed, May 22, 2013 at 9:05 PM, Stefan Monnier

windresize.el is not part of my distribution, so I haven't. I will
give it a try, but I feel that functionality should be built-in.
Thanks for the hint anyway.

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

Rüdiger Sonderfeld — 2013-05-23T11:43:02

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))

[PATCH 1/2] Add menu for ielm.

Rüdiger Sonderfeld — 2013-05-23T11:42:45

* 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)

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

chad — 2013-05-23T00:18:50

I haven't tried this yet, but I imagine that I would want subsequent
commands to *ignore* the prefix. For example, I would grow a window
by 4 or 16, then use single keystrokes to fit more accurately from
there. I do something similar to this now with a simple macro
(long-since built into my fingers) that grows a window by 12.

Have you perhaps tried this behavior with window-sizing commands?
Did it feel more natural to always adjust the window by a large
increment, or did you find that you typically adjusted it by a small
increment and repeated the growth multiple times?

Thanks in advance.
~Chad

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

Drew Adams — 2013-05-22T23:53:55

That's reassuring; thanks.  As no one had yet had a chance to respond
to the bug report, I wasn't sure that you would see it that way.


Do you mean that comment or the bug #14095 report?


Sounds good to me (with limited understanding).


A priori, that too sounds good to me (again, with limited understanding).

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

Drew Adams — 2013-05-22T23:53:43

Fine with me, if the things discussed (e.g., prefix arg passed to all
final-key "repetitions" after the prefix key) can be worked out.

I agree that, since it lets you define a group of related "repeatable"
final keys for the same prefix key, the `set-temporary-overlay-map'
approach is more general than what I do with `repeat-command'.  But it
is a little less convenient for the use case of a singleton group.

One good thing might be to have an abbreviation to handle that use case.
IOW, a simple way to do what one can do with `repeat-command', avoiding
explicitly creating a singleton keymap.  Not a big deal; it would be
just a little more convenient.

There is also the question (assuming a fix that would apply the prefix
arg from the prefix key to each repeated final key) of whether using a
prefix arg before an individual final key should affect only that key
occurrence or all subsequent key hits as well.

IOW, should using a prefix arg be modal for the repeated keys that follow it
(until/unless you use ano

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

Stefan Monnier — 2013-05-22T22:24:51

Duh: universal-argument uses overriding-terminal-local-map, so yes, of
course it bumps into similar problems as isearch when combines with
set-temporary-overlay-map.


        Stefan

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

Stefan Monnier — 2013-05-22T22:08:13

Indeed.  But I don't think it's a big deal: set-temporary-overlay-map
makes it easy enough that you shouldn't need to use repeat.el
programatically (i.e. repeat.el is only useful as an implementation of
the C-x z command).


        Stefan

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

Stefan Monnier — 2013-05-22T21:47:18

I haven't looked into it, but at least I wouldn't know offhand why that
would be a problem (`universal-argument' is a special command with some
nasty ad-hoc handling in the command_loop C code for it, but I can't
think of an obvious reason why it would explain what you're seeing).


Of course.  Bug#14095 is a clear bug linked to the following comment in
set-temporary-overlay-map:

    ;; FIXME: That's the keymaps with highest precedence, except for
    ;; the `keymap' text-property ;-(

the bug is actually wrong, because additionally to the `keymap'
property, overriding-local-map and overriding-terminal-local-map are two
more keymaps of higher precedence.  So the right fix for it is to
introduce a new keymap (call it "overriding-temporary-local-map" or
something) which is like overriding-terminal-local-map except that it
doesn't disable other keymaps (it just has higher precedence).


Isearch might benefit from being changed to use such a new
overriding-temporary-local-map as well.  It might let us drop the

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

Drew Adams — 2013-05-22T21:39:14

Dunno.  But anyway, as I said, the typical use case for repetition (at least for me) would reuse the same prefix-arg value given to the prefix key.  IOW, I would typically not want to use a different prefix value for one occurrence of repetition from another.

Or at least I would not want to be *obliged* to repeat the prefix arg each time I repeated the final key.  And I think that is what your approach amounts to (assuming you can fix it so a prefix arg does not exit the map).

It would be OK for a user to be *able* to employ a new prefix arg along the way, for a one-off final-key occurrence.  But you wouldn't want to be forced to keep providing a prefix arg for each final-key repetition. 


Yes, I saw that.  Good.  I would still prefer a simpler approach.  You are essentially requiring each repeatable command to set variables `isearch-repeat-command' and `isearch-repeat-key'.  (That might be similar to the older approach used in repeat.el - dunno.)

I would prefer something simpler, using either an approa

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

Stefan Monnier — 2013-05-22T19:05:34

Have you tried M-x windresize ?  It's too modal for my taste (I'd like
to be able to exit more easily than via `q'), but other than that
I hope such a command will eventually make C-x {, C-x }, and C-x ^ redundant.



        Stefan

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

Juri Linkov — 2013-05-22T18:55:38

I don't know why a prefix arg exits temporary-overlay-map.  Trying to

  (define-key window-size-adjust-keymap [?\C-u] 'universal-argument)

doesn't help to fix this.  `C-u' still terminates the key sequence
`C-x } } } } C-u }'.


In bug#10654 I proposed a patch that implements repeatable keys for Isearch
e.g. `M-s C-f C-f M-f C-f ...'

Maybe a better implementation would be with the help of
`set-temporary-overlay-map'.  I'll try to do this for Isearch.
But it seems repeat.el can't be used if there are different commands
in the key sequence.

Re: global-auto-revert-mode and file time stamps

Timur Aydin — 2013-05-22T18:50:59

 >

I can confirm that this problem is fixed. Thank you Michael.

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

Drew Adams — 2013-05-22T17:44:54

Juri's suggestion is a good one.

There is another way to do this (which I have mentioned before):

;; Needs library `repeat.el'.  Either autoload it or add (require 'repeat)
;; to a command that needs it.
;;;### (autoload 'repeat-command "repeat" t nil)

(defun repeat-command (command) ; To be added to `repeat.el'.
  "Repeat COMMAND."
  (let ((repeat-message-function  'ignore))
    (setq last-repeatable-command  command)
    (repeat nil)))

You can then make a repeatable command from any ordinary command. 
E.g., window-sizing:

(defun window-widen (arg)
  "...."
  (interactive "P")
  (repeat-command 'enlarge-window-horizontally))

(defun window-narrow (arg)
  "...."
  (interactive "P")
  (repeat-command 'shrink-window-horizontally))

(defun window-heighten (arg)
  "...."
  (interactive "P")
  (repeat-command 'enlarge-window))

(defun window-shorten (arg)
  "...."
  (interactive "P")
  (repeat-command 'shrink-window))

Bind to any keys you like.  E.g., replace non-repeatable cmds:

(define-key ctl-x-map [(?}

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

Eli Zaretskii — 2013-05-22T14:51:49

Define "realistic".

The definition I used (and still do) is "where Emacs 23 provided
adequate behavior people wouldn't complain about."  In each such case
which I found or which was described to me, if Emacs 24 slowed things
down so they got past the humanly perceptible delay threshold, I
looked for and found optimizations that pushed Emacs 24 back below the
threshold, where the times used by Emacs 23 and 24 could not be
distinguished by humans.

If you find "realistic examples" by that definition, please by all
means report them as bugs.

But it was never a goal to make the performance of the bidirectional
display adequate where Emacs 23 wasn't, nor make it as inadequate as
Emacs 23.  That is another project, which needs to change display
algorithms and design on a different level.

Re: global-auto-revert-mode and file time stamps

Michael Albinus — 2013-05-22T14:50:06

Hi,


I've fixed this in the trunk.

Best regards, Michael.

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

Ulrich Mueller — 2013-05-22T05:10:38



Sure, the example with 16 MB in one line is unrealistic. I made it so,
simply because I wanted the times to be long enough to be measurable
with a stop watch.

But wouldn't the factors between 23.4 and 24.3 be similar for more
realistic examples?

Ulrich