Re: vim too complicated? or too powerful?

* <kouzennoki@gmail.com> [2015-01-31 00:24]:
> It is funny to see that the person responding to my 'empty'
> recommendations also does not provide anything meaningful, in that
> sense, but merely questions my experiences and opinions ;-).

well.. that's what happens when you follow someone who does it that way.

yes, you succeeded in side-tracking me. congratulations!
but at least you should have updated the subject accordingly.

so i did now.

> Also, I do not think that personal experiences require
> "evidence" unless I would want to pose it as a universal
> truth or anything, which I don't have any desire to do.

well.. i'm glad to help with a particular problem.
but i think the problem is yourself. blaming effects to
happen when you mistype is hardly a problem of the program.

it is unfortunate that many programs do not have an undo.
but vim does have a thousand undos by default. it also
offfers a redo command. you can go several ways with this
in an undo tree - and it is persistent to editing sessions.

the only thing you are missing here is how to use it.
there is documentation galore. you just need to learn it.

> But to the questions. It is pretty obvious that in any regular
> editor, search and replace (of text, or even patterns,
> sometimes) is a very simple task to perform. You go to a
> visible menu, select a visible option, fill in a few visible
> field with visible options.... and in Vim you have to remember
> to do :s/text/text/ig or something like that. Or is it
> %s/text/text/ig ?. I don't remember. Now. I like Vim's visual
> mode but I don't know much else that is that easy. It is a bit
> like Linux's "info" system, but Vim is easier than that :p.

by "regular" you mean "the way i am used to", right?
so you want an interface to pop up with different text
areas for the search string and the replacement string?
and a button for "ignore case" and "ask me every time"?

how to navigate around this in an environment with mice?
TAB and shift-TAB perhaps? all these things within GUIs?

how about an interface where all these things
can be down with exactly *one* keystroke?
answer: the command line. just put the search
and replacement string right behind each other.
only requires separation with slashes. done.

just put the lines to operate on before it.
"1,23" or "23,42" or "42,$" ('$' = last line).
the '%' is the abbreviation for "all lines".
otherwise it simply operates on the current line.
these are *concepts* - and you will find that
other programs are also using it. coincidence?

anyway - you need to remember this.
as with *everything* you do, right?

if you however do not WANT to remember this and
you think popup dialogs are the way to go, well,
it is right there with every other program, right?

you could add these dialogs to vim - but there is a
reason why it hasnt been added. one of these is
the consistency with its ancestor "vi" - and another
one is that it should work on terminals as well.

> The whole idea of making a lot of key press mistakes is because
> the environment allows you to really quickly do various tasks.
> So it is not a contradiction: the mistakes result from being a
> fast typer and Vim does not put any hinderness or obstruction in
> the way of working really fast. So obviously in that context if
> you press a lot of mode switches you regularly enter a text
> input when you are accidentily in a command mode.

bzzt!
you keep talking about mistakes.
but who makes them? you do!

vim indeed has not been designed for you
to mistype and still get the same results.
if you are asking for that then you may as
well go trolling with this everywhere else.

vim has just two modes really:
in one it works - and in the
other you are simply mistyping.

> Which then does things you do not want and you don't even know
> what commands you just executed, just that you need (sometimes)
> a way to undo it again. Undo is your friend, but sometimes it is
> the only thing that keeps you floating ;-). There is a
> difference ;-).

> I still don't know or remember how to do window editing.

it is not the program's task to make remember everything.
that's *your* task. besides, there's ":help". a lot of it!

> I still don't know how to copy text from one file
> to another except by doing :e or :f filename which
> always replaces the current file, I believe.

this is not a matter of belief.
you can switch buffers with *surprise* "buffer" command - ":b"

> The whole prospect of having to copy text from one
> file to another with Vim makes me feel miserable
> and wish I had a regular editor.

a *regular* editor? well, the text editor
compendium lists 200+ of them. use one!

> and normally I (still!!!) use various different
> (Putty, e.g.) terminals to copy the text
> using the regular desktop I am working in.

