What's your favourite *under_publicized* editing feature of Emacs?

107 views
Skip to first unread message

Le Wang

unread,
Jan 27, 2011, 3:33:13 AM1/27/11
to help-gn...@gnu.org
Hi all,

If you're like me, you get comfortable in your own Emacs workflow and just let your fingers do the walking all the time.  That's why Emacs is great.  Maybe you can think about your muscle memorized actions and pick out the single most useful function (whether a part of Emacs or in an addon package) that you don't think is well publicized and share it with us?

I'll get the ball rolling: C-x C-/ `session-jump-to-last-change' defined in session.el - http://emacs-session.sourceforge.net/

Obviously it jumps to the location of last change in the current buffer.  But the cool thing, is you can invoke it repeatedly to revisit all the locations in the current buffer where you've made a change.  The function works by analyzing the undo list, and it's light weight and unobtrusive (unlike highlight-changes-mode).

Your turn. 

--
Le

Deniz Dogan

unread,
Jan 27, 2011, 4:29:50 AM1/27/11
to Le Wang, help-gn...@gnu.org
2011/1/27 Le Wang <l26...@gmail.com>:

I get along just fine without many external packages. The most extreme
thing I have is probably the binding of M-n and M-p to
forward-paragraph and backward-paragraph respectively. Extremely
useful. :)

--
Deniz Dogan

Wang Lei

unread,
Jan 27, 2011, 7:03:41 AM1/27/11
to help-gn...@gnu.org
Le Wang <l26...@gmail.com> writes:

> Hi all,
>
> If you're like me, you get comfortable in your own Emacs workflow and just
> let your fingers do the walking all the time. That's why Emacs is great.
> Maybe you can think about your muscle memorized actions and pick out the
> single most useful function (whether a part of Emacs or in an addon package)
> that you don't think is well publicized and share it with us?
>
> I'll get the ball rolling: C-x C-/ `session-jump-to-last-change' defined in
> session.el - http://emacs-session.sourceforge.net/
>
> Obviously it jumps to the location of last change in the current buffer.
> But the cool thing, is you can invoke it repeatedly to revisit all the
> locations in the current buffer where you've made a change. The function
> works by analyzing the undo list, and it's light weight and unobtrusive
> (unlike highlight-changes-mode).
>
> Your turn.

I use C-u C-Space to jump to the last mark point frequently. But
`session-jump-to-last-change' you just mentioned looks very interesting.

--
Regards
Lei

Ken Goldman

unread,
Jan 27, 2011, 9:12:25 AM1/27/11
to help-gn...@gnu.org
I don't know if it's under-publicized, but I got hooked on emacs when I
discovered keyboard macros. I have start/end/call assigned to function
keys, and I use them whenever I'm doing repetitive editing.

I also like the integrated grep and next-error, which I also assign to
function keys.

... and the combination of grep, next-error and keyboard macros really
automates global changes.

suvayu ali

unread,
Jan 27, 2011, 9:13:00 AM1/27/11
to help-gn...@gnu.org
On Thu, Jan 27, 2011 at 9:33 AM, Le Wang <l26...@gmail.com> wrote:
> I'll get the ball rolling: C-x C-/ `session-jump-to-last-change' defined in
> session.el - http://emacs-session.sourceforge.net/
>

Just tried it out, very impressive. :)

My personal favourites are all the rectangle and register commands.
Try `C-x r C-h' to get a list. And of course there is always the `C-x
C-SPC' or `C-x C-@' for navigation. Specially with the following
setting, `C-u C-SPC' comes alive.


set-mark-command-repeat-pop is a variable defined in `simple.el'.
Its value is t
Original value was nil

Documentation:
Non-nil means repeating . after popping mark pops it again.
That means that C-u . .
will pop the mark twice, and
C-u . . .
will pop the mark three times.

A value of nil means .'s behavior does not change
after C-u ..

--
Suvayu

Open source is the future. It sets us free.

Erik Iverson

unread,
Jan 27, 2011, 1:11:47 PM1/27/11
to Le Wang, help-gn...@gnu.org
This may only work in 23+, but I enable subword-mode in
some buffers to deal with the camelCase naming convention.

What this does is lets you quickly navigate within identifiers.
M-f and M-b now will move forward and backward within words like
the following:

aVariableNamedLikeThis
^ ^ ^ ^

There is also glasses-mode that overlays characters within the
buffer between the subwords, but I couldn't get used to that.

Oh, and also:

(mouse-avoidance-mode 'cat-and-mouse)

Le Wang wrote:
> Hi all,
>
> If you're like me, you get comfortable in your own Emacs workflow and
> just let your fingers do the walking all the time. That's why Emacs is

> great. Maybe you can think about your muscle memorized actions and pick

> out the single most useful function (whether a part of Emacs or in an
> addon package) that you don't think is well publicized and share it with us?
>

> I'll get the ball rolling: C-x C-/ `session-jump-to-last-change' defined
> in session.el - http://emacs-session.sourceforge.net/
>

> Obviously it jumps to the location of last change in the current buffer.
> But the cool thing, is you can invoke it repeatedly to revisit all the
> locations in the current buffer where you've made a change. The
> function works by analyzing the undo list, and it's light weight
> and unobtrusive (unlike highlight-changes-mode).
>
> Your turn.
>

> --
> Le

Joe Fineman

unread,
Jan 27, 2011, 5:23:38 PM1/27/11
to
Ken Goldman <kg...@watson.ibm.com> writes:

> I don't know if it's under-publicized, but I got hooked on emacs
> when I discovered keyboard macros. I have start/end/call assigned
> to function keys, and I use them whenever I'm doing repetitive
> editing.

A slight refinement: You can start & end the definition with the same
key if you install

(defun define-kbd-macro ()
"Begin or end definition of keyboard macro."
(interactive)
(if defining-kbd-macro (end-kbd-macro) (start-kbd-macro nil)))
--
--- Joe Fineman jo...@verizon.net

||: If you can make it from one fart to the next, you'll live a :||
||: long time. :||

Jason Rumney

unread,
Jan 28, 2011, 1:40:17 AM1/28/11
to
Or use what is already there since 23.1:

<f3> runs the command kmacro-start-macro-or-insert-counter, which is
an interactive autoloaded Lisp function in `kmacro.el'.

<f4> runs the command kmacro-end-or-call-macro, which is an
interactive autoloaded Lisp function in `kmacro.el'.


Simón Ortiz

unread,
Jan 28, 2011, 4:54:03 AM1/28/11
to
I don't know if it is under_publicized, but I like a lot M-x hexl-mode

It's mode for editing binary files! Extremely useful when you need to
save/load data to/from binaries.

Also, since I have several windows opened at same time, I use windmove-
up, windmove-right, etc. to navigate the windows. It's more precise
than C-x o. Of course, I have these command assigned to shortcuts.

Erik: I'm adopting mouse-avoidance-mode :D thanks!

Drew Adams

unread,
Jan 28, 2011, 1:25:00 PM1/28/11
to gnu.ema...@googlegroups.com, help-gn...@gnu.org
> Or use what is already there since 23.1:
> <f3> runs the command kmacro-start-macro-or-insert-counter...
> <f4> runs the command kmacro-end-or-call-macro...

It's unfortunate however that two repeatable keys were wasted for these default
bindings. Repeatable keys are better reserved for operations that you want to
easily repeat by just holding down a key or chord.

Yes, you can use `f4' for both ending a macro definition and executing the
macro, and the latter operation is repeatable. Still, it is better to use a
repeatable suffix on a prefix key for this, e.g. `C-x e e e...' (which you can
already use as an alternative to `f4 f4 f4...'). Single repeatable keys are a
valuable resource and should not be wasted.

`f3' and `f4' also do not offer mnemonic help.

Consider by contrast the keys bound to `kmacro-start-macro' and
`kmacro-end-macro': `C-x (' and `C-x )'. Those bindings were made decades ago
(to the parents of the current commands: `start-kbd-macro' and `end-kbd-macro').
They are mnemonic, visually indicating start and end, and they are not easily
repeatable by holding keys down. Start/end have no need to be repeatable.

In the past Emacs also used the similar keys `C-x [' and `C-x ]' for generating
the corresponding Emacs-Lisp code while defining a keyboard macro. I don't
recall whether those keys were in Gnu Emacs or some other Emacs from days of
yore. The point is that here too mnemonic start/end keys were used, and no
repeatable keys/chords were wasted gratuitously. (Yes, it is also true that
natural pairs such as () [] \/ and <> are rare and should be used judiciously.)

There was some discussion back in 2002 about wasting `f3' and `f4' for this. At
first (with no discussion AFAICT), `f7' and `f8' were implemented for it - same
problems obviously. A user pointed out that function keys `f5' to `f9' are
supposed to be reserved for users to bind, so the macro commands got moved to
`f3' and `f4'.

What was the main argument for binding kmacro commands to such keys? "I need to
bind them to two adjacent function keys" and "it makes a nice interface to have
this on two function keys next to each other". Which is no reason at all (why
do they need to be adjacent? why do they need to be on function keys?).

