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

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

[Le Wang]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1079 bytes --]

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

[Deniz Dogan]

2011/1/27 Le Wang <l26wang@gmail.com>:
> 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
>

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

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

[Wang Lei]

Le Wang <l26wang@gmail.com> writes:

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

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

-- 
Regards
Lei

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

[suvayu ali]

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

Just tried it out, very impressive. :)

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


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

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

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

-- 
Suvayu

Open source is the future. It sets us free.

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

[Ken Goldman]

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

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

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

On 01/27/2011 03:33 AM, Le Wang wrote:
> 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?
>

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

[Erik Iverson]

This may only work in 23+, but I enable subword-mode in
some buffers to deal with the camelCase naming convention.

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

aVariableNamedLikeThis
  ^       ^    ^   ^

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

Oh, and also:

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

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

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

[Joe Fineman]

Ken Goldman <kgold@watson.ibm.com> writes:

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

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

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

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

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

[Jason Rumney]

Or use what is already there since 23.1:

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

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

RE: What's your favourite *under_publicized* editing feature ofEmacs?

[Drew Adams]

> Or use what is already there since 23.1:
> <f3> runs the command kmacro-start-macro-or-insert-counter...
> <f4> runs the command kmacro-end-or-call-macro...

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

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

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

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

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

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

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

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

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

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

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

AFAIK no poll was ever taken.

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

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Xah Lee]

On Jan 28, 10:25 am, "Drew Adams" <drew.ad...@oracle.com> wrote:
> > Or use what is already there since 23.1:
> > <f3> runs the command kmacro-start-macro-or-insert-counter...
> > <f4> runs the command kmacro-end-or-call-macro...
>
> It's unfortunate however that two repeatable keys were wasted for these default
> bindings.  Repeatable keys are better reserved for operations that you want to
> easily repeat by just holding down a key or chord.
>
> Yes, you can use `f4' for both ending a macro definition and executing the
> macro, and the latter operation is repeatable.  Still, it is better to use a
> repeatable suffix on a prefix key for this, e.g. `C-x e e e...' (which you can
> already use as an alternative to `f4 f4 f4...').  Single repeatable keys are a
> valuable resource and should not be wasted.
>
> `f3' and `f4' also do not offer mnemonic help.
>
> Consider by contrast the keys bound to `kmacro-start-macro' and
> `kmacro-end-macro': `C-x (' and `C-x )'.  Those bindings were made decades ago
> (to the parents of the current commands: `start-kbd-macro' and `end-kbd-macro').
> They are mnemonic, visually indicating start and end, and they are not easily
> repeatable by holding keys down.  Start/end have no need to be repeatable.

totally agree with Drew Adam here.

i also like add a point about why i think f3 f4 is bad. (maybe Drew
agree too or maybe not)

f3 and f4 is one of those easy-to-press keys: single key, big key, in
easy-to-access positions. These type of keys are rare. (in the sense
that you have some 10 times more commands you want to have easy key in
emacs)

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.

in this regard, f3 and f4 are bad keys for kmacro-start-macro and
kmacro-end-macro.

> 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

again, i agree with what Drew wrote above.

i think the other oddity is F1 for help. Is that due to Windows
influence?

I think one of the F key should be execute-extended-command.

PS offkey but i really love to remark: i use my own ErgoEmacs binding
set of course, which completely remap all the primary keys based on
command frequency. On top of that, i have over a hundred more personal
emacs keyboard shortcuts, and a hundred more outside of emacs. (on
Windows, that's AutoHotkey) Also note, sometime i read online (e.g.
reddit, hackernews) that people remark that my use or teaching of
emacs is like from Windoz Notebook newb. Actually, the first 6 years
of my emacs using, from 1998 to 2004, is in plain old text terminals
(not even XTerm), and absolutely traditional emacs keybinding. I even
avoid adding anything to my “.emacs”. (have written amply about this
on my site or if one care to research past posts on the net)

... a bit more about keybinding. In the past 3 or so years, due to my
obsession of keyboarding efficiency, by steps of piecemeal improvement
of my emacs use by *practical* experiences (with emphasis on
statistics and science basis as opposed to “i feel” or anecdotes), i
realized that i've  eliminated all keys that require multi-sequences.
A few months ago, the last one to go was kill-rectangle 【C-x r k】 and
string-rectangle 【C-x r t】. They are now 【C-8】 and 【C-9】.

(actually, there are still exceptions. Ι still haven't remapped
【C-h f】, 【C-h k】, which i use few times a hour on average. Also, still
use 【C-x (】 and 【C-x )】 perhaps few times a week. Actually a few
more.. especially mode specific that starts with 【C-c】.)

in the past 6 months, i started to wonder if vi's so-called “modal”
way is actually more efficient. Am certain of it now. I think it is un-
avoidable that sometimes soon i'll be creating a ErgoEmacs-Viper mode,
due to my keyboarding obsession.

also, you know i live among tech geeker communities. The internet is
my home. My life. And among tech geekers, y'know how harsh it is, that
there's always someone who know more than you, and often not shy to
show it.  On the net, you often hear linux or emacs geeks brag about
they keyboarding habits n setups, such as some ratpoison or haskell
based tiling windows etc. (n they not shy to tell you about it, and
tell you how you should do it this or that way with this or that
tools)

I tell you now, and you can quote me on this: i don't care what linux
you on, what ratpoison you use, whot X11 xmodmap you've done, how
extensive your customization is, how many years of emacs you've been
using: my setup n system, is more efficient than you, by any means of
scientific accessment.

AND: i don't care if you are richard stallman or old time emacs dev.
The total time i spend in emacs, in past 3 years, is more than you
have. (if you think you can challenge that, first ask ur self if you
LITERALLY spend 14 hours in front of the computer DAILY on average in
the past 3 years, STATISTICALLY speaking. If not, forget it. If you
have a family, forget it. If you watch TV, go out to dinner, or
occasionally go to bar or social events such as movies or bar etc,
forget it. If you work in a day job (with meetings, time spend on
driving, etc), forget it. If you take shower daily, take time to cook
diner, or go to gym, forget it. If you hang out with friends, or chat
with room-mates, forget it. Now, if you are city hermit, a ascetic, a
extreme weirdo, like me, then, possibly we can compare notes.
Otherwise, you can forget about challenging me on things i say
forcefully.)

(the above paragraph speaks of last 3 years. But the pattern is about
the same for past 20 years, just more severe in past 3.)

with respect to emacs keybinding, emacs should completely ditch the C-
x. Not by simply turn on cua-mode, but re-write the entire shit, axe
the cua-mode hack. Stop the C-m C-i to Enter Tab equivalences. Support
the 7 or so standard keys such as Open, Close, Copy, Paste. Re-design
the whole major shortcut keys (e.g. cursor movement, text deletion.)
(adopt my ErgoEmacs keybinding design if u want.) This will not only
make emacs compatible to current standards (e.g. for those Windows
newbs we love to hate), but also much more efficient for the most hard-
core tech geekers (e.g. what u'd call “hackers” such as many here).

for each point i made in this post, i have written a essay with
hundreds words details. They are all on my website. I shall not make
any links here.

Also, a disclaimer: i claim exactly what i've written as they can be
reasonably interpreted. With all the bragging, i do not claim, for
example, that i know more elisp than many here, nor that i'm a better
programer, etc.

i guess it is old school netiquette that when flaming is over, one
makes a note of it. But no, the bragging has only began!

No U! It's Me!

 Xah ∑ http://xahlee.org/

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[despen]

Xah Lee <xahlee@gmail.com> writes:

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

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

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

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Alan Mackenzie]

Hi, Xah,

I see you're in combative mood again.  ;-)

In comp.emacs Xah Lee <xahlee@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.

> Xah ? http://xahlee.org/

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Xah Lee]

hi Alan,

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

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

 Xah

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

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.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Rafe Kettler]

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.). It's also nice to have a
slightly more complex incantation for save so that you don't save
anything you might not want to (I know you can undo but if you don't
realize what you did you could be in for a problem).

Rafe

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 22/02/2011 9:33 PM, Rafe Kettler wrote:
> On Feb 22, 9:06 pm, Cthun<cthun_...@qmail.net.au>  wrote:
>> On 22/02/2011 2:47 PM, Alan Mackenzie wrote:
>>
>>> There seems to be a contradiction between those last two paragraphs.
>>> Saving buffers and finding files are relatively rare operations which
>>> thus shouldn't be given very easy to press key sequences like C-s and
>>> C-o.
>>
>> Where do you live where software never crashes and the electricity never
>> goes out? Most of us learn to save very frequently to limit how much
>> we'll have to do over again if the power goes out or whatever.
>
> Emacs is really, really stable. My computer hasn't crashed in the past
> 6 months, either. The power hasn't gone out in 3 months or so here
> (eastern US).
>
> Save and open are relatively infrequent command relative to others
> (actual typing, cursor movement, etc.).

Yeah, but for "actual typing" you only need the normal 
alphanumeric/symbol keys (no ctrl- or alt- combos) and for cursor 
movement, the arrow/home/end/etc. key group to the right of the main 
keyboard area. You've got loads and loads of ctrl-letter and ctrl-number 
combinations still after exhausting all of these more-frequent actions.

And then not everyone lives somewhere where the power is that reliable.

And then not everyone is daft enough not to fork their file before doing 
something truly drastic to it, especially large elisions.

And then, of course, there's the tendency of operating systems to 
blue-screen, laptops to overheat and hang, etc. no matter how stable the 
editor application is.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Tim X]

Cthun <cthun_117@qmail.net.au> writes:

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

Unless you are a power keyboard user, in which case, lifting your hands
from the keyboard to the arrow keys et. al. or to use the mouse to
access menus, is annoying and slows you down. Having C-n/C-p/C-a/C-e/C-o/C-j etc
plus many other frequently used editing commands on single depth
bindings is far more useful and used more frequently than save file or
find file. When you consider all of these bindings, there are not many
free single depth key bindings available at all. You can increase the
number by using the 'extra' super and hyper modifiers, but as not all
keyboards have easy access to these modifiers, they are not good defaults.

> And then not everyone lives somewhere where the power is that reliable.
>

Then a UPS would be the right solution, especially as you can pick up
small UPS units for very little cost that give you enough time to save
and shutdown, plus the added benefit of most UPS units is 'conditioning'
of your power supply and providing some protection from surges and
brown-outs etc.

> 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. Of course, if they are using a good editor, it will
automatically create a backup file for them. 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. 

> 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. If you are forced to use such unreliable setups, then you need
better solutions than just hitting save every few minutes.  

Of course, even if you have an unreliable OS, at least with emacs you
know your files are auto-saved regularly and you can configure things to
automatically create backups. 

There is little justification for wasting valuable single depth key
bindings for saving and opening files. 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. 

It should also be noted that the selection of key bindings in emacs is
not as arbitrary as it may seem. There is a pattern and the single depth
bindings have been worked out over many years based on user experience.
While many people may find them alien because of what they have used
before, their efficiency is very good. Yes, we here reports of people
who have developed RSI using emacs, 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). 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 i.e. they have a predisposition for getting rsi. At the
end of the day, emacs, like any other bit of software is good for some
and not for others. If enough find it good, it will stand the test of
time, otherwise it will fade away and be forgotten. At the end of the
day, it isn't that important. 

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. This is the real power of emacs - its not how it
comes '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.

Tim

-- 
tcross (at) rapttech dot com dot au

Keyboarding [Re: What's your favourite *under_publicized* editing feature ofEmacs?]

[Xah Lee]

here are some points i think most programers are not aware of when
discussing keybinding choices or keyboard practices.

• what keyboard you use matters a lot. e.g. full sized keyboard vs
laptop keyboard. Apparently, a lot programers today half of the time
are using laptop keyboards. Even between full sized keyboard, there
are major differences that effect keybinding design. e.g. standard pc
keyboard vs split ergonomic ones vs such as Kinesis.

• there's major difference between those who touch type and those who
don't. Good typing tips or keybinding design for one is usually not
good for the other.

• expected amount of typing per day matters a lot. Good advices for
programers are not good for heavy duty data entry clerks. Among
programers, the actual amount of typing varies a lot too. Good advices
or key choices for 3 hours per day typer is different for designs for
those 6 hours per day.

here's some examples:

some programer claim to have used certain habit for n decades and
never have a problem. Sure. Maybe the actual time their fingers are
pushing keys is just 4 hours per day. If they do data entry work,
perhaps they'll have RSI within a week.

some programer claim hunt'n'peck is best practice to avoid RSI. This
is like saying the best way to avoid sport injury is not to go pro.
Sure, you can hunt'n'peck as a programer and still be considered a
fast coder, but don't think that is a good advise about typing
ergonomics.

some programer will claim that they do fine on normal straight pc
keyboard and conclude that those curved split ergonomic keyboard are
not useful or “depends”. Be careful here. This does not mean the
ergonomic quality of keyboards amount to just personal preferences.

you can test many aspects of keyboarding yourself and for yourself,
since scientific report usually seems remote and impersonal. You can
conduct experiment to see which key choices are better among 2. Or,
which of the 2 keyboard is more ergonomic. Or, whether swapping Ctrl
and Caps Lock is better or Ctrl Alt.  You just have to be careful in
the experiement in eliminating bias, such as your habit, familiarity.
This is especially important when you give out your advices to others.

〈Keyboards, Layouts, Hotkeys, Macros, RSI〉
http://xahlee.org/Periodic_dosage_dir/keyboarding.html

 Xah

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

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

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

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

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

...

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

You're joking.

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

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

"Then let them eat UPS cake!"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Confirmed: emacs fanatic.

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

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

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

By the Marquis de Sade.

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

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

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

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

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

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

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

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

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

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

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

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

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

Except to its cultists, of course.

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

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

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

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Óscar Fuentes]

Cthun <cthun_117@qmail.net.au> writes:

> On 23/02/2011 2:07 AM, Tim X wrote:
>> Cthun<cthun_117@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]

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Tim X]

Cthun <cthun_117@qmail.net.au> writes:

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

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[trebol55555]

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

Trebol.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 23/02/2011 5:57 PM, Tim X wrote:
> Cthun<cthun_117@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.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Brendan Halpin]

On Wed, Feb 23 2011, Cthun wrote:

>> On Feb 22, 9:06 pm, Cthun<cthun_...@qmail.net.au>  wrote:
>>> 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.

[...]

> And then not everyone lives somewhere where the power is that reliable.

You do realise Emacs has autosave?

Brendan
-- 
Brendan Halpin,  Department of Sociology,  University of Limerick,  Ireland
Tel: w +353-61-213147 f +353-61-202569 h +353-61-338562; Room F1-009 x 3147
mailto:brendan.halpin@ul.ie  http://www.ul.ie/sociology/brendan.halpin.html

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Rafe Kettler]

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

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

Rafe

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Ilya Zakharevich]

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

LOL!

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

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

Puzzled,
Ilya

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Deniz Dogan]

2011/2/23 Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2011-02-23, Rafe Kettler <rafe.kettler@gmail.com> wrote:
>> 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?
>

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.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 23/02/2011 1:33 PM, Ilya Zakharevich wrote:
> On 2011-02-23, Rafe Kettler<rafe.kettler@gmail.com>  wrote:
>>> And then, of course, there's the tendency of operating systems to
>>> blue-screen, laptops to overheat and hang, etc. no matter how stable the
>>> editor application is.
>>
>> You must be a Windows user. You must also not be an Emacs power user,
>> because you think it's acceptable to use the arrow keys as cursors.
>
> LOL!
>
>> If you don't, please use C-b, C-f, C-p, and C-n in place of the
>> arrow keys. It dramatically improves speed.
>
> But my driving speed is most of the time limited by applicable laws.
> Even if using these keys would improve speed of my car, would not I
> get more tickets?

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.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 23/02/2011 12:15 PM, Rafe Kettler wrote:
> You must be a Windows user. You must also not be an Emacs power user

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

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