so you are using an external program to copy+paste? why?
because you do not know how to use all those
nifty commands for copy+paste built in already?
come on.. you keep showing your ignorance here.

you need to unplug that mouse for a week or so.
there are plenty of commands you copy+paste text.

> And then when finally I was working in like jEdit
> again, I was heaving so many sighs of relief ;-).

well.. use jEdit then?!

> But I regularly do PHP editing in Vim. I have never saw fit to integrate any
> thing outside into it (compilers, other..) so my workflow is pretty bad, but
> it is enough when you can just reload a webpage from your home computer ;-).
> It definitely beats having to reupload changed files every time.

read up on ":help quickfix"..

> But I seriously sometimes would download a file, using whatever difficult
> means because a PHP file is not easily downloaded when it is executed, then
> change it (copy paste stuff) locally, and then find a way to scp it back.
> All very tedious and arduous, but it was a better spending of
> time for me than learning the Vim way at those points or moments.

so the other programs you use make this easier? how so?

> And that is just the way it has been for me.

until you find out and use something like sshfs:
http://en.wikipedia.org/wiki/SSHFS
or maybe www.emacswiki.org/TrampMode

> Learning or reading documentation to do simple things is
> not exactly my favourite pastime, eventually especially
> when you forget how to do a certain thing again because
> it never quite makes it to muscle memory.

yeah.. reading up on how to do things more
efficiently doesnt seem to be your thing.
but that makes *everything* in your hands look bad.
until one realizes that *you* are the problem here.

> Even writing this email in Alpine (Pico) is just amazingly
> relaxing compared to having to do such a thing in Vi.
> Arrow keys always do what they should, I don't have to
> remember HJKL keys if the arrow keys don't work for some
> reason as well as being bugged by which of the BWE keys I
> need this time (I make so many 'mistakes' in that).

yes, i do agree here: the strength of this editor
is that it displays some commands always on screen.
that why i gave pico to beginners first. easy start!
and i also supported it to be rewritten as nano
which separated it from the pine mailer/newsreader,
gave it a free license and a lot more commands, too.

however.. even nano doesnt have a
concept of number prefix to repeat things.
it does not have the dot operator
to repeat the last change command.
it does not have filtering and..
a lot more. that's why i use vim.

to give an example, i wrote it down:
http://www.guckes.net/pico/vs.vi.html

vim has way too many commands to display -
and its strength is in the *concept* of
combining commands (such as 23yy and 42dd)
which simply cannot be easily shown on screen.

think of the "vi mug" - even this cannot show everything.
a "vim mug" to show all commands would probably
be the size of a bath tub or even a pool. (i know..
i have written a few command summaries myself.)

> The things that work fast in Vim are the easy things: dd p
> But in a different editor you would shift-down-arrow,
> ctrl-x, down-arrow, ctrl-v. More arduous, but easy.

..and deleting 42 lines is simply "42dd".
how do you do this is another editor
without counting in your head or
looking at the lines numbers?

my point: the prefix number for commands is a very
poweful concept. alas, nano/pico dont have that.

> And something you do automatically.

... once you have learned it.

this is not a feature of the program -
this is a feature of your *brain*.

> I would say the power of Vim's command is also its
> downfall or its nemesis. Because of being able to
> do impressive things with short commands you are
> enticed or induced to do these things very fast.
> This means you get into a higher mode of
> concentration and ..speed. Even exiting the thing
> is the quickest thing ever with a quick :wq

.. or just ZZ.

would you rather opt for more? or something else?
you can certainly have that if you want. just map it!

> Regular editors are not so easily closed
> and reopened, especially on a desktop.
> It makes no sense to do that on a desktop.

huh? your statement doesnt make sense.

> So on a desktop you often have to save the file,
> alt-tab to the right window where your shell is
> (commandline) which is sometimes hard to find, etcetera.

a shell/terminal is hard to find
when you are using a given environment
where the authors agreed to hide it.

a terminal can be opened on quite a few systems with
a shortcut (ctrl-alt-t is a frequent example) - or
with whatever shortcut *you* want. just make it so!

