|
Grex > Agora56 > #122: How to edit another file without save the current file in vi? | |
|
| Author |
Message |
| 25 new of 59 responses total. |
remmers
|
|
response 13 of 59:
| 
Feb 23 14:48 UTC 2006 |
I actually find it easier to remember how to cut, paste, and save in
emacs than in vi. X Window versions of emacs will actually let you do
all that with the mouse in the standard ways.
|
jep
|
|
response 14 of 59:
|
Feb 23 15:05 UTC 2006 |
re resp:12: Yes it does. Sorry I didn't realize it before. If you
want to save the original version of a file, you'd have to back it up
before editing it. (Which is not a bad idea anyway if you ask me.)
|
lyun
|
|
response 15 of 59:
|
Feb 23 15:11 UTC 2006 |
how can i open another file without closing the current file that may
be saved indeed?
|
jep
|
|
response 16 of 59:
|
Feb 23 15:22 UTC 2006 |
Can you repeat that? I didn't follow what you were asking about.
|
lyun
|
|
response 17 of 59:
|
Feb 23 15:30 UTC 2006 |
yep, now that is : i just wanna open another file when editing one,
which may be saved but not closed.
|
jep
|
|
response 18 of 59:
|
Feb 23 15:41 UTC 2006 |
When you open a 2nd file with:
:e file2
The name of the previous file you were editing ("file1") is saved in a
buffer. When you use CTRL-^, that file name is re-loaded from disk.
The contents are not saved in a buffer or in memory, just the name of
the previous file.
I don't know of a way to keep the contents of the first file in memory,
if that's what you mean. Why would you want to do that?
|
lyun
|
|
response 19 of 59:
|
Feb 23 15:53 UTC 2006 |
Thank you, jep
i.e.: when i use CTRL-^, then the current file name was kept into a
buffer, and the contents were saved to disk?
i gotta shutdown my computer now, i will come here tens of hours
later, thanks again
|
jep
|
|
response 20 of 59:
|
Feb 23 16:20 UTC 2006 |
No, CTRL-^ will not save the current file for you. It will inform you
the file hasn't been saved. You have to save it yourself. Once you do
so, then you can use CTRL-^ to jump to the last file you had edited
during the current session.
|
mcnally
|
|
response 21 of 59:
|
Feb 23 17:39 UTC 2006 |
I have two suggestions for lijun --
1) Use the "screen" command to manage your terminal session..
You can then open another virtual terminal using a hotkey
and start a separate vi session within that terminal.
Switching back and forth between them uses another hotkey
combination. Screen is also highly useful in other ways.
2) Learn to use one of the multi-file-capable supersets of the
vi editor. remmers (jokingly?) suggests using one of the
emacs vi modes (in typical emacs fashion there are even
several competing versions to choose from) but I think
that's overkill.. I'd strongly recommend using vim. vim
can edit multiple files at one time, saved or unsaved,
and provides other nice functions, too (such as multiple-level
undo..)
|
mcnally
|
|
response 22 of 59:
|
Feb 23 18:56 UTC 2006 |
Spelling it out a little more clearly, here's how lijun can try
it out using vim.
Start by editing a file, for example foo.c:
vim foo.c
Now make a few changes to the file (just to prove we can have
more than one modified file open at a time, just as you asked..)
Now use the vim windowing commands to create a new window:
^Wn (that's control-W, followed by n.)
Your cursor will be moved to the new window. Open a second file
for editing in that window, e.g.:
:e bar.c
Now you'll have foo.c open for editing in the bottom half of the
screen and bar.c open for editing in the top half. You can switch
between the two using ^W^W and when you're done you can save
either or neither.
|
naftee
|
|
response 23 of 59:
|
Feb 23 21:54 UTC 2006 |
can anyone give me a good reason for using vi on a normal system ?
|
twenex
|
|
response 24 of 59:
|
Feb 23 21:58 UTC 2006 |
OK, I'll bite.
Because once you've learnt it's quick to use and doesn't get in the way. (Who
REALLY needs all those instructions at the bottom of a nano window once
they've used it for the billionth time?)
|
kingjon
|
|
response 25 of 59:
|
Feb 23 21:59 UTC 2006 |
Because once you've passed the learning curve, it's the easiest editor to use.
|
naftee
|
|
response 26 of 59:
|
Feb 23 22:15 UTC 2006 |
oh. but it mustn't be the BEST editor, because here you guys are recommending
emacs for the job.
|
remmers
|
|
response 27 of 59:
|
Feb 23 22:24 UTC 2006 |
I'm the only one I've noticed recommending emacs. But I'm quite serious
about it. I prefer it for serious code development. I like vi for
quick editing jobs like editing config files or posting responses here.
"Best" is inherently a subjective judgement when it comes to editors, in
any case.
|
mcnally
|
|
response 28 of 59:
|
Feb 23 22:43 UTC 2006 |
re #23: Because it's efficient, lightweight, powerful, and can be found
already installed on a very wide array of systems.
However, I have to admit that when an improved vi alternative such as vim
or nvi are available, I generally use those instead.
|
twenex
|
|
response 29 of 59:
|
Feb 23 22:44 UTC 2006 |
Yeah. But friends don't let friends use nano! (shudder)
|
marcvh
|
|
response 30 of 59:
|
Feb 23 22:59 UTC 2006 |
I pretty much go along with Remmers's thoughts in #27. I would not try
to write a 10,000 line class library in vi; vi is for writing a 10 line
email message, or for editing /etc/foo.conf.
|
mcnally
|
|
response 31 of 59:
|
Feb 23 23:21 UTC 2006 |
re #30: There are modern vi variants with syntax highlighting,
code folding, and other programmer power features. I'll admit
that emacs has very nice integration with gcc and gdb but I'd
have no problems with using vi for the *editing* part of a large
project. The problem only comes in when you compare it to
options that provide a lot more functionality than just editing.
|
kingjon
|
|
response 32 of 59:
|
Feb 24 01:38 UTC 2006 |
Vi is my editor of choice for all pure-text word processing I do, except
perhaps entering responses in Picospan (because it erases the last responses in
my scroll-back buffer). The only reason I might not try to write a 10,000 line
library in vi is that jumping around would take minutes per jump due to the
immense size of the file -- and emacs would probably be worse on that score.
|
marcvh
|
|
response 33 of 59:
|
Feb 24 04:27 UTC 2006 |
It would be silly to put 10,000 lines of code into a single file, but I do
regularly open text files of that size in both vi and emacs, usually log
files for viewing. As long as the machine in question has sufficient memory
it's not a big deal.
|
jep
|
|
response 34 of 59:
|
Feb 24 19:14 UTC 2006 |
I use vi for viewing huge log files, too.
I have vim installed on my Windows machines at work and home. I need
it. I can do case-sensitive and pattern based searches in vi or vim
which I cannot do in any other editor available to me. I can also do
find and replace operations in vi or vim much more easily than in any
other editor available to me.
I don't use vi/vim for every situation, but I use Wordpad, Notepad and
MS Word (or 602Text) as required for different things. But I like vi
or vim the best and use them the most often.
|
remmers
|
|
response 35 of 59:
|
Feb 24 22:11 UTC 2006 |
I'll agree that vi excels at repetitive find-and-replace. If I'm in
emacs and want to do something like that, I switch emacs to vi-emulation
(by a single keystroke), do my find-and-replaces via the usual vi
keystrokes, then switch back to native emacs mode (also via a single
keystroke).
|
mcnally
|
|
response 36 of 59:
|
Feb 25 00:50 UTC 2006 |
What John doesn't tell you is that that "single keystroke" requires
a chord combination using six different modifier keys, plus the
EditMode key, a seventh key that isn't available on consumer-grade
keyboards produced for sale in the western hemisphere.
John can manage it because he's a concert-quality ragtime pianist
but if any of you were to try it without proper training your fingers
would snap like twigs.
|
remmers
|
|
response 37 of 59:
|
Feb 25 13:42 UTC 2006 |
Foof. The keystroke I'm talking about is control-Z.
|