Editors

[null1024]

In regards to the no need to hit the spacebar ever comment, I mean that you can use nothing but to arrow keys to provide spacing.

Example set of keypresses:
a[right]man[right]sat[right]idly[right]on[right]the[right]floor.[down]---

would produce:

a man sat idly on the floor.
---

Also, EDIT.COM is why I don't have Vi/Vim [I really don't care which, old OSX versions had vi, and I've had better experiences with anything labled vi than vim [notably with the arrow keys echoing instead of moving, so I'd end up with A, B, C, or D when I wanted to move the cursor] on different systems] on Windows.

[netcrusher88]

Example set of keypresses:
a[right]man[right]sat[right]idly[right]on[right]the[right]floor.[down]---

would produce:

a man sat idly on the floor.
---

Eww. It's quicker to just hit the spacebar. Less hand movement. Same idea with vi-style hjkl movement.

[hotaru]

In regards to the no need to hit the spacebar ever comment, I mean that you can use nothing but to arrow keys to provide spacing.

Example set of keypresses:
a[right]man[right]sat[right]idly[right]on[right]the[right]floor.[down]---

would produce:

a man sat idly on the floor.
---

no, the obvious way to do it is use the mouse to position the cursor after each word

[enk]

I've had better experiences with anything labled vi than vim [notably with the arrow keys echoing instead of moving, so I'd end up with A, B, C, or D when I wanted to move the cursor

Heh.. that's because the arrow keys are not meant to be used

But yeah, I've had that problem on an old Solaris with vi, but never with vim. What system did you see this on?

[Two9A]

This might be a silly question, but:

Is there a version of ed which holds an internal syntax-highlighted buffer? If I had highlighting, I'd probably leave my first love (vim) for ed. I can't see it happening though.

[hotaru]

Is there a version of ed which holds an internal syntax-highlighted buffer?

sure there is. if you open a syntax-highlighted file, ed will leave the highlighting in it. just make sure to preserve the highlighting as you edit the file, and then remove it before you try to compile the code.

[enk]

This might be a silly question, but:

Is there a version of ed which holds an internal syntax-highlighted buffer? If I had highlighting, I'd probably leave my first love (vim) for ed. I can't see it happening though.

ed led to ex led to vi led to vim. That's a pretty big step backwards you're proposing.

[zombie_monkey]

ed is still the best thing in certain contexts. Screen readers work extremely well with ed for example. Not with vim.

[hotaru]

ed led to ex led to vi led to vim.

not quite. ex and vi are different modes of the same editor.

That's a pretty big step backwards you're proposing.

actually, ex[imath]\rightarrow[/imath]vim was a huge step backwards, further than the step from ed to ex. which makes vim[imath]\rightarrow[/imath]ed a step forward.

[phlip]

Out of curiosity, hotaru... given your loathing for vim and C++ and anything that's newer than something else, what web browser do you use? Something old and low-featured, I would suspect... Lynx? Netcat? A pushbutton and a LED directly attached to a network cable? (10BASE2 of course, 10BASE-T is newer and thus inferior.)

I'm surprised you're here on a website at all... HTTP has all this extra clutter that wasn't there in the nice simple Gopher protocol.

[hotaru]

Out of curiosity, hotaru... given your loathing for vim and C++ and anything that's newer than something else, what web browser do you use? Something old and low-featured, I would suspect... Lynx? Netcat? A pushbutton and a LED directly attached to a network cable? (10BASE2 of course, 10BASE-T is newer and thus inferior.)

i don't loath anything that's newer than something else. i just dislike software that's poorly written or poorly designed, and prefer free software over non-free software. i use quite a few browsers, most of them using webkit.

[enk]

ed led to ex led to vi led to vim.

not quite. ex and vi are different modes of the same editor.

Became. If I am to trust wikipedia. ex existed on its own before it was engulfed by vi and its visual features.

That's a pretty big step backwards you're proposing.

actually, ex[imath]\rightarrow[/imath]vim was a huge step backwards, further than the step from ed to ex. which makes vim[imath]\rightarrow[/imath]ed a step forward.

Would you choose ed over vim for actual editing?

[hotaru]

ed led to ex led to vi led to vim.

not quite. ex and vi are different modes of the same editor.

Became. If I am to trust wikipedia. ex existed on its own before it was engulfed by vi and its visual features.

in 1BSD, ex was pretty much just a more user-friendly implementation of ed. in 2BSD, it included the visual mode that it's known for now.

That's a pretty big step backwards you're proposing.

