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 ;-).
Which kinda proves that there is not much to go for this particular
solution, or people would be giving positives instead of negatives, in
reply to something that may seem like a negative.
Which was just an expression of a bit of frustration, be it something that
obviously is just a personal experience, but a truth nonetheless, or
nevertheless.
And I really believe I am not the only one with such frustratiosn ;-).
The amount of time I spent editing a PHP colour file, or something that
had to work with it!!! :@.
Even discussed with its maintainer, but that person also didn't really
know how the system worked, he had just been asked to maintain it after
making some changes, or whatever.
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.
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.
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.
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. 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. 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, and normally I (still!!!)
use various different (Putty, e.g.) terminals to copy the text using the
regular desktop I am working in.
Which then requires ways of ignoring the indents, which after a long while
(!!) I discovered was done with .. oh I think it is :set paste. That
improved my Vim experience by 500%, learning that :p.
I had been bugged with auto-indents (or more, same-line or same-indent on
next-line or new-line) that would spread the indents out to the right,
which caused me to do a visual select followed by an auto-indent with =.
Which was obviously a bit of pain.
And then when finally I was working in like jEdit again, I was heaving so
many sighs of relief ;-).
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.
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.
And that is just the way it has been for me.
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.
So Vim is for me 80% frustration and 80% delight, if such a thing were
possible :p.
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). 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 something you do automatically. 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
Regular editors are not so easily closed and reopened, especially on a
desktop. It makes no sense to do that on a desktop.
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. 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. And it is no longer a component you can build into a
wider solution where you are free to choose the components you want.
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.
I just lack and lacked a good copy-paste mechanism. 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. 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.
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.
I am doing a lot of coding on telnet and ANSI. Perchance I will eventually
learn of a way, when I have enough knowhow.
Doesn't seem like a bad thing to do in any case. ANSI commands are usually
very short, but it is not like there is a real length limit, I believe.
There is a facility for sending quoted strings, and you could easily
devise a length-limited mechanism for sending a longer "copy" in parts.
There are a lot of possible commands (ANSI uses characters in the range of
@ to ^, which ends with (int)127, so to speak. For its commands. Some
commmands are even modified by a (final) number parameter like 6i. A
recurring copy-past send could be or would have to be nothing more than
CSI followed by, so usually ESC[1;"the text"z or something, or perhaps you
cannot put a command after a quote; ESC[1;"the text";z you would get. The
parameter (number) would simply indicate whether it is the start, mid, or
ending of a message. ANSI is encoded within a character-encoded stream
actually. So you have plain ASCII ANSI, but also UTF-8 ANSI, and so on.
The ANSI interpreter hence needs to sit on top of the character decoding
layer (or processing). Who knows what is possible.
You might get issues with newlines breaking up an ANSI control sequence
because normally I believe they don't ever have any and many terminals may
not like that. Nevertheless. It would be funky and funny and fun.
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.
Anyway.
Just my thoughts and feelings.
Regards,.
On Fri, 30 Jan 2015, Sven Guckes wrote:
> * <kouzennoki@gmail.com> [2015-01-30 21:26]:
>> Personally I think Vim is the antithesis of something poetic,
>> because of the vast difficulty in doing simple things :p.
>> The topics that are regular on this list, and elsewhere... it is
>> like it is an attempt at doing everything the difficult way ;-).
>
> i am sure you have many examples to show..
> can you show, say, three examples?
>
>> I would never write anything non-software
>> or non-configuration file or non-technical.
>
> so you basically dont know anything about Eric's proposed question?
>
>> Because I would not want to be bugged by endless keypress-mistakes
>> and the only reason I use Vim really is because of its speed.
>
> you just contradicted yourself.
>
>> Sometimes hating the day I (or it) was born when I
>> accidentily delete a piece of text and I cannot
>> revert the change for some reason.
>
> "undo" is your friend.
>
>> I had this keyboard or computer where
>> I was that didn't do CTRL-R.
>
> hardly a vim problem, but poor choice of keyboard.
>
>> Yes, only Vim can perform such a feat.
>> Press two wrong buttons and lose your entire file.
>> It is for the risky and daunting.
>
> let me repeat: "undo" is your friend.
> it is even persistent between sessions.
> how many more editors do you know which
> can do that? please name at least one.
>
>> Anyway, good luck with your search.
>> I'll be using vim just for
>> Linux/Unix editing though.
>
> Vim exists for many more systems - and for
> whatever kind of text you want to write.
>
> alas, you completely failed to give any
> evidence to your statements. and no
> info at all about the question itself. :-/
>
> 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.
>
No comments:
Post a Comment