gmane.emacs.devel

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

[PATCH] Desktop mode saves mark-ring too verbosely

Kelly Dean — 2013-05-22T03:44:15

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 _unsupport

Re: reveal-filename

Stephen J. Turnbull — 2013-05-22T02:46:16

 > > How about "Produce a canonical ..." or "Produce a normalized ..."?
 > 
 > The problem is, it can be neither.  If the argument is just "foo", it
 > will be returned unchanged.

Well, yes, that's what "normalize" and "canonicalize" mean.  If you
hand one of those operations an object already in normal form, it
won't be changed.  If calling doing nothing "Produce" bothers you,
s/Produce/Return/.

Re: MS-Windows build using Posix configury

Stephen Leake — 2013-05-21T19:36:36


Ok; INSTALL should say that. The point is to make clear what your
reasons are, so if I decide to ignore your advice, I know what the
issues are.

I had the same complaint about the Cygwin installer; it used to complain
if I installed to c:/ (requiring an extra confirming click), without
saying anything about why that might matter, leaving me to wonder if
Cygwin would break in some way. In that case, there was a rationale
posted online, which boiled down to "users might have other stuff
installed at c:/". 


I'm one :). I don't use Cygwin Emacs, because it doesn't work well
with the MinGW and native Windows tools I use. Although that may have
improved since I first played with this, back in Emacs 21 days. I do use
Cygwin bash and make, under native Emacs; that works well.

Re: reveal-filename

Stefan Monnier — 2013-05-21T19:37:24

Thanks, no hurry,


        Stefan

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

Juri Linkov — 2013-05-21T18:34:04

Thanks for this useful feature.  I am experiencing the same difficulties
with `C-x }' and `C-x {', so your feature would be of a great help.


Please make the keymap user-customizable, e.g. if you'll create
a separate keymap with a name like `window-size-adjust-keymap' then
users would be able to add more keybindings in ~/.emacs like:

  (define-key window-size-adjust-keymap [right] 'enlarge-window-horizontally)
  (define-key window-size-adjust-keymap [left]  'shrink-window-horizontally)
  (define-key window-size-adjust-keymap [down]  'enlarge-window)
  (define-key window-size-adjust-keymap [up]    'shrink-window)

to use arrow keys for window resizing.  Then having such map
you could just add one line:

  (set-temporary-overlay-map window-size-adjust-keymap)

to the end of all these four functions to implement this feature.
I mean changing existing commands:

(defun shrink-window-horizontally (delta)
  (interactive "p")
  (shrink-window delta t))

to

(defun shrink-window-horizontally (delta)
  (interactiv

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

Dmitry Antipov — 2013-05-21T18:28:44


RTSL, it's better to start from comments in xdisp.c and dispextern.h.

Dmitry

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

Michael Albinus — 2013-05-21T18:17:10


Hi,


I could reproduce the problem. I will check tomorrow what's up. Likely,
it is because the new file change notification mechanism introduced with
Emacs 24.3.50.

Best regards, Michael.

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

Randy Yates — 2013-05-21T18:03:54

Allow me to take a look. Are these algorithms documented? Or is it RTSL?

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

Eli Zaretskii — 2013-05-21T17:55:33

I see no degradation in performance: both 4 sec and 6 sec, let alone 9
and 34, are the same as infinity.  You cannot have any useful editing
with such reaction times to a simple cursor movement command.  It is
therefore meaningless to compare such "performance" figures and draw
any conclusions from them.

Emacs 24 has got a bidirectional display engine.  Bidirectional
display needs to do much more work than the previous unidirectional
one in Emacs 23 and before.  In a nutshell, where the unidirectional
display simply incremented a pointer, the bidirectional display calls
a complex function that does some very non-trivial processing based on
the bidirectional class of each character.

Now, this sounds scary, but really isn't.  The bidirectional display
was optimized so that in all the known uses where the old display
provided reasonable performance, the new one does, too.  While the
bidi display is still slower than the unidirectional one, the
optimizations keep the slowdown in check, such that the delays ar

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

Eli Zaretskii — 2013-05-21T17:21:16

Not sure the bidi display is involved in 6 vs 4 sec, but you should
know that turning off bidi-display-reordering doesn't revert all the
differences between the old unidirectional display and the
bidirectional one.  It was never meant to do that in the first place.

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

Eli Zaretskii — 2013-05-21T17:18:24

2 to 3 times in my experience, unless you specifically choose
character classes to trip the bidi iterator.

Re: MS-Windows build using Posix configury

Eli Zaretskii — 2013-05-21T17:07:50

Yes, "make install" will create it, but that's not the point.  See the
second part of the sentence I wrote and you quoted above.  The point
is that I want to encourage people to install ports of GNU and Unix
software in a single tree, so that they all play together well without
a lot of tinkering with environment variables.  And _since_ there
usually is not /usr/local on Windows systems, I doubt that /usr/local
will be a good guess of where people might put such a tree.  So I
_want_ them to think about the root of that tree, and I want them to
use that in the --prefix option.


Are there such users who don't prefer Cygwin instead?


Actually, still yes, although for a slightly different reason ;-)

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

Eli Zaretskii — 2013-05-21T16:45:07

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'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.


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.


That's not true, at least not with the GnuTLS and libxml

Re: reveal-filename

Eli Zaretskii — 2013-05-21T16:22:09

The problem is, it can be neither.  If the argument is just "foo", it
will be returned unchanged.


Well, that will be changed when the function is renamed.

Re: reveal-filename

Eli Zaretskii — 2013-05-21T16:20:31

Will do.

Re: reveal-filename

Eli Zaretskii — 2013-05-21T16:19:24

But that's what the function does, no less, no more.  And yes, it's
ad-hoc, because it simply works around an MSYS bug (I tried to find
other solutions, but failed).


When the function is extended to do that, it would make sense to
change the doc string along these lines.  For now, saying that would
be simply incorrect.

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

Gauthier Östervall — 2013-05-21T13:53:34

It would. It could even work after entering with C-x {, and { could
work after entering with C-x ^. For example:
C-x { { { { } } ^ ^ }
C-x ^ ^ } }
could be valid sequences.

One problem is that there is currently no standard key binding for
(shrink-window). That would need to be decided upon first. Having
(enlarge-window) and not its opposite would not work well.

Even more, + (balance-windows) could be included (and possibly exit
this resize mode).
Same thing with - (shrink-window-if-larger-than-buffer).

I'm willing to implement (balance-windows) as a second step if this
patch is accepted.

I nearly never `C-x -' or `C-x ^', but I could put it in once there is
an opposite to `C-x ^', for completeness. How are standard key
bindings decided upon, may I just come up with something?