actually, ex[imath]\rightarrow[/imath]vim was a huge step backwards, further than the step from ed to ex. which makes vim[imath]\rightarrow[/imath]ed a step forward.

Would you choose ed over vim for actual editing?

on systems that have ed and vim but not ex i usually use ed until i can get ex.

[netcrusher88]

on systems that have ed and vim but not ex i usually use ed until i can get ex.

Every implementation of vim (or vi) I know of starts in ex mode when called as ex (and on most systems, ex is a symlink to vim) just like when you call it as vi it starts in compatibility mode, so:

Code: Select all

alias ex=vim

Or, if that doesn't work, use 'vim -e'. I really don't understand your disdain for the visual mode though. I agree there are many times when a line editor like ex is useful like find and replace (which can be called from visual mode anyway), but for the most part visual mode is just easier.

ed led to ex led to vi led to vim. That's a pretty big step backwards you're proposing.

ed led to em led to en led to ex had :vi led to vi led to vim. em and en seem to have vanished, though.

[hotaru]

on systems that have ed and vim but not ex i usually use ed until i can get ex.

Every implementation of vim (or vi) I know of starts in ex mode when called as ex (and on most systems, ex is a symlink to vim) just like when you call it as vi it starts in compatibility mode, so:

Code: Select all

alias ex=vim

Or, if that doesn't work, use 'vim -e'. I really don't understand your disdain for the visual mode though. I agree there are many times when a line editor like ex is useful like find and replace (which can be called from visual mode anyway), but for the most part visual mode is just easier.

ex and vi are the same editor. i usually use the visual mode.
and vim, even in compatibility mode, is very different from ex.

[netcrusher88]

ex mode is ex (or more to the point, 'ex' is ex mode now). You can call ex commands from visual mode. I don't understand what you mean.

[enk]

on systems that have ed and vim but not ex i usually use ed until i can get ex.

Dude, there has got to be some reason you're not telling us.

The improved features in vim can save your lost startup time so many times if you just stop fighting the progress. It can't be the startup time.

Is it open mode? You could just use vim and go back to vi when you need that open mode. Can't be that.

The size...? Cry me a river.

Do you think you're cool if you use something other people find hard?

Do you think you're cool if you denounce GPL?

I'm going to go with a mix of the last two until I get a better reason.

[hotaru]

Dude, there has got to be some reason you're not telling us.

a lot of things just don't work right in vim. here are a few examples, from vim's documentation:

Search patterns have more features. The <NL> character is seen as part of the
search pattern and the substitute string of ":s". Vi sees it as the end of
the command.

Searches can put the cursor on the end of a match and may include a character
offset.

Count added to "~", ":next", ":Next", "n" and "N".

The command ":next!" with 'autowrite' set does not write the file. In vi the
file was written, but this is considered to be a bug, because one does not
expect it and the file is not written with ":rewind!".

In Vi when entering a <CR> in replace mode deletes a character only when 'ai'
is set (but does not show it until you hit <Esc>). Vim always deletes a
character (and shows it immediately).

Added :wnext command. Same as ":write" followed by ":next".

The ":w!" command always writes, also when the file is write protected. In Vi
you would have to do ":!chmod +w %" and ":set noro"

"cw" can be used to change white space formed by several characters (Vi is
confusing: "cw" only changes one space, while "dw" deletes all white space).

"o" and "O" accept a count for repeating the insert (Vi clears a part of
display).

Flags after Ex commands not supported (no plans to include it).

No check for "tail recursion" with mappings. This allows things like
":map! foo ^]foo".

When a mapping starts with number, vi loses the count typed before it (e.g.
when using the mapping ":map g 4G" the command "7g" goes to line 4). This is
considered a vi bug. Vim concatenates the counts (in the example it becomes
"74G"), as most people would expect.

The "p" and "P" commands of vi cannot be repeated with "." when the putted
text is less than a line. In Vim they can always be repeated.

":noremap" command can be used to enter a mapping that will not be remapped.
This is useful to exchange the meaning of two keys. ":cmap", ":cunmap" and
":cnoremap" can be used for mapping in command-line editing only. ":imap",
":iunmap" and ":inoremap" can be used for mapping in insert mode only.
Similar commands exist for abbreviations: ":noreabbrev", ":iabbrev"
":cabbrev", ":iunabbrev", ":cunabbrev", ":inoreabbrev", ":cnoreabbrev".

In Vi the command ":map foo bar" would remove a previous mapping
":map bug foo". This is considered a bug, so it is not included in Vim.
":unmap! foo" does remove ":map! bug foo", because unmapping would be very
difficult otherwise (this is vi compatible).