It *is* what they're there for.

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

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

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

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

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Pascal J. Bourguignon]

Cthun <cthun_117@qmail.net.au> writes:

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


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


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



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

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

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 23/02/2011 6:46 PM, Pascal J. Bourguignon wrote:
> Cthun<cthun_117@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.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Stefan Monnier]

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

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


        Stefan

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Leo]

On 2011-02-24 11:58 +0800, Stefan Monnier wrote:
> 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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Richard Riley]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> You must be a Windows user. You must also not be an Emacs power user,
>> because you think it's acceptable to use the arrow keys as cursors. If
>> you don't, please use C-b, C-f, C-p, and C-n in place of the arrow
>> keys. It dramatically improves speed.
>
> I'll let you judge whether I qualify as "Emacs power user", but I use
> the mouse and the arrow keys fairly heavily.

Ditto with regard to the arrows. Most people I know who use emacs all
use the arrows keys too.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[despen]

Richard Riley <rileyrg@googlemail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> You must be a Windows user. You must also not be an Emacs power user,
>>> because you think it's acceptable to use the arrow keys as cursors. If
>>> you don't, please use C-b, C-f, C-p, and C-n in place of the arrow
>>> keys. It dramatically improves speed.
>>
>> I'll let you judge whether I qualify as "Emacs power user", but I use
>> the mouse and the arrow keys fairly heavily.
>
> Ditto with regard to the arrows. Most people I know who use emacs all
> use the arrows keys too.

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.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[fortunatus]

On Feb 23, 12:15 pm, Rafe Kettler <rafe.kett...@gmail.com> wrote:
> 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!!

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Xah Lee]

2011-02-24

On Feb 24, 6:43 am, fortunatus <daniel.elia...@excite.com> wrote:
> On Feb 23, 12:15 pm, Rafe Kettler <rafe.kett...@gmail.com> wrote:
>
> > 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!!

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/

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Eric Schulte]

Hi Xah,

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

[2]  https://github.com/technomancy/emacs-starter-kit/tree

[3]  http://eschulte.github.com/emacs-starter-kit/

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 24/02/2011 12:48 PM, Eric Schulte wrote:
> 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.?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Xah Lee]

On Feb 24, 9:48 am, "Eric Schulte" <schulte.e...@gmail.com> wrote:
> Hi Xah,
>
> 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
>
> [2]  https://github.com/technomancy/emacs-starter-kit/tree
>
> [3]  http://eschulte.github.com/emacs-starter-kit/

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/

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[javax.swing.JSnarker]

On 24/02/2011 6:14 PM, Xah Lee wrote:
> 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.

-- 
In <iijn58$ccs$1@news.albasani.net>, Lew admitted:
 > The JLS is obfuscatory in parts

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Alan Mackenzie]

In comp.emacs Xah Lee <xahlee@gmail.com> wrote:

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[rusi]

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?

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Alan Mackenzie]

Hi, Rusi,

In comp.emacs rusi <rustompmody@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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Thien-Thi Nguyen]

() Alan Mackenzie <acm@muc.de>
() 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.)

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[rusi]

On Feb 25, 11:54 pm, Alan Mackenzie <a...@muc.de> wrote:

> 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?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[javax.swing.JSnarker]

On 24/02/2011 9:43 AM, fortunatus wrote:
> On Feb 23, 12:15 pm, Rafe Kettler<rafe.kett...@gmail.com>  wrote:
>> 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!!

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Deniz Dogan]

2011/2/24 fortunatus <daniel.eliason@excite.com>:
> On Feb 23, 12:15 pm, Rafe Kettler <rafe.kett...@gmail.com> wrote:
>> 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!!
>

Possibly, assuming you're in "normal mode" or whatever they call it.
And assuming that you use QWERTY.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[D Herring]

On 02/22/2011 09: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.). It's also nice to have a
> slightly more complex incantation for save so that you don't save
> anything you might not want to (I know you can undo but if you don't
> realize what you did you could be in for a problem).

Emacs already uses autosave "#file#"s (see auto-save-timeout, 
auto-save-interval, etc.).  You don't have to do manual saves to guard 
against accidental loss.

My main reasons for saving are to make changes visible to other 
programs (e.g. gitk or a compiler).  But this key sequence doesn't 
slow that down noticeably.  Just remember C-x opens the file menu and 
C-s selects save...

- Daniel

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Tim X]

Cthun <cthun_117@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.

Tim
-- 
tcross (at) rapttech dot com dot au

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

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

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

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

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

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

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Eli Zaretskii]

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

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

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

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Jason Earl]

On Wed, Feb 23 2011, Cthun wrote:

> On 23/02/2011 12:22 AM, Tim X wrote:
>> Cthun<cthun_117@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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

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

Oh, wonderful.

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

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

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

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

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

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

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

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

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

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

Thanks, but no thanks.

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

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

Ah, progress ...

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

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

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

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

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

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Jason Earl]

On Wed, Feb 23 2011, Cthun wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

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

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

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

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

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

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

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

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

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

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

Precisely one of my points, Earl.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hardly a real scream, Earl.

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

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

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

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[PJ Weisberg]

On Wed, Feb 23, 2011 at 7:13 AM, Cthun <cthun_117@qmail.net.au> wrote:

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

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

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

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

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

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

-PJ

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Todd Wylie]

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


On Feb 23, 2011, at 11:19 PM, PJ Weisberg wrote:

> On Wed, Feb 23, 2011 at 7:13 AM, Cthun <cthun_117@qmail.net.au> wrote:
> 
>> The other option is auto-save to some temporary file, or a sequence of
>> numbered files. Of course if you have a power outage or something now you
>> have to go hunting for where the darn thing saved these. Depending, they may
> 
> More likely, the editor will just ask you if you want to recover the
> auto-saved version the next time you open the file.  (Or do what Emacs
> does, which is open the file normally but display a message suggesting
> you execute "M-x recover-this-file".)
> 
>> even be vulnerable to being erased by an automatic temp file cleanup script
>> before you get to them.
> 
> If you choose to run such a script, I would recommend using one that
> only deletes files that are several days old.
> 
>> Sequences of numbered files used to risk filling up the filesystem, too, but
>> not with text files in this day and age.
> 
> If you're concerned about that, customize kept-old-versions and/or
> kept-new-versions to manage the number of backup versions that are
> saved.
> 
> -PJ

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[PJ Weisberg]

On Wed, Feb 23, 2011 at 9:38 PM, Todd Wylie <todd@monkeybytes.org> wrote:
> 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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Jim Janney]

Tim X <timx@nospam.dev.null> writes:

> Cthun <cthun_117@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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

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.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[PJ Weisberg]

It strikes me that a novel would probably benefit more from version
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.

On 2/25/11, Cthun <cthun_117@qmail.net.au> 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.
>


-- 

-PJ

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Stefan Monnier]

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

Don't know about novels, but at least revision control works very well
for academic publications.


        Stefan

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 26/02/2011 3:13 PM, Stefan Monnier 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.
>
> Don't know about novels, but at least revision control works very well
> for academic publications.

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.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[David Kastrup]

Cthun <cthun_117@qmail.net.au> writes:

> On 26/02/2011 3:13 PM, Stefan Monnier 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.
>>
>> Don't know about novels, but at least revision control works very well
>> for academic publications.
>
> 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"
<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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 27/02/2011 3:08 AM, David Kastrup wrote:
> Cthun <cthun_117@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.

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.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[David Kastrup]

Cthun <cthun_117@qmail.net.au> writes:

> On 27/02/2011 3:08 AM, David Kastrup wrote:
>> Cthun <cthun_117@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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 27/02/2011 10:46 AM, David Kastrup wrote:
> Cthun<cthun_117@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!

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Julian Bradfield]

["Followup-To:" header set to comp.emacs, since this has nothing to do
 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 <cthun_117@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.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 27/02/2011 12:28 PM, Julian Bradfield wrote:
> On 2011-02-27, Cthun <cthun_117@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 X with X

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.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Alan Mackenzie]

In comp.emacs Cthun <cthun_117@qmail.net.au> wrote:
> On 27/02/2011 12:28 PM, Julian Bradfield wrote:
>> On 2011-02-27, Cthun <cthun_117@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!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 27/02/2011 3:41 PM, Alan Mackenzie wrote:
> In comp.emacs Cthun<cthun_117@qmail.net.au>  wrote:
>> On 27/02/2011 12:28 PM, Julian Bradfield wrote:
>>> On 2011-02-27, Cthun<cthun_117@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.

Who is "Thun", Mackenzie? There is nobody in this newsgroup using that 
alias.

> You ignore somebody's Followup-To: header (perfectly politely inserted)

He posted personal attacks in comp.lang.lisp. I am going to rebut those 
before the same audience. Had I not ignored his Followup-To: header, 
comp.lang.lisp readers would likely have seen his attacks apparently go 
unrebutted and may even have believed some of them as a result.

> Get ye gone, third rate troll!

Who is "third rate troll", Mackenzie? There is nobody in this newsgroup 
using that alias.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Robert D. Crawford]

Cthun <cthun_117@qmail.net.au> writes:

> What does your classic unsubstantiated and erroneous claim, combined
> with a classic contradiction, have to do with Lisp, Bradfield?

I just wanted to say that, if you used emacs, you would be able to save
yourself untold amounts of typing by using Yasnippet to insert this
constant refrain.

Just a thought.
-- 
Robert D. Crawford                                     robdcraw@gmail.com

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Tim Bradshaw]

On 2011-02-27 17:28:50 +0000, Julian Bradfield said:
> 
> 
>> 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?

This is nothing to do with being an academic.  What happens when, for 
instance, a novel is being published? The author sends it to the 
publisher, who sends back a copy with various changes, which the author 
then either accepts, accepts in some modified form, or rejects.  This 
process is then iterated several times.  I've not written a novel, but 
I know people who have reasonably recently, and they did it using the 
revision-tracking stuff in Word.  Unquestionably a proper 
revision-control system would have been better (the critical thing is a 
visual diff tool).

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 27/02/2011 3:58 PM, Tim Bradshaw wrote:
> This is nothing to do with being an academic. What happens when, for
> instance, a novel is being published? The author sends it to the
> publisher, who sends back a copy with various changes, which the author
> then either accepts, accepts in some modified form, or rejects. This
> process is then iterated several times.

And this process does not involve a CVS repository.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[David Kastrup]

Cthun <cthun_117@qmail.net.au> writes:

> On 27/02/2011 3:58 PM, Tim Bradshaw wrote:
>> This is nothing to do with being an academic. What happens when, for
>> instance, a novel is being published? The author sends it to the
>> publisher, who sends back a copy with various changes, which the author
>> then either accepts, accepts in some modified form, or rejects. This
>> process is then iterated several times.
>
> And this process does not involve a CVS repository.

With me, it nowadays usually involves a git repository.  I used CVS
previously, but that is less convenient.

-- 
David Kastrup

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 27/02/2011 4:12 PM, David Kastrup wrote:
> Cthun<cthun_117@qmail.net.au>  writes:
>> On 27/02/2011 3:58 PM, Tim Bradshaw wrote:
>>> This is nothing to do with being an academic. What happens when, for
>>> instance, a novel is being published? The author sends it to the
>>> publisher, who sends back a copy with various changes, which the author
>>> then either accepts, accepts in some modified form, or rejects. This
>>> process is then iterated several times.
>>
>> And this process does not involve a CVS repository.
>
> With me, it nowadays usually involves a git repository.  I used CVS
> previously, but that is less convenient.

You're insane.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Stefan Monnier]

>>>> This is nothing to do with being an academic. What happens when, for
>>>> instance, a novel is being published? The author sends it to the
>>>> publisher, who sends back a copy with various changes, which the author
>>>> then either accepts, accepts in some modified form, or rejects. This
>>>> process is then iterated several times.
>>> And this process does not involve a CVS repository.
>> With me, it nowadays usually involves a git repository.  I used CVS
>> previously, but that is less convenient.
> You're insane.

No, we're just people using good tools for the job at hand.  E.g. each
co-author has his branch and uses pull&push&merge to share its work with
the others.


        Stefan

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>> This is nothing to do with being an academic. What happens when, for
>>>>> instance, a novel is being published? The author sends it to the
>>>>> publisher, who sends back a copy with various changes, which the author
>>>>> then either accepts, accepts in some modified form, or rejects. This
>>>>> process is then iterated several times.
>>>> And this process does not involve a CVS repository.
>>> With me, it nowadays usually involves a git repository.  I used CVS
>>> previously, but that is less convenient.
>> You're insane.
>
> No, we're just people using good tools for the job at hand.  E.g. each
> co-author has his branch and uses pull&push&merge to share its work with
> the others.

I do this for work I do quite by myself (like theses and articles).
Makes it much easier to keep track of work you do.  Co-authors tend to
use different (or no) version control, so even when I used CVS, the
workflow tended to be that of a non-central version control system.  I
certainly would not have given others write access to my personal
repositories.

-- 
David Kastrup

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 28/02/2011 4:53 AM, David Kastrup wrote:
> Stefan Monnier<monnier@iro.umontreal.ca>  writes:
>
>>>>>> This is nothing to do with being an academic. What happens when, for
>>>>>> instance, a novel is being published? The author sends it to the
>>>>>> publisher, who sends back a copy with various changes, which the author
>>>>>> then either accepts, accepts in some modified form, or rejects. This
>>>>>> process is then iterated several times.
>>>>> And this process does not involve a CVS repository.
>>>> With me, it nowadays usually involves a git repository.  I used CVS
>>>> previously, but that is less convenient.
>>> You're insane.
>>
>> No

What does Monnier's classic unsubstantiated and erroneous claim have to 
do with Lisp, Kastrup?

> I do this for work I do quite by myself (like theses and articles).

How odd.

> Makes it much easier to keep track of work you do.

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Kastrup? Using version control software entails a lot of 
complex use of command-line tools to check out, copy, and check in 
files, Kastrup, and that's after scaling the software's learning curve. 
This hardly seems likely to be "much easier" than just using a word 
processor like normal folk, Kastrup.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Eric Abrahamsen]

On Tue, Mar 01 2011, Cthun wrote:

> On 28/02/2011 4:53 AM, David Kastrup wrote:
>> Stefan Monnier<monnier@iro.umontreal.ca>  writes:
>>
>>>>>>> This is nothing to do with being an academic. What happens when, for
>>>>>>> instance, a novel is being published? The author sends it to the
>>>>>>> publisher, who sends back a copy with various changes, which the author
>>>>>>> then either accepts, accepts in some modified form, or rejects. This
>>>>>>> process is then iterated several times.
>>>>>> And this process does not involve a CVS repository.
>>>>> With me, it nowadays usually involves a git repository.  I used CVS
>>>>> previously, but that is less convenient.
>>>> You're insane.
>>>
>>> No
>
> What does Monnier's classic unsubstantiated and erroneous claim have
> to do with Lisp, Kastrup?

I started out sympathetic to your argument, but by this point you've
motivated me to dig up the gnus manual section on scoring, just to learn
how to mute you.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Ted Zlatanov]

On Tue, 01 Mar 2011 03:03:57 +0800 Eric Abrahamsen <eric@ericabrahamsen.net> wrote: 

EA> you've motivated me to dig up the gnus manual section on scoring,
EA> just to learn how to mute you.

`L a s p' to lower permanently by author substring.  Or you could lower
the thread score.  Anyhow, `L' is what you need, the rest is just
answering prompts.

Ted

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[David Kastrup]

Cthun <cthun_117@qmail.net.au> writes:

> On 28/02/2011 4:53 AM, David Kastrup wrote:
>> Stefan Monnier<monnier@iro.umontreal.ca>  writes:
>>
>>>>>>> This is nothing to do with being an academic. What happens when, for
>>>>>>> instance, a novel is being published? The author sends it to the
>>>>>>> publisher, who sends back a copy with various changes, which the author
>>>>>>> then either accepts, accepts in some modified form, or rejects. This
>>>>>>> process is then iterated several times.
>>>>>> And this process does not involve a CVS repository.
>>>>> With me, it nowadays usually involves a git repository.  I used CVS
>>>>> previously, but that is less convenient.
>>>> You're insane.