i mean, if you really this often then you
simply make it accessible easily, dont you?

> Unless and until you the start integrating everything into
> the editor or IDE itself, which then becomes a bliss, but
> it still lacks the power of a real editor like Vi. Because
> then you are bound and chained to that particular IDE.

you are not chained to do anything.
you are just limitd to your abilities.

> And it is no longer a component you can build into a wider
> solution where you are free to choose the components you want.

yes, you are not free - when you dont know what you can do.

> It is just that I just haven't had the time or need or
> opportunity to invest a lot of time into making Vim my
> default workflow component across a network link. I would
> never use it on a local computer because usually I would
> prefer desktop editors for that. I just like the idea of
> working on e.g. a development server with vi for editing.

wrong again. you didnt take the time. again - your fault.
and you can choose whatever as your environment - and
again this is NOT a built-in problem of vim. it's you.

> I just lack and lacked a good copy-paste mechanism.

"ayy use register 'a' to copy the current line
:b 23 switch to buffer 23
"ap use register 'a' to paste its contents
^W ^W switch to the window below the current one
42"ap paste 42 times the contents of register 'a'

there is a register (read: clipboard) for every letter.
so 26 clipboards altogether. been there for decades now.
and they are retained in the viminfo file - if you wish.
why would you use the system default clipboard instead?

which of your other programs have more than two clipboards?
built-in? in the smallest version? for years? name one!

> I believe I will never learn the Vim way and I don't need to,
> a desktop environment should or would be sufficient I believe.

wait.. you already have something better than vim which
suits you? then why the hell complain about vim at all?
just use it - and tell us about it. what is better?
and please explain *why*. give some examples!

> But in that case I am seriously looking into thinking
> about having a way to get this information sent over
> the link into my own clipboard, for instance.

"if your only tool is a hammer - every problem looks like a nail."

> Currently I am writing this in KDE (Kubuntu 15.04, their new
> alpha version 2) and it has a reasonably good clipboard tool.
> Perhaps we could in the end devise a way for such a program
> like Vim (and I would not mind programming on it) in
> combination with a shell (likewise) to get a mechanism where
> these copy-pastes are actually processed from the editor into
> the shell, from the shell to the terminal, and from the
> terminal to the receiving client. I mean, why not.

you are not the first person to think up something like this.
and there are a LOT of tools out there which already do this.
have you never tried looking this up?

> I am doing a lot of coding on telnet and ANSI. Perchance
> I will eventually learn of a way, when I have enough knowhow.

"coding *on* telnet" - a telnet program?
or are you using telnet to log in?
(clear text? no encryption? uh-oh.)

> Ideally I would really want to have a pipe like that. You
> could even pipe the text into a unix pipe and the terminal
> itself will read it when configured, or whatever. I don't
> know how (unix) interprocess communication works like
> that, but I think pipes are an excellent idea for that.

you can use the gui clipboard from within vim.
you simply use its name ("*) before copy/paste.
see ":help quotestar". you may easily copy the
current text object (word, sentence, paragraph)
to put it right there with one function key.

whatever shortcut you want - it is you who decides.
and it *must* be you to change vim's configuration.
it all depends on your own editing habits.
no interface can assign all possibel nice thing
to any key - unless you are get yourself one
of those keyboards with *hundreds* on keys.

my advice:
monitor yourself. what commands do you need?
how do you do it so far? write it down.
ask for advice to amke it more efficient.

take the TIME to look at some howtos, even videos.
ask a friend, ask the local community,
ask the virtual community online.

follow the edvice you are given.
train yourself some commands.

for repetetive tasks - try to find an abbreviating command.
it may need to create a function and bind it to a key (sequence).
see also: http://www.youtube.com/watch?v=eX9m3g5J-XA

take a look at some of the plugins.

try to do the same task in another program.

and if no program gives you everything - use several.

if you must have everything in one program
and you cannot find one - write your own!
or try to do the same with the help of others.
programming is not a crime. (well, not yet.)

Sven

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.