CTRL-@ (insert previously inserted text) works always (Vi: only when typed as
first character).

<Esc> terminates the command-line without executing it. In vi the command
line would be executed, which is not what most people expect (hitting <Esc>
should always get you back to command mode). To avoid problems with some
obscure macros, an <Esc> in a macro will execute the command. If you want a
typed <Esc> to execute the command like vi does you can fix this with
":cmap ^V<Esc> ^V<CR>"

Error messages are shown at least one second (Vi overwrites error messages).

If Vim gives the |hit-enter| prompt, you can hit any key. Characters other
than <CR>, <NL> and <Space> are interpreted as the (start of) a command. (Vi
only accepts a command starting with ':').

The contents of the numbered and unnamed registers is remembered when
changing files.

The "No lines in buffer" message is a normal message instead of an error
message, since that may cause a mapping to be aborted.

[enk]

Well, I know. That's why it's called vi improved.

CTRL-@ (insert previously inserted text) works always (Vi: only when typed as
first character)

The "p" and "P" commands of vi cannot be repeated with "." when the putted
text is less than a line. In Vim they can always be repeated.

The "No lines in buffer" message is a normal message instead of an error
message, since that may cause a mapping to be aborted.

Error messages are shown at least one second (Vi overwrites error messages).

How do these improvements disturb you, exactly?


