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
Pascal J. Bourguignon
> 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
> 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
Please, oohhh please.
This is "help-gnu-emacs".
It's enough.
There are a lot of stupid post sites.
Trebol.
Cthun
> 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
> 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
> 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
> 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
> 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
> I'll let you judge whether I qualify as "Emacs power user", but I use
> the mouse and the arrow keys fairly heavily.
Interesting input.
There are a few Ctrl key combinations that are note easy to type for
example C-b so overtime I have got used to using the arrow keys and the
trackpad quite a bit.
Sadly I have come to this article too late:
http://splittist.livejournal.com/3114.html.
Leo
fortunatus
> 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.
Don't go down that path: "vi" has a way-better key binding for cursor
movement!!
Richard Riley
Ditto with regard to the arrows. Most people I know who use emacs all
use the arrows keys too.
Xah Lee
it should be noted, that vi's jkl; is not optimal. Better is ijkl in
inverted T shape.
also, note that vi's Esc is FAST route to RSI. See:
〈Left Wrist side-to-side Motion Pain; vi Esc key Syndrome〉
http://xahlee.org/emacs/vi_esc_syndrome.html
also note, emacs keys and vi keys, are not out of much conscious
design. Like unix tool bags, they are piled on over the years without
much thinking. It was good enough, at the time. In fact, most things
in life are like that. They are not anywhere close to optimal in any
sense.
The following is a quote from Daniel Weinreb (danweinreb.org) ,
2008-06-01, on comp.emacs newsgroup. Source.
That's true. At the time Guy Steele put together the Emacs default
key mappings, many people in the target user community (about 20
people at MIT!) were already using these key bindings. It would have
been hard to get the new Emacs bindings accepted by the community if
they differed for such basic commands. As you point out, anyone using
Emacs can very easily change this based on their own ergonomic
preferences.
See:
〈Keyboard Hardware's Influence on Keyboard Shortcut Design (How Emacs
and vi keys came to be)〉
http://xahlee.org/emacs/keyboard_hardware_and_key_choices.html
〈Why Emacs's Keyboard Shortcuts Are Painful〉
http://xahlee.org/emacs/emacs_kb_shortcuts_pain.html
This “design” by evolution applies to Keyboard hardware itself. As it
is, it's the worst shit possible. It was good enough in the 1970s,
where there are just a handful of programers in the world. And today,
but vast majority of people (mom & pop, who occasionally chat online
or write email), it's good enough! Even for most programers, who's
finger actually dance on keyboard perhaps no more than accumulated 3
hours a day, it's good enough! But for data entry clerks, or
programers who seriously type a lot or write docs all day, it's hello
RSI. That's why we have so many problems on keybinding debates,
radical input device designs, dvorak advocacy, and RSI is a serious
medical problem. See:
〈Keyboard Hardware Design Flaws〉
http://xahlee.org/emacs/keyboard_problems.html
this also applies to key layouts. e.g. we all know the story of qwerty
and dvorak. But in my study, i found that it's just not that. Most
international layout are ergonomic garbage. See:
〈Idiocy of Keyboard Layouts: QWERTZ, AZERTY, Alt Graph〉
http://xahlee.org/kbd/keyboard_layouts.html
〈Dvorak, Maltron, Colemak, NEO, Bépo, Turkish-F, Keyboard Layouts
Fight!〉
http://xahlee.org/kbd/dvorak_and_all_keyboard_layouts.html
also note, in the programing industry, if there is one software that
induces most cases of RSI, it is emacs, by far. See:
〈Celebrity Programers with RSI (Repetitive Strain Injury)〉
http://xahlee.org/emacs/emacs_hand_pain_celebrity.html
the emacs's keybinding, in my assessment, of all possible keybinding
systems one could devise, with the PC keyboard as given constraint, i
rate it near the bottom. Better than random assignment, but not much.
One thing damaging is that GNU Emacs has a tendency to refuse change,
much like most unix-bag. Emacs's keybinding today is pretty much
identical to emacs of 1970s. But, the landscape of computing has
changed tremendously in past 30 years.
why most emacs people don't see this but in fact advocates emacs
keybinding? My guess is that most people have not studied the issue.
There are tens of thousands of things in life, we learned and use
daily by habit, but never thought about it seriously. If you are
interested, i think if you actually start to study keybinding, say, in
the next 30 days, your job is to research keybinding design 8 hours a
day for 30 days, i think you'll have a changed view. (no, i don't mean
to brag about how many hundreds of software you've used in past n
decades. Me too bro. I mean: stop dead and spend 8 hours a day for the
next 30 days to do nothing but study keybindings. Yours truely have
done so.)
Xah ∑ http://xahlee.org/
des...@verizon.net
Glad to hear it. I was starting to think I was doing something
wrong.
Sure I have to move my hand to find the arrow keys, but the keys
are easy to find without looking.
More important, every once in a while I actually use a program other
than Emacs. (There I admitted it.) My mind is too feeble to adapt
to using different keystrokes for the same thing.
Eric Schulte
I just read your "modernizing Emacs" page [1] and I wonder, have you
looked at the "Emacs Starter Kit" [2] (or /shameless-plug/ my literate
version of the same [3]). I think that by being distributed as a
configuration for GNU emacs such `starter-kits' could serve as a good
place to test and/or prove the utility of eventual changes to GNU emacs.
Have you considered wrapping your modernization suggestions up into such
a starter kit? It seems that if such a kit gained popularity it would
raise the chances of general Emacs adoption.
Also, more pursuant to the points in your previous email, I wonder if
you can recommend a good set of key-bindings for common commands such as
cursor movement, file save-open-close, buffer-movement etc...
Cheers -- Eric
as a side note, I've been using Emacs for ~5 years, and over the last
year have developed hand pains which were greatly relieved by using a
Kinesis keyboard.
Footnotes:
[1] http://xahlee.org/emacs/modernization.html
javax.swing.JSnarker
DUCK AND COVER!
Goggles on, NOW!
Do NOT look directly into the flash!
--
In <iijn58$ccs$1...@news.albasani.net>, Lew admitted:
> The JLS is obfuscatory in parts
Cthun
> Also, more pursuant to the points in your previous email, I wonder if
> you can recommend a good set of key-bindings for common commands such as
> cursor movement, file save-open-close, buffer-movement etc...
Is there something wrong with arrows, ctrl-S/ctrl-O, pageup, pagedn, etc.?
Todd Wylie
;; universal directory
(setq backup-directory-alist `(("." . "~/.emacs.d/AUTOSAVE/")))
and periodically expunge them manually, simply by opening the directory in dired, type '~', and flush them in one go.
Best, T
Deniz Dogan
Possibly, assuming you're in "normal mode" or whatever they call it.
And assuming that you use QWERTY.
Xah Lee
hi Eric,
i think several alt emacs distributions all does that.
Lennart's EmacsW32+Emacs does that for Windows.
my humble ErgoEmacs does it.
David Reitter's AquamacEmacs does it.
all these by default have keybindings that's radically different from
GNU Emacs. (in Lennart's EmacsW32 you have to turn it on.) They also
add various UI improvements, and lots of other packages to make it
more easier to use or more powerful.
i know that EmacsW32 and AquamacsEmacs are quite popular too. (my
guess is that their combined user is more than the number of GNU emacs
users counting all from linux distros.)
from what i've seen in GNU emacs mailing list, any little suggestion
about incorporating any UI change into GNU Emacs is met with major
resistance and debate. Almost everytime, giant fireball blows up in
the list. I don't know if that's good or bad, for FSF or for the
world, but that's what i've seen. (both Lennart and Reitter are on the
list as accepted contributors)
... Nice going with Kinesis. I'd love one too.
i haven't looked into what's in emacs starter kit much...
http://eschulte.github.com/emacs-starter-kit/
heard it around in reddit etc now and then.
btw, why would people use it? seems complex.
Xah ∑ http://xahlee.org/
javax.swing.JSnarker
> Lennart's EmacsW32+Emacs does that for Windows.
>
> my humble ErgoEmacs does it.
>
> David Reitter's AquamacEmacs does it.
>
> all these by default have keybindings that's radically different from
> GNU Emacs. (in Lennart's EmacsW32 you have to turn it on.) They also
> add various UI improvements
I'd be more impressed by that claim if it were actually difficult to do.
But making emacs segfault on startup would qualify as a UI improvement,
so ...
> from what i've seen in GNU emacs mailing list, any little suggestion
> about incorporating any UI change into GNU Emacs is met with major
> resistance and debate. Almost everytime, giant fireball blows up in
> the list.
The correlation between emacs and flamewars is well known by now.
PJ Weisberg
> I find it simplest to consolidate backups to a single directory:
>
> ;; universal directory
> (setq backup-directory-alist `(("." . "~/.emacs.d/AUTOSAVE/")))
>
> and periodically expunge them manually, simply by opening the directory in dired, type '~', and flush them in one go.
>
> Best, T
I do the same, but I have a cron job that deletes them after a month
or so without my intervention.
-PJ
Alan Mackenzie
> from what i've seen in GNU emacs mailing list, any little suggestion
> about incorporating any UI change into GNU Emacs is met with major
> resistance and debate. Almost everytime, giant fireball blows up in the
> list. I don't know if that's good or bad, for FSF or for the world, but
> that's what i've seen. (both Lennart and Reitter are on the list as
> accepted contributors)
For what it's worth, it's not personal. A giant fireball blows up when
_anybody_ suggests UI changes in Emacs. The UI is an important part of
what Emacs is, so it's bound to give rise to discussion when anybody
wants to change it.
> Xah ? http://xahlee.org/
--
Alan Mackenzie (Nuremberg, Germany).
rusi
>
> For what it's worth, it's not personal. A giant fireball blows up when
> _anybody_ suggests UI changes in Emacs. The UI is an important part of
> what Emacs is, so it's bound to give rise to discussion when anybody
> wants to change it.
Hi Alan.
I remember you suggesting some time an idea that you called
'emacsicality' -- basically a grain of customizability larger than
individual key/function binding or even major mode.
[Subsequently I tried to look it up but my google-fu failed me]
Do you remember what this suggestion was?
In any case do you realize that this statement of yours suggests that
*fact* of emacs encrustation is opposed to the *philosophy* of
infinite customizability?
Rusi
Jim Janney
> 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. Compared to other
> operations, saving files and opening files are less frequent operations
> and do not need to be as convenient keystrokes as other more frequent
> editing operations.
Anything I'm working on that would be expensive to lose goes under
version control anyway.
--
Jim Janney
Alan Mackenzie
In comp.emacs rusi <rusto...@gmail.com> wrote:
> On Feb 25, 12:16?pm, Alan Mackenzie <a...@muc.de> wrote:
>> For what it's worth, it's not personal. ?A giant fireball blows up
>> when _anybody_ suggests UI changes in Emacs. ?The UI is an important
>> part of what Emacs is, so it's bound to give rise to discussion when
>> anybody wants to change it.
> Hi Alan.
> I remember you suggesting some time an idea that you called
> 'emacsicality' -- basically a grain of customizability larger than
> individual key/function binding or even major mode. [Subsequently I
> tried to look it up but my google-fu failed me]
> Do you remember what this suggestion was?
I don't remember using "emacsicality" (but it's the sort of "word" I
would use). An idea I once had was "Emacs personalities" - there'd be
classic Emacs, CUA Emacs, possibly Ergo Emacs each callable from the
command line as its own command. So you might start the editor with the
command
% cua-emacs
. The commands would all be aliases (or the W32 equivalent, whatever
that is) of the plain emacs command. It would be implemented by a
"personality" configuration file, loaded before site-start.el.
The idea would be to allow newbies, who might otherwise be overwhelmed by
configuration, to get a taste of the variety possible under Emacs.
I think the idea came up when the making of transient-mark-mode on by
default was being discussed on the Emacs development list. That
discussion was more like a supernova than a fireball. ;-)
> In any case do you realize that this statement of yours suggests that
> *fact* of emacs encrustation is opposed to the *philosophy* of infinite
> customizability?
:-). I don't really think so. More precisely, discussions about UI are
nearly always about the _defaults_, and the wisdom, or otherwise, of
changing them. Pretty much any new UI feature is welcome, provided it is
an option which is disabled by default. The stability of the default
features doesn't in any way contradict the philosophy of infinite
customisability.
My view is that the defaults should remain very stable indeed, (but not
totally frozen). At the same time I have an extensive .emacs.
> Rusi
Thien-Thi Nguyen
() Fri, 25 Feb 2011 18:54:35 +0000 (UTC)
My view is that the defaults should remain very stable indeed, (but not
totally frozen). At the same time I have an extensive .emacs.
(The more stable the terrace the bigger the trees you can plant on it.)
rusi
> My view is that the defaults should remain very stable indeed, (but not
> totally frozen). At the same time I have an extensive .emacs.
Maybe one basic/generic kind of personality/emacsicality would be say
for emacs 23 to 'become' emacs 22 or 21 etc. IOW the 'totally frozen'
should be an available option. I say this because recently there was
a fireball (supernova?) with Mark Crispin getting upset with visual-
line-mode changing basic newline behavior. On the one hand the new is
generally accepted to be better behavior, on the other it broke old
code. Maybe being able to say:
$ emacs23 --emacsicality=emacs22 ...
would be good to have?
[I personally would like more progress even at the cost of more
breakage a la Xah. Just exploring if a win-win is possible...]
Heres a possible list of emacsicalities:
emacs22, emacs21
cua
dvorak
xemacs?
Cthun
> Anything I'm working on that would be expensive to lose goes under
> version control anyway.
Then woe betide you if you ever work on, say, a novel rather than a
computer program.
PJ Weisberg
control than a program. A lost piece of prose seems like it would be
harder to re-implement than a lost piece of functionality. And plenty
of prose gets deleted and mashed around during rewrites and editing.
--
-PJ
Stefan Monnier
>> version control anyway.
> Then woe betide you if you ever work on, say, a novel rather
> than a computer program.
Don't know about novels, but at least revision control works very well
for academic publications.
Stefan
Tim Bradshaw
> Then woe betide you if you ever work on, say, a novel rather than a
> computer program.
What a confused thing to say.
Cthun
Oh, really? I for one cannot recall ever seeing a version 1.5 of a novel
or a version 2.0 of a magazine article.
Cthun
What does your classic unsubstantiated and erroneous claim have to do
with Lisp, Bradshaw?
David Kastrup
Well, I've been responsible for the typesetting software for "Die
Kritische Gesamtausgabe der Werke von Ernst Troeltsch"
<URL:http://www.st.evtheol.uni-muenchen.de/troeltsch/kga/arbeit/index.html>,
and you'll find that he published various articles in about 5 venues,
with various changes in wording and content. The challenge was to
present a readable manner in which the purchaser of the critical edition
could tell for each of the various venues what wording has been
employed, what the differences to the other versions were, and on which
pages of each version the various text passages were to be found.
So definitely there were various versions of the same article published.
And even if your work is not worth publishing more than once, you can
easily have several major revisions before that, and intermediate
versions might contain content that you first removed, then later
decided to use anyway.
The gestation of both articles and novels is rarely linear.
--
David Kastrup
Cthun
> Cthun <cthu...@qmail.net.au> writes:
>> Oh, really? I for one cannot recall ever seeing a version 1.5 of a
>> novel or a version 2.0 of a magazine article.
>
> Well, I've been responsible for the typesetting software for "Die
> Kritische Gesamtausgabe der Werke von Ernst Troeltsch"
>
> So definitely there were various versions of the same article published.
But that's not the same thing as software versioning, or anywhere close.
> The gestation of both articles and novels is rarely linear.
True enough. But it is also not going to fit especially well to what
systems designed for software revision control do. There is a single
long piece of text rather than lots of interacting software modules, for
one thing; there are no builds or library dependencies or bug reports or
feature requests. There's also a point where it's actually *finished*,
while software is never finished and has many successive versions
released, each fixing the bugs in the previous and adding new features.
In short there's almost nothing of what source code control systems are
actually there for. If you want to be able to recover deleted material
you use strikethru (and delete anything still in strikethru when it's
done) or cut it and save it to a clippings file or something.
David Kastrup
> On 27/02/2011 3:08 AM, David Kastrup wrote:
>> Cthun <cthu...@qmail.net.au> writes:
>>> Oh, really? I for one cannot recall ever seeing a version 1.5 of a
>>> novel or a version 2.0 of a magazine article.
>>
>> Well, I've been responsible for the typesetting software for "Die
>> Kritische Gesamtausgabe der Werke von Ernst Troeltsch"
>> [anecdote trimmed]
>>
>> So definitely there were various versions of the same article published.
>
> But that's not the same thing as software versioning, or anywhere
> close.
One can still use the same tools nowadays.
>> The gestation of both articles and novels is rarely linear.
>
> True enough. But it is also not going to fit especially well to what
> systems designed for software revision control do. There is a single
> long piece of text
Which can still be separated into chapters if you like, subject to
reordering and conditional inclusion.
> rather than lots of interacting software modules, for one thing; there
> are no builds or library dependencies or bug reports or feature
> requests.
Last time I looked, revision control did not concern itself with builds
or library dependencies or bug reports or feature requests.
> There's also a point where it's actually *finished*,
Uh, you already forgot what I wrote about the various versions of
articles published several times?
> while software is never finished and has many successive versions
> released, each fixing the bugs in the previous and adding new
> features.
Like a republished polished article.
> In short there's almost nothing of what source code control systems
> are actually there for. If you want to be able to recover deleted
> material you use strikethru (and delete anything still in strikethru
> when it's done) or cut it and save it to a clippings file or
> something.
Gross. You are not confusing word processing on a computer with
handwritten manuscripts by chance?
_I_ use git for working on non-trivial articles. There is no point in
juggling "strikethru" or other material around while trying to do actual
work. There is also no point in manually keeping possibly incomplete
clippings around in an unorganized manner that makes it hard to figure
out a history of changes or undo particular changes.
--
David Kastrup
Cthun
> Cthun<cthu...@qmail.net.au> writes:
>> But that's not the same thing as software versioning, or anywhere
>> close.
>
> One can still use the same tools nowadays.
You can use a cheese grater to peel potatoes, too. But I wouldn't
recommend it.
>>> The gestation of both articles and novels is rarely linear.
>>
>> True enough. But it is also not going to fit especially well to what
>> systems designed for software revision control do. There is a single
>> long piece of text
>
> Which can still be separated into chapters if you like, subject to
> reordering and conditional inclusion.
A single C source file contains separate functions.
What's your point?
>> rather than lots of interacting software modules, for one thing; there
>> are no builds or library dependencies or bug reports or feature
>> requests.
>
> Last time I looked, revision control did not concern itself with builds
> or library dependencies or bug reports or feature requests.
Sure it does.
Check out sourceforge sometime. You'll note that the key features
involve many of these things. They work together as an integrated whole.
What is the "master branch" but the currently evolving code base, the
"2.1 branch" but the 2.1 build of the software, etc.?
>> There's also a point where it's actually *finished*,
>
> Uh, you already forgot what I wrote about the various versions of
> articles
No, it's simply not relevant. Articles are typically written, revised,
and eventually *finished*.
>> while software is never finished and has many successive versions
>> released, each fixing the bugs in the previous and adding new
>> features.
>
> Like a republished polished article.
Articles are not typically published with "bugs" and then later
republished without them. Typical articles are published once and then
that's it.
>> In short there's almost nothing of what source code control systems
>> are actually there for. If you want to be able to recover deleted
>> material you use strikethru (and delete anything still in strikethru
>> when it's done) or cut it and save it to a clippings file or
>> something.
>
> Gross. You are not confusing word processing on a computer with
> handwritten manuscripts by chance?
Of course not. You on the other hand seem to be confusing word
processing with software development!
Perry Smith
This started back with:
On Feb 26, 2011, at 12:05 AM, Cthun wrote:
> On 25/02/2011 1:43 PM, Jim Janney wrote:
>> Anything I'm working on that would be expensive to lose goes under
>> version control anyway.
>
> Then woe betide you if you ever work on, say, a novel rather than a computer program.
The phrase you pulled out referred to "version control". You are now talking about source code control systems...
Also, SCMs that I know like git, svn, rcs, bzr, etc do not have any concept of build, dependencies, bug reports, or feature requests. Its one of my frustrations. If you know if a single system that has all those, I'd love to know about them. The only fully integrated example I have is IBM's CMVC and IBM dumped it because no one understood it.
Aside from that, I'm not getting your point at all. An article can easily be broken into sections, a book into chapters which are then subdivided into sections. Those sections will have dependencies. I doubt if the author will add those in but the concept still applies. And as far as history, there are countless examples where a single journalistic piece has a very long life to it. Haven't ever listened to where historians go back and review the author's original notes? God... there are entire books about the American Constitution trying to reconstruct the various versions and the intentions behind each of them.
So... I just don't see anything special about software verses english text as far as wanting to track and follow the history at all.
By the way, if anyone else wants this moved to private channels, please let me know. No one has complained yet so I posted to the whole list but this is way off topic for emacs as far as I can tell.
Thank you and apologize if necessary
pedz
rusi
>
> So... I just don't see anything special about software verses english text as far as wanting to
> track and follow the history at all.
"software verses" (versus versus) -- nice pun in context :-)
Eric Abrahamsen
> On Feb 27, 2011, at 9:28 AM, Cthun wrote:
>
>> On 27/02/2011 3:08 AM, David Kastrup wrote:
>>> Cthun <cthu...@qmail.net.au> writes:
>>>> Oh, really? I for one cannot recall ever seeing a version 1.5 of a
>>>> novel or a version 2.0 of a magazine article.
>>>
>>> Well, I've been responsible for the typesetting software for "Die
>>> Kritische Gesamtausgabe der Werke von Ernst Troeltsch"
>>> [anecdote trimmed]
>>>
>>> So definitely there were various versions of the same article published.
>>
>> But that's not the same thing as software versioning, or anywhere close.
>>
>>> The gestation of both articles and novels is rarely linear.
>>
>> True enough. But it is also not going to fit especially well to what
>> systems designed for software revision control do. There is a single
>> long piece of text rather than lots of interacting software modules,
>> for one thing; there are no builds or library dependencies or bug
>> reports or feature requests. There's also a point where it's
>> actually *finished*, while software is never finished and has many
>> successive versions released, each fixing the bugs in the previous
>> and adding new features.
[...]
>> Then woe betide you if you ever work on, say, a novel rather than a
>> computer program.
>
>
> The phrase you pulled out referred to "version control". You are now
> talking about source code control systems...
>
> Also, SCMs that I know like git, svn, rcs, bzr, etc do not have any
> concept of build, dependencies, bug reports, or feature requests. Its
> one of my frustrations. If you know if a single system that has all
> those, I'd love to know about them. The only fully integrated example
> I have is IBM's CMVC and IBM dumped it because no one understood it.
>
> Aside from that, I'm not getting your point at all. An article can
> easily be broken into sections, a book into chapters which are then
> subdivided into sections. Those sections will have dependencies. I
> doubt if the author will add those in but the concept still applies.
> And as far as history, there are countless examples where a single
> journalistic piece has a very long life to it. Haven't ever listened
> to where historians go back and review the author's original notes?
> God... there are entire books about the American Constitution trying
> to reconstruct the various versions and the intentions behind each of
> them.
To add my cent-and-a-half… I use emacs (and git) for novel
translation—functionally the same as novel writing. While I'm far
happier with this setup than with any other (in moving from a Mac to
Linux, my only regret is the loss of Tinderbox), I can certainly see
cthun's point. When you are writing long-form text, the unit is the
paragraph. When writing code, the unit is the line. Writing prose, the
addition of one word can transform a whole paragraph (using fill-mode).
Writing code, the addition of one "word" generally only changes a line.
Version control systems thus become that much less useful. Not useless,
just less useful. Git is still great for doing a commit with translation
and research notes in, and then another with them out, or even
branching—that sort of thing. But you have to think harder about how
conceptual alterations should be recorded as version changes.
E
Julian Bradfield
with lisp - an option which you curiously have never chosen, despite
repeated complaints about it not being to do with lisp. ]
On 2011-02-27, Cthun <cthu...@qmail.net.au> wrote:
> On 27/02/2011 10:46 AM, David Kastrup wrote:
>> Last time I looked, revision control did not concern itself with builds
>> or library dependencies or bug reports or feature requests.
>
> Sure it does.
You're confusing a source code management system with revision
control aka version control. RCS is a version control system - nothing
else.
>> Uh, you already forgot what I wrote about the various versions of
>> articles
>
> No, it's simply not relevant. Articles are typically written, revised,
> and eventually *finished*.
Have you ever actually written an academic article?
> Articles are not typically published with "bugs" and then later
> republished without them. Typical articles are published once and then
> that's it.
You're not an academic, are you?
>>> In short there's almost nothing of what source code control systems
>>> are actually there for. If you want to be able to recover deleted
>>> material you use strikethru (and delete anything still in strikethru
>>> when it's done) or cut it and save it to a clippings file or
>>> something.
>>
>> Gross. You are not confusing word processing on a computer with
>> handwritten manuscripts by chance?
As David says, gross. What is "strikethru" anyway?
> Of course not. You on the other hand seem to be confusing word
> processing with software development!
Only those who don't know any better use word processors to write
articles. I'm sure David doesn't use a word processor.
Joe Riel
Eric Abrahamsen <er...@ericabrahamsen.net> wrote:
> To add my cent-and-a-half… I use emacs (and git) for novel
> translation—functionally the same as novel writing. While I'm far
> happier with this setup than with any other (in moving from a Mac to
> Linux, my only regret is the loss of Tinderbox), I can certainly see
> cthun's point. When you are writing long-form text, the unit is the
> paragraph. When writing code, the unit is the line. Writing prose, the
> addition of one word can transform a whole paragraph (using
> fill-mode). Writing code, the addition of one "word" generally only
> changes a line.
That depends on how one writes.
When using LaTeX I usually write so that
the structure of the source reflects the paragraph/sentence structure;
clauses get indented, etc.
As such, I don't use fill-mode;
a one-word addition just changes one line.
--
Joe Riel
Cthun
> On 2011-02-27, Cthun <cthu...@qmail.net.au> wrote:
>> On 27/02/2011 10:46 AM, David Kastrup wrote:
>>> Last time I looked, revision control did not concern itself with builds
>>> or library dependencies or bug reports or feature requests.
>>
>> Sure it does.
>
What does your classic unsubstantiated and erroneous claim, combined
with a classic contradiction, have to do with Lisp, Bradfield?
>>> Uh, you already forgot what I wrote about the various versions of
>>> articles
>>
>> No, it's simply not relevant. Articles are typically written, revised,
>> and eventually *finished*.
>
> Have you ever actually written an academic article?
What does your question have to do with Lisp, Bradfield?
>> Articles are not typically published with "bugs" and then later
>> republished without them. Typical articles are published once and then
>> that's it.
>
> You're not an academic, are you?
What does your classic erroneous presupposition have to do with Lisp,
Bradfield?
>>> Gross. You are not confusing word processing on a computer with
>>> handwritten manuscripts by chance?
>
> As David says, gross. What is "strikethru" anyway?
You're not a writer, are you, Bradfield?
>> Of course not. You on the other hand seem to be confusing word
>> processing with software development!
>
> Only those who don't know any better use word processors
What does your classic unsubstantiated and erroneous claim have to do
with Lisp, Bradfield? One wonders what you think word processors are for
and what explanation you'd proffer for the fact that they are one of the
more lucrative categories of software out there, Bradfield.
Alan Mackenzie
> On 27/02/2011 12:28 PM, Julian Bradfield wrote:
>> On 2011-02-27, Cthun <cthu...@qmail.net.au> wrote:
>>> On 27/02/2011 10:46 AM, David Kastrup wrote:
> What does your classic unsubstantiated and erroneous claim, combined
> with a classic contradiction, have to do with Lisp, Bradfield?
You know, Thun, you've got an awful lot to learn about trolling. You
ignore somebody's Followup-To: header (perfectly politely inserted), you
complain about the effect of it's lack, then you think nobody will notice
when you put in a Followup-To: an OS/2 group.
Get ye gone, third rate troll!
Tim Bradshaw
> Oh, really? I for one cannot recall ever seeing a version 1.5 of a
> novel or a version 2.0 of a magazine article.
Even if there's only one published version, which is not always the
case, revision control can be useful for the development of natural
language texts, of any kind. Why do you think virtually every modern
word processor supports revision tracking?