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.