Now the one about whether <esc> executes or terminates the command line I can see would take some getting used to (if you don't want to map your way out of it). And some of the others as well. But the other vi derivatives improve vi as well, how can you use those, then? nvi for example also does like vim for [count]o.

Why not just take the plunge and learn the small differences and benefit from the improvements? Multi-level undo, block operators, word completion, etc.

[netcrusher88]

Again, with most systems, ex is actually vim, if vim is installed. Otherwise it's vi... which is actually vim if vim is installed. On some systems, calling vim as vi starts it in compatibility mode, but don't count on it. If you really want vi, run vim and ':set compatible' or even put it in ~/.vimrc. If you execute 'vi' and really want vi, you should do ':set compatible?' and if it responds with nocompatible you know you're using vim, not in compatibility mode.

Compatibility isn't perfect. There's places that document the differences between vi and vim compatibility, but it's mostly "vi acted stupid and it's too much trouble to make vim act the same way" things.

One other thing: if you execute ex on a system with vim, it starts vim in line mode. Calling as ex does not set compatibility.

As Bill Joy once pointed out, the only way to know exactly what you're getting is to use ed. But these days, most vi (and vim compatibility) are pretty much the same, and most systems have vim anyway. Learn two near-identical pieces of software, and you'll find something so close as to be the same as one of them everywhere you find a UNIX prompt.

[hotaru]

How do these improvements disturb you, exactly?

they aren't improvements. if it isn't broke, don't fux it.

Why not just take the plunge and learn the small differences and benefit from the improvements? Multi-level undo, block operators, word completion, etc.

multi-level undo is the opposite of improvement. if by "block operators" you mean working with rectangular areas of text, that's completely useless for pretty much anything except befunge code. word completion might be useful if it actually worked right.

Again, with most systems, ex is actually vim, if vim is installed. Otherwise it's vi... which is actually vim if vim is installed.

this is not vim.

[netcrusher88]

Again, with most systems, ex is actually vim, if vim is installed. Otherwise it's vi... which is actually vim if vim is installed.

this is not vim.

if vim is installed

Try this: on any modern system, run 'file `which ex`'. And then if it's a symlink to /etc/alternatives/ex (or something - this is how Ubuntu does it), run file on that until you find which executable it actually is. On most modern systems - again, most - when you install vim, it (by default) makes vi and ex symlinks to vim. And when vim is called as ex, it enters line mode automatically. On some systems (such as Debian, I believe), calling it as vi will turn on compatible too. On others (Ubuntu) it does not.

Likewise you can uninstall vim and just install vi, or (on systems that support alternatives, which is most these days) just configure it so that vi and ex call real vi, not vim.

Also, the specific things enk quoted are unequivocally improvements. Massive UI improvements. If commands don't work consistently, and you make them work consistently (which is what he was talking about there), that is an improvement.

[phlip]

multi-level undo is the opposite of improvement.

Ah! I get it now! Everything suddenly makes sense.

I guess I should start a thread in Linguistics now, to find out what language hotaru is actually speaking... it's clearly something similar to, but not quite, English, where "improvement" is a bad thing.

But more seriously,

they aren't improvements.

How is "the way this option in vi worked was stupid, and would break in edge cases... vim is less stupid, and works on those edge cases" not an improvement? The only argument I can see is that you see vi as some kind of holy ideal, and any deviation from it is automatically inferior. Or you've got huge piles of vi macros that rely on the stupid behavior, and would rather denounce fixing said stupid behaviour over fixing the macros (and probably simplifying them in the process).

[hotaru]

But more seriously,

they aren't improvements.

How is "the way this option in vi worked was stupid, and would break in edge cases... vim is less stupid, and works on those edge cases" not an improvement?

you'd be a lot less likely to run into walls on a bicycle that can't move, but most people wouldn't call that an improvement. breaking common cases to make things not break in edge cases is often not a good thing.

[phlip]

you'd be a lot less likely to run into walls on a bicycle that can't move, but most people wouldn't call that an improvement. breaking common cases to make things not break in edge cases is often not a good thing.

To pick an example from the list of things you quoted:

The "p" and "P" commands of vi cannot be repeated with "." when the putted text is less than a line. In Vim they can always be repeated.

How does that break the common case?

Pasting less than a line of text isn't even much of an edge case... this isn't breaking the common case to fix an edge case, this is doing something that doesn't affect a common case to fix another common case.

And this isn't the only one in your list of examples that's like that.

[hotaru]

To pick an example from the list of things you quoted:

The "p" and "P" commands of vi cannot be repeated with "." when the putted text is less than a line. In Vim they can always be repeated.

How does that break the common case?

Pasting less than a line of text isn't even much of an edge case... this isn't breaking the common case to fix an edge case, this is doing something that doesn't affect a common case to fix another common case.

how much extra code does it take to "fix" that? what are the chances that any bugs in that extra code affect common cases? and pasting less than a line isn't an edge case, but repeatedly pasting less than a line is.

[phlip]

how much extra code does it take to "fix" that?

So, basically,

The size...? Cry me a river.

what are the chances that any bugs in that extra code affect common cases?

The more relevant question is "what are the chances that that extra code has bugs that still haven't been found and fixed in the 18 years since vim was initially released, but still somehow affect common cases?"

Let me rephrase: Can you give a single concrete common case that is adversely affected by fixing vi's bug in the repeated-pasting case? Or any of the other "vi was stupid, vim fixes it" things you mentioned?

Would you advocate never fixing any bugs in software ever, as that would inevitably involve writing code, which could be buggy? Taking the law of conservation of bugs as an inescapable fact, and giving up?

[hotaru]

what are the chances that any bugs in that extra code affect common cases?

The more relevant question is "what are the chances that that extra code has bugs that still haven't been found and fixed in the 18 years since vim was initially released, but still somehow affect common cases?"

bugs over 20 years old have been found in much simpler code.

Let me rephrase: Can you give a single concrete common case that is adversely affected by fixing vi's bug in the repeated-pasting case? Or any of the other "vi was stupid, vim fixes it" things you mentioned?

in vi, if you type some text in insert mode, then leave insert mode and paste less than a line and then hit ".", it repeats the previous insertion instead of the paste. in vim it doesn't.

Would you advocate never fixing any bugs in software ever, as that would inevitably involve writing code, which could be buggy? Taking the law of conservation of bugs as an inescapable fact, and giving up?

plenty of bugs have been fixed in ex over the years.
what i'd advocate is not introducing new bugs to try to "fix" things that aren't broken.

[phlip]

in vi, if you type some text in insert mode, then leave insert mode and paste less than a line and then hit ".", it repeats the previous insertion instead of the paste.

And this is (a) not broken and counterintuitive, and (b) a common case... how, exactly?

[hotaru]

in vi, if you type some text in insert mode, then leave insert mode and paste less than a line and then hit ".", it repeats the previous insertion instead of the paste.

And this is (a) not broken and counterintuitive, and (b) a common case... how, exactly?

a. in what way is arbitrarily changing the behavior of "." after so many years (during which it worked just fine for a lot of people) not broken and counterintuitive?
b. when is the last time you used "." to repeat pasting less than a line? when is the last time you used "." to repeat typeing some text in insert mode?

[phlip]

a. in what way is arbitrarily changing the behavior of "." after so many years (during which it worked just fine for a lot of people) not broken and counterintuitive?

So now your argument is just "it's always worked that way and change is scary"?

The way that's not counterintuitive is that "it's worked that way for a while" and "I was trained to expect this" are not criteria for intuitiveness. "It makes some semblance of sense" is. So changing it from behaving nonsensically to doing something that makes more sense, while meaning some re-learning, is not counterintuitive.

As for "broken", you might have a leg to stand on that changing something that would mean people have to re-learn has a chance of qualifying for some weak definition of the word. You'd still have to argue how that minor inconvenience is enough to outweigh the benefits of making "." saner.

And really, you haven't answered my question, which was, more explicitly: how is "The dot button repeats the last change" not simpler, less broken, more intuitive, and make more sense than "The dot button repeats the last change, unless it was one of <list of broken cases>, in which case it does something different. Good luck."

b. when is the last time you used "." to repeat pasting less than a line? when is the last time you used "." to repeat typeing some text in insert mode?

Using "." to repeat a less-than-a-line paste: occasionally. Not especially often.
Using "." to repeat an insert: occasionally. Not especially often.
Using "." to repeat an insert when it's not the most recent command, 'cause I've done a paste in-between: never. Why on earth would I do that? I mean seriously now. Are you trying to claim this is a common case?

And another question: How does it make sense for "." to treat sub-line pastes and multi-line pastes differently?

Really, it sounds like you're trying to argue that it's not a good idea to fix a bug... not only that, but fixing the bug is actively detrimental... with your only argument being that the bug has existed for a while, and people have learned to work around it.

[hotaru]

So now your argument is just "it's always worked that way and change is scary"?

no. my argument is that the way vi does it works for me, and the way vim does it doesn't.

The way that's not counterintuitive is that "it's worked that way for a while" and "I was trained to expect this" are not criteria for intuitiveness. "It makes some semblance of sense" is. So changing it from behaving nonsensically to doing something that makes more sense, while meaning some re-learning, is not counterintuitive.

if it was intuitive, people would just expect it to work that way and it wouldn't require re-learning.

As for "broken", you might have a leg to stand on that changing something that would mean people have to re-learn has a chance of qualifying for some weak definition of the word. You'd still have to argue how that minor inconvenience is enough to outweigh the benefits of making "." saner.

And really, you haven't answered my question, which was, more explicitly: how is "The dot button repeats the last change" not simpler, less broken, more intuitive, and make more sense than "The dot button repeats the last change, unless it was one of <list of broken cases>, in which case it does something different. Good luck."

the things that "." doesn't repeat make sense not to repeat.

b. when is the last time you used "." to repeat pasting less than a line? when is the last time you used "." to repeat typeing some text in insert mode?

Using "." to repeat a less-than-a-line paste: occasionally. Not especially often.
Using "." to repeat an insert: occasionally. Not especially often.
Using "." to repeat an insert when it's not the most recent command, 'cause I've done a paste in-between: never. Why on earth would I do that? I mean seriously now. Are you trying to claim this is a common case?

i've never used "." to repeat any paste, but i have used "." to repeat insertions with pastes in between several times.

And another question: How does it make sense for "." to treat sub-line pastes and multi-line pastes differently?

it doesn't, but the obvious way to fix that would be to make "." not repeat pastes at all.

Really, it sounds like you're trying to argue that it's not a good idea to fix a bug... not only that, but fixing the bug is actively detrimental... with your only argument being that the bug has existed for a while, and people have learned to work around it.

no, i'm arguing that the way to fix a bug is not to make it worse.

[phlip]

no. my argument is that the way vi does it works for me, and the way vim does it doesn't.

Doesn't work for you? Fine. I'm not going to argue against that. But stop claiming that people who it does work for are Doin It Rong, or that vim is objectively worse than vi.

if it was intuitive, people would just expect it to work that way and it wouldn't require re-learning.

You underestimate the power of habit. No matter how stupid the old way is, and how intuitive the new way is, anyone used to the old way will have to unlearn their habits and workarounds when it changes. And really, "is it intuitive?" has nothing to do with "will existing users like it?" but "will new users be able to pick it up faster?".

the things that "." doesn't repeat make sense not to repeat.

Why not? Pastes change the file. "." repeats the last change. Put two and two together, and you get? What's special about pastes that you never want to repeat them?

i've never used "." to repeat any pasted=, but i have used "." to repeat insertions with pastes in between several times.

So you do strange things, fine. I ask again: are you trying to claim this is a common case?

it doesn't, but the obvious way to fix that would be to make "." not repeat pastes at all.

But if they'd done that in vim, you'd still be complaining that they'd change it from the holy ideal of what vi did.

And you'd still have people being confused that ".", while nominally repeating the last change, ignores pastes.

[netcrusher88]

it doesn't, but the obvious way to fix that would be to make "." not repeat pastes at all.

Now you're just grasping at straws to say vim does everything wrong. Redoing a paste is a very useful thing when you're recycling a bit of logic into several procedures while programming. Ditto a partial-line paste when you're using regex.

[hotaru]

the things that "." doesn't repeat make sense not to repeat.

Why not? Pastes change the file. "." repeats the last change. Put two and two together, and you get? What's special about pastes that you never want to repeat them?

undoing the last action changes the file, but vim doesn't let you repeat that with ".". what's so special about pastes that you want to repeat them?

So you do strange things, fine. I ask again: are you trying to claim this is a common case?

it's more common than repeating a paste.

But if they'd done that in vim, you'd still be complaining that they'd change it from the holy ideal of what vi did.

no, i wouldn't. vi is far from perfect. the problem with vim is that they took every single thing in vi that doesn't make sense and asked themselves "how can we make this more confusing and less useful?".

And you'd still have people being confused that ".", while nominally repeating the last change, ignores pastes.

people don't seem to have that problem with all the things that change the file that vim still doesn't repeat with "."...

[phlip]

undoing the last action changes the file, but vim doesn't let you repeat that with ".". what's so special about pastes that you want to repeat them?

What's so special about inserts that you want to repeat them? Or anything else that you can repeat, for that matter? The answer is "nothing" - being repeatable is the default case, things don't need to be special to be repeatable... they need to be special to be non-repeatable.

The right question to follow that statement is "what's so special about undo that you don't want to repeat it", which is a more interesting question.

For one, "undo" in and of itself is not a context-free command, and what it does varies wildly with context. Compare that with, say, inserts, which always let you type text and add it to the file (and can be sanely repeated by inserting the same text) or pastes, which always insert text from a buffer into the file (and can be sanely repeated by pasting the same buffer)... what should "repeating an undo" actually do? There are a couple of options - it could undo to the next level, but that would have "." do wildly different things each time you press it... you expect that from "undo", by its nature, but "." you expect to do the same thing if you press it several times in a row. Or it could repeat the undone action - eg if you delete the word "cat", and then undo that deletion, "." could insert the word "cat". This seems particularly useless, and anyway, not all operations can be repeatedly undone like this... redo could be done in this way, but would still be useless.

For two, "undo" and "redo" are conceptually sort of meta-operations... you have your normal operations: insert, delete, copy, paste... with work directly with the file. Then a layer above that, conceptually, there's "." which repeats the last command. Then above that, there's undo and redo. It only really makes sense for "." to repeat the commands that are lower down than it on the layers of meta-commands.

But that's my reasoning. "." doesn't repeat undo or redo, and this makes sense, as it is valid as a special case. Paste is not a special case.

it's more common than repeating a paste.

Citation seriously needed. Or at least some kind of reasoning behind it. Ditto on your claim that having "." repeat pastes is more confusing. A tip: Just claiming it again does not count as "reasoning".

[Emu*]

This argument is putting me off ever using vi or vim. Yay for nano and Kate.

[hotaru]

Citation seriously needed. Or at least some kind of reasoning behind it. Ditto on your claim that having "." repeat pastes is more confusing. A tip: Just claiming it again does not count as "reasoning".

you're the one arguing for making a radical change to commonly used functionality. i'm saying it works the way it is. if you think the change is good, you should provide citations for your claims.

[phlip]

I have given my reasoning. My reasoning is "it makes it more consistent", and I've backed that up by comparing it to the things it should be consistent to (like showing how pastes are similar to inserts, which are repeated, and fundamentally different to undos, which aren't).

Your reasoning is "it breaks the common case", the common case being performing an action, then doing a paste, then repeating that first action with "."... and you haven't backed up your assertion that that's a common case, at all.

I only said "citation needed" because "reasoning needed" isn't the meme... I doubt there's some study out there about how often people use an obscure feature (or abuse an obscure bug) in a certain text editor... and I don't really expect you to find one. Just explain why you think that this is a common case at all.

[edit] Also, "radical change"? You're going to need to back that up, too.

[null1024]

I found jEdit.

All other editors must bow down. It's amazing. It's notepad on steroids, emacs-y but actually usable, and it looks good [well, if you like the Swing Metal UI, and change the border decorations to Metal [first thing I did on Mac, OSX makes Java apps look horrid, titlebar in menu with Aqua looks disgusting]]. Disregard my previous posts in this thread.