What's your favourite *under_publicized* editing feature of Emacs?
Le Wang
--
Le
Deniz Dogan
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
> 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
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
> 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
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
> 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
<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
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
> <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
I've often needed an insert, as opposed to overwrite. Do you know if
there's a way to insert?
Stefan Monnier
> 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
- 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
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
> 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
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
Agreed,
Stefan
Oleksandr Gavenko
> On 2011-01-29 14:55, Javier Sanz wrote:
>> Some that come to my mind:
>> logs, which highlights errors and warnings in different colors and
>> makes them easier to see.
>
> 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
>> 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
>>> 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).
>
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
>>> 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).
>
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
() 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
> 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
(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
> 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
Thien-Thi Nguyen
() 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
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
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
des...@verizon.net
> 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.
Xah Lee
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
Glenn Morris
[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.
Cthun
> 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.
>>
>> 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
>>> 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.
>>>
>>> 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
> 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.
>
>
> something truly drastic to it, especially large elisions.
>
> 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
> 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
>> 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
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
> 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
> 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
> 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
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
> 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
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