I should say _that_ would be an unsubstantiated claim.  Though being
insane might have something to do with Lisp.

>>> No
>
> What does Monnier's classic unsubstantiated and erroneous claim have
> to do with Lisp, Kastrup?
>
>> I do this for work I do quite by myself (like theses and articles).
>
> How odd.

Not at all.

>> Makes it much easier to keep track of work you do.
>
> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Kastrup? Using version control software entails a lot of
> complex use of command-line tools to check out, copy, and check in
> files, Kastrup,

That's why one uses a Lisp-based editor with version-control support
called Emacs to do the hard work.

> and that's after scaling the software's learning curve. This hardly
> seems likely to be "much easier" than just using a word processor like
> normal folk, Kastrup.

Your discussion style (or rather your apodictic statement style) does
not suggest that you would be able to speak for normal folk with
authority.

-- 
David Kastrup

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 28/02/2011 3:04 PM, David Kastrup wrote:
> Cthun<cthun_117@qmail.net.au>  writes:
>
>> On 28/02/2011 4:53 AM, David Kastrup wrote:
>>> Stefan Monnier<monnier@iro.umontreal.ca>   writes:
>>>
>>>>>> With me, it nowadays usually involves a git repository.  I used CVS
>>>>>> previously, but that is less convenient.
>>>>> You're insane.
>
> I should say _that_ would be an unsubstantiated claim.

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

> Though being insane might have something to do with Lisp.

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Kastrup? It is well known that it is all-caps languages like 
COBOL and BASIC that cause brain damage, Kastrup.

>>> I do this for work I do quite by myself (like theses and articles).
>>
>> How odd.
>
> Not at all.

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

>>> Makes it much easier to keep track of work you do.
>>
>> What does your classic unsubstantiated and erroneous claim have to do
>> with Lisp, Kastrup? Using version control software entails a lot of
>> complex use of command-line tools to check out, copy, and check in
>> files, Kastrup,
>
> That's why one uses a Lisp-based editor with version-control support
> called Emacs to do the hard work.

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Kastrup? Using emacs entails even more complexity and 
difficulty, with even steeper learning curves, than using version 
control tools, Kastrup.

>> and that's after scaling the software's learning curve. This hardly
>> seems likely to be "much easier" than just using a word processor like
>> normal folk, Kastrup.
>
> Your discussion style (or rather your apodictic statement style) does
> not suggest that you would be able to speak for normal folk with
> authority.

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[TheFlyingDutchman]

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

Can you be more specific? In what way was it unsubstantiated? How was
it erroneous? What made it classic?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 28/02/2011 7:14 PM, TheFlyingDutchman wrote:
>>
>> What does your classic unsubstantiated and erroneous claim have to do
>> with Lisp, Kastrup?
>
> Can you be more specific? In what way was it unsubstantiated? How was
> it erroneous? What made it classic?

What do your four questions have to do with Lisp, Dutchman?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[TheFlyingDutchman]

On Feb 28, 4:16 pm, Cthun <cthun_...@qmail.net.au> wrote:
> On 28/02/2011 7:14 PM, TheFlyingDutchman wrote:
>
>
>
> >> What does your classic unsubstantiated and erroneous claim have to do
> >> with Lisp, Kastrup?
>
> > Can you be more specific? In what way was it unsubstantiated? How was
> > it erroneous? What made it classic?
>
> What do your four questions have to do with Lisp, Dutchman?

What does your one question have to do with Lisp, Cthun?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Sean Sieger]

TheFlyingDutchman <zzbbaadd@aol.com> writes:

    On Feb 28, 4:16 pm, Cthun <cthun_...@qmail.net.au> wrote:

    > What do your four questions have to do with Lisp, Dutchman?

    What does your one question have to do with Lisp, Cthun?

Does he speak this way in real life??  Astonishing.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[David Kastrup]

Cthun <cthun_117@qmail.net.au> writes:

> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Kastrup? It is well known that it is all-caps languages
> like COBOL and BASIC that cause brain damage, Kastrup.

Today's Common Lisp is just as case insensitive as those.  The original
Lisp has a history dating to computers that did not support lowercase
letters in their native character set.

You are not particularly good at avoiding unsubstantiated and erroneous
claims, are you?  You don't even get the premises to your inane
conclusions right.

-- 
David Kastrup

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 01/03/2011 4:27 AM, David Kastrup wrote:
> Cthun<cthun_117@qmail.net.au>  writes:
>
>> What does your classic unsubstantiated and erroneous claim have to do
>> with Lisp, Kastrup? It is well known that it is all-caps languages
>> like COBOL and BASIC that cause brain damage, Kastrup.
>
> Today's Common Lisp is just as case insensitive as those.

Except that it's not called "COMMON LISP", Kastrup.

> You are not particularly good at avoiding unsubstantiated and erroneous
> claims, are you?

What does your classic erroneous presupposition have to do with Lisp, 
Kastrup.

> You don't even get the premises to your inane conclusions right.

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[TheFlyingDutchman]

On Mar 1, 5:52 am, Cthun <cthun_...@qmail.net.au> wrote:
> On 01/03/2011 4:27 AM, David Kastrup wrote:
>
> > Cthun<cthun_...@qmail.net.au>  writes:
>
> >> What does your classic unsubstantiated and erroneous claim have to do
> >> with Lisp, Kastrup? It is well known that it is all-caps languages
> >> like COBOL and BASIC that cause brain damage, Kastrup.
>
> > Today's Common Lisp is just as case insensitive as those.
>
> Except that it's not called "COMMON LISP", Kastrup.
>
Because it is not an acronymn, Cthun.  COBOL and BASIC are not
capitalized to do how their language handles case but because they are
acronyms:

COBOL - COmmon Business-Oriented Language
BASIC - Beginner's All-Purpose Symbolic Instruction Code

Acronyms are all-caps, whereas words are only capitalized, Cthun.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 01/03/2011 5:51 PM, TheFlyingDutchman wrote:
> On Mar 1, 5:52 am, Cthun<cthun_...@qmail.net.au>  wrote:
>> On 01/03/2011 4:27 AM, David Kastrup wrote:
>>
>>> Cthun<cthun_...@qmail.net.au>    writes:
>>
>>>> What does your classic unsubstantiated and erroneous claim have to do
>>>> with Lisp, Kastrup? It is well known that it is all-caps languages
>>>> like COBOL and BASIC that cause brain damage, Kastrup.
>>
>>> Today's Common Lisp is just as case insensitive as those.
>>
>> Except that it's not called "COMMON LISP", Kastrup.
>
> Because it is not an acronymn, Cthun.

What does that have to do with emacs, Dutchman?

The languages whose names are in all caps seem to be the ones that cause 
brain damage, Dutchman, and Common Lisp is not among them.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[David Kastrup]

Cthun <cthun_117@qmail.net.au> writes:

> On 01/03/2011 5:51 PM, TheFlyingDutchman wrote:
>> On Mar 1, 5:52 am, Cthun<cthun_...@qmail.net.au>  wrote:
>>> On 01/03/2011 4:27 AM, David Kastrup wrote:
>>>
>>>> Cthun<cthun_...@qmail.net.au>    writes:
>>>
>>>>> What does your classic unsubstantiated and erroneous claim have to do
>>>>> with Lisp, Kastrup? It is well known that it is all-caps languages
>>>>> like COBOL and BASIC that cause brain damage, Kastrup.
>>>
>>>> Today's Common Lisp is just as case insensitive as those.
>>>
>>> Except that it's not called "COMMON LISP", Kastrup.
>>
>> Because it is not an acronymn, Cthun.
>
> What does that have to do with emacs, Dutchman?

Editor MACroS.

-- 
David Kastrup

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 02/03/2011 3:22 AM, David Kastrup wrote:
> Cthun<cthun_117@qmail.net.au>  writes:
>> On 01/03/2011 5:51 PM, TheFlyingDutchman wrote:
>>> On Mar 1, 5:52 am, Cthun<cthun_...@qmail.net.au>   wrote:
>>>> Except that it's not called "COMMON LISP", Kastrup.
>>>
>>> Because it is not an acronymn, Cthun.
>>
>> What does that have to do with emacs, Dutchman?
>
> Editor MACroS.

Classic illogic. "Common Lisp" not being an acronym has nothing to do 
with emacs, Dutchman.

Cthun-bot discussion

[TheFlyingDutchman]

On Mar 2, 6:33 am, Cthun <cthun_...@qmail.net.au> wrote:
> On 02/03/2011 3:22 AM, David Kastrup wrote:
>
> > Cthun<cthun_...@qmail.net.au>  writes:
> >> On 01/03/2011 5:51 PM, TheFlyingDutchman wrote:
> >>> On Mar 1, 5:52 am, Cthun<cthun_...@qmail.net.au>   wrote:
> >>>> Except that it's not called "COMMON LISP", Kastrup.
>
> >>> Because it is not an acronymn, Cthun.
>
> >> What does that have to do with emacs, Dutchman?
>
> > Editor MACroS.
>
> Classic illogic. "Common Lisp" not being an acronym has nothing to do
> with emacs, Dutchman.

Oops. A serious bug in the Cthun-bot. Incorrectly picked up who it was
responding to.

Re: Cthun-bot discussion

[Cthun]

On 02/03/2011 4:51 PM, TheFlyingDutchman wrote:
>> Classic illogic. "Common Lisp" not being an acronym has nothing to do
>> with emacs, Dutchman.
>
> Oops. A serious bug in the Cthun-bot. Incorrectly picked up who it was
> responding to.

Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using 
that alias.

Cthun-bot discussion

[TheFlyingDutchman]

On Mar 2, 2:20 pm, Cthun <cthun_...@qmail.net.au> wrote:
> On 02/03/2011 4:51 PM, TheFlyingDutchman wrote:
>
> >> Classic illogic. "Common Lisp" not being an acronym has nothing to do
> >> with emacs, Dutchman.
>
> > Oops. A serious bug in the Cthun-bot. Incorrectly picked up who it was
> > responding to.
>
> Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using
> that alias.

Just to prevent confusion here, the Chun-bot has incorrectly referred
to it's name as an alias. Cthun-bot is the actual name of the Cthun-
bot, not an alias. The alias of the Cthun-bot is Cthun.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 02/03/2011 6:54 PM, TheFlyingDutchman wrote:
> On Mar 2, 2:20 pm, Cthun<cthun_...@qmail.net.au>  wrote:
>> On 02/03/2011 4:51 PM, TheFlyingDutchman wrote:
>>>> Classic illogic. "Common Lisp" not being an acronym has nothing to do
>>>> with emacs, Dutchman.
>>
>>> Oops. A serious bug in the Cthun-bot. Incorrectly picked up who it was
>>> responding to.
>>
>> Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using
>> that alias.
>
> Just to prevent confusion here, the Chun-bot has incorrectly referred
> to it's name as an alias. Cthun-bot is the actual name of the Cthun-
> bot, not an alias. The alias of the Cthun-bot is Cthun.

Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using 
that alias.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Jason Earl]

On Wed, Mar 02 2011, Cthun wrote:

> On 02/03/2011 6:54 PM, TheFlyingDutchman wrote:
>> On Mar 2, 2:20 pm, Cthun<cthun_...@qmail.net.au>  wrote:
>>> On 02/03/2011 4:51 PM, TheFlyingDutchman wrote:
>>>>> Classic illogic. "Common Lisp" not being an acronym has nothing to do
>>>>> with emacs, Dutchman.
>>>
>>>> Oops. A serious bug in the Cthun-bot. Incorrectly picked up who it was
>>>> responding to.
>>>
>>> Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using
>>> that alias.
>>
>> Just to prevent confusion here, the Chun-bot has incorrectly referred
>> to it's name as an alias. Cthun-bot is the actual name of the Cthun-
>> bot, not an alias. The alias of the Cthun-bot is Cthun.
>
> Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using
> that alias.

You are the Cthun-bot, your alias is Cthun.

Jason

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 02/03/2011 7:06 PM, Jason Earl wrote:
> On Wed, Mar 02 2011, Cthun wrote:
>> Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using
>> that alias.
>
> You are the Cthun-bot

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

> your alias is Cthun.

What does that have to do with Lisp, Earl?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Marco Antoniotti]

On Mar 3, 1:06 am, Jason Earl <je...@notengoamigos.org> wrote:
> On Wed, Mar 02 2011, Cthun wrote:
> > On 02/03/2011 6:54 PM, TheFlyingDutchman wrote:
> >> On Mar 2, 2:20 pm, Cthun<cthun_...@qmail.net.au>  wrote:
> >>> On 02/03/2011 4:51 PM, TheFlyingDutchman wrote:
> >>>>> Classic illogic. "Common Lisp" not being an acronym has nothing to do
> >>>>> with emacs, Dutchman.
>
> >>>> Oops. A serious bug in the Cthun-bot. Incorrectly picked up who it was
> >>>> responding to.
>
> >>> Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using
> >>> that alias.
>
> >> Just to prevent confusion here, the Chun-bot has incorrectly referred
> >> to it's name as an alias. Cthun-bot is the actual name of the Cthun-
> >> bot, not an alias. The alias of the Cthun-bot is Cthun.
>
> > Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using
> > that alias.
>
> You are the Cthun-bot, your alias is Cthun.

Not only... the bot is written in Common Lisp (as tfb confessed :) ),
hence its psychology :)

Cheers
--
MA

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[David Kastrup]

Marco Antoniotti <marcoxa@gmail.com> writes:

> On Mar 3, 1:06 am, Jason Earl <je...@notengoamigos.org> wrote:
>> On Wed, Mar 02 2011, Cthun wrote:
>> > On 02/03/2011 6:54 PM, TheFlyingDutchman wrote:
>> >> On Mar 2, 2:20 pm, Cthun<cthun_...@qmail.net.au>  wrote:
>> >>> On 02/03/2011 4:51 PM, TheFlyingDutchman wrote:
>> >>>>> Classic illogic. "Common Lisp" not being an acronym has nothing to do
>> >>>>> with emacs, Dutchman.
>>
>> >>>> Oops. A serious bug in the Cthun-bot. Incorrectly picked up who it was
>> >>>> responding to.
>>
>> >>> Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using
>> >>> that alias.
>>
>> >> Just to prevent confusion here, the Chun-bot has incorrectly referred
>> >> to it's name as an alias. Cthun-bot is the actual name of the Cthun-
>> >> bot, not an alias. The alias of the Cthun-bot is Cthun.
>>
>> > Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using
>> > that alias.
>>
>> You are the Cthun-bot, your alias is Cthun.
>
> Not only... the bot is written in Common Lisp (as tfb confessed :) ),
> hence its psychology :)

Well, the overuse of keywords is quite glaring.

-- 
David Kastrup

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 03/03/2011 5:21 AM, David Kastrup wrote:
> Marco Antoniotti <marcoxa@gmail.com> writes:
>> On Mar 3, 1:06 am, Jason Earl <je...@notengoamigos.org> wrote:
>>> On Wed, Mar 02 2011, Cthun wrote:
>>>> Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using
>>>> that alias.
>>>
>>> You are the Cthun-bot

What does Earl's classic unsubstantiated and erroneous claim have to do 
with Lisp, Kastrup?

>>> your alias is Cthun.

What does that have to do with Lisp, Antoniotti?

>> Not only... the bot is written in Common Lisp (as tfb confessed :) ),
>> hence its psychology :)

Who is "the bot", Kastrup? There is nobody in this newsgroup using that 
alias.

> Well, the overuse of keywords is quite glaring.

What does your overuse of keywords have to do with emacs, Kastrup?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 03/03/2011 5:04 AM, Marco Antoniotti wrote:
> On Mar 3, 1:06 am, Jason Earl <je...@notengoamigos.org> wrote:
>> On Wed, Mar 02 2011, Cthun wrote:
>>> Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using
>>> that alias.
>>
>> You are the Cthun-bot