The other arguments given in support of wasting `f3|4' for this: (a) "I don't
see why we should hide an excellent feature like keyboard macros", (b) keys like
`C-x (' are "way too cumbersome" for defining a macro, and (c) "I really don't
understand why binding function keys by default is worth making a fuzz about".

(b) is the most misguided of these: you don't need a quick, repeatable key just
to turn on/off keyboard recording. Use easily repeatable keys for repeatable
operations (incremental changes, cycling, etc.), and use keys that are a bit
more cumbersome for one-off operations such as on/off, start/end.

To their credit, Stefan and Miles argued against using function keys for this,
but with no success. This was the last word, from RMS:

"I think there is no harm in supporting F3 and F4 as well as
C-x (, C-x ) and C-x e and C-x C-k, if users like F3 and F4.
We could take a poll and ask them."

AFAIK no poll was ever taken.

Although Stefan's suggestion to use `C-x e e e...' to repeat macro execution was
also implemented, `f3' and `f4' remain bound by default, and `C-x e e e...' took
a back seat in the doc (and consequently in practice, no doubt), seemingly as an
afterthought. There isn't even any mention of the `C-x e' option
`kmacro-call-repeat-key'.

http://lists.gnu.org/archive/html/emacs-devel/2002-08/msg00760.html


Ken Goldman

unread,
Jan 28, 2011, 4:22:25 PM1/28/11
to help-gn...@gnu.org
I use hexl-mode all the time.

I've often needed an insert, as opposed to overwrite. Do you know if
there's a way to insert?

Stefan Monnier

unread,
Jan 28, 2011, 5:59:21 PM1/28/11
to
> I use hexl-mode all the time.
> I've often needed an insert, as opposed to overwrite. Do you know if
> there's a way to insert?

Sadly, there isn't. I have a new mode I call "nhexl-mode" which does
"the same" as hexl-mode but in a completely different way (the
conversion is done in a font-lockish way, so the buffer's content is
not affected, only the display) so you can use it with buffer insertion
and pretty much anything else. Sadly, it bumps into some severe
performance limitations in the current redisplay code, so it's largely
unusable other than on very small buffers :-(


Stefan

Javier Sanz

unread,
Jan 29, 2011, 7:55:19 AM1/29/11
to
Some that come to my mind:
- nXML mode, specially sexp navigation. I edit XML files quite a lot,
and features like navigating up and down in the tree, killing the
contents of some XML element or auto tag closing are great.
- I could not live with other some minor modes: autopair.el, guess-
style.el, browse-kill-ring.el, globalff.el
- Using define-generic-mode, I've defined a major mode for my app
logs, which highlights errors and warnings in different colors and
makes them easier to see.
- hippie-expand, rgrep, psvn-mode, global-linum-mode. These are more
common.
- Some macros that call some command line Linux tools to process the
content of a buffer have saved me a lot of time.

Oleksandr Gavenko

unread,
Jan 29, 2011, 9:46:33 AM1/29/11
to help-gn...@gnu.org
It is possible read only portion of file by Emacs
and don't load all file content into buffer?

Many hex viewer in read-only mode allow open large files without
performance penalty. Emacs don't.

--
Best regards!


Eli Zaretskii

unread,
Jan 29, 2011, 10:00:55 AM1/29/11
to help-gn...@gnu.org
> From: Oleksandr Gavenko <gave...@gmail.com>
> Date: Sat, 29 Jan 2011 16:46:33 +0200

>
> It is possible read only portion of file by Emacs
> and don't load all file content into buffer?

Yes, see the doc string of insert-file-contents.

> Many hex viewer in read-only mode allow open large files without
> performance penalty. Emacs don't.

It won't help in this case, because the performance problems Stefan
mentions make his nhexl-mode unusable even on relatively small
buffers, unfortunately.

Perry Smith

unread,
Jan 29, 2011, 10:02:14 AM1/29/11
to help-gn...@gnu.org

On Jan 29, 2011, at 8:46 AM, Oleksandr Gavenko wrote:

> On 2011-01-29 0:59, Stefan Monnier wrote:

> It is possible read only portion of file by Emacs
> and don't load all file content into buffer?
>

> Many hex viewer in read-only mode allow open large files without
> performance penalty. Emacs don't.

This thread is beginning to drift a bit... but something I wish I had was a way
to view a file without loading all of it. I look at hugh trace files and I have to
get out of emacs and start a shell so I can use more / less.

The shame of it all! ;-)

I don't know of such a critter. If there is one, that would be super cool.

Perry


Stefan Monnier

unread,
Jan 29, 2011, 11:08:04 AM1/29/11
to
> I don't know of such a critter. If there is one, that would be super cool.

Agreed,


Stefan

Oleksandr Gavenko

unread,
Feb 8, 2011, 6:10:35 PM2/8/11
to help-gn...@gnu.org
On 2011-02-06 22:11, Oleksandr Gavenko wrote:

> On 2011-01-29 14:55, Javier Sanz wrote:
>> Some that come to my mind:
>> - Using define-generic-mode, I've defined a major mode for my app
>> logs, which highlights errors and warnings in different colors and
>> makes them easier to see.
> How large your log files?
>
> I set 'grep-mode' on my log file (which follow GNU
> error coding convention). On 50-100 KiB logs it take
> 10 sec to highlight matches. On larger files I type
> C-g to stop matching for highlighting.
>
Performance penalty because I use grep-mode which based on compilation-mode.

In private mail Javier Sanz show me his log mode based on
'define-generic-mode'.

I check and found that font-lock mechanism is pretty fast.

This become start point to develop some code by hand.

And I realize that compilation-mode is dumb as it try
set on all matched file/line pairs text properties to
allow move to another file by RET.

Instead I highlight required patterns and make GOTO error
function which analyse only current line:


;;; my-log-mode.el --- major mode for error logs

;; Copyright (C) 2010 by Oleksandr Gavenko <gave...@gmail.com>

;; You can do anything with this file without any warranty.

;; Author: Oleksandr Gavenko <gave...@gmail.com>
;; Maintainer: Oleksandr Gavenko <gave...@gmail.com>
;; Created: 2011-02-09
;; Version: 0.1
;; Keywords: logging

;;; Commentary:
;;
;; Very pure release.

;;; Code:

(defun my-log-goto (point)
""
(interactive "d")
(let ( start stop line fname fline (fregex
"^\\([^:]+\\):\\([[:digit:]]+\\):") )
(save-excursion
(move-beginning-of-line 1)
(setq start (point))
(move-end-of-line 1)
(setq stop (point))
(setq line (filter-buffer-substring start stop))
(string-match fregex line)
(setq fname (match-string 1 line))
(when fname
(setq fline (string-to-int (match-string 2 line)))
)
)
(when (and fname (file-exists-p fname))
(find-file-other-window fname)
(goto-line fline)
)
))

(setq my-log-mode-map (make-sparse-keymap))
(define-key my-log-mode-map (kbd "RET") 'my-log-goto)

(require 'generic-x)

;;;###autoload
(define-generic-mode
'my-log-mode
nil
nil
'(
("^\\([^:]+\\):\\([[:digit:]]+\\):[^
]+$" (1 font-lock-keyword-face) (2 font-lock-type-face))
("^\\([^:]\\{1,10\\}\\):[^
]+$" (1 font-lock-function-name-face))
)
;; '("\\.log$")
nil
(list
(lambda nil
;; (setq buffer-read-only t)
(use-local-map my-log-mode-map)
(modify-syntax-entry ?' ".")
(modify-syntax-entry ?\" ".")
))
)

;;; my-log-mode.el ends here

--
Best regards!


Stefan Monnier

unread,
Feb 8, 2011, 11:37:20 PM2/8/11
to
>> I set 'grep-mode' on my log file (which follow GNU
>> error coding convention). On 50-100 KiB logs it take
>> 10 sec to highlight matches. On larger files I type
>> C-g to stop matching for highlighting.

You may want to try the Emacs trunk's version of compile.el (I think
it'll work with Emacs-23 as well). It should help out by being more
lazy (e.g. it'll still takes 10s to parse the file when you jump to the
end of it, but it should open instantaneously because it'll only need to
parse the first page for that).

> And I realize that compilation-mode is dumb as it try
> set on all matched file/line pairs text properties to
> allow move to another file by RET.

compilation-mode indeed does more work than I'd like at the "highlight"
time, and some of that work could indeed be delayed to the moment the
user hits RET on a line. But my impression is that most of the time is
spent regexp-matching (i.e. looking for matches) anyway, so moving this
work won't make much difference if any. IOW my impression is that if
your code is faster it's because it uses either more efficient regexps,
or fewer regexps.

> ("^\\([^:]+\\):\\([[:digit:]]+\\):[^

E.g. this regexp is more efficient than the one used by grep.el, by
disallowing : in file names (resulting in a backtrack-free regexp).


Stefan

Oleksandr Gavenko

unread,
Feb 9, 2011, 3:51:37 PM2/9/11
to help-gn...@gnu.org
On 2011-02-09 6:37, Stefan Monnier wrote:
>>> I set 'grep-mode' on my log file (which follow GNU
>>> error coding convention). On 50-100 KiB logs it take
>>> 10 sec to highlight matches. On larger files I type
>>> C-g to stop matching for highlighting.
>
> You may want to try the Emacs trunk's version of compile.el (I think
> it'll work with Emacs-23 as well). It should help out by being more
> lazy (e.g. it'll still takes 10s to parse the file when you jump to the
> end of it, but it should open instantaneously because it'll only need to
> parse the first page for that).
>
Sound interesting.

But you wrote that jumping to end of buffer take whole time ((

We recently discuss about Emacs hex mode and I ask how read only
needed part of file to display (as binaries some times very large
for opening in Emacs).

This allow Emacs spend time on processing only needed (displayed)
part of information.

Same with highlighting of compilation/grep like buffers.

Usually reference for file/line placed on single line (or two...).

So highlighting can be performed only on visible part on large files.

Does currently Emacs highlight all file or this depend on mode?

How about generic-modes?

>> And I realize that compilation-mode is dumb as it try
>> set on all matched file/line pairs text properties to
>> allow move to another file by RET.
>
> compilation-mode indeed does more work than I'd like at the "highlight"
> time, and some of that work could indeed be delayed to the moment the
> user hits RET on a line. But my impression is that most of the time is
> spent regexp-matching (i.e. looking for matches) anyway, so moving this
> work won't make much difference if any. IOW my impression is that if
> your code is faster it's because it uses either more efficient regexps,
> or fewer regexps.
>
>> ("^\\([^:]+\\):\\([[:digit:]]+\\):[^
>
> E.g. this regexp is more efficient than the one used by grep.el, by
> disallowing : in file names (resulting in a backtrack-free regexp).
>

I previously ask about regex performance in this list and
try define-generic-mode with different regex. Time to
highlighting do not significant changed with different regex.

Seems problem in another place and I read doc how profile.

Look at 'my.log' file, which is 289 KiB long:

-*- mode: my-log; default-directory: "~/devel/job/plugin-hg/" -*-
WM: 0x0024: WM_GETMINMAXINFO
win-gui-admin.c:140: WndProc #8
WM: 0x0024: WM_GETMINMAXINFO
win-gui-admin.c:140: WndProc #8
WM: 0x0024: WM_GETMINMAXINFO
... (repeat 2 last lines many times)

When I eval: (benchmark-run 1 (revert-buffer))
I get: (0.172 0 0.0)

When I change mode line to

-*- mode: grep; default-directory: "~/devel/job/plugin-hg/" -*-

and eval: (benchmark-run 1 (revert-buffer))
I get: (22.406 1 0.156)

As you can see it is 100 times slower!

I perform 'M-x elp-instrument-package grep'
and 'M-x elp-instrument-package compilation'. Next I perform
'(revert-buffer)' and 'M-x elp-results' and get:

grep-mode 1 23.906 23.906
compilation-error-properties 4742 23.047 0.0048601855
compilation-internal-error-properties 4742 0.094 1.98...e-005
compilation-get-file-structure 4742 0.016 3.37...e-006
compilation-mode 1 0.0 0.0
compilation-mode-font-lock-keywords 1 0.0 0.0
compilation-setup 1 0.0 0.0

As you can see 'compilation-error-properties' eat a lot of time and
it executed on all lines like 'file:line: msg' (in my example half of
lines match such pattern)!

I press C-u C-x = on green underscored char (file name for jump) and see
among text properties: 'message' with value is:

((nil 140
(("win-gui-admin.c" nil)
nil
(140 #1)))
2 nil)

I assume that 'compilation-error-properties' spend time on setting this
properties.

So because of unnecessary work to set text property to well structured
data on *all* lines we have slow down instead perform parsing of
reference on demand.

As I previously shown 'my-log-goto' func for this purpose.

I think such idea (trying match pattern on point position) can be
generalized by looping across 'compilation-error-regexp-alist'.

Do you think this need filed as a bug or request?

Or I am something missing?

--
Best regards!


Oleksandr Gavenko

unread,
Feb 9, 2011, 4:31:15 PM2/9/11
to help-gn...@gnu.org
On 2011-02-09 6:37, Stefan Monnier wrote:
>>> I set 'grep-mode' on my log file (which follow GNU
>>> error coding convention). On 50-100 KiB logs it take
>>> 10 sec to highlight matches. On larger files I type
>>> C-g to stop matching for highlighting.
>
> You may want to try the Emacs trunk's version of compile.el (I think
> it'll work with Emacs-23 as well). It should help out by being more
> lazy (e.g. it'll still takes 10s to parse the file when you jump to the
> end of it, but it should open instantaneously because it'll only need to
> parse the first page for that).
>
Sound interesting.

But you wrote that jumping to end of buffer take whole time ((

We recently discuss about Emacs hex mode and I ask how read only
needed part of file to display (as binaries some times very large
for opening in Emacs).

This allow Emacs spend time on processing only needed (displayed)
part of information.

Same with highlighting of compilation/grep like buffers.

Usually reference for file/line placed on single line (or two...).

So highlighting can be performed only on visible part on large files.

Does currently Emacs highlight all file or this depend on mode?

How about generic-modes?

>> And I realize that compilation-mode is dumb as it try


>> set on all matched file/line pairs text properties to
>> allow move to another file by RET.
>
> compilation-mode indeed does more work than I'd like at the "highlight"
> time, and some of that work could indeed be delayed to the moment the
> user hits RET on a line. But my impression is that most of the time is
> spent regexp-matching (i.e. looking for matches) anyway, so moving this
> work won't make much difference if any. IOW my impression is that if
> your code is faster it's because it uses either more efficient regexps,
> or fewer regexps.
>
>> ("^\\([^:]+\\):\\([[:digit:]]+\\):[^
>
> E.g. this regexp is more efficient than the one used by grep.el, by
> disallowing : in file names (resulting in a backtrack-free regexp).
>

Thien-Thi Nguyen

unread,
Feb 9, 2011, 5:32:07 PM2/9/11
to Oleksandr Gavenko, help-gn...@gnu.org
() Oleksandr Gavenko <gave...@gmail.com>
() Wed, 09 Feb 2011 23:31:15 +0200

So because of unnecessary work to set text property to well
structured data on *all* lines we have slow down instead perform
parsing of reference on demand.

[...]

Or I am something missing?

You have well-structured data but the compilation (likewise, grep)
font-locking tries to cope with a more general input. You can prune
some elements from ‘compilation-error-regexp-alist’ to help focus the
font-locking. Have you tried that?

Stefan Monnier

unread,
Feb 10, 2011, 12:24:13 PM2/10/11
to
> I perform 'M-x elp-instrument-package grep'
> and 'M-x elp-instrument-package compilation'. Next I perform
> '(revert-buffer)' and 'M-x elp-results' and get:

> grep-mode 1 23.906 23.906
> compilation-error-properties 4742 23.047 0.0048601855
> compilation-internal-error-properties 4742 0.094 1.98...e-005
> compilation-get-file-structure 4742 0.016 3.37...e-006
> compilation-mode 1 0.0 0.0
> compilation-mode-font-lock-keywords 1 0.0 0.0
> compilation-setup 1 0.0 0.0

Duh! I completely forgot about it, but yes, there was a clear
performance bug in compilation-error-properties which made it take time
proportional to the buffer size in cases such as M-x grep.
This performance bug is also largely fixed in Emacs-24's compile.el.


Stefan

Oleksandr Gavenko

unread,
Feb 14, 2011, 3:44:48 PM2/14/11
to help-gn...@gnu.org
Yes. I wrote:

(require 'compile)
(setq my-log2-error-regexp-alist
'(
("^\\([^:]+\\):\\([[:digit:]]+\\):" 1 2)
))
(define-compilation-mode my-log2-mode "MyLog"
"Log mode."
(set (make-local-variable 'compilation-error-regexp-alist)
my-log2-error-regexp-alist)
)

And as I describe previously I eval on same 289 KiB long buffer:
(benchmark-run 1 (revert-buffer))
and get: (20.937 1 0.109)

In contrast to test of 'grep-mode' where I get: (22.406 1 0.156)

As I use same regex for derived from compilation mode as for
custom highlighting mode I decide that bottle neck lies
in setting properties to text.

When set only 'face' property - this is fast. But when set 'message'
property it is slow as 'message' is complex structure which must
recalculated on every matching lines.

--
Best regards!


Giorgos Keramidas

unread,
Feb 17, 2011, 5:53:20 AM2/17/11
to
On Sat, 29 Jan 2011 09:02:14 -0600, Perry Smith <ped...@gmail.com> wrote:
> This thread is beginning to drift a bit... but something I wish I had
> was a way to view a file without loading all of it. I look at hugh
> trace files and I have to get out of emacs and start a shell so I can
> use more / less.
>
> The shame of it all! ;-)
>
> I don't know of such a critter. If there is one, that would be super
> cool.

If there was some way to lazy-load files, I'd be happy too.

Perry Smith

unread,
Feb 17, 2011, 8:43:54 AM2/17/11
to Giorgos Keramidas, help-gn...@gnu.org
I looked at this.  The approach I was going to take was to put into the C code
an "open", "close", "read", and "lseek" concept and that would need a new
"type" for a file descriptor.  You might as well add "write" to complete the set.
There is nothing currently like that in the C code.  I'm not sure if you want
to put this on top of open and its siblings or on top of fopen and let the C
I/O help some with the buffering.

From there, it becomes a matter of writing lisp to load in a "page" into a
buffer so it can be displayed and then a key map so the user can page
forward and backward.  For searches I couldn't come up with a nice
solution so I was just going to loop loading a page and searching the page
until the match was found.

The second generation of this could have a fixed sized cache of pages so that
small movements (like back a page) would be instant and you could even
get fancier and pre-fetch the next page.

This could grow into a hugh beast.  You would want to hook up to the
character set things so that it would detect and process all the different
characters sets (like UTF-8, etc) properly.  And then, what the hell, you
might as well plop the nifty coloring modes on top as well so that
as you page through C text, it would be colored.  In my case, I want to
plop a wireshark mode on top so that I can view network packets.

But, for my own personal case, I have way too many projects going already
so I didn't even post this to the list until just now.  I think its a concept
whose time has come but I don't have the time right now.  I'd love to
contribute to it if anyone wants to start.

Perry

Thien-Thi Nguyen

unread,
Feb 17, 2011, 9:01:54 AM2/17/11
to Perry Smith, Giorgos Keramidas, help-gn...@gnu.org
() Perry Smith <ped...@gmail.com>
() Thu, 17 Feb 2011 07:43:54 -0600

I looked at this. The approach I was going to take was to put
into the C code an "open", "close", "read", and "lseek" concept
and that would need a new "type" for a file descriptor. You
might as well add "write" to complete the set. There is
nothing currently like that in the C code.

Perhaps ‘insert-file-contents’ can be used to implement this
feature in Lisp.

Ted Zlatanov

unread,
Feb 17, 2011, 2:04:08 PM2/17/11
to
On Thu, 17 Feb 2011 15:01:54 +0100 Thien-Thi Nguyen <t...@gnuvola.org> wrote:

TN> () Perry Smith <ped...@gmail.com>
TN> () Thu, 17 Feb 2011 07:43:54 -0600

TN> I looked at this. The approach I was going to take was to put
TN> into the C code an "open", "close", "read", and "lseek" concept
TN> and that would need a new "type" for a file descriptor. You
TN> might as well add "write" to complete the set. There is
TN> nothing currently like that in the C code.

TN> Perhaps ‘insert-file-contents’ can be used to implement this
TN> feature in Lisp.

(subject adjusted to match the thread referenced below)

Please see http://thread.gmane.org/gmane.emacs.devel/108604/focus=108836
and vlf.el on the EmacsWiki.

I'd like to implement this for large (over int size) files and with
editing, but it's low on my TODO list. If someone else is feeling
frisky...

Ted

Tim X

unread,
Feb 17, 2011, 7:09:33 PM2/17/11
to
Giorgos Keramidas <kera...@ceid.upatras.gr> writes:

Many years ago I needed to load large trace files from Oracle. I just
looked and seem to have lost the code I used, but you may find the
approach useful. This was done on a Linux box and uses standard Linux
utilities.

The basic approach I used was to write some elisp functions that created
a temporary directory, applied the 'split' program to the input file,
split the input file into manageable chunks (split will/can add a
prefix/suffix to sequence/number the chunks) and put them into the temp
directory and then open the first chunk in a buffer. I could then run
dired, which would list al the chunks and open any one of those chunks
for viewing further chunks of the file.

I also used a defadvice around view-file which automated the process if
the file suffix was .trc. I always planned to clean it up and add a few
extra features (such as not splitting the file if it had already been
split before etc), but then my job changed a bit and I no longer had the
need to view such large trace files.

It worked quite well. Maybe not as clean as jus having a 'lazy file
read', but did mean I could view these large files from within emacs and
setting things up was largely automated. I do vaguely remember having to
play with split a bit before I got things just right. Later I added a
command that would use sed to replace strings in really large files,
which was useful when migrating large oracle databases and you wanted to
modify the paths in order to refresh a dev version with data form a
production system. Again, can't find that code as we now do things
differently and I've not kept it.

Tim


--
tcross (at) rapttech dot com dot au

Message has been deleted

des...@verizon.net

unread,
Feb 22, 2011, 11:27:22 AM2/22/11
to
Xah Lee <xah...@gmail.com> writes:

> On Jan 28, 10:25 am, "Drew Adams" <drew.ad...@oracle.com> wrote:
> i think the other oddity is F1 for help. Is that due to Windows
> influence?

F1 was help in ISPF (IBM mainframe) for a long time
before MSFT.

If you remember IBM and MSFT got together and created a
standard called SAA. I'd guess that's how F1 moved from IBM to
Windows.

Well despite all that, I bound F1 to compile.
Seemed like a good idea at the time.
I don't need a special help key for emacs.

Message has been deleted

Xah Lee

unread,
Feb 22, 2011, 7:21:29 PM2/22/11
to
hi Alan,

On Feb 22, 11:47 am, Alan Mackenzie <a...@muc.de> wrote:
> Hi, Xah,
>
> I see you're in combative mood again.  ;-)
>
> In comp.emacs Xah Lee <xah...@gmail.com> wrote:
>
> > in my quite painstaking research about all aspects of keyboard in the
> > past few years, i came to this one single most important principle:
> > most frequently used command needs to go to most easy to press key
> > spots.
> > all other keybinding considerations, such as ease-to-remember, logical
> > placement with similar commands, are in comparsion almost unimportant.
>
> [ ..... ]
>
> > with respect to emacs keybinding, emacs should ..... support the 7 or
> > so standard keys such as Open, Close, Copy, Paste.
>
> There seems to be a contradiction between those last two paragraphs.
> Saving buffers and finding files are relatively rare operations which
> thus shouldn't be given very easy to press key sequences like C-s and
> C-o.

you are right. If we go full re-design without regards to any
compatibility, then the Open 【Ctrl+o】, Copy 【Ctrl+c】, Save 【Ctrl+s】
etc keys won't be good choices.

Xah

Message has been deleted
Message has been deleted

Glenn Morris

unread,
Feb 22, 2011, 10:52:53 PM2/22/11
to

[Pointless cross-posting removed]

My favourite under publicized feature is the FAQ.

"Guidelines for newsgroup postings"

The newsgroup comp.emacs is for discussion of Emacs programs in general.
The newsgroup gnu.emacs.help is specifically for GNU Emacs. It therefore
makes no sense to cross-post to both groups, since only one can be
appropriate to any question.

Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted

Cthun

unread,
Feb 23, 2011, 10:13:16 AM2/23/11
to
On 23/02/2011 12:22 AM, Tim X wrote:
> Cthun<cthu...@qmail.net.au> writes:

>
>> On 22/02/2011 2:47 PM, Alan Mackenzie wrote:
>>> There seems to be a contradiction between those last two paragraphs.
>>> Saving buffers and finding files are relatively rare operations which
>>> thus shouldn't be given very easy to press key sequences like C-s and
>>> C-o.
>>
>> Where do you live where software never crashes and the electricity never goes
>> out? Most of us learn to save very frequently to limit how much we'll have to
>> do over again if the power goes out or whatever.
>
> Most of us use smart editors that auto-save regularly and free the user
> form having to do this manually all the time.

Ah, auto-save, another fruitful source of trouble.

Auto-save has two design alternatives. One, it just acts like the user
hit control-S, every some interval.

This runs into trouble if you do something drastic you later want to
undo. Sure you can fork the file, but if you forget ... and then there's
forking it "dangerously" -- first you make a big deletion, and then you
hit alt, f, a for save-as to save the drastically-changed version under
a new name, but pow, an autosave happens to occur *after* the deletion
and *before* the save-as. So much for being able to undo it...

The other option is auto-save to some temporary file, or a sequence of
numbered files. Of course if you have a power outage or something now
you have to go hunting for where the darn thing saved these. Depending,
they may even be vulnerable to being erased by an automatic temp file
cleanup script before you get to them.

Sequences of numbered files used to risk filling up the filesystem, too,
but not with text files in this day and age.

Cthun

unread,
Feb 23, 2011, 10:39:27 AM2/23/11
to
On 23/02/2011 2:07 AM, Tim X wrote:
> Cthun<cthu...@qmail.net.au> writes:
>
>> On 22/02/2011 9:33 PM, Rafe Kettler wrote:

>>> On Feb 22, 9:06 pm, Cthun<cthun_...@qmail.net.au> wrote:
>>>> On 22/02/2011 2:47 PM, Alan Mackenzie wrote:
>>>>
>>>>> There seems to be a contradiction between those last two paragraphs.
>>>>> Saving buffers and finding files are relatively rare operations which
>>>>> thus shouldn't be given very easy to press key sequences like C-s and
>>>>> C-o.
>>>>
>>>> Where do you live where software never crashes and the electricity never
>>>> goes out? Most of us learn to save very frequently to limit how much
>>>> we'll have to do over again if the power goes out or whatever.
>>>
>>> Emacs is really, really stable. My computer hasn't crashed in the past
>>> 6 months, either. The power hasn't gone out in 3 months or so here
>>> (eastern US).
>>>
>>> Save and open are relatively infrequent command relative to others
>>> (actual typing, cursor movement, etc.).
>>
>> Yeah, but for "actual typing" you only need the normal alphanumeric/symbol keys
>> (no ctrl- or alt- combos) and for cursor movement, the arrow/home/end/etc. key
>> group to the right of the main keyboard area. You've got loads and loads of
>> ctrl-letter and ctrl-number combinations still after exhausting all of these
>> more-frequent actions.
>
> Unless you are a power keyboard user, in which case, lifting your hands
> from the keyboard to the arrow keys et. al. or to use the mouse to
> access menus, is annoying and slows you down.

I will interpret the above as if you had said "unless you are weird, in
which case ..."

No-one I know finds having clearly labeled navigation keys annoying, or
prefers goofy, difficult-to-remember crap like

> C-n/C-p/C-a/C-e/C-o/C-j etc

...

>> And then not everyone lives somewhere where the power is that reliable.
>
> Then a UPS would be the right solution

You're joking.

You would recommend that everybody blow $2-300 on an extra chunk of
expensive electronics in preference to *having to type ctrl-S every
couple of minutes to protect themselves from data loss*? Are you fucking
nuts? Or maybe just stinking rich or something. Well then I've got news
for you, buddy -- not all of us, or even anywhere close to very *many*
of us, can just go rooting under the sofa cushions and come up with $300
worth of spare change anytime the whimsy strikes them to go splurge at
the local Best Buy.

"But the people have no control-S bread!"

"Then let them eat UPS cake!"

Last person to so grossly overestimate the buying power of the general
public in quite this manner got beheaded if I recall my history
correctly. :)

>> And then not everyone is daft enough not to fork their file before doing
>> something truly drastic to it, especially large elisions.
>
> Well, if their not using a version control system, especially when they
> are so readily available and cost so little, they probably get what they
> deserve.

Who said we were necessarily talking about computer programmers here?
Heck, with a decent language (i.e. a Lisp) with strong abstraction
facilities (i.e. higher-order functions, macros) the amount of code you
have to write is basically logarithmic in the complexity of the
application, rather than linear. Good programmers don't actually need to
do all that much typing, so much as thinking and designing and planning
and of course testing and debugging. Bad programmers can go hang.
Novelists, data entry clerks, and the like aren't using CVS/git/Subversion.

> Of course, if they are using a good editor, it will automatically create
> a backup file for them.

Good luck finding it, or in all likelihood even realizing that it even
created one if there's no overt indication of the existence of the
feature. (And if it's turned off by default, so much the worse.)

You'll wind up spending more time searching the filesystem for plausible
names for this backup file than you'd have spent hitting control-S,
unless it's right there next to the original with an only slightly
altered name.

> We should not restrict or constrain things to cater for a few who use
> bad workflows at the cost of benefits for the majority who do the right
> thing.

Ah, I'd recognize that overweening arrogance anywhere. You must be a
comp.emacs regular rather than from comp.lang.lisp. You emacs fanatics
really are all alike, arencha?

>> And then, of course, there's the tendency of operating systems to blue-screen,
>> laptops to overheat and hang, etc. no matter how stable the editor application
>> is.
>
> I guess that depends on your OS. I rarely see such problems - the last
> time was due to a hard disk failure and these days with RAID, even this
> is rare.

And what about the rest of us -- you know, the great plebian masses that
can't afford to splurge a couple thousand bucks on a high end RAID
system and have to make do with plain old ordinary hard drives? YOU may
be both able and willing to spend more on your disks than on your actual
computer proper but that's hardly something on which you can base sound
advice for the rest of the world.

As for choice of operating system, here in the real world you either use
Windows or you make yourself incompatible with a lot of applications and
other stuff you can't get along in the world without.

Oh, yeah, that's right, you're rich enough to splurge on UPSes and RAIDs
-- I guess you don't need to actually work for a living, handle office
documents, run work-related software that is proprietary and not ported
to anything but Windows, etc. Lucky you. Wish we were so fortunate.

> If you are forced to use such unreliable setups, then you need
> better solutions than just hitting save every few minutes.

Better solutions like what, a second antitrust suit that actually has
some real penalties in it for Microsoft if they lose? A magic wand that
will convince workplaces the world over to give up on Microsoft software
(and another that will convince game companies to universally support
unix)? Autosave features that either overwrite your files at bad times,
or make their autosaves in dusty corners of the file system where you
can't easily find them and may not even know they exist?

> There is little justification for wasting valuable single depth key
> bindings for saving and opening files.

If you're rich and can therefore afford UPSes, RAIDs, and to use a
maverick OS that shuts you out of interoperating with any nine-to-five
work stuff, perhaps.

> I also suspect that those who use unreliable systems with unreliable
> power supplies and adopt poor practices are also likely the type of
> person who doesn't bother learning key stroke short-cuts and uses the
> menu to save/open files. Using scarce single depth bindings would be
> wasted on them.

What about people that are stuck with unreliable systems, unreliable
power supplies, and unreliable operating systems and don't adopt poor
practices?

> It should also be noted that the selection of key bindings in emacs

Confirmed: emacs fanatic.

> is not as arbitrary as it may seem. There is a pattern

Yes, maximum annoyance, confusion, and incompatibility with everything
else in the known universe. Everyone who tries emacs quickly spots the
pattern. Except maybe for a few assorted nuts and fruits.

> and the single depth bindings have been worked out over many years
> based on user experience.

By the Marquis de Sade.

> While many people may find them alien because of what they have used
> before, their efficiency is very good.

Alien and efficient at driving men mad. I think that confirms what we've
always suspected: emacs is not actually a text editor at all, but rather
a diabolical incantation slightly more complex than "Ia! Ia! Cthulhu
fhtagn!" and arising from exactly the same source.

> Yes, we here reports of people who have developed RSI using emacs

That's not "RSI", that's "Help my arms are turning into tentacles and my
brain to mush -- gbl;aetisl;{}re22][d[ ... Ia! Ia!"

> but I know many (including myself) who have used it for many years who
> have never suffered any ill effects (I've used it pretty much daily
> for over 18 years).

Some of us do consider wild, staring eyes, growth of chin-tentacles, and
the shriveling of the genitalia to be "ill effects", you know.

> I often wonder if those who are affected would have found any system
> which used as many key bindings, regardless of what style, would have
> suffered the ill effects anyway

More awkward ctrl-alt-etc. chording = less RSI? On what planet? Oh yes,
of course, *that* one, from whence came he who lies dreaming.

> At the end of the day, emacs, like any other bit of software is good
> for some and not for others.

Most software is good for some humans and not for other humans, though.

> If enough find it good, it will stand the test of time, otherwise it
> will fade away and be forgotten.

Nah, it will just lie dreaming in R'lyeh, awaiting its next chance to
rise from the deeps and cause mass insanity. ;)

> At the end of the day, it isn't that important.

Except to its cultists, of course.

> The good news of course is that nobody is forced to use emacs and for
> those who do want to use it and don't like the bindings or want to bind
> save-file to a single depth binding, then they can free up the binding
> they want and use it.

If they can figure out how to remap keys before they run out of Sanity
Points and get a Nonstandard Game Over, that is.

> This is the real power of emacs - its not how it come 'out of the
> box' but the extent you can make it what you want and not be forced
> to adopt an arbitrary workflow imposed by someone else.

Except, of course, that until you figure out how and rebind all the
keys, you're forced to adopt the arbitrary workflow imposed by the
diabolical mind that crafted it while dreaming in R'lyeh.

Rafe Kettler

unread,
Feb 23, 2011, 12:15:40 PM2/23/11
to
On Feb 23, 12:19 am, Cthun <cthun_...@qmail.net.au> wrote:
> On 22/02/2011 9:33 PM, Rafe Kettler wrote:
>
>
>
> > On Feb 22, 9:06 pm, Cthun<cthun_...@qmail.net.au>  wrote:
> >> On 22/02/2011 2:47 PM, Alan Mackenzie wrote:
>
> >>> There seems to be a contradiction between those last two paragraphs.
> >>> Saving buffers and finding files are relatively rare operations which
> >>> thus shouldn't be given very easy to press key sequences like C-s and
> >>> C-o.
>
> >> Where do you live where software never crashes and the electricity never
> >> goes out? Most of us learn to save very frequently to limit how much
> >> we'll have to do over again if the power goes out or whatever.
>
> > Emacs is really, really stable. My computer hasn't crashed in the past
> > 6 months, either. The power hasn't gone out in 3 months or so here
> > (eastern US).
>
> > Save and open are relatively infrequent command relative to others
> > (actual typing, cursor movement, etc.).
>
> Yeah, but for "actual typing" you only need the normal
> alphanumeric/symbol keys (no ctrl- or alt- combos) and for cursor
> movement, the arrow/home/end/etc. key group to the right of the main
> keyboard area. You've got loads and loads of ctrl-letter and ctrl-number
> combinations still after exhausting all of these more-frequent actions.
>
> And then not everyone lives somewhere where the power is that reliable.
>
> And then not everyone is daft enough not to fork their file before doing
> something truly drastic to it, especially large elisions.
>
> And then, of course, there's the tendency of operating systems to
> blue-screen, laptops to overheat and hang, etc. no matter how stable the
> editor application is.

You must be a Windows user. You must also not be an Emacs power user,
because you think it's acceptable to use the arrow keys as cursors. If
you don't, please use C-b, C-f, C-p, and C-n in place of the arrow
keys. It dramatically improves speed.

Rafe

Eli Zaretskii

unread,
Feb 23, 2011, 1:06:36 PM2/23/11
to help-gn...@gnu.org
> From: Cthun <cthu...@qmail.net.au>
> Date: Wed, 23 Feb 2011 10:13:16 -0500

>
> Ah, auto-save, another fruitful source of trouble.
>
> Auto-save has two design alternatives. One, it just acts like the user
> hit control-S, every some interval.
>
> This runs into trouble if you do something drastic you later want to
> undo. Sure you can fork the file, but if you forget ... and then there's
> forking it "dangerously" -- first you make a big deletion, and then you
> hit alt, f, a for save-as to save the drastically-changed version under
> a new name, but pow, an autosave happens to occur *after* the deletion
> and *before* the save-as. So much for being able to undo it...

Please read the Emacs manual: when you make a drastic change, Emacs
disables auto-save (and tell you about that), until you re-enable it.

> The other option is auto-save to some temporary file, or a sequence of
> numbered files. Of course if you have a power outage or something now
> you have to go hunting for where the darn thing saved these. Depending,
> they may even be vulnerable to being erased by an automatic temp file
> cleanup script before you get to them.

Please read the manual: Emacs places the auto-save files in the same
directory where the original file lives, so it won't be erased by
cleanup jobs. Emacs also automatically finds the auto-save file when
you visit the original file again, and suggests to recover the edits
from there.

Ilya Zakharevich

unread,
Feb 23, 2011, 1:33:37 PM2/23/11
to
On 2011-02-23, Rafe Kettler <rafe.k...@gmail.com> wrote:
>> And then, of course, there's the tendency of operating systems to
>> blue-screen, laptops to overheat and hang, etc. no matter how stable the
>> editor application is.
>
> You must be a Windows user. You must also not be an Emacs power user,
> because you think it's acceptable to use the arrow keys as cursors.

LOL!

> If you don't, please use C-b, C-f, C-p, and C-n in place of the
> arrow keys. It dramatically improves speed.

But my driving speed is most of the time limited by applicable laws.
Even if using these keys would improve speed of my car, would not I
get more tickets?

Puzzled,
Ilya

Deniz Dogan

unread,
Feb 23, 2011, 1:47:13 PM2/23/11
to Ilya Zakharevich, help-gn...@gnu.org
2011/2/23 Ilya Zakharevich <nospam...@ilyaz.org>:

What are you talking about? By your logic we should all stop using
computers and go back to typewriters or pen and paper.

Most Emacs power users cringe at the thought of using the arrow keys
instead of C-f and its siblings. I too was skeptical before I sat
down and forced myself to learn it, but in the end it is worth it.
Learning it is not really difficult or time-consuming either.

Jason Earl

unread,
Feb 23, 2011, 2:22:58 PM2/23/11
to
On Wed, Feb 23 2011, Cthun wrote:

> On 23/02/2011 12:22 AM, Tim X wrote:
>> Cthun<cthu...@qmail.net.au> writes:
>>
>>> On 22/02/2011 2:47 PM, Alan Mackenzie wrote:
>>>> There seems to be a contradiction between those last two
>>>> paragraphs. Saving buffers and finding files are relatively rare
>>>> operations which thus shouldn't be given very easy to press key
>>>> sequences like C-s and C-o.
>>>
>>> Where do you live where software never crashes and the electricity
>>> never goes out? Most of us learn to save very frequently to limit
>>> how much we'll have to do over again if the power goes out or
>>> whatever.
>>
>> Most of us use smart editors that auto-save regularly and free the
>> user form having to do this manually all the time.
>
> Ah, auto-save, another fruitful source of trouble.

I don't think that I have ever had problems with auto save. Especially
with the sort of plain text documents that Emacs deals with.

> Auto-save has two design alternatives. One, it just acts like the user
> hit control-S, every some interval.

This is what I set up. In fact, I have an entire directory (under
~/.emacs.d/backup) full of old save files. I don't think that I have
ever actually fished a file out of there, Emacs' recover-session stuff
has always been more than good enough, but it is nice to know that they
exist.

> This runs into trouble if you do something drastic you later want to
> undo.

Actually, Emacs warns you before it makes drastic changes to an autosave
file. This at least gives you the opportunity to do something about it.

> Sure you can fork the file, but if you forget ... and then there's
> forking it "dangerously" -- first you make a big deletion, and then
> you hit alt, f, a for save-as to save the drastically-changed version
> under a new name, but pow, an autosave happens to occur *after* the
> deletion and *before* the save-as. So much for being able to undo
> it...

The solution, of course, is to manually save *before* the fork. I real
life I don't think that this is much of a problem, especially with Emacs
which has infinite undo and which tends to be a very stable piece of
software.

What's more, Emacs is flexible enough that you can easily set up
whatever sort of auto-save functionality that you think you want. If
you feel like your data is so critical that you want it saved in a
version control system and pushed off to a new machine every 5 minutes
Emacs can do that. It has an auto-save-hook that you can add code to,
and it has all sorts of built in machinery for committing to version
control, saving files on remote machines, etc.

> The other option is auto-save to some temporary file, or a sequence of
> numbered files. Of course if you have a power outage or something now
> you have to go hunting for where the darn thing saved
> these. Depending, they may even be vulnerable to being erased by an
> automatic temp file cleanup script before you get to them.

Emacs does not (by default) save auto-save files somewhere where they
are likely to get cleaned up. I suppose you could set up your system in
such a way as to jeopardize these files, but you can not hardly blame
Emacs for that.

Another alternative, of course, is to simply save the file whenever you
feel you have something worth saving. C-x C-s is not exactly hard to
type. C-x v v would probably even commit the changes to version
control.

> Sequences of numbered files used to risk filling up the filesystem,
> too, but not with text files in this day and age.

On the bright side Emacs can be made to do whatever makes you the
happiest. Very few other programs have anywhere near that sort of
flexibility. For most folks, however, the defaults are what they want.
I don't like having the auto-save files clutter up my directories, so I
customized a single variable to save them in a central location. That
seems easy enough to me.

Jason

Óscar Fuentes

unread,
Feb 23, 2011, 2:50:51 PM2/23/11
to help-gn...@gnu.org
Cthun <cthu...@qmail.net.au> writes:

> On 23/02/2011 2:07 AM, Tim X wrote:
>> Cthun<cthu...@qmail.net.au> writes:

[snip]

>>> And then not everyone lives somewhere where the power is that reliable.
>>
>> Then a UPS would be the right solution
>
> You're joking.
>
> You would recommend that everybody blow $2-300 on an extra chunk of
> expensive electronics

If you have frequent power outages, surges, etc, a UPS is a must-have,
not only for not losing your work when the computer suddenly switchs
off, but for protecting the computer equipment. Here where I live, those
300$ (or, in my case, 800 euros for a reliable on-line UPS) amortizes in
just one winter.

> in preference to *having to type ctrl-S every
> couple of minutes to protect themselves from data loss*?

If your editor has no auto-save&recovery, please consider using Emacs,
which eliminates the distraction and anxiety of having to remember about
pressing Ctrl-s from time to time.

[snip]


Cthun

unread,
Feb 23, 2011, 5:07:12 PM2/23/11
to
On 23/02/2011 12:15 PM, Rafe Kettler wrote:
> You must be a Windows user. You must also not be an Emacs power user

If by that you mean "you must be a normal, sane human being", then you
are correct. :)

> because you think it's acceptable to use the arrow keys as cursors.

It *is* what they're there for.

> If you don't, please use C-b, C-f, C-p, and C-n in place of the arrow
> keys. It dramatically improves speed.

Hardly likely. For one thing those require extra keys held down, and for
another, which one of them corresponds to which arrow? On my keyboard at
least those are arranged like this:

.........p
...f.....
....bn.

which doesn't come anywhere close to forming a cross-shape or a T-shape.
Furthermore, the letters themselves are not obviously meaningful (e.g.
u, d, l, and r). So, they're not mnemonic. More time will be spent
fumbling with them either trying to remember which one does what or
using trial-and-error to re-ascertain which one does what than will be
spent actually navigating.

Those key bindings are designed for things with tentacles and
fundamentally alien minds. And non-qwerty keyboards. :)

Cthun

unread,
Feb 23, 2011, 5:08:44 PM2/23/11
to

Good point. Most typing tasks are not just vast quantities of mindless
data entry; the limit to speed comes from something else, like "how fast
can I think up the stuff I'm typing in" or similarly, anyway.

And then there's the "get more typos" factor. Speed and accuracy tend to
be inversely correlated no matter what the motor skill.

Cthun

unread,
Feb 23, 2011, 5:18:49 PM2/23/11
to
On 23/02/2011 2:22 PM, Jason Earl wrote:
> On Wed, Feb 23 2011, Cthun wrote:
>> This runs into trouble if you do something drastic you later want to
>> undo.
>
> Actually, Emacs warns you before it makes drastic changes to an autosave
> file. This at least gives you the opportunity to do something about it.

Oh, wonderful.

Do you know what I'd do if I was in the middle of typing some stuff into
a text editor after just having deleted a bunch of stuff and then
suddenly a box popped up saying something about autosaving and drastic
changes and yadda yadda yadda but I didn't have time to read it before
one of my enter keypresses (intended for the actual document I was
typing into when the box interrupted me) triggers one of the dialog's
buttons (which?) and it disappears again (and does who knows what to my
hard drive?).

I'd delete that editor and go get a new one, that's what. :)

> The solution, of course, is to manually save *before* the fork.

Yes, but the reality is that people will sometimes forget to do so, or
in that order.

> I real life I don't think that this is much of a problem, especially
> with Emacs which has infinite undo

Infinite undo? On what planet? When I experimented with it, back in
college, I found the undo to just toggle undo/redo like Windows
Notepad's. (I ended up experimenting also with LSD and mescaline and
decided on none of the above.)

> What's more, Emacs is flexible enough that you can easily set up
> whatever sort of auto-save functionality that you think you want.

If you're a computer programmer with time to spare reprogramming the
editor instead of actually doing your job, perhaps.

> Emacs can do that. It has an auto-save-hook that you can add code to

and ten million ways to subtly or drastically-but-irrecoverably fuck
things up if you make some subtle mistake doing so, no doubt.

Thanks, but no thanks.

> Another alternative, of course, is to simply save the file whenever you
> feel you have something worth saving.

Well, there you go, then. That's exactly what I was originally
advocating! So, you've come around to agreeing with me at last.

Ah, progress ...

>> Sequences of numbered files used to risk filling up the filesystem,
>> too, but not with text files in this day and age.
>
> On the bright side Emacs can be made to do whatever makes you the
> happiest.

Can it be made to cut itself, scream like a thing tortured, and then die? ;)

> Very few other programs have anywhere near that sort of flexibility.

If I want that much flexibility I'll look at that Russian mail-order
catalog. There *is* something to be said for structure and stability in
fundamental, daily-use tools. And standards-adherence.

> For most folks, however, the defaults are what they want.

Wait a minute. I thought you just said that the Emacs defaults are what
most people want. But that's clearly impossible, so I can only presume
that your post got garbled in transit. Care to repost whatever you'd
said at this point?

Tim X

unread,
Feb 23, 2011, 5:57:07 PM2/23/11
to
Cthun <cthu...@qmail.net.au> writes:

I raise the point that there are not as many keys 'free' as you claim
because some people who I referred to as power users, prefer to use
short-cut keys over the mouse, cursor keys etc and your response is to
try and totally discount such users by claiming they are weird just
because they are different from what you know. Let me guess, in your
little world of identical clones, your never wrong are you?

>
> No-one I know finds having clearly labeled navigation keys annoying, or prefers
> goofy, difficult-to-remember crap like
>
>> C-n/C-p/C-a/C-e/C-o/C-j etc
>

Your arguements are weak because they lack any real facts and it is
obvious you are just arguing for the sake of it. Anyone in doubt can
just look at your resonses to the numerous posts regarding auto-save and
the weak counter arguements you presented which don't even fit with the
facts.

>
>>> And then not everyone lives somewhere where the power is that reliable.
>>
>> Then a UPS would be the right solution
>
> You're joking.
>
> You would recommend that everybody blow $2-300 on an extra chunk of expensive
> electronics in preference to *having to type ctrl-S every couple of minutes to
> protect themselves from data loss*? Are you fucking nuts? Or maybe just
> stinking rich or something. Well then I've got news for you, buddy -- not all
> of us, or even anywhere close to very *many* of us, can just go rooting under
> the sofa cushions and come up with $300 worth of spare change anytime the
> whimsy strikes them to go splurge at the local Best Buy.
>

If you have unreliable power supplies and don't have a UPS then your an
idiot. Unreliable power will not just cause loss of data, it will cause
hardware damage. Furthermore, you run the risk of your saved file being
currupted as a result of the power outage anyway, making your frequent
saves pontless.

You also over-estimate the cost of a UPS. You can pick up small UPS
systems for just over $150, which is little compared to the cost of
replacing a system damaged from power problems. If your data is not
worth that much investment, it obviously isn't that valuable in any
case.


> "But the people have no control-S bread!"
>
> "Then let them eat UPS cake!"
>
> Last person to so grossly overestimate the buying power of the general public
> in quite this manner got beheaded if I recall my history correctly. :)
>
>>> And then not everyone is daft enough not to fork their file before doing
>>> something truly drastic to it, especially large elisions.
>>
>> Well, if their not using a version control system, especially when they
>> are so readily available and cost so little, they probably get what they
>> deserve.
>
> Who said we were necessarily talking about computer programmers here? Heck,
> with a decent language (i.e. a Lisp) with strong abstraction facilities (i.e.
> higher-order functions, macros) the amount of code you have to write is
> basically logarithmic in the complexity of the application, rather than linear.
> Good programmers don't actually need to do all that much typing, so much as
> thinking and designing and planning and of course testing and debugging. Bad
> programmers can go hang. Novelists, data entry clerks, and the like aren't
> using CVS/git/Subversion.
>

Version control systems don't need to be cvs/svn/git/whatever. Corporate
record management systems are just glorified version control systems.
Web content management systems are also version control systems - even
database backups are a form of version control. Any business that has
not addressed issues of data protection is doomed. Likewise, anyone who
relies on remembering to save regularly in order to protect their data
is doomed.

>> Of course, if they are using a good editor, it will automatically create
>> a backup file for them.
>
> Good luck finding it, or in all likelihood even realizing that it even created
> one if there's no overt indication of the existence of the feature. (And if
> it's turned off by default, so much the worse.)
>

Its very obvious you know nothing about emacs and are attempting to talk
with authority when you have little understanding of the facts. If you
have used emacs and had the unfortunate situation of a power outage,
crash etc, you would be more familiar with how its auto-save feature
works and would not have written the above garbage.

> You'll wind up spending more time searching the filesystem for plausible names
> for this backup file than you'd have spent hitting control-S, unless it's right
> there next to the original with an only slightly altered name.
>

which it is by default.

>> We should not restrict or constrain things to cater for a few who use
>> bad workflows at the cost of benefits for the majority who do the right
>> thing.
>
> Ah, I'd recognize that overweening arrogance anywhere. You must be a comp.emacs
> regular rather than from comp.lang.lisp. You emacs fanatics really are all
> alike, arencha?
>

I'll try to be less arrogant if you try to be a bit smarter.

>>> And then, of course, there's the tendency of operating systems to blue-screen,
>>> laptops to overheat and hang, etc. no matter how stable the editor application
>>> is.
>>
>> I guess that depends on your OS. I rarely see such problems - the last
>> time was due to a hard disk failure and these days with RAID, even this
>> is rare.
>
> And what about the rest of us -- you know, the great plebian masses that can't
> afford to splurge a couple thousand bucks on a high end RAID system and have to
> make do with plain old ordinary hard drives?
>
> YOU may be both able and willing
> to spend more on your disks than on your actual computer proper but that's
> hardly something on which you can base sound advice for the rest of the world.
>

You must be living in the dark ages. My last two computers, commodity
hardware purchased from the local computer shop came with RAID built-in.
All I had to spend was an additional $200 for an extra hard drive. This
isn't high end stuff anymore - it is a standard feature of modern
systems.

> As for choice of operating system, here in the real world you either use
> Windows or you make yourself incompatible with a lot of applications and other
> stuff you can't get along in the world without.
>
> Oh, yeah, that's right, you're rich enough to splurge on UPSes and RAIDs -- I
> guess you don't need to actually work for a living, handle office documents,
> run work-related software that is proprietary and not ported to anything but
> Windows, etc. Lucky you. Wish we were so fortunate.
>

Ah, yes, the poor old victim mentality.

As with much of your other responses, your arguements are outdated or
just completely wrong. I use windows every day at work. I've not had a
crash or a blue screen in years. Believe it or not, Windows has improved
a lot from where it use to be. You have no idea about the modern work
environment and the level of awareness regarding data protection,
corporate records management, etc. You have little grasp regarding
modern storage systems or even the level of protection built into basic
commodity hardware or even the vast range of low cost solutions out
there and you totally underestimate the sophistication and awareness of
most average users. Your insistance on the need for end users to have
save file on a single depth key bindings because it is a frequent
operation is over stated and outdated.

>> If you are forced to use such unreliable setups, then you need
>> better solutions than just hitting save every few minutes.
>
> Better solutions like what, a second antitrust suit that actually has some real
> penalties in it for Microsoft if they lose? A magic wand that will convince
> workplaces the world over to give up on Microsoft software (and another that
> will convince game companies to universally support unix)? Autosave features
> that either overwrite your files at bad times, or make their autosaves in dusty
> corners of the file system where you can't easily find them and may not even
> know they exist?
>
>> There is little justification for wasting valuable single depth key
>> bindings for saving and opening files.
>
> If you're rich and can therefore afford UPSes, RAIDs, and to use a maverick OS
> that shuts you out of interoperating with any nine-to-five work stuff, perhaps.
>

No, there are lots of solutions, you just have to decide to not be a
victim and look for better answers.

>> I also suspect that those who use unreliable systems with unreliable
>> power supplies and adopt poor practices are also likely the type of
>> person who doesn't bother learning key stroke short-cuts and uses the
>> menu to save/open files. Using scarce single depth bindings would be
>> wasted on them.
>
> What about people that are stuck with unreliable systems, unreliable power
> supplies, and unreliable operating systems and don't adopt poor practices?
>

Ignoring the fact that anyone in that situation is not going to find
frequent saving much help anyway and ignoring the fact we have not taken
away their ability to save - in fact, have only argued the existing
configuration is fine and ignoring the fact emacs' auto-save works well
and without all the ficticious counter-arguements you presented, we are
left with a basic contradiction in your statement. If they don't adopt
poor practices, they will have a far better solution than using manually
controlled regular saving of their data. In reality, if they have an
unreliable system, unreliable power supply and unreliable operating
systems and they adopt good practices, they would be addressing the
cause of the problem and not focusing on the symptom.

>> It should also be noted that the selection of key bindings in emacs
>
> Confirmed: emacs fanatic.
>
>> is not as arbitrary as it may seem. There is a pattern
>
> Yes, maximum annoyance, confusion, and incompatibility with everything else in
> the known universe. Everyone who tries emacs quickly spots the pattern. Except
> maybe for a few assorted nuts and fruits.
>

If you don't like it, then why are you here? Nobody is forcing you to
use it and in fact, many would likely ask you not to.

>> and the single depth bindings have been worked out over many years
>> based on user experience.
>
> By the Marquis de Sade.
>
>> While many people may find them alien because of what they have used
>> before, their efficiency is very good.
>
> Alien and efficient at driving men mad. I think that confirms what we've always
> suspected: emacs is not actually a text editor at all, but rather a diabolical
> incantation slightly more complex than "Ia! Ia! Cthulhu fhtagn!" and arising
> from exactly the same source.
>

and again, if you don't like it, why post to an emacs newsgroup?


>> Yes, we here reports of people who have developed RSI using emacs
>
> That's not "RSI", that's "Help my arms are turning into tentacles and my brain
> to mush -- gbl;aetisl;{}re22][d[ ... Ia! Ia!"
>
>> but I know many (including myself) who have used it for many years who
>> have never suffered any ill effects (I've used it pretty much daily
>> for over 18 years).
>
> Some of us do consider wild, staring eyes, growth of chin-tentacles, and the
> shriveling of the genitalia to be "ill effects", you know.
>
>> I often wonder if those who are affected would have found any system
>> which used as many key bindings, regardless of what style, would have
>> suffered the ill effects anyway
>
> More awkward ctrl-alt-etc. chording = less RSI? On what planet? Oh yes, of
> course, *that* one, from whence came he who lies dreaming.

and yet, for each person you can point to who has suffered RSI after
using emacs, I can point to one who has used it longer that has not.

It is obvious you have an issue with the emacs' keybinding defaults and
it would seem the software as a whole and it now seems clear you are
just being a troll and arguing for the sake o it. I will not be
responding further.

Tim

--
tcross (at) rapttech dot com dot au

Pascal J. Bourguignon

unread,
Feb 23, 2011, 6:46:56 PM2/23/11
to
Cthun <cthu...@qmail.net.au> writes:

> On 23/02/2011 12:15 PM, Rafe Kettler wrote:
>> You must be a Windows user. You must also not be an Emacs power user
>
> If by that you mean "you must be a normal, sane human being", then you
> are correct. :)


For Heinlein, a normal, sane human being had to be able to compute an
integral, otherwise Heinlein didn't consider that he should be allowed
to vote.


You'll excuse us, but when you post on gnu.emacs.help, comp.emacs, and
comp.lang.lisp, it is expected that a normal, sane human being be
defined as being able to use emacs and program in emacs lisp.

> Hardly likely. For one thing those require extra keys held down, and
> for another, which one of them corresponds to which arrow? On my
> keyboard at least those are arranged like this:
>
> .........p
> ...f.....
> ....bn.

This doesn't matter, because emacs users don't work at the low level.
You can expect an amobea to be able to direct itself up right down and
left. But when we edit with emacs, we use higher level notions, such as
(n)ext, (p)revious, (f)orward, (b)ackward, x {character, line,
paragraph, sexp}. We don't edit characters, we edit structured sources
symbolically.

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Jason Earl

unread,
Feb 23, 2011, 6:54:29 PM2/23/11
to
On Wed, Feb 23 2011, Cthun wrote:

> On 23/02/2011 2:22 PM, Jason Earl wrote:
>> On Wed, Feb 23 2011, Cthun wrote:
>>> This runs into trouble if you do something drastic you later want to
>>> undo.
>>
>> Actually, Emacs warns you before it makes drastic changes to an autosave
>> file. This at least gives you the opportunity to do something about it.
>
> Oh, wonderful.
>
> Do you know what I'd do if I was in the middle of typing some stuff
> into a text editor after just having deleted a bunch of stuff and then
> suddenly a box popped up saying something about autosaving and drastic
> changes and yadda yadda yadda but I didn't have time to read it before
> one of my enter keypresses (intended for the actual document I was
> typing into when the box interrupted me) triggers one of the dialog's
> buttons (which?) and it disappears again (and does who knows what to
> my hard drive?).
>
> I'd delete that editor and go get a new one, that's what. :)

So would I, but, of course, that's not what Emacs does. It just turns
off auto-save and warns you in the mini-buffer. Here's the message:

Buffer foo.txt has shrunk a lot; auto save disabled in that buffer
until next real save

Emacs' auto-save is triggered by default on idle, so it should never
happen while you are typing. However, even if it does, it is not going
to get in your way.

And, like all things Emacs, if you do not like the default you can
change it easily.

>> The solution, of course, is to manually save *before* the fork.
>
> Yes, but the reality is that people will sometimes forget to do so, or
> in that order.

It would seem to me that you would basically have to be the sort of
person that *relies* on the auto-save feature to do things in any other
order. If I am manually going fork a file then it seems like I would
want to make sure that I forked from a known good spot.

I used to work on a help desk and my experience says that most people
don't even know that their editor has an auto-save (or how to get the
auto-save files it creates) until something tragic happens. They
certainly don't expect their editor to magically save the correct state
of a file that they didn't manually save.

>> I real life I don't think that this is much of a problem, especially
>> with Emacs which has infinite undo
>
> Infinite undo? On what planet? When I experimented with it, back in
> college, I found the undo to just toggle undo/redo like Windows
> Notepad's. (I ended up experimenting also with LSD and mescaline and
> decided on none of the above.)

I thought it was infinite undo, but according to the manual the default
limit is 12,000,000 bytes. Needless to say, I have never actually ran
out of undo information.

>> What's more, Emacs is flexible enough that you can easily set up
>> whatever sort of auto-save functionality that you think you want.
>
> If you're a computer programmer with time to spare reprogramming the
> editor instead of actually doing your job, perhaps.

I'm just saying that, if you care about auto-save as much as you seem to
care about auto-save, that Emacs gives you options that other tools do
not. Personally, other than changing where Emacs saves its auto-save
files I just stick with the defaults.

I personally think that Emacs' superior auto-save features would be a
strange reason for choosing Emacs, but who am I to judge.

>> Emacs can do that. It has an auto-save-hook that you can add code to
>
> and ten million ways to subtly or drastically-but-irrecoverably fuck
> things up if you make some subtle mistake doing so, no doubt.
>
> Thanks, but no thanks.

Obviously any time you are writing code you have the opportunity to code
something that doesn't work. On the other hand, computers are far less
likely to "forget" a step than you or I are. Automation is generally a
good thing.

>> Another alternative, of course, is to simply save the file whenever
>> you feel you have something worth saving.
>
> Well, there you go, then. That's exactly what I was originally
> advocating! So, you've come around to agreeing with me at last.
>
> Ah, progress ...

>>> Sequences of numbered files used to risk filling up the filesystem,
>>> too, but not with text files in this day and age.
>>
>> On the bright side Emacs can be made to do whatever makes you the
>> happiest.
>
> Can it be made to cut itself, scream like a thing tortured, and then
> die? ;)

That seems like an odd thing to want from a text editor, but yes, you
can teach emacs to do that. I even tested it.

--8<---------------cut here---------------start------------->8---
(defun die! ()
(save-buffers-kill-emacs t))

(defun scream ()
(message "Arrgggh!"))

(defun cut-yourself ()
(interactive)
(message "I am bleeding")
(sleep-for 5)
(scream)
(sleep-for 5)
(die!))
--8<---------------cut here---------------end--------------->8---

>> Very few other programs have anywhere near that sort of flexibility.
>
> If I want that much flexibility I'll look at that Russian mail-order
> catalog. There *is* something to be said for structure and stability
> in fundamental, daily-use tools. And standards-adherence.

Emacs has been adhering to the same standards almost as long as I have
been alive.

>> For most folks, however, the defaults are what they want.
>
> Wait a minute. I thought you just said that the Emacs defaults are
> what most people want. But that's clearly impossible, so I can only
> presume that your post got garbled in transit. Care to repost whatever
> you'd said at this point?

Emacs' defaults for auto-save are what most people want.

trebo...@yahoo.es

unread,
Feb 23, 2011, 7:04:56 PM2/23/11
to help-gn...@gnu.org

Please, oohhh please.
This is "help-gnu-emacs".
It's enough.
There are a lot of stupid post sites.

Trebol.

Cthun

unread,
Feb 23, 2011, 10:48:54 PM2/23/11
to
On 23/02/2011 5:57 PM, Tim X wrote:
> Cthun<cthu...@qmail.net.au> writes:
>> On 23/02/2011 2:07 AM, Tim X wrote:
>>> Unless you are a power keyboard user, in which case, lifting your hands
>>> from the keyboard to the arrow keys et. al. or to use the mouse to
>>> access menus, is annoying and slows you down.
>>
>> I will interpret the above as if you had said "unless you are weird, in which
>> case ..."
>
> I raise the point that there are not as many keys 'free' as you claim
> because some people who I referred to as power users, prefer to use
> short-cut keys over the mouse, cursor keys etc

A tiny and very strange minority of users, X. Even most people I'd
characterize as "power users" do not do such strange things, X.

>> No-one I know finds having clearly labeled navigation keys annoying, or prefers
>> goofy, difficult-to-remember crap like
>>
>>> C-n/C-p/C-a/C-e/C-o/C-j etc
>
> Your arguements are weak because they lack any real facts

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

Interesting that as soon as I bring up a strong piece of statistical
evidence you promptly accuse me of "lacking facts", X.

> and it is obvious you are just arguing for the sake of it.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

> Anyone in doubt can just look at your resonses to the numerous posts
> regarding auto-save

Classic pontification.

> and the weak counter arguements you presented which don't even fit with the
> facts.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

>> You would recommend that everybody blow $2-300 on an extra chunk of expensive
>> electronics in preference to *having to type ctrl-S every couple of minutes to
>> protect themselves from data loss*? Are you fucking nuts? Or maybe just
>> stinking rich or something. Well then I've got news for you, buddy -- not all
>> of us, or even anywhere close to very *many* of us, can just go rooting under
>> the sofa cushions and come up with $300 worth of spare change anytime the
>> whimsy strikes them to go splurge at the local Best Buy.
>
> If you have unreliable power supplies and don't have a UPS then your an
> idiot.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

> Unreliable power will not just cause loss of data, it will cause
> hardware damage.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

Power that sometimes cuts out does not cause damage to well-designed
hardware, X. Surges can cause damage, but are rarer. Surge suppressors
are also available much more cheaply than UPS units, X.

> Furthermore, you run the risk of your saved file being currupted as
> a result of the power outage anyway, making your frequent saves
> pontless.

Only if the program is poorly designed, X. Smart developers make the
save function save to a temporary file, then rename the temporary file
over the old one, so if the power cuts out before the rename the
previous version is still intact and if it cuts out after the subsequent
one is intact. The file with the normal name is never in a half-written,
truncated, or otherwise corrupt state, X.

> You also over-estimate the cost of a UPS.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

> You can pick up small UPS systems for just over $150

Hardly an improvement, X. It would have to be an order of magnitude
cheaper than $300 to be an option for most people, X, not just a factor
of two, and furthermore the cheapest units also don't provide any
significant battery life. In a typical power outage they will only
postpone the inevitable, X.

> which is little compared to the cost of replacing a system damaged
> from power problems.

I have had numerous power failures, X, but have yet to see a system
damaged from power problems. You overestimate the frequency with which
that occurs. Perhaps where you come from the power quality is poor and
surges are frequent, X; but this is not true elsewhere.

>> Who said we were necessarily talking about computer programmers here? Heck,
>> with a decent language (i.e. a Lisp) with strong abstraction facilities (i.e.
>> higher-order functions, macros) the amount of code you have to write is
>> basically logarithmic in the complexity of the application, rather than linear.
>> Good programmers don't actually need to do all that much typing, so much as
>> thinking and designing and planning and of course testing and debugging. Bad
>> programmers can go hang. Novelists, data entry clerks, and the like aren't
>> using CVS/git/Subversion.
>>
>
> Version control systems don't need to be cvs/svn/git/whatever.

The exact one chosen is not important, X. Only the fact that not
everyone using a text editor is using it to develop software, X. For
that matter, not everyone using it to develop software uses it solely
for that, X. And not everyone using it to develop software is developing
all of it for big, established companies and/or open source projects
that have repositories, X. Sometimes it's for personal use, learning, or
whatever, X.

> anyone who relies on remembering to save regularly in order to protect
> their data is doomed.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

>>> Of course, if they are using a good editor, it will automatically create
>>> a backup file for them.
>>
>> Good luck finding it, or in all likelihood even realizing that it even created
>> one if there's no overt indication of the existence of the feature. (And if
>> it's turned off by default, so much the worse.)
>
> Its very obvious you know nothing about emacs

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X? Besides, we were not discussing emacs specifically at that
point, X, but a generic "good editor" with some backup functionality.

> and are attempting to talk with authority when you have little understanding
> of the facts.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

> If you have used emacs and had the unfortunate situation of a power outage,
> crash etc, you would be more familiar with how its auto-save feature
> works

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X? For most emacs features, you can only become familiar with
how that feature works, or even with the fact that it exists, from being
shown the ropes by a mentor, X; mere need does not suffice, X, because
emacs does not provide a way to browse through its features and options
like a modern application does, X.

> and would not have written the above garbage.

What does your classic erroneous presupposition have to do with Lisp, X?

>> You'll wind up spending more time searching the filesystem for plausible names
>> for this backup file than you'd have spent hitting control-S, unless it's right
>> there next to the original with an only slightly altered name.
>
> which it is by default.

In what editor(s), X? In the context of the above paragraph no single
specific editor had been being discussed.

>>> We should not restrict or constrain things to cater for a few who use
>>> bad workflows at the cost of benefits for the majority who do the right
>>> thing.
>>
>> Ah, I'd recognize that overweening arrogance anywhere. You must be a comp.emacs
>> regular rather than from comp.lang.lisp. You emacs fanatics really are all
>> alike, arencha?
>
> I'll try to be less arrogant if you try to be a bit smarter.

What does your classic erroneous presupposition have to do with Lisp, X?

>> YOU may be both able and willing
>> to spend more on your disks than on your actual computer proper but that's
>> hardly something on which you can base sound advice for the rest of the world.
>
> You must be living in the dark ages.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

> My last two computers, commodity hardware purchased from the local computer
> shop came with RAID built-in.

Most of us do not have access to such an unusual computer shop, X. Most
computer shops do not sell built-in RAID, X.

> This isn't high end stuff anymore - it is a standard feature of modern
> systems.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X? I dare you to browse the shelves of any major computer
retailer, X -- Best Buy, Circuit City, Future Shop, Office Depot, or
etc. -- and try to find RAID as even a rare and expensive extra, X, let
alone a "standard feature" on a line of reasonably-priced desktop
computers, X.

>> Oh, yeah, that's right, you're rich enough to splurge on UPSes and RAIDs -- I
>> guess you don't need to actually work for a living, handle office documents,
>> run work-related software that is proprietary and not ported to anything but
>> Windows, etc. Lucky you. Wish we were so fortunate.
>
> Ah, yes, the poor old victim mentality.

What does your poor old victim mentality have to do with Lisp, X?

> As with much of your other responses, your arguements are outdated or
> just completely wrong.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

> I use windows every day at work.

What does that have to do with Lisp, X?

> I've not had a crash or a blue screen in years.

Classic contradiction.

> Believe it or not, Windows has improved a lot from where it use to be.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

> You have no idea about the modern work environment and the level of
> awareness regarding data protection, corporate records management, etc.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

> You have little grasp regarding modern storage systems or even the
> level of protection built into basic commodity hardware or even the
> vast range of low cost solutions out there

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

> and you totally underestimate the sophistication and awareness of
> most average users.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

> Your insistance on the need for end users to have save file on a
> single depth key bindings because it is a frequent operation is
> over stated and outdated.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

>>> There is little justification for wasting valuable single depth key
>>> bindings for saving and opening files.
>>
>> If you're rich and can therefore afford UPSes, RAIDs, and to use a maverick OS
>> that shuts you out of interoperating with any nine-to-five work stuff, perhaps.
>
> No, there are lots of solutions, you just have to decide to not be a
> victim and look for better answers.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

>>> I also suspect that those who use unreliable systems with unreliable
>>> power supplies and adopt poor practices are also likely the type of
>>> person who doesn't bother learning key stroke short-cuts and uses the
>>> menu to save/open files. Using scarce single depth bindings would be
>>> wasted on them.
>>
>> What about people that are stuck with unreliable systems, unreliable power
>> supplies, and unreliable operating systems and don't adopt poor practices?
>
> Ignoring the fact that anyone in that situation is not going to find
> frequent saving much help anyway

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

> and ignoring the fact we have not taken away their ability to save

Hiding it where nobody will ever find it without expert help effectively
takes away the ability, X.

> in fact, have only argued the existing configuration is fine and
> ignoring the fact emacs' auto-save works well

What does your classic erroneous presupposition have to do with Lisp, X?

> and without all the ficticious counter-arguements you presented

What does your classic erroneous presupposition have to do with Lisp, X?

> we are left with a basic contradiction in your statement.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

> If they don't adopt poor practices, they will have a far better solution
> than using manually controlled regular saving of their data.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

> In reality, if they have an unreliable system, unreliable power supply
> and unreliable operating systems and they adopt good practices, they
> would be addressing the cause of the problem and not focusing on the
> symptom.

Only if they won the lottery, X.

>>> is not as arbitrary as it may seem. There is a pattern
>>
>> Yes, maximum annoyance, confusion, and incompatibility with everything else in
>> the known universe. Everyone who tries emacs quickly spots the pattern. Except
>> maybe for a few assorted nuts and fruits.
>
> If you don't like it, then why are you here?

What does your question have to do with Lisp, X?

> Nobody is forcing you to use it

How fortunate, since I refuse to touch emacs on general principles, X.

> and in fact, many would likely ask you not to.

How odd. Why should they care what editor I use, X?

>>> While many people may find them alien because of what they have used
>>> before, their efficiency is very good.
>>
>> Alien and efficient at driving men mad. I think that confirms what we've always
>> suspected: emacs is not actually a text editor at all, but rather a diabolical
>> incantation slightly more complex than "Ia! Ia! Cthulhu fhtagn!" and arising
>> from exactly the same source.
>
> and again, if you don't like it, why post to an emacs newsgroup?

Because you crossposted to one, X.

>>> I often wonder if those who are affected would have found any system
>>> which used as many key bindings, regardless of what style, would have
>>> suffered the ill effects anyway
>>
>> More awkward ctrl-alt-etc. chording = less RSI? On what planet? Oh yes, of
>> course, *that* one, from whence came he who lies dreaming.
>
> and yet, for each person you can point to who has suffered RSI after
> using emacs, I can point to one who has used it longer that has not.

Classic pontification. All that says is that RSIs have an overall
incidence under 50%, X. We knew that already. It does not rebut my point.

> It is obvious you have an issue with the emacs' keybinding defaults

Classic pontification. It is obvious that the vast majority of computer
users have an issue with emacs' keybinding defaults, or would have one
if they attempted to use that behemoth, X.

> and it would seem the software as a whole

Classic pontification.

> and it now seems clear you are just being a troll and arguing for the
> sake o it.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, X?

> I will not be responding further.

Famous Last Words.

Cthun

unread,
Feb 23, 2011, 10:53:07 PM2/23/11
to
On 23/02/2011 6:46 PM, Pascal J. Bourguignon wrote:
> Cthun<cthu...@qmail.net.au> writes:
>
>> On 23/02/2011 12:15 PM, Rafe Kettler wrote:
>>> You must be a Windows user. You must also not be an Emacs power user
>>
>> If by that you mean "you must be a normal, sane human being", then you
>> are correct. :)
>
> For Heinlein, a normal, sane human being had to be able to compute an
> integral, otherwise Heinlein didn't consider that he should be allowed
> to vote.

What does your classic pontification have to do with Lisp, Bourguignon?

> You'll excuse us, but when you post on gnu.emacs.help, comp.emacs, and
> comp.lang.lisp, it is expected that a normal, sane human being be
> defined as being able to use emacs and program in emacs lisp.

Classic unsubstantiated and erroneous claim.

>> Hardly likely. For one thing those require extra keys held down, and
>> for another, which one of them corresponds to which arrow? On my
>> keyboard at least those are arranged like this:
>>
>> .........p
>> ...f.....
>> ....bn.
>
> This doesn't matter, because emacs users don't work at the low level.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, Bourguignon?

> You can expect an amobea to be able to direct itself up right down and
> left. But when we edit with emacs, we use higher level notions, such as
> (n)ext, (p)revious, (f)orward, (b)ackward, x {character, line,
> paragraph, sexp}. We don't edit characters, we edit structured sources
> symbolically.

Then why do you use a text editor and not a properly-designed IDE,
Bourguignon? A text editor is by definition designed for editing
amorphous strings of ASCII text, Bourguignon. If you want higher level
constructs to be recognized you should be using NetBeans, Bourguignon.
It has operations for refactoring and working with units from
identifiers all the way up to methods and whole classes, and, with
Enclojure, for working with functions and sexps, Bourguignon.

Stefan Monnier

unread,
Feb 23, 2011, 10:58:38 PM2/23/11
to
> You must be a Windows user. You must also not be an Emacs power user,
> because you think it's acceptable to use the arrow keys as cursors. If
> you don't, please use C-b, C-f, C-p, and C-n in place of the arrow
> keys. It dramatically improves speed.

I'll let you judge whether I qualify as "Emacs power user", but I use
the mouse and the arrow keys fairly heavily.


Stefan

Cthun

unread,
Feb 23, 2011, 11:05:57 PM2/23/11
to
On 23/02/2011 6:54 PM, Jason Earl wrote:
> On Wed, Feb 23 2011, Cthun wrote:
>
>> On 23/02/2011 2:22 PM, Jason Earl wrote:
>>> On Wed, Feb 23 2011, Cthun wrote:
>>>> This runs into trouble if you do something drastic you later want to
>>>> undo.
>>>
>>> Actually, Emacs warns you before it makes drastic changes to an autosave
>>> file. This at least gives you the opportunity to do something about it.
>>
>> Oh, wonderful.
>>
>> Do you know what I'd do if I was in the middle of typing some stuff
>> into a text editor after just having deleted a bunch of stuff and then
>> suddenly a box popped up saying something about autosaving and drastic
>> changes and yadda yadda yadda but I didn't have time to read it before
>> one of my enter keypresses (intended for the actual document I was
>> typing into when the box interrupted me) triggers one of the dialog's
>> buttons (which?) and it disappears again (and does who knows what to
>> my hard drive?).
>>
>> I'd delete that editor and go get a new one, that's what. :)
>
> So would I, but, of course, that's not what Emacs does. It just turns
> off auto-save and warns you in the mini-buffer.

In other words, instead of actually warning you, autosave just quietly
and unobtrusively stops working and unless you look in a particular spot
on the screen for some reason you won't know about it. Hardly a good
alternative, Earl. In fact, if the popup's default button was Cancel,
Earl, at least the popup scenario would cause you to realize that
*something* had happened.

In the modern age we have something nifty and newfangled called tray
notification, Earl. Also these amazing new gadgets called "sound cards".
It is possible to alert a user to a status change without stealing the
input focus, Earl. All too few application designers take advantage of
that to both ensure that a message gets the user's attention and avoid
undesired focus theft, though, Earl.

> And, like all things Emacs, if you do not like the default you can
> change it easily.

For values of "easily" that might make sense to a quantum physicist, Earl.

>>> The solution, of course, is to manually save *before* the fork.
>>
>> Yes, but the reality is that people will sometimes forget to do so, or
>> in that order.
>
> It would seem to me that you would basically have to be the sort of
> person that *relies* on the auto-save feature to do things in any other
> order.

What does your classic erroneous presupposition have to do with Lisp, Earl?

> If I am manually going fork a file then it seems like I would
> want to make sure that I forked from a known good spot.

You might think of it only after making a large selection and beginning
to type over it, Earl, if the drastic alteration that occurred to you
was a spur-of-the-moment thing. Not everyone takes a careful, measured,
chess-game-like approach to text editing, Earl.

> I used to work on a help desk and my experience says that most people
> don't even know that their editor has an auto-save (or how to get the
> auto-save files it creates) until something tragic happens.

Precisely one of my points, Earl.

> They certainly don't expect their editor to magically save the correct
> state of a file that they didn't manually save.

Precisely my *original* point, Earl. Thus manual save should be easy and
painless, Earl. Thus manual save should be bound to ctrl-S, Earl.

>>> I real life I don't think that this is much of a problem, especially
>>> with Emacs which has infinite undo
>>
>> Infinite undo? On what planet? When I experimented with it, back in
>> college, I found the undo to just toggle undo/redo like Windows
>> Notepad's. (I ended up experimenting also with LSD and mescaline and
>> decided on none of the above.)
>
> I thought it was infinite undo, but according to the manual the default
> limit is 12,000,000 bytes. Needless to say, I have never actually ran
> out of undo information.

When the actual behavior is to just toggle between the two most recent
document states, Earl, you'd have to be deleting most of a massive log
file to hit that limit.

>>> What's more, Emacs is flexible enough that you can easily set up
>>> whatever sort of auto-save functionality that you think you want.
>>
>> If you're a computer programmer with time to spare reprogramming the
>> editor instead of actually doing your job, perhaps.
>
> I'm just saying that, if you care about auto-save as much as you seem to
> care about auto-save, that Emacs gives you options that other tools do
> not.

Options a quantum physicist might manage to successfully use, Earl.

> Personally, other than changing where Emacs saves its auto-save
> files I just stick with the defaults.

Since you are indubitably not a quantum physicist, this is probably a
wise course, Earl. Of course, "not using emacs" would probably be a
wiser one.

> I personally think that Emacs' superior auto-save features would be a
> strange reason for choosing Emacs, but who am I to judge.

What does your classic erroneous presupposition have to do with Lisp, Earl?

>>> Emacs can do that. It has an auto-save-hook that you can add code to
>>
>> and ten million ways to subtly or drastically-but-irrecoverably fuck
>> things up if you make some subtle mistake doing so, no doubt.
>>
>> Thanks, but no thanks.
>
> Obviously any time you are writing code you have the opportunity to code
> something that doesn't work.

This is why most of us prefer our applications' developers to have done
that work for us, Earl, instead of leaving the job incomplete and us to
finish the last little bit of it. That way the whole user base gets the
benefit of one developer's work and testing and debugging, Earl, instead
of each one separately reinventing the wheel and many coming up with a
square one.

> On the other hand, computers are far less likely to "forget" a step
> than you or I are. Automation is generally a good thing.

A good argument against not leaving features missing that your users
will have to either work around or use your application's internal
scripting language to implement, Earl.

>>>> Sequences of numbered files used to risk filling up the filesystem,
>>>> too, but not with text files in this day and age.
>>>
>>> On the bright side Emacs can be made to do whatever makes you the
>>> happiest.
>>
>> Can it be made to cut itself, scream like a thing tortured, and then
>> die? ;)
>
> That seems like an odd thing to want from a text editor, but yes, you
> can teach emacs to do that. I even tested it.

A text editor inbuilt scripting language is not going to have sound card
APIs, Earl, so this statement is highly implausible.

> (defun scream ()
> (message "Arrgggh!"))

Hardly a real scream, Earl.

>>> Very few other programs have anywhere near that sort of flexibility.
>>
>> If I want that much flexibility I'll look at that Russian mail-order
>> catalog. There *is* something to be said for structure and stability
>> in fundamental, daily-use tools. And standards-adherence.
>
> Emacs has been adhering to the same standards almost as long as I have
> been alive.

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, Earl? Emacs adheres to no standards; it is an iconoclast in
virtually every way.

>>> For most folks, however, the defaults are what they want.
>>
>> Wait a minute. I thought you just said that the Emacs defaults are
>> what most people want. But that's clearly impossible, so I can only
>> presume that your post got garbled in transit. Care to repost whatever
>> you'd said at this point?
>
> Emacs' defaults for auto-save are what most people want.

Emacs itself is not what most people want, Earl, or Emacs would have
market share to rival that of Windows. This is clearly not actually the
case, though, Earl.

PJ Weisberg

unread,
Feb 24, 2011, 12:19:27 AM2/24/11
to Cthun, help-gn...@gnu.org
On Wed, Feb 23, 2011 at 7:13 AM, Cthun <cthu...@qmail.net.au> wrote:

> The other option is auto-save to some temporary file, or a sequence of
> numbered files. Of course if you have a power outage or something now you
> have to go hunting for where the darn thing saved these. Depending, they may

More likely, the editor will just ask you if you want to recover the
auto-saved version the next time you open the file. (Or do what Emacs
does, which is open the file normally but display a message suggesting
you execute "M-x recover-this-file".)

> even be vulnerable to being erased by an automatic temp file cleanup script
> before you get to them.

If you choose to run such a script, I would recommend using one that
only deletes files that are several days old.

> Sequences of numbered files used to risk filling up the filesystem, too, but
> not with text files in this day and age.

If you're concerned about that, customize kept-old-versions and/or
kept-new-versions to manage the number of backup versions that are
saved.

-PJ

Leo

unread,
Feb 24, 2011, 2:06:41 AM2/24/11