What does Earl's classic unsubstantiated and erroneous claim have to do 
with Lisp, Antoniotti?

>> your alias is Cthun.

What does that have to do with Lisp, Antoniotti?

> Not only... the bot is written in Common Lisp (as tfb confessed :) ),
> hence its psychology :)

Who is "the bot", Antoniotti? There is nobody in this newsgroup using 
that alias.

Cthun-bot discussion

[TheFlyingDutchman]

On Mar 1, 3:43 pm, Cthun <cthun_...@qmail.net.au> wrote:
> On 01/03/2011 5:51 PM, TheFlyingDutchman wrote:
>
> > On Mar 1, 5:52 am, Cthun<cthun_...@qmail.net.au>  wrote:
> >> On 01/03/2011 4:27 AM, David Kastrup wrote:
>
> >>> Cthun<cthun_...@qmail.net.au>    writes:
>
> >>>> What does your classic unsubstantiated and erroneous claim have to do
> >>>> with Lisp, Kastrup? It is well known that it is all-caps languages
> >>>> like COBOL and BASIC that cause brain damage, Kastrup.
>
> >>> Today's Common Lisp is just as case insensitive as those.
>
> >> Except that it's not called "COMMON LISP", Kastrup.
>
> > Because it is not an acronymn, Cthun.
>
> What does that have to do with emacs, Dutchman?

Why did the Cthun-bot talk about COMMON LISP and then revert to emacs?
Are they doing any testing at all?

> The languages whose names are in all caps seem to be the ones that cause
> brain damage, Dutchman, and Common Lisp is not among them.

It is always refreshing when the Cthun-bot can spit out a sentence
that differs from it's normal small set, even if it doesn't make any
sense.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 02/03/2011 3:39 AM, TheFlyingDutchman wrote:
> On Mar 1, 3:43 pm, Cthun<cthun_...@qmail.net.au>  wrote:
>> On 01/03/2011 5:51 PM, TheFlyingDutchman wrote:
>>> On Mar 1, 5:52 am, Cthun<cthun_...@qmail.net.au>    wrote:
>>>> Except that it's not called "COMMON LISP", Kastrup.
>>
>>> Because it is not an acronymn, Cthun.
>>
>> What does that have to do with emacs, Dutchman?
>
> Why did the Cthun-bot talk about COMMON LISP and then revert to emacs?

Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using 
that alias.

> Are they doing any testing at all?

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

>> The languages whose names are in all caps seem to be the ones that cause
>> brain damage, Dutchman, and Common Lisp is not among them.
>
> It is always refreshing when the Cthun-bot can spit out a sentence
> that differs from it's normal small set

Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using 
that alias.

> even if it doesn't make any sense.

Classic unsubstantiated and erroneous claim.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Antony]

On 2/28/2011 4:06 PM, Cthun wrote:
> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Kastrup? It is well known that it is all-caps languages like
> COBOL and BASIC that cause brain damage, Kastrup.
Hmm, talking about "classic unsubstantiated and erroneous claim"s
-Antony

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 27/02/2011 10:51 PM, Stefan Monnier wrote:
>>>>> This is nothing to do with being an academic. What happens when, for
>>>>> instance, a novel is being published? The author sends it to the
>>>>> publisher, who sends back a copy with various changes, which the author
>>>>> then either accepts, accepts in some modified form, or rejects. This
>>>>> process is then iterated several times.
>>>> And this process does not involve a CVS repository.
>>> With me, it nowadays usually involves a git repository.  I used CVS
>>> previously, but that is less convenient.
>> You're insane.
>
> No

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Perry Smith]

On Feb 27, 2011, at 9:28 AM, Cthun wrote:

> On 27/02/2011 3:08 AM, David Kastrup wrote:
>> Cthun <cthun_117@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.
> 
> 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.

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Eric Abrahamsen]

On Mon, Feb 28 2011, Perry Smith wrote:

> On Feb 27, 2011, at 9:28 AM, Cthun wrote:
>
>> On 27/02/2011 3:08 AM, David Kastrup wrote:
>>> Cthun <cthun_117@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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Joe Riel]

On Mon, 28 Feb 2011 01:22:12 +0800
Eric Abrahamsen <eric@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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[PJ Weisberg]

On 2/27/11, Perry Smith <pedzsan@gmail.com> wrote:
> 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

It became clear a while ago that Cthun was just annoyed with the
original message being cross-posted to comp.lang.list and is now just
trying to piss off Emacs users as much as possible.  Reply if you
enjoy debating for its own sake,  but don't expect any productive
discussion.  (I doubt he sees this reply, since I'm sending to
help-gnu-emacs@gnu.org, but I don't know how the mail<=>news gateway
actually works.)

-PJ

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Stefan Monnier]

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

Note that most of those tools don't actually care about lines, or may
not even use lines that much internally.  The only part that uses lines
is the default tool that provides a visual diff, as well as the default
tool that performs 3-way merges.

But yes, they tend to be tuned for source code, and prose tends to work
less well.  FWIW, to come back to Emacs, diff-mode and smerge-mode both
support word-grained highlighting of differences, so while the diff
hunks and merge conflicts will include whole paragraphs rather than just
lines, the `refine'd highlighting will let you see which parts have
really changed.  I implemented this specifically to address this problem
when working with LaTeX documents.  At some point, I guess we should
improve that support to provide word-grained diffs and merge conflicts,
which will require a different format since context diffs and diff3
conflict markers are inherently line-based.


        Stefan

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[rusi]

On Feb 28, 8:58 am, Stefan Monnier <monn...@iro.umontreal.ca> 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.
>
> Note that most of those tools don't actually care about lines, or may
> not even use lines that much internally.  The only part that uses lines
> is the default tool that provides a visual diff, as well as the default
> tool that performs 3-way merges.
>
> But yes, they tend to be tuned for source code, and prose tends to work
> less well.  FWIW, to come back to Emacs, diff-mode and smerge-mode both
> support word-grained highlighting of differences, so while the diff
> hunks and merge conflicts will include whole paragraphs rather than just
> lines, the `refine'd highlighting will let you see which parts have
> really changed.  I implemented this specifically to address this problem
> when working with LaTeX documents.  At some point, I guess we should
> improve that support to provide word-grained diffs and merge conflicts,
> which will require a different format since context diffs and diff3
> conflict markers are inherently line-based.
>
>         Stefan

For emacs (and such) this may be the way to go and is welcome.
For git (and such) however it may be preferable to have generic diff/
merge plugin capability; specifically for 'xml-container' formats like
odt and docx  but also more generically.

Personal note: I use nted
http://vsr.informatik.tu-chemnitz.de/~jan/nted/nted.xhtml
to enter music and I have a hell of a time versioning and diffing.

[eg I used a cello for one audience and organ for another, or do-re-mi
for a western audience and sa-re-ga for an Indian]

As things are I could tag such things with git (and such) but not diff/
merge and emacs is not so much use for low-level file formats.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Stefan Monnier]

> For Emacs (and such) this may be the way to go and is welcome.
> For git (and such) however it may be preferable to have generic diff/
> merge plugin capability; specifically for 'xml-container' formats like
> odt and docx  but also more generically.

Versioning documents in formats like odt is indeed a different issue:
for diffs and merges you don't want to do it at the line-level of
course, but neither do you necessarily want to do it at the XML level
itself: maybe automatic merging can be done at the XML level, but when
conflicts or diffs need to be shown to users, they have to be shown in
terms that the user can understand and most users have no idea about
odt's underlying XML representation other than that it exists.  So you
need something like OpenOffice to do the diff for you.

> Personal note: I use nted
> http://vsr.informatik.tu-chemnitz.de/~jan/nted/nted.xhtml
> to enter music and I have a hell of a time versioning and diffing.

Right: since this uses WYSIWYG you basically get the same problem: only
nted can do the diff and merge-conflict display in a way that can make
sense to the user.
If you care about revision control, you're generally better off without
WYSIWYG (I tend to think you're better off without it in any
circumstance, but that's a different discussion ;-).


        Stefan

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[rusi]

On Mar 1, 4:31 am, Stefan Monnier <monn...@iro.umontreal.ca> wrote:

> > I use nted
> > http://vsr.informatik.tu-chemnitz.de/~jan/nted/nted.xhtml
> > to enter music and I have a hell of a time versioning and diffing.
>
> Right: since this uses WYSIWYG you basically get the same problem: only
> nted can do the diff and merge-conflict display in a way that can make
> sense to the user.
> If you care about revision control, you're generally better off without
> WYSIWYG (I tend to think you're better off without it in any
> circumstance, but that's a different discussion ;-).
>

How do you enter *and play* music textually??? I would sure like a
tool that does not make me go clicking all over to get notes entered.
Something like abc http://abc.sourceforge.net/ or lilypond.
But I need something that can do this http://vimeo.com/16894001/ and
allows me to change the score live in front of a (singing) class.  Do
you know of any??

In fact I have spent some time wondering what it would mean to add
emacs' scripting functionality to nted.  In short, we would start by
factorizing emacs into 2 parts:
1. the 'pure lisp' scripting glue -- things like car, cdr, defun, cond
setq etc
2. the buffers, characters, input-methods etc that are *text* editor
specific.

For music, 2' would be provided with something like nted and then 1
can be 'married' to 2' to get a scriptable music editor/player.

With a text editor there is a clear set of 'atoms'
- "a key that is typed"
- "a character that is displayed."

For music there is no such set (at least to me) -- its too
multidimensional with staves, voices, real time rendering with etc

> > For Emacs (and such) this may be the way to go and is welcome.
> > For git (and such) however it may be preferable to have generic diff/
> > merge plugin capability; specifically for 'xml-container' formats like
> > odt and docx  but also more generically.
>
> Versioning documents in formats like odt is indeed a different issue:
> for diffs and merges you don't want to do it at the line-level of
> course, but neither do you necessarily want to do it at the XML level
> itself: maybe automatic merging can be done at the XML level, but when
> conflicts or diffs need to be shown to users, they have to be shown in
> terms that the user can understand and most users have no idea about
> odt's underlying XML representation other than that it exists.  So you
> need something like OpenOffice to do the diff for you.

Thats why I said plugin capability.  SW like openoffice (or nted)
would know how to diff 2 docs or merge 3.  The revision control
system's plugin would present it the 2 or 3 docs to diff or merge --
what vc does for emacs.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Uday Reddy]

On 2/28/2011 3:58 AM, Stefan Monnier wrote:

> FWIW, to come back to Emacs, diff-mode and smerge-mode both
> support word-grained highlighting of differences, so while the diff
> hunks and merge conflicts will include whole paragraphs rather than just
> lines, the `refine'd highlighting will let you see which parts have
> really changed.  I implemented this specifically to address this problem
> when working with LaTeX documents.

Fantastic, thanks very much Stefan.  I would like to point out that the 
refined highlighting is extremely useful for me to work with code as 
well.  It allows me to do reformatting and reindenting and such things 
without worrying about too many useless diffs showing up.  It would be 
even better if white space diffs are completely ignored by Emacs.

Cheers,
Uday

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[rusi]

On Feb 27, 9:05 pm, Perry Smith <pedz...@gmail.com> wrote:
>
> 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 :-)

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Tim Bradshaw]

On 2011-02-27 06:21:08 +0000, Cthun said:

> 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?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 27/02/2011 3:52 PM, Tim Bradshaw wrote:
> On 2011-02-27 06:21:08 +0000, Cthun said:
>
>> 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?

What word processors do is very different from what tools like CVS do 
that are designed specifically for computer source code.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Tim Bradshaw]

On 2011-02-26 06:05:22 +0000, Cthun said:

> Then woe betide you if you ever work on, say, a novel rather than a 
> computer program.

What a confused thing to say.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 26/02/2011 7:08 PM, Tim Bradshaw wrote:
> On 2011-02-26 06:05:22 +0000, Cthun said:
>
>> Then woe betide you if you ever work on, say, a novel rather than a
>> computer program.
>
> What a confused thing to say.

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Jim Janney]

Cthun <cthun_117@qmail.net.au> writes:

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

I haven't written any novels, but the purpose of a version control
system is to manage text, and this is useful in many contexts besides
computer programming: any place where you might want a compact, reliable
history of changes made to a file.  I rarely lose work due to power
failures or software crashes, but I often experiment with making changes
that I later decide not to use.  With a revision control system it's
easy to do that and still get back to a good version.  I could work
without one, but I would have to do everything more slowly and
carefully.

-- 
Jim Janney

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Petter Gustad]

Jim Janney <jjanney@shell.xmission.com> writes:

> Cthun <cthun_117@qmail.net.au> writes:
>
>> 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.
>
> I haven't written any novels, but the purpose of a version control
> system is to manage text, and this is useful in many contexts besides
> computer programming: any place where you might want a compact, reliable

I haven't written any novels either, but I've written documentation
using Emacs and LaTeX and I keep my files in a revision control system
(SCCS -> RCS -> CVS -> SVN -> GIT) which I think works great.

You can also make branches where you write new stuff and keep the
master pretty clean. You can also have other authors push into a
branch. You can clone your repo from your laptop and push whatever you
wrote while traveling onto your repo when you get home or to the
office.


//Petter

-- 
.sig removed by request. 

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 28/02/2011 6:38 AM, Jim Janney wrote:
> Cthun<cthun_117@qmail.net.au>  writes:
>
>> 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.
>
> I haven't written any novels, but the purpose of a version control
> system is to manage text

First of all, the purpose of a version control system is to manage text 
that's compilable by build tools, Janney; and moreover, word processor 
documents are typically binary files, which version control systems cope 
poorly with. Subversion's diff tool will not play nicely with .doc 
files, Janney, and without it there is little point in using version 
control.

> I rarely lose work due to power failures or software crashes

That is easily accomplished without using version control, Janney. 
Saving frequently and having a backup tool suffices for normal people.

> but I often experiment with making changes that I later decide not
> to use.  With a revision control system it's easy to do that and
> still get back to a good version.

It's much easier to do that with COPY FOO.DOC FOO.DOC.BAK, Janney.

> I could work without one, but I would have to do everything more
> slowly and carefully.

Right click, drop, "copy here" is not especially slow, particularly 
compared to learning all of the complexities of a version control 
system, Janney. Version control systems have servers, clients, complex 
command lines for checking things in and out of them, and so on and have 
to be found, downloaded, installed, and configured. You need to set up 
your router/firewall to hide the server from the rest of the internet 
for security reasons. You have to set up some loopback interface port 
for the server to use and then point the client at 127.0.0.1:portno. You 
may even have to put all those numbers on every single command line to 
check in or check out a file, depending on the software you chose, Janney.

All of this complexity, when you could just alt, f, "save as" or right 
click, "copy here" or COPY FOO.DOC FOO.DOC.BAK, Janney.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Jim Janney]

Cthun <cthun_117@qmail.net.au> writes:

> On 28/02/2011 6:38 AM, Jim Janney wrote:
>> Cthun<cthun_117@qmail.net.au>  writes:
>>
>>> 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.
>>
>> I haven't written any novels, but the purpose of a version control
>> system is to manage text
>
> First of all, the purpose of a version control system is to manage
> text that's compilable by build tools

That's a bit like saying that the purpose of Usenet is pointless
bickering; while that is one of the uses to which it's commonly put,
it's hardly the only one

> and moreover, word
> processor documents are typically binary files, which version control
> systems cope poorly with. Subversion's diff tool will not play nicely
> with .doc files, Janney, and without it there is little point in using
> version control.

I did say text; clever of you to pick up on that.

>> I rarely lose work due to power failures or software crashes
>
> That is easily accomplished without using version control,
> Janney. Saving frequently and having a backup tool suffices for normal
> people.

And it can be accomplished even more easily with Emacs and any one of a
number of version control systems.

>> but I often experiment with making changes that I later decide not
>> to use.  With a revision control system it's easy to do that and
>> still get back to a good version.
>
> It's much easier to do that with COPY FOO.DOC FOO.DOC.BAK, Janney.
>
>> I could work without one, but I would have to do everything more
>> slowly and carefully.
>
> Right click, drop, "copy here" is not especially slow, particularly
> compared to learning all of the complexities of a version control
> system, Janney. Version control systems have servers, clients, complex
> command lines for checking things in and out of them, and so on and
> have to be found, downloaded, installed, and configured. You need to
> set up your router/firewall to hide the server from the rest of the
> internet for security reasons. You have to set up some loopback
> interface port for the server to use and then point the client at
> 127.0.0.1:portno. You may even have to put all those numbers on every
> single command line to check in or check out a file, depending on the
> software you chose, Janney.

That would certainly be a lot of work, if it were indeed necessary.  It
may please you to learn that, if you're not sharing your work with
others, there are a number of version control systems -- including
Subversion -- for which none of that is necessary.  All you need is the
local file system and no server.  Good news!

> All of this complexity, when you could just alt, f, "save as" or right
> click, "copy here" or COPY FOO.DOC FOO.DOC.BAK, Janney.

That's rather more work than simply hitting a few key strokes in Emacs.
And you get less for it.

-- 
Jim Janney

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[rusi]

On Mar 1, 9:32 am, Jim Janney <jjan...@shell.xmission.com> wrote:
> Cthun <cthun_...@qmail.net.au> writes:
> > On 28/02/2011 6:38 AM, Jim Janney wrote:
> >> Cthun<cthun_...@qmail.net.au>  writes:
>
> >>> 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.
>
> >> I haven't written any novels, but the purpose of a version control
> >> system is to manage text
>
> > First of all, the purpose of a version control system is to manage
> > text that's compilable by build tools
>
> That's a bit like saying that the purpose of Usenet is pointless
> bickering; while that is one of the uses to which it's commonly put,
> it's hardly the only one

Historically, sccs tracked source and could not manage much else, in
particular binary files were a problem.

This was 40 years ago.

With rcs this stopped being true and it has been so for some 30 odd
years.

git is the most radical shift away from version control systems as
managing (source code) versions to generally managing content.

From http://marc.info/?l=linux-kernel&m=111314792424707

In many ways you can just see git as a filesystem - it's content-
addressable, and it has a notion of versioning, but I really really
designed it coming at the problem from the viewpoint of a _filesystem_
person (hey, kernels is what I do), and I actually have absolutely
_zero_
interest in creating a traditional SCM system.  -- Linus Torvalds

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 01/03/2011 1:18 AM, rusi wrote:
> On Mar 1, 9:32 am, Jim Janney<jjan...@shell.xmission.com>  wrote:
>> Cthun<cthun_...@qmail.net.au>  writes:
>>> First of all, the purpose of a version control system is to manage
>>> text that's compilable by build tools
>>
>> That's a bit like saying that the purpose of Usenet is pointless
>> bickering; while that is one of the uses to which it's commonly put,
>> it's hardly the only one

What does Janney's classic unsubstantiated and erroneous claim have to 
do with Lisp, rusi? Saying version control is for novels is like saying 
the purpose of Usenet is pointless bickering, rusi; saying it's for 
source code is like saying the purpose of Usenet is for discussion. 
Janney's mistake is rather ironic, though, considering his own 
considerable recent contributions to the misuse of Usenet for pointless 
bickering, rusi.

> Historically, sccs tracked source and could not manage much else, in
> particular binary files were a problem.

What does that have to do with Lisp, rusi?

> This was 40 years ago.

What does that have to do with Lisp, rusi?

> With rcs this stopped being true and it has been so for some 30 odd
> years.

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

> git is the most radical shift away from version control systems as
> managing (source code) versions to generally managing content.

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, rusi? I see that of a random sampling of github projects, all 
appear to be software source code development, rusi. Suffering from 
reading comprehension problems, rusi?

>  From http://marc.info/?l=linux-kernel&m=111314792424707
>
> In many ways you can just see git as a filesystem - it's content-
> addressable, and it has a notion of versioning, but I really really
> designed it coming at the problem from the viewpoint of a _filesystem_
> person (hey, kernels is what I do), and I actually have absolutely
> _zero_
> interest in creating a traditional SCM system.  -- Linus Torvalds

What does any of that have to do with Lisp, rusi?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 28/02/2011 11:32 PM, Jim Janney wrote:
> Cthun<cthun_117@qmail.net.au>  writes:
>> On 28/02/2011 6:38 AM, Jim Janney wrote:
>>> I haven't written any novels, but the purpose of a version control
>>> system is to manage text
>>
>> First of all, the purpose of a version control system is to manage
>> text that's compilable by build tools
>
> That's a bit like saying that the purpose of Usenet is pointless
> bickering

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Janney? Saying version control is for novels is like saying 
the purpose of Usenet is pointless bickering, Janney; saying it's for 
source code is like saying the purpose of Usenet is for discussion. Your 
mistake is rather ironic, though, considering your own considerable 
recent contributions to the misuse of Usenet for pointless bickering, 
Janney.

> while that is one of the uses to which it's commonly put,
> it's hardly the only one

What does that have to do with Lisp, Janney?

>> and moreover, word
>> processor documents are typically binary files, which version control
>> systems cope poorly with. Subversion's diff tool will not play nicely
>> with .doc files, Janney, and without it there is little point in using
>> version control.
>
> I did say text; clever of you to pick up on that.

Plain, unformatted ASCII text, Janney, which is hardly useful for 
writing novels and articles. Novels tend to contain italics and other 
formatting here and there, Janney, whereas articles frequently contain 
scientific and mathematical symbols that do not exist in ASCII or 
sometimes even Unicode, and tables, graphs, charts, and formatted 
equations that cannot be represented nicely using a grid of characters.

>>> I rarely lose work due to power failures or software crashes
>>
>> That is easily accomplished without using version control,
>> Janney. Saving frequently and having a backup tool suffices for normal
>> people.
>
> And it can be accomplished even more easily with Emacs and any one of a
> number of version control systems.

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Janney? Occasionally hitting control-S and backing up your 
files regularly is a lot easier than learning Emacs, Janney.

>>> I could work without one, but I would have to do everything more
>>> slowly and carefully.
>>
>> Right click, drop, "copy here" is not especially slow, particularly
>> compared to learning all of the complexities of a version control
>> system, Janney. Version control systems have servers, clients, complex
>> command lines for checking things in and out of them, and so on and
>> have to be found, downloaded, installed, and configured. You need to
>> set up your router/firewall to hide the server from the rest of the
>> internet for security reasons. You have to set up some loopback
>> interface port for the server to use and then point the client at
>> 127.0.0.1:portno. You may even have to put all those numbers on every
>> single command line to check in or check out a file, depending on the
>> software you chose, Janney.
>
> That would certainly be a lot of work, if it were indeed necessary.  It
> may please you to learn that, if you're not sharing your work with
> others, there are a number of version control systems -- including
> Subversion -- for which none of that is necessary.

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Janney? Version control systems are inherently complex and 
inherently client/server oriented, Janney; if they weren't they'd be 
useless for their primary purpose, which is to enable collaborative 
software development, Janney.

>> All of this complexity, when you could just alt, f, "save as" or right
>> click, "copy here" or COPY FOO.DOC FOO.DOC.BAK, Janney.
>
> That's rather more work than simply hitting a few key strokes in Emacs.

It's rather less work than struggling to learn, and later struggling to 
remember, those "few key strokes in Emacs", Janney. Not to mention the 
sprained wrists from tying your hands into pretzels trying to hit seven 
different modifier keys simultaneously, Janney. Emacs is not a text 
editor, Janney, it is a keyboard-implemented version of the game "Twister".

> And you get less for it.

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Janney? And it remains true that using SVN to "develop" a 
novel is like using a hammer to insert a screw, Janney.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Mario Lassnig]

On 3/1/11 3:05 PM, Cthun wrote:
> Saying version control is for novels is like saying
> the purpose of Usenet is pointless bickering, Janney; saying it's for
> source code is like saying the purpose of Usenet is for discussion. Your
> mistake is rather ironic, though, considering your own considerable
> recent contributions to the misuse of Usenet for pointless bickering,
> Janney.

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

> Plain, unformatted ASCII text, Janney, which is hardly useful for
> writing novels and articles. Novels tend to contain italics and other
> formatting here and there, Janney, whereas articles frequently contain
> scientific and mathematical symbols that do not exist in ASCII or
> sometimes even Unicode, and tables, graphs, charts, and formatted
> equations that cannot be represented nicely using a grid of characters.

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

> Occasionally hitting control-S and backing up your
> files regularly is a lot easier than learning Emacs, Janney.

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

> Version control systems are inherently complex and
> inherently client/server oriented, Janney; if they weren't they'd be
> useless for their primary purpose, which is to enable collaborative
> software development, Janney.

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

> It's rather less work than struggling to learn, and later struggling to
> remember, those "few key strokes in Emacs", Janney. Not to mention the
> sprained wrists from tying your hands into pretzels trying to hit seven
> different modifier keys simultaneously, Janney. Emacs is not a text
> editor, Janney, it is a keyboard-implemented version of the game "Twister".

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

> And it remains true that using SVN to "develop" a
> novel is like using a hammer to insert a screw, Janney.

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 01/03/2011 9:21 AM, Mario Lassnig wrote:
> On 3/1/11 3:05 PM, Cthun wrote:
>> Saying version control is for novels is like saying
>> the purpose of Usenet is pointless bickering, Janney; saying it's for
>> source code is like saying the purpose of Usenet is for discussion. Your
>> mistake is rather ironic, though, considering your own considerable
>> recent contributions to the misuse of Usenet for pointless bickering,
>> Janney.
>
> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Cthun?

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

>> Plain, unformatted ASCII text, Janney, which is hardly useful for
>> writing novels and articles. Novels tend to contain italics and other
>> formatting here and there, Janney, whereas articles frequently contain
>> scientific and mathematical symbols that do not exist in ASCII or
>> sometimes even Unicode, and tables, graphs, charts, and formatted
>> equations that cannot be represented nicely using a grid of characters.
>
> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Cthun?

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

>> Occasionally hitting control-S and backing up your
>> files regularly is a lot easier than learning Emacs, Janney.
>
> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Cthun?

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

>> Version control systems are inherently complex and
>> inherently client/server oriented, Janney; if they weren't they'd be
>> useless for their primary purpose, which is to enable collaborative
>> software development, Janney.
>
> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Cthun?

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

>> It's rather less work than struggling to learn, and later struggling to
>> remember, those "few key strokes in Emacs", Janney. Not to mention the
>> sprained wrists from tying your hands into pretzels trying to hit seven
>> different modifier keys simultaneously, Janney. Emacs is not a text
>> editor, Janney, it is a keyboard-implemented version of the game
>> "Twister".
>
> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Cthun?

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

>> And it remains true that using SVN to "develop" a
>> novel is like using a hammer to insert a screw, Janney.
>
> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Cthun?

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[rusi]

On Mar 1, 8:02 pm, Cthun <cthun_...@qmail.net.au> wrote:
> On 01/03/2011 9:21 AM, Mario Lassnig wrote:
>
> > On 3/1/11 3:05 PM, Cthun wrote:
> >> Saying version control is for novels is like saying
> >> the purpose of Usenet is pointless bickering, Janney; saying it's for
> >> source code is like saying the purpose of Usenet is for discussion. Your
> >> mistake is rather ironic, though, considering your own considerable
> >> recent contributions to the misuse of Usenet for pointless bickering,
> >> Janney.
>
> > What does your classic unsubstantiated and erroneous claim have to do
> > with Lisp, Cthun?
>
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?
>
> >> Plain, unformatted ASCII text, Janney, which is hardly useful for
> >> writing novels and articles. Novels tend to contain italics and other
> >> formatting here and there, Janney, whereas articles frequently contain
> >> scientific and mathematical symbols that do not exist in ASCII or
> >> sometimes even Unicode, and tables, graphs, charts, and formatted
> >> equations that cannot be represented nicely using a grid of characters.
>
> > What does your classic unsubstantiated and erroneous claim have to do
> > with Lisp, Cthun?
>
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?
>
> >> Occasionally hitting control-S and backing up your
> >> files regularly is a lot easier than learning Emacs, Janney.
>
> > What does your classic unsubstantiated and erroneous claim have to do
> > with Lisp, Cthun?
>
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?
>
> >> Version control systems are inherently complex and
> >> inherently client/server oriented, Janney; if they weren't they'd be
> >> useless for their primary purpose, which is to enable collaborative
> >> software development, Janney.
>
> > What does your classic unsubstantiated and erroneous claim have to do
> > with Lisp, Cthun?
>
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?
>
> >> It's rather less work than struggling to learn, and later struggling to
> >> remember, those "few key strokes in Emacs", Janney. Not to mention the
> >> sprained wrists from tying your hands into pretzels trying to hit seven
> >> different modifier keys simultaneously, Janney. Emacs is not a text
> >> editor, Janney, it is a keyboard-implemented version of the game
> >> "Twister".
>
> > What does your classic unsubstantiated and erroneous claim have to do
> > with Lisp, Cthun?
>
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?
>
> >> And it remains true that using SVN to "develop" a
> >> novel is like using a hammer to insert a screw, Janney.
>
> > What does your classic unsubstantiated and erroneous claim have to do
> > with Lisp, Cthun?
>
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?


Recursion maybe??

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 01/03/2011 10:06 AM, rusi wrote:
> On Mar 1, 8:02 pm, Cthun<cthun_...@qmail.net.au>  wrote:
>> On 01/03/2011 9:21 AM, Mario Lassnig wrote:
>>> What does your classic unsubstantiated and erroneous claim have to do
>>> with Lisp, Cthun?
>>
>> What does your classic erroneous presupposition have to do with Lisp,
>> Lassnig?
>
> Recursion maybe??

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[David Kastrup]

Cthun <cthun_117@qmail.net.au> writes:

> On 01/03/2011 10:06 AM, rusi wrote:
>> On Mar 1, 8:02 pm, Cthun<cthun_...@qmail.net.au>  wrote:
>>> On 01/03/2011 9:21 AM, Mario Lassnig wrote:
>>>> What does your classic unsubstantiated and erroneous claim have to do
>>>> with Lisp, Cthun?
>>>
>>> What does your classic erroneous presupposition have to do with Lisp,
>>> Lassnig?
>>
>> Recursion maybe??
>
> What does your question have to do with Lisp, rusi?

Where did your parens go wrong?

-- 
David Kastrup

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Ted Zlatanov]

On Tue, 01 Mar 2011 16:26:11 +0100 David Kastrup <dak@gnu.org> wrote: 

DK> Cthun <cthun_117@qmail.net.au> writes:
>> On 01/03/2011 10:06 AM, rusi wrote:
>>> On Mar 1, 8:02 pm, Cthun<cthun_...@qmail.net.au>  wrote:
>>>> On 01/03/2011 9:21 AM, Mario Lassnig wrote:
>>>>> What does your classic unsubstantiated and erroneous claim have to do
>>>>> with Lisp, Cthun?
>>>> 
>>>> What does your classic erroneous presupposition have to do with Lisp,
>>>> Lassnig?
>>> 
>>> Recursion maybe??
>> 
>> What does your question have to do with Lisp, rusi?

DK> Where did your parens go wrong?

Brilliant.  I hope a.h.b-o-u is still active 'cause this is going up there.

Ted

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 01/03/2011 10:26 AM, David Kastrup wrote:
> Cthun <cthun_117@qmail.net.au> writes:
>> On 01/03/2011 10:06 AM, rusi wrote:
>>> On Mar 1, 8:02 pm, Cthun <cthun_...@qmail.net.au> wrote:
>>>> On 01/03/2011 9:21 AM, Mario Lassnig wrote:
>>>>> What does your classic unsubstantiated and erroneous claim have to do
>>>>> with Lisp, Cthun?
>>>>
>>>> What does your classic erroneous presupposition have to do with Lisp,
>>>> Lassnig?
>>>
>>> Recursion maybe??
>>
>> What does your question have to do with Lisp, rusi?
>
> Where did your parens go wrong?

What does your classic erroneous presupposition have to do with emacs, 
Kastrup?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[TheFlyingDutchman]

>
> What does your classic erroneous presupposition have to do with emacs,
> Kastrup?

Which part of the post was erroneous?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 01/03/2011 4:24 PM, TheFlyingDutchman wrote:
>> What does your classic erroneous presupposition have to do with emacs,
>> Kastrup?
>
> Which part of the post was erroneous?

The presupposition that my parens went wrong was erroneous, Dutchman. 
Suffering from reading comprehension problems, Dutchman?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[TheFlyingDutchman]

On Mar 1, 1:33 pm, Cthun <cthun_...@qmail.net.au> wrote:
> On 01/03/2011 4:24 PM, TheFlyingDutchman wrote:
>
> >> What does your classic erroneous presupposition have to do with emacs,
> >> Kastrup?
>
> > Which part of the post was erroneous?
>
> The presupposition that my parens went wrong was erroneous, Dutchman.
> Suffering from reading comprehension problems, Dutchman?

Actually, I wasn't referring to just that instance of you accusing Mr.
Kastrup of having made a classic erroneous presupposition. It was mos
of the others. In order to avoid further miscommunication, it would be
best if you gave more details regarding your most recent dozen uses of
that phrase with respect to Mr. Kastrup.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Thien-Thi Nguyen]

() David Kastrup <dak@gnu.org>
() Tue, 01 Mar 2011 16:26:11 +0100

   Where did your parens go wrong?

first there was the whitespace,
and nothing was as i had expected.
then a token here and there,
accumulating all, none rejected.
open-close, open-open-close-close,
rhythmic stack growth i dig thy grace.
literals and the occasional lone dot:
on top or beside, you all have your place.

but meta is bettah; i succumb to the hash.
some comma mal-drama => big entropy => big crash.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Mario Lassnig]

On 3/1/11 4:02 PM, Cthun wrote:
> On 01/03/2011 9:21 AM, Mario Lassnig wrote:
>> What does your classic unsubstantiated and erroneous claim have to do
>> with Lisp, Cthun?
>
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?

What does your classic misuse of the word presupposition have to do with 
Lisp, Cthun?

>> What does your classic unsubstantiated and erroneous claim have to do
>> with Lisp, Cthun?
>
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?

What does your classic misuse of the word presupposition have to do with 
Lisp, Cthun?

>> What does your classic unsubstantiated and erroneous claim have to do
>> with Lisp, Cthun?
>
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?

What does your classic misuse of the word presupposition have to do with 
Lisp, Cthun?

>> What does your classic unsubstantiated and erroneous claim have to do
>> with Lisp, Cthun?
>
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?

What does your classic misuse of the word presupposition have to do with 
Lisp, Cthun?

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

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

What does your classic misuse of the word presupposition have to do with 
Lisp, Cthun?

>> What does your classic unsubstantiated and erroneous claim have to do
>> with Lisp, Cthun?
>
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?

What does your classic misuse of the word presupposition have to do with 
Lisp, Cthun?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 01/03/2011 10:12 AM, Mario Lassnig wrote:
> On 3/1/11 4:02 PM, Cthun wrote:
>> What does your classic erroneous presupposition have to do with Lisp,
>> Lassnig?
>
> What does your classic misuse of the word presupposition have to do with
> Lisp, Cthun?

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

>> What does your classic erroneous presupposition have to do with Lisp,
>> Lassnig?
>
> What does your classic misuse of the word presupposition have to do with
> Lisp, Cthun?

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

>> What does your classic erroneous presupposition have to do with Lisp,
>> Lassnig?
>
> What does your classic misuse of the word presupposition have to do with
> Lisp, Cthun?

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

>> What does your classic erroneous presupposition have to do with Lisp,
>> Lassnig?
>
> What does your classic misuse of the word presupposition have to do with
> Lisp, Cthun?

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

>> What does your classic erroneous presupposition have to do with Lisp,
>> Lassnig?
>
> What does your classic misuse of the word presupposition have to do with
> Lisp, Cthun?

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

>> What does your classic erroneous presupposition have to do with Lisp,
>> Lassnig?
>
> What does your classic misuse of the word presupposition have to do with
> Lisp, Cthun?

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[TheFlyingDutchman]

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

Can you elaborate on what made it a classic erroneous presupposition?
Perhaps rewriting his post as an erroneous presupposition so we can
contrast it with a classic erroneous presupposition?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Mario Lassnig]

On 3/1/11 10:21 PM, Cthun wrote:
> On 01/03/2011 10:12 AM, Mario Lassnig wrote:
>> What does your classic misuse of the word presupposition have to do with
>> Lisp, Cthun?
>
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?


Welcome to my LISP-based killfile, Cthun.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 02/03/2011 3:11 AM, Mario Lassnig wrote:
> On 3/1/11 10:21 PM, Cthun wrote:
>> On 01/03/2011 10:12 AM, Mario Lassnig wrote:
>>> What does your classic misuse of the word presupposition have to do with
>>> Lisp, Cthun?
>>
>> What does your classic erroneous presupposition have to do with Lisp,
>> Lassnig?
>
> Welcome to my LISP-based killfile, Cthun.

Famous Last Words.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Susan Calvin]

On Tue, 01 Mar 2011 16:21:13 -0500, Cthun wrote:

> On 01/03/2011 10:12 AM, Mario Lassnig wrote:
>> On 3/1/11 4:02 PM, Cthun wrote:
>>> What does your classic erroneous presupposition have to do with Lisp,
>>> Lassnig?
>>
>> What does your classic misuse of the word presupposition have to do
>> with Lisp, Cthun?
> 
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?
> 
>>> What does your classic erroneous presupposition have to do with Lisp,
>>> Lassnig?
>>
>> What does your classic misuse of the word presupposition have to do
>> with Lisp, Cthun?
> 
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?
> 
>>> What does your classic erroneous presupposition have to do with Lisp,
>>> Lassnig?
>>
>> What does your classic misuse of the word presupposition have to do
>> with Lisp, Cthun?
> 
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?
> 
>>> What does your classic erroneous presupposition have to do with Lisp,
>>> Lassnig?
>>
>> What does your classic misuse of the word presupposition have to do
>> with Lisp, Cthun?
> 
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?
> 
>>> What does your classic erroneous presupposition have to do with Lisp,
>>> Lassnig?
>>
>> What does your classic misuse of the word presupposition have to do
>> with Lisp, Cthun?
> 
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?
> 
>>> What does your classic erroneous presupposition have to do with Lisp,
>>> Lassnig?
>>
>> What does your classic misuse of the word presupposition have to do
>> with Lisp, Cthun?
> 
> What does your classic erroneous presupposition have to do with Lisp,
> Lassnig?

To everyone in these newsgroups: the troll that has plagued you for some 
time now is David J. Tholen. Tholen is a notorious Usenet kook who has 
won KOTM once (March 1998) and Clueless Newbie of the Month *twice* (in 
February 2003 as himself -- despite being on usenet for at *least* five 
years by that point -- and again in April 2009 as "Seamus MacRae" as an 
ELEVEN year Usenet veteran).

Tholen has been active under a wide variety of aliases for over a dozen 
years and is recognizable by a distinct pattern of OCD-like ritualized 
responses once under attack. He has a few such patterns, one of which is 
the "what does X have to do with <newsgroup topic>/classic 
unsubstantiated and erroneous claim" most closely associated with his 
real-world identity. Then there's the "[insult deleted]"/"none of the 
nasty things" pattern, and others.

Tholen is not actually a reply-bot, but he might as well be one. The only 
recourse with Tholen is your killfile. If you want Tholen to shut up, do 
not reply to Tholen.

This will be my only post to this thread.

HTH.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 10/03/2011 5:56 PM, Susan Calvin wrote:
> To everyone in these newsgroups: the troll that has plagued you for some
> time now is David J. Tholen. Tholen is a notorious Usenet kook who has
> won KOTM once (March 1998) and Clueless Newbie of the Month *twice* (in
> February 2003 as himself -- despite being on usenet for at *least* five
> years by that point -- and again in April 2009 as "Seamus MacRae" as an
> ELEVEN year Usenet veteran).

What does your information about the tholenbot that invaded from 
comp.os.os2.advocacy have to do with Lisp, Calvin?

> Tholen has been active under a wide variety of aliases for over a dozen
> years and is recognizable by a distinct pattern of OCD-like ritualized
> responses once under attack. He has a few such patterns, one of which is
> the "what does X have to do with<newsgroup topic>/classic
> unsubstantiated and erroneous claim" most closely associated with his
> real-world identity. Then there's the "[insult deleted]"/"none of the
> nasty things" pattern, and others.

What does your information about the tholenbot that invaded from 
comp.os.os2.advocacy have to do with Lisp, Calvin?

> Tholen is not actually a reply-bot, but he might as well be one. The only
> recourse with Tholen is your killfile. If you want Tholen to shut up, do
> not reply to Tholen.

What does your information about the tholenbot that invaded from 
comp.os.os2.advocacy have to do with Lisp, Calvin?

> This will be my only post to this thread.

Famous Last Words.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[David Kastrup]

Cthun <cthun_117@qmail.net.au> writes:

> On 28/02/2011 11:32 PM, Jim Janney wrote:
>> Cthun<cthun_117@qmail.net.au>  writes:
>
>>> and moreover, word
>>> processor documents are typically binary files, which version control
>>> systems cope poorly with. Subversion's diff tool will not play nicely
>>> with .doc files, Janney, and without it there is little point in using
>>> version control.
>>
>> I did say text; clever of you to pick up on that.
>
> Plain, unformatted ASCII text, Janney, which is hardly useful for
> writing novels and articles.

Typewritten manuscripts have been the standard for novel manuscripts for
a substantial amount of time, definitely more limited than ASCII.

> Novels tend to contain italics and other formatting here and there,
> Janney, whereas articles frequently contain scientific and
> mathematical symbols that do not exist in ASCII or sometimes even
> Unicode, and tables, graphs, charts, and formatted equations that
> cannot be represented nicely using a grid of characters.

You probably never heard of LaTeX.  Word processors are mostly good for
simple tasks.  They make the typesetting of mathematics unnecessary
cumbersome and depending on the typesetting skills of the author (who
rarely specializes in that area), and they fall down even in text-only
situations when you have to do things like critical typesetting with
multiple layers of hierarchical footnotes.

Been there, done that.

>> And it can be accomplished even more easily with Emacs and any one of
>> a number of version control systems.
>
> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Janney? Occasionally hitting control-S and backing up your
> files regularly is a lot easier than learning Emacs, Janney.

It does not give you convenient tools for navigating and reusing the
history of the file.

> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Janney? And it remains true that using SVN to "develop" a
> novel is like using a hammer to insert a screw, Janney.

Nope.  More like using a filing system to keep track of your screws,
assemblies and prototypes in the various stages of production.

-- 
David Kastrup

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 01/03/2011 9:31 AM, David Kastrup wrote:
> Cthun<cthun_117@qmail.net.au>  writes:
>
>> On 28/02/2011 11:32 PM, Jim Janney wrote:
>>> Cthun<cthun_117@qmail.net.au>   writes:
>>
>>>> and moreover, word
>>>> processor documents are typically binary files, which version control
>>>> systems cope poorly with. Subversion's diff tool will not play nicely
>>>> with .doc files, Janney, and without it there is little point in using
>>>> version control.
>>>
>>> I did say text; clever of you to pick up on that.
>>
>> Plain, unformatted ASCII text, Janney, which is hardly useful for
>> writing novels and articles.
>
> Typewritten manuscripts have been the standard for novel manuscripts for
> a substantial amount of time

What does that have to do with Lisp, Kastrup?

> definitely more limited than ASCII.

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Kastrup? You could put an italic typewriter ball in your 
typewriter, Kastrup. Typewriters allowed you (at some expense) to use 
multiple styles and fonts, Kastrup.

>> Novels tend to contain italics and other formatting here and there,
>> Janney, whereas articles frequently contain scientific and
>> mathematical symbols that do not exist in ASCII or sometimes even
>> Unicode, and tables, graphs, charts, and formatted equations that
>> cannot be represented nicely using a grid of characters.
>
> You probably never heard of LaTeX.

What does that have to do with Lisp, Kastrup?

> Word processors are mostly good for simple tasks.  They make the
> typesetting of mathematics unnecessary cumbersome and depending on the
> typesetting skills of the author (who rarely specializes in that area),
> and they fall down even in text-only situations when you have to do
> things like critical typesetting with multiple layers of hierarchical
> footnotes.

What does any of that have to do with Lisp, Kastrup?

> Been there, done that.

What does your having been there and done that have to do with Lisp, 
Kastrup?

>>> And it can be accomplished even more easily with Emacs and any one of
>>> a number of version control systems.
>>
>> What does your classic unsubstantiated and erroneous claim have to do
>> with Lisp, Janney? Occasionally hitting control-S and backing up your
>> files regularly is a lot easier than learning Emacs, Janney.
>
> It does not give you convenient tools for navigating and reusing the
> history of the file.

That's true, but irrelevant, Kastrup, since navigating and reusing the 
history beyond keeping a single experimental version is not necessary in 
that context.

>> What does your classic unsubstantiated and erroneous claim have to do
>> with Lisp, Janney? And it remains true that using SVN to "develop" a
>> novel is like using a hammer to insert a screw, Janney.
>
> Nope.  More like using a filing system to keep track of your screws,
> assemblies and prototypes in the various stages of production.

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

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Jim Janney]

k'Chu <cthun_117@qmail.net.au> writes:

> On 28/02/2011 11:32 PM, Jim Janney wrote:
>> Cthun<cthun_117@qmail.net.au>  writes:
>>> On 28/02/2011 6:38 AM, Jim Janney wrote:
>>>> I haven't written any novels, but the purpose of a version control
>>>> system is to manage text
>>>
>>> First of all, the purpose of a version control system is to manage
>>> text that's compilable by build tools
>>
>> That's a bit like saying that the purpose of Usenet is pointless
>> bickering
>
> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Janney? Saying version control is for novels is like saying
> the purpose of Usenet is pointless bickering, Janney; saying it's for
> source code is like saying the purpose of Usenet is for
> discussion. Your mistake is rather ironic, though, considering your
> own considerable recent contributions to the misuse of Usenet for
> pointless bickering, Janney.
>
>> while that is one of the uses to which it's commonly put,
>> it's hardly the only one
>
> What does that have to do with Lisp, Janney?
>
>>> and moreover, word
>>> processor documents are typically binary files, which version control
>>> systems cope poorly with. Subversion's diff tool will not play nicely
>>> with .doc files, Janney, and without it there is little point in using
>>> version control.
>>
>> I did say text; clever of you to pick up on that.
>
> Plain, unformatted ASCII text, Janney, which is hardly useful for
> writing novels and articles. Novels tend to contain italics and other
> formatting here and there, Janney, whereas articles frequently contain
> scientific and mathematical symbols that do not exist in ASCII or
> sometimes even Unicode, and tables, graphs, charts, and formatted
> equations that cannot be represented nicely using a grid of
> characters.
>
>>>> I rarely lose work due to power failures or software crashes
>>>
>>> That is easily accomplished without using version control,
>>> Janney. Saving frequently and having a backup tool suffices for normal
>>> people.
>>
>> And it can be accomplished even more easily with Emacs and any one of a
>> number of version control systems.
>
> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Janney? Occasionally hitting control-S and backing up your
> files regularly is a lot easier than learning Emacs, Janney.
>
>>>> I could work without one, but I would have to do everything more
>>>> slowly and carefully.
>>>
>>> Right click, drop, "copy here" is not especially slow, particularly
>>> compared to learning all of the complexities of a version control
>>> system, Janney. Version control systems have servers, clients, complex
>>> command lines for checking things in and out of them, and so on and
>>> have to be found, downloaded, installed, and configured. You need to
>>> set up your router/firewall to hide the server from the rest of the
>>> internet for security reasons. You have to set up some loopback
>>> interface port for the server to use and then point the client at
>>> 127.0.0.1:portno. You may even have to put all those numbers on every
>>> single command line to check in or check out a file, depending on the
>>> software you chose, Janney.
>>
>> That would certainly be a lot of work, if it were indeed necessary.  It
>> may please you to learn that, if you're not sharing your work with
>> others, there are a number of version control systems -- including
>> Subversion -- for which none of that is necessary.
>
> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Janney? Version control systems are inherently complex and
> inherently client/server oriented, Janney; if they weren't they'd be
> useless for their primary purpose, which is to enable collaborative
> software development, Janney.
>
>>> All of this complexity, when you could just alt, f, "save as" or right
>>> click, "copy here" or COPY FOO.DOC FOO.DOC.BAK, Janney.
>>
>> That's rather more work than simply hitting a few key strokes in Emacs.
>
> It's rather less work than struggling to learn, and later struggling
> to remember, those "few key strokes in Emacs", Janney. Not to mention
> the sprained wrists from tying your hands into pretzels trying to hit
> seven different modifier keys simultaneously, Janney. Emacs is not a
> text editor, Janney, it is a keyboard-implemented version of the game
> "Twister".
>
>> And you get less for it.
>
> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Janney? And it remains true that using SVN to "develop" a
> novel is like using a hammer to insert a screw, Janney.

Since good news cannot be too often repeated, I will recap:

You don't need to set up your router/firewall to hide the server (you
don't need a server) from the internet.  Although if your computer is
connected to a network your firewall should already be configured
anyway.

You don't have to set up the loopback interface port for the server to
use (you don't need a server).

You don't have to point the client at the server (you don't need a
server).

You don't have to put any numbers on a command line (Emacs handles that
for you in the few cases it's required).

You don't have to do any of that with RCS.
You don't have to do any of that with CVS.
You don't have to do any of that with Subversion.
You don't have to do any of that with git.
You don't have to do any of that with Mercurial.

You can do these things if you want to, but none of them are required.
With RCS, all you have to do is type

   ci filename

and you're good to go. In any case, it's a poor tool that can only be
used as its designer intended.  And an even poorer mind that can only
imagine one use for something as versatile as version control.

-- 
Jim Janney

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 01/03/2011 12:39 PM, Jim Janney wrote:
> k'Chu <cthun_117@qmail.net.au>

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

>> On 28/02/2011 11:32 PM, Jim Janney wrote:
>>> And you get less for it.
>>
>> What does your classic unsubstantiated and erroneous claim have to do
>> with Lisp, Janney? And it remains true that using SVN to "develop" a
>> novel is like using a hammer to insert a screw, Janney.
>
> Since good news cannot be too often repeated, I will recap

What does your recap have to do with Lisp, Janney?

> You don't need to set up your router/firewall to hide the server

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Janney? Not hiding an open port from the Internet is an open 
invitation to hackers, Janney.

> (you don't need a server)

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Janney? How can you connect to the version repository to 
check files in and out if you aren't running the repo's server, Janney?

> You don't have to set up the loopback interface port for the server to
> use

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Janney? The version control client (used to check files in 
and out of the repo) needs a port to connect to, Janney.

> (you don't need a server).

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Janney? How can you connect to the version repository to 
check files in and out if you aren't running the repo's server, Janney?

> You don't have to point the client at the server

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Janney? The version control client (used to check files in 
and out of the repo) needs to know where to connect to, Janney.

> (you don't need a server).

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Janney? How can you connect to the version repository to 
check files in and out if you aren't running the repo's server, Janney?

> You don't have to put any numbers on a command line

What does your classic unsubstantiated and erroneous claim have to do 
with Lisp, Janney? Version control clients are generally shell commands, 
Janney, e.g. cvs and svn. IDEs like Eclipse and NetBeans may provide 
graphical front ends to common version control systems, Janney, but such 
IDEs are only applicable if you're using the version control system for 
its intended purpose of software development, Janney.

> (Emacs handles that for you in the few cases it's required).

How ironic. Emacs has a steeper learning curve than any of the other 
software that's been discussed here, Janney; consequently, using emacs 
cannot possibly make any of these tasks easier.

> You don't have to do any of that with RCS.

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

> You don't have to do any of that with CVS.

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

> You don't have to do any of that with Subversion.

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

> You don't have to do any of that with git.

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

> You don't have to do any of that with Mercurial.

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

> You can do these things if you want to, but none of them are required.

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

> With RCS, all you have to do is type
>
>     ci filename

So much for your claims regarding it not being a command-line tool, Janney.

> In any case, it's a poor tool that can only be used as its designer
> intended.

That a well-designed screwdriver might, in a pinch, be slammed into a 
nail to drive it in does not make it preferable to a hammer for that 
purpose, Janney.

> And an even poorer mind that can only imagine one use for something
> as versatile as version control.

What does your classic erroneous presupposition have to do with Lisp, 
Janney? I can imagine it just fine -- I just don't like the results I 
see when I imagine it. Diffs that are gobbledygook when you try to check 
the history of your .doc files. Awkward work at 80s-retro command line 
interfaces. The hellish experience of struggling with emacs's 
idiosyncrasies trying to get it to do anything useful. Of such things 
are my nightmares composed, Janney -- I who can face the likes of 
Cthulhu with equanimity.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[TheFlyingDutchman]

On Mar 1, 1:30 pm, Cthun <cthun_...@qmail.net.au> wrote:
> What does your classic unsubstantiated and erroneous claim have to do
> with Lisp, Janney?
>
He was responding to your comments about Version Control in
comp.lang.lisp. What does your discussion of Version Control have to
do with Lisp, Cthun?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 01/03/2011 5:19 PM, TheFlyingDutchman wrote:
> On Mar 1, 1:30 pm, Cthun <cthun_...@qmail.net.au> wrote:
>> What does your classic unsubstantiated and erroneous claim have to do
>> with Lisp, Janney?
>
> He was responding to your comments about Version Control in
> comp.lang.lisp.

What does your observation have to do with Lisp, Dutchman?

> What does your discussion of Version Control have to
> do with Lisp, Cthun?

It has as much to do with Lisp as Janney's posts, Dutchman. Suffering 
from reading comprehension problems, Dutchman?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[TheFlyingDutchman]

On Mar 1, 2:37 pm, Cthun <cthun_...@qmail.net.au> wrote:
> On 01/03/2011 5:19 PM, TheFlyingDutchman wrote:
>
> > On Mar 1, 1:30 pm, Cthun <cthun_...@qmail.net.au> wrote:
> >> What does your classic unsubstantiated and erroneous claim have to do
> >> with Lisp, Janney?
>
> > He was responding to your comments about Version Control in
> > comp.lang.lisp.
>
> What does your observation have to do with Lisp, Dutchman?

What does your observation of my observation have to do with Lisp,
Cthun?

>
> > What does your discussion of Version Control have to
> > do with Lisp, Cthun?
>
> It has as much to do with Lisp as Janney's posts, Dutchman. Suffering
> from reading comprehension problems, Dutchman?

If your comments about Version Control in a Lisp newgroup are kosher,
then so are Mr. Janney's. Suffering from logic problems, Cthun?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 01/03/2011 5:47 PM, TheFlyingDutchman wrote:
> On Mar 1, 2:37 pm, Cthun<cthun_...@qmail.net.au>  wrote:
>> On 01/03/2011 5:19 PM, TheFlyingDutchman wrote:
>>> What does your discussion of Version Control have to
>>> do with Lisp, Cthun?
>>
>> It has as much to do with Lisp as Janney's posts, Dutchman. Suffering
>> from reading comprehension problems, Dutchman?
>
> If your comments about Version Control in a Lisp newgroup are kosher,
> then so are Mr. Janney's.

If the situation were symmetrical, you'd have a point, Dutchman, but in 
fact the situation is not symmetrical. Somebody was the first to raise 
the topic of version control, Dutchman, and it wasn't me.

> Suffering from logic problems, Cthun?

No, but thanks for your concern, Dutchman. But what does your question 
have to do with Lisp, Dutchman?

Cthun-bot discussion

[TheFlyingDutchman]

On Mar 1, 3:46 pm, Cthun <cthun_...@qmail.net.au> wrote:
> On 01/03/2011 5:47 PM, TheFlyingDutchman wrote:
>
> > On Mar 1, 2:37 pm, Cthun<cthun_...@qmail.net.au>  wrote:
> >> On 01/03/2011 5:19 PM, TheFlyingDutchman wrote:
> >>> What does your discussion of Version Control have to
> >>> do with Lisp, Cthun?
>
> >> It has as much to do with Lisp as Janney's posts, Dutchman. Suffering
> >> from reading comprehension problems, Dutchman?
>
> > If your comments about Version Control in a Lisp newgroup are kosher,
> > then so are Mr. Janney's.
>
> If the situation were symmetrical, you'd have a point, Dutchman, but in
> fact the situation is not symmetrical. Somebody was the first to raise
> the topic of version control, Dutchman, and it wasn't me.

Mr. Janney was not the first to raise the topic of version control so
the Cthun-bot has no case, as the symmetry is excellent. I hate to
denigrate programming efforts, but the Cthun-bot appears to be the
work of an unskilled amateur. It's not clear why it was released
without further testing, and why it isn't withdrawn until it can at
least get to a state that a programmer could be somewhat proud of.

>
> > Suffering from logic problems, Cthun?
>
> No, but thanks for your concern, Dutchman. But what does your question
> have to do with Lisp, Dutchman?

What does your question have to do with Lisp, Cthun-bot?

Re: Cthun-bot discussion

[PJ Weisberg]

On Tue, Mar 1, 2011 at 4:02 PM, TheFlyingDutchman <zzbbaadd@aol.com> wrote:
>
> Mr. Janney was not the first to raise the topic of version control so
> the Cthun-bot has no case, as the symmetry is excellent. I hate to
> denigrate programming efforts, but the Cthun-bot appears to be the
> work of an unskilled amateur. It's not clear why it was released
> without further testing, and why it isn't withdrawn until it can at
> least get to a state that a programmer could be somewhat proud of.

The "What does your erroneous, unsubstantiated claim have to do with
Lisp, $name?" part does seem like an automated change-the-subject
phrase, but I would be impressed as hell if the rest of it was a bot.
Usually you can trip a bot up with a question like "Which is bigger, a
Boeing 747 or my big toe?"  ;-)

-PJ

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 01/03/2011 7:02 PM, TheFlyingDutchman wrote:
> On Mar 1, 3:46 pm, Cthun<cthun_...@qmail.net.au>  wrote:
>> On 01/03/2011 5:47 PM, TheFlyingDutchman wrote:
>>> If your comments about Version Control in a Lisp newgroup are kosher,
>>> then so are Mr. Janney's.
>>
>> If the situation were symmetrical, you'd have a point, Dutchman, but in
>> fact the situation is not symmetrical. Somebody was the first to raise
>> the topic of version control, Dutchman, and it wasn't me.
>
> Mr. Janney was not the first to raise the topic of version control so
> the Cthun-bot has no case, as the symmetry is excellent.

Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using 
that alias.

> I hate to denigrate programming efforts, but the Cthun-bot appears to
> be the work of an unskilled amateur.

Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using 
that alias.

> It's not clear why it was released without further testing, and why
> it isn't withdrawn until it can at least get to a state that a
> programmer could be somewhat proud of.

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

>>> Suffering from logic problems, Cthun?
>>
>> No, but thanks for your concern, Dutchman. But what does your question
>> have to do with Lisp, Dutchman?
>
> What does your question have to do with Lisp, Cthun-bot?

Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using 
that alias.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Bot Tester]

On Tue, 01 Mar 2011 18:46:20 -0500, Cthun <cthun_117@qmail.net.au> wrote:

> On 01/03/2011 5:47 PM, TheFlyingDutchman wrote:
> > On Mar 1, 2:37 pm, Cthun<cthun_...@qmail.net.au>  wrote:
> >> On 01/03/2011 5:19 PM, TheFlyingDutchman wrote:
> >>> What does your discussion of Version Control have to
> >>> do with Lisp, Cthun?

Are you written in Lisp, Cthun?

What is erroneous and unsubstantiated?

What has this got to do with perl?

What has this got to do with python?

What has this got to do with ruby?

What has this got to do with Lisp?

What has this got to do with Emacs?

Does Cthun require manual prompting?

Should Cthun be moderated by list admins?

Perhaps phrase matching on "ubstantiated and erroneous"?

Or is it erroneous, unsubstantiated claim, Cthun?

Regards,
Bot Tester

Cthun-bot discussion

[TheFlyingDutchman]

On Mar 1, 3:46 pm, Cthun <cthun_...@qmail.net.au> wrote:
> On 01/03/2011 5:47 PM, TheFlyingDutchman wrote:
>
> > On Mar 1, 2:37 pm, Cthun<cthun_...@qmail.net.au>  wrote:
> >> On 01/03/2011 5:19 PM, TheFlyingDutchman wrote:
> >>> What does your discussion of Version Control have to
> >>> do with Lisp, Cthun?
>
> >> It has as much to do with Lisp as Janney's posts, Dutchman. Suffering
> >> from reading comprehension problems, Dutchman?
>
> > If your comments about Version Control in a Lisp newgroup are kosher,
> > then so are Mr. Janney's.
>
> If the situation were symmetrical, you'd have a point, Dutchman, but in
> fact the situation is not symmetrical. Somebody was the first to raise
> the topic of version control, Dutchman, and it wasn't me.

I hope they can fix this bug in the Cthun-bot. I pointed out that Mr.
Janney did not raise the issue of Version Control but the Cthun-bot
was unable to grasp it's illogic. Clearly the Cthun-bot is not a good
example of Artificial Intelligence.

>
> > Suffering from logic problems, Cthun?
>
> No, but thanks for your concern, Dutchman. But what does your question
> have to do with Lisp, Dutchman?

I hope the people who programmed the Cthun-bot didn't spend too much
time on it as they clearly can't advertise that fact. "I worked on the
Cthun-bot" would be a sure way to get your resume tossed out or your
job interview cut short.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 02/03/2011 3:42 AM, TheFlyingDutchman wrote:
> On Mar 1, 3:46 pm, Cthun<cthun_...@qmail.net.au>  wrote:
>> On 01/03/2011 5:47 PM, TheFlyingDutchman wrote:
>>> If your comments about Version Control in a Lisp newgroup are kosher,
>>> then so are Mr. Janney's.
>>
>> If the situation were symmetrical, you'd have a point, Dutchman, but in
>> fact the situation is not symmetrical. Somebody was the first to raise
>> the topic of version control, Dutchman, and it wasn't me.
>
> I hope they can fix this bug in the Cthun-bot.

Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using 
that alias.

> I pointed out that Mr. Janney did not raise the issue of Version
> Control but the Cthun-bot was unable to grasp it's illogic.

Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using 
that alias.

> Clearly the Cthun-bot is not a good example of Artificial Intelligence.

Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using 
that alias.

>>> Suffering from logic problems, Cthun?
>>
>> No, but thanks for your concern, Dutchman. But what does your question
>> have to do with Lisp, Dutchman?
>
> I hope the people who programmed the Cthun-bot didn't spend too much
> time on it as they clearly can't advertise that fact.

Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using 
that alias.

> "I worked on the Cthun-bot" would be a sure way to get your resume
> tossed out or your job interview cut short.

Who is "Cthun-bot", Dutchman? There is nobody in this newsgroup using 
that alias.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Bastien]

Can you move this "conversation" elsewhere?

-- 
 Bastien

Re: Cthun-bot discussion

[Peter Keller]

In comp.lang.lisp TheFlyingDutchman <zzbbaadd@aol.com> wrote:
> I hope the people who programmed the Cthun-bot didn't spend too much
> time on it as they clearly can't advertise that fact. "I worked on the
> Cthun-bot" would be a sure way to get your resume tossed out or your
> job interview cut short.

Then again, when people do spend time on something, they make this:

http://www.rawstory.com/rs/2011/02/22/exclusive-militarys-persona-software-cost-millions-used-for-classified-social-media-activities/

Of course, I have no idea if it is true. Who does? It's the internet.

-pete

Re: Cthun-bot discussion

[Cthun]

On 03/03/2011 7:52 PM, Peter Keller wrote:
> In comp.lang.lisp TheFlyingDutchman<zzbbaadd@aol.com>  wrote:
>> I hope the people who programmed the Cthun-bot didn't spend too much
>> time on it as they clearly can't advertise that fact. "I worked on the
>> Cthun-bot" would be a sure way to get your resume tossed out or your
>> job interview cut short.

Who is "Cthun-bot", Keller? There is nobody in this newsgroup using that 
alias.

> Then again, when people do spend time on something, they make this:
>
> http://www.ridiculously-long-url.deleted

What does any of that have to do with Lisp, Keller?

> Of course, I have no idea if it is true. Who does? It's the internet.

What does your ignorance have to do with Lisp, Keller?

Re: Cthun-bot discussion

[TheFlyingDutchman]

>
> Then again, when people do spend time on something, they make this:
>
> http://www.rawstory.com/rs/2011/02/22/exclusive-militarys-persona-sof...
>
> Of course, I have no idea if it is true. Who does? It's the internet.

I have no problem believing it. Before the Iraq invasion there should
have been a story run repeatedly in every newspaper and on every
newstation in the country with the headline "If Iraq has WMD's, why
aren't the UN Weapons Inspectors finding them despite visiting 100's
of sites as given to them by the United States spy agencies?"

And the consequences of not running that headline were death and
destruction.

So the only thing the US government and military have to concern
themselves with prior to the next invasion would be something like a
massive twitter retweeting of the headline the US media should have
run or a Facebook page with millions of followers devoted to the topic
the US media won't discuss.

But I also could see Facebook and Twitter being told to stop "anti-
American" or "un-American" or "traitorous" content else their domain
names will cease to function.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 04/03/2011 12:55 AM, TheFlyingDutchman wrote:
:>
:> Then again, when people do spend time on something, they make this:
:>
:> http://www.rawstory.com/rs/2011/02/22/exclusive-militarys-persona-sof...
:>
:> Of course, I have no idea if it is true. Who does? It's the internet.
:
: I have no problem believing it. Before the Iraq invasion there should
: have been a story run repeatedly in every newspaper and on every
: newstation in the country with the headline "If Iraq has WMD's, why
: aren't the UN Weapons Inspectors finding them despite visiting 100's
: of sites as given to them by the United States spy agencies?"
:
: And the consequences of not running that headline were death and
: destruction.
:
: So the only thing the US government and military have to concern
: themselves with prior to the next invasion would be something like a
: massive twitter retweeting of the headline the US media should have
: run or a Facebook page with millions of followers devoted to the topic
: the US media won't discuss.
:
: But I also could see Facebook and Twitter being told to stop "anti-
: American" or "un-American" or "traitorous" content else their domain
: names will cease to function.

What does any of that have to do with Lisp, Dutchman?

Cthun-bot discussion

[TheFlyingDutchman]

Emacs Lisp is a dialect of Lisp.

Re: Cthun-bot discussion

[David Kastrup]

TheFlyingDutchman <zzbbaadd@aol.com> writes:

> Emacs Lisp is a dialect of Lisp.

What does your classic unsubstantiated claim have to do with Cthun-bot?

Emacs Lisp is not falling apart at its seams.  So far.

-- 
David Kastrup

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Jim Janney]

Cthun <cthun_117@qmail.net.au> writes:

>  Of such
> things are my nightmares composed, Janney -- I who can face the likes
> of Cthulhu with equanimity.

Oh, I don't know.  I think the Real Old One is kind of cute.  And if you
don't want to buy him, you can always get the pattern and sew your own.

-- 
Jim Janney

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 01/03/2011 7:36 PM, Jim Janney wrote:
> Cthun<cthun_117@qmail.net.au>  writes:
>
>>   Of such
>> things are my nightmares composed, Janney -- I who can face the likes
>> of Cthulhu with equanimity.
>
> Oh, I don't know.  I think the Real Old One is kind of cute.  And if you
> don't want to buy him, you can always get the pattern and sew your own.

Classic illogic. Looked upon his visage a few too many times, Janney?

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Jim Janney]

Cthun <cthun_117@qmail.net.au> writes:

> On 01/03/2011 7:36 PM, Jim Janney wrote:
>> Cthun<cthun_117@qmail.net.au>  writes:
>>
>>>   Of such
>>> things are my nightmares composed, Janney -- I who can face the likes
>>> of Cthulhu with equanimity.
>>
>> Oh, I don't know.  I think the Real Old One is kind of cute.  And if you
>> don't want to buy him, you can always get the pattern and sew your own.
>
> Classic illogic. Looked upon his visage a few too many times, Janney?

Someone needs to take a better look at the organizations in this
thread.  Remember, he's cuddly!

-- 
Jim Janney

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Cthun]

On 02/03/2011 2:52 PM, Jim Janney wrote:
> Cthun<cthun_117@qmail.net.au>  writes:
>> On 01/03/2011 7:36 PM, Jim Janney wrote:
>>> Oh, I don't know.  I think the Real Old One is kind of cute.  And if you
>>> don't want to buy him, you can always get the pattern and sew your own.
>>
>> Classic illogic. Looked upon his visage a few too many times, Janney?
>
> Someone needs to take a better look at the organizations in this
> thread.

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

> Remember, he's cuddly!

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

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

[Steve]

[-- Attachment #1: Type: text/plain, Size: 3575 bytes --]

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

Why do you say that?


> What does your recap have to do with Lisp, Janney?

I don't understand.


> What does your classic unsubstantiated and erroneous claim have to
> do with Lisp, Janney? Not hiding an open port from the Internet is
> an open invitation to hackers, Janney.

Maybe your life has something to do with this.


> What does your classic unsubstantiated and erroneous claim have to
> do with Lisp, Janney? How can you connect to the version repository
> to check files in and out if you aren't running the repo's server,
> Janney?

Is it because can me connect to the version repository to check files
in and out if I am not running the repo's server that you came to me?


> What does your classic unsubstantiated and erroneous claim have to
> do with Lisp, Janney? The version control client (used to check
> files in and out of the repo) needs a port to connect to, Janney.

What makes you believe repo might want to have this port to connect
to?


> What does your classic unsubstantiated and erroneous claim have to
> do with Lisp, Janney? The version control client (used to check
> files in and out of the repo) needs to know where to connect to,
> Janney.

How does it feel to want?


> What does your classic unsubstantiated and erroneous claim have to
> do with Lisp, Janney? Version control clients are generally shell
> commands, Janney, e.g. cvs and svn. IDEs like Eclipse and NetBeans
> may provide graphical front ends to common version control systems,
> Janney, but such IDEs are only applicable if you're using the
> version control system for its intended purpose of software
> development, Janney.

Does it bother you that such ides are only applicable if I am using
the version control system for its intended purpose of software
development?


> How ironic. Emacs has a steeper learning curve than any of the other
> software that's been discussed here, Janney; consequently, using emacs
> cannot possibly make any of these tasks easier.

Emacs?  Hah!  I would appreciate it if you would continue.


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

Perhaps your plans have something to do with this.


>So much for your claims regarding it not being a command-line tool, Janney.

Is it because of the people you hang around with that you are going
through all this?


> That a well-designed screwdriver might, in a pinch, be slammed into a
> nail to drive it in does not make it preferable to a hammer for that
> purpose, Janney.

Does the fact that a well designed screwdriver might in a pinch be
slammed into a nail to drive it in does not make it preferable to a
hammer for that purpose explain anything else?


> What does your classic erroneous presupposition have to do with Lisp,
> Janney?  I can imagine it just fine -- I just don't like the results I
> see when I imagine it.

What happened when you imagine it?


> Diffs that are gobbledygook when you try to check
> the history of your .doc files.

Is it because are gobbledygook when me try to check the history of my
doc files that you came to me?


> Awkward work at 80s-retro command line
> interfaces. The hellish experience of struggling with emacs's
> idiosyncrasies trying to get it to do anything useful.

What makes you believe that?


> Of such things are my nightmares composed, Janney -- I who can face
> the likes of Cthulhu with equanimity.

Earlier you said gobbledygook when me try to check the history of my
doc files?


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[PJ Weisberg]

To sum up:

Paper never gets corrupted during a power outage.
Pens don't crash, even when you're forced to use Windows.
Version control is for noobs who haven't learned how to use the photocopier yet.

End of discussion.

-PJ

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Alan Mackenzie]

In comp.emacs Cthun <cthun_117@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?

Germany.  I think I tripped a circuit breaker about 5 years ago, but
other than that the power stays up.  Emacs doesn't crash (except when I'm
doing very wierd things).

> 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 keeps backups as it goes along, so that on a failure you've got M-x
recover-session.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Sean Sieger]

Xah Lee <xahlee@gmail.com> writes:

    my setup n system, is more efficient than you, by any means of
    scientific accessment.

But, you still don't type properly.

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[David Kastrup]

Sean Sieger <sean.sieger@gmail.com> writes:

> Xah Lee <xahlee@gmail.com> writes:
>
>     my setup n system, is more efficient than you, by any means of
>     scientific accessment.
>
> But, you still don't type properly.

I wish I were as good a player as my accordion is an instrument.  But
getting a better-matched instrument won't improve my playing, so why not
be proud of it?

-- 
David Kastrup

Re: What's your favourite *under_publicized* editing feature ofEmacs?

[Sean Sieger]

David Kastrup <dak@gnu.org> writes:

    Sean Sieger <sean.sieger@gmail.com> writes:

    > Xah Lee <xahlee@gmail.com> writes:
    >
    >     my setup n system, is more efficient than you, by any means of
    >     scientific accessment.
    >
    > But, you still don't type properly.

    I wish I were as good a player as my accordion is an instrument.  But
    getting a better-matched instrument won't improve my playing, so why not
    be proud of it?

Practice, practice, practice.

It was only days ago that I thought of you and wondered, `Are ya
listening to Albert Ayler?'

Oof.

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

[Simón Ortiz]

I don't know if it is under_publicized, but I like a lot M-x hexl-mode

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

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

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

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

[Ken Goldman]

I use hexl-mode all the time.

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

On 01/28/2011 04:54 AM, Simón Ortiz wrote:
> I don't know if it is under_publicized, but I like a lot M-x hexl-mode
>
> It's mode for editing binary files! Extremely useful when you need to
> save/load data to/from binaries.

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

[Stefan Monnier]

> I use hexl-mode all the time.
> I've often needed an insert, as opposed to overwrite.  Do you know if
> there's a way to insert?

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


        Stefan

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

[Oleksandr Gavenko]

On 2011-01-29 0:59, Stefan Monnier wrote:
>> I use hexl-mode all the time.
>> I've often needed an insert, as opposed to overwrite.  Do you know if
>> there's a way to insert?
>
> Sadly, there isn't.  I have a new mode I call "nhexl-mode" which does
> "the same" as hexl-mode but in a completely different way (the
> conversion is done in a font-lockish way, so the buffer's content is
> not affected, only the display) so you can use it with buffer insertion
> and pretty much anything else.  Sadly, it bumps into some severe
> performance limitations in the current redisplay code, so it's largely
> unusable other than on very small buffers :-(
>
It is possible read only portion of file by Emacs
and don't load all file content into buffer?

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

-- 
Best regards!

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

[Eli Zaretskii]

> From: Oleksandr Gavenko <gavenkoa@gmail.com>
> Date: Sat, 29 Jan 2011 16:46:33 +0200
> 
> It is possible read only portion of file by Emacs
> and don't load all file content into buffer?

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

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

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

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

[Perry Smith]

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

> On 2011-01-29 0:59, Stefan Monnier wrote:
>>> I use hexl-mode all the time.
>>> I've often needed an insert, as opposed to overwrite.  Do you know if
>>> there's a way to insert?
>> 
>> Sadly, there isn't.  I have a new mode I call "nhexl-mode" which does
>> "the same" as hexl-mode but in a completely different way (the
>> conversion is done in a font-lockish way, so the buffer's content is
>> not affected, only the display) so you can use it with buffer insertion
>> and pretty much anything else.  Sadly, it bumps into some severe
>> performance limitations in the current redisplay code, so it's largely
>> unusable other than on very small buffers :-(
>> 
> 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

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

[Stefan Monnier]

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

Agreed,


        Stefan

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

[Giorgos Keramidas]

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

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

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

[Perry Smith]

[-- Attachment #1: Type: text/plain, Size: 2228 bytes --]


On Feb 17, 2011, at 4:53 AM, Giorgos Keramidas wrote:

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

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

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

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

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

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

Perry


[-- Attachment #2: Type: text/html, Size: 3307 bytes --]

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

[Thien-Thi Nguyen]

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

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

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

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

[Tim X]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

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

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

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

[Javier Sanz]

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

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

[Oleksandr Gavenko]

On 2011-01-29 14:55, Javier Sanz wrote:
> Some that come to my mind:
> - Using define-generic-mode, I've defined a major mode for my app
> logs, which highlights errors and warnings in different colors and
> makes them easier to see.
How large your log files?

I set 'grep-mode' on my log file (which follow GNU
error coding convention). On 50-100 KiB logs it take
10 sec to highlight matches. On larger files I type
C-g to stop matching for highlighting.

-- 
Best regards!

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

[Oleksandr Gavenko]

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

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

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

This become start point to develop some code by hand.

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

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


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

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

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

;; Author: Oleksandr Gavenko <gavenkoa@gmail.com>
;; Maintainer: Oleksandr Gavenko <gavenkoa@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!

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

[Stefan Monnier]

>> I set 'grep-mode' on my log file (which follow GNU
>> error coding convention). On 50-100 KiB logs it take
>> 10 sec to highlight matches. On larger files I type
>> C-g to stop matching for highlighting.

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

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

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

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

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


        Stefan

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

[Oleksandr Gavenko]

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

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

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

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

Same with highlighting of compilation/grep like buffers.

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

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

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

How about generic-modes?

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

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

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

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

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

When I change mode line to

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

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

As you can see it is 100 times slower!

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

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

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

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

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

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

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

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

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

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

Or I am something missing?

-- 
Best regards!

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

[Oleksandr Gavenko]

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

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

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

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

Same with highlighting of compilation/grep like buffers.

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

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

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

How about generic-modes?

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

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

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

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

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

When I change mode line to

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

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

As you can see it is 100 times slower!

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

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

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

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

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

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

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

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

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

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

Or I am something missing?

-- 
Best regards!

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

[Thien-Thi Nguyen]

() Oleksandr Gavenko <gavenkoa@gmail.com>
() Wed, 09 Feb 2011 23:31:15 +0200

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

   [...]

   Or I am something missing?

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

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

[Oleksandr Gavenko]

On 2011-02-10 0:32, Thien-Thi Nguyen wrote:
> () Oleksandr Gavenko<gavenkoa@gmail.com>
> () Wed, 09 Feb 2011 23:31:15 +0200
>
>     So because of unnecessary work to set text property to well
>     structured data on *all* lines we have slow down instead perform
>     parsing of reference on demand.
>
>     [...]
>
>     Or I am something missing?
>
> You have well-structured data but the compilation (likewise, grep)
> font-locking tries to cope with a more general input.  You can prune
> some elements from ‘compilation-error-regexp-alist’ to help focus the
> font-locking.  Have you tried that?
>
Yes. I wrote:

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

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

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

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

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

-- 
Best regards!

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

[Stefan Monnier]

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

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

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


        Stefan