Re: Why bottom-posting is prefered on Vim Mainling List?
Christian J. Robinson wrote: On Tue, 29 May 2007, [EMAIL PROTECTED] wrote: As far as I know, most e-mail clients defaults to top-posting (i.e. replied message shows before the original message), In my experience it's more that it can be frustrating to try to automatically position the cursor without the software "guessing" wrong, and it's not helpful for context replying (see below). In other words, it's better to let the user move the cursor where he wants it. I wonder whether the cursor starts at the top of the email message because that's where the trimming would most naturally begin, rather than to facilitate top-posting. Perhaps it's the default "deletion point" instead of the default "insertion point" :-) Michael Henry
Re: Why bottom-posting is prefered on Vim Mainling List?
[EMAIL PROTECTED] wrote: > Matthew Winn <[EMAIL PROTECTED]> 写于 2007-05-29 16:10:57: >> That's the wrong attitude. This is the Internet. You're supposed to >> insist that you know better than everyone else even if they've been >> using the Internet for decades, and you have loads of lurkers who >> support your point of view but they're all too scared of The Clique >> to speak up, and when you're in charge you'll Show Us All. > > I feel you're talking friendly and for good. But due to my poor English > proficiency I don't seem to catch what you said. I think your English is good. Even native speakers sometimes have difficulty detecting sarcasm[1], which is notoriously easy to overlook in written language. I'm quite sure Matthew was being sarcastic here, and was actually complimenting your behavior by "stating the opposite of the intended meaning" (as the Wikipedia article on sarcasm explains it). > PS: This Off-topic thread has been talked long and I'm sorry to bring > excess load to vim mailing list, please mail directly to me if any vimmer > friends wants to talk futher about it. Thanks. I continue to be impressed by the Vim mailing list. Contributors are helpful, willing to spend time answering in detail, and above all very polite. This is one of the nicest "top- versus bottom-posting" discussions I've seen on a mailing list :-) Michael Henry [1]: http://en.wikipedia.org/wiki/Sarcasm
Re: undo & replace in multiple files
Tim Chase wrote: I think given those conditions (autowrite and nohidden), there seems to be no such way from my experimenting. However, if you switch to using hidden instead of nohidden, you can do :argdo u which will undo the last action in each argument. I've been casually looking for such a feature, but so far I've come up a little short. After a multi-file search-and-replace, I'd like to be able to undo the replace across the files. The `:argdo u` command almost does what I want, but I can't think how to restrict the undo operation to changes made only by the replace operation. For example, suppose I create two files and edit them together: echo "first file" > first.txt echo "second file" > second.txt gvim first.txt second.txt Suppose in first.txt I edit `first` to become `1st` using Vim editing commands: cw1st Now I perform a search-and-replace to change `second` to `2nd`: :argdo %s/second/2nd/ge Now I try to undo my most recent replace operation: :argdo u I'd like this to undo only the change(s) made by the s/// command, but it also changes `1st` back to `first`. Since the `u` is performed indiscriminately in all arguments regardless of whether the s/// command made changes there, I can't blindly use the undo trick to reverse an arbitrary replace operation. I've tried saving all buffers before doing the replace operation, but `:argdo u` undoes past the save (which generally pleases me greatly, but is unfortunate in this case :-)). I searched for "replace undo" in Vim's plugins and tips, but came up empty. Does anyone have a pointer to a plugin or other resource to allow blind undoing of multi-file replace operations? Thanks, Michael Henry
Re: editor size
linda.s wrote: On 5/7/07, Michael Henry <[EMAIL PROTECTED]> wrote: Try this in your .gvimrc: set columns=78 I set columns=78 but when I opened vim editor, I found the editor's column size to be 70. Why? Linda, Are you using a console version (text-mode only, typically invoked with `vim`) of Vim or a GUI version (graphical display, typically invoked with `gvim`)? If you are using a console version, settings in your .gvimrc won't be used. In my limited testing, I can make my console-mode vim resize by putting this line in my ~/.vimrc: set columns=120 I can also make it happen with the following one-liner invocation: vim "+set columns=120" It also works with gvim: gvim "+set columns=120" You may also want to test using the -N and -u NONE options: vim -N -u NONE "+set columns=120" (Feel free to change the number of columns to see if you are getting any effect.) It may help others diagnose your problem if you mention which operating system you are using and how you are invoking vim (or gvim), as well as the contents of your .vimrc (and .gvimrc if using gvim). Michael Henry
Re: editor size
linda.s wrote: After I set textwidth=78 in the .gvimrc and .vimrc, I opened my vim editor and the cursor ends at column 68. Everytime I need manaually drag the editor to make it column 78. Is there a way to make the editor the desired size (column 78)? Linda, Have a look at the 'columns' variable (:help 'columns). It controls the width of your window. The 'textwidth' variable controls the column at which your text will wrap for things like the "format lines" command (:help gq), and it sets the maximum width of text that will be inserted (longer lines will be broken at whitespace). Try this in your .gvimrc: set columns=78 Michael Henry
Minor fix for Vim Tip #1078 (Closing buffer without closing window)
All,
Vim Tip #1078 ("Best way to close (delete) buffer without closing its
window") is pretty useful. In the version shown on the tip page[1], it
doesn't keep your cursor in the window you are trying to preserve. I
think the following line is supposed to serve that purpose:
execute "normal " . g:kwbdWinNum . ""
The final pair of double-quotes are likely not supposed to be empty.
If you replace the line above with the following line, the active window
will be preserved:
execute g:kwbdWinNum "wincmd w"
I would have posted a comment on the tip, but comments are currently
disabled due to spam considerations.
As a side note, is there hope for re-enabling the comment feature? I've
found that many of the scripts have valuable comments, sometimes
containing bug fixes, sometimes pointing to similar or complementary
scripts, etc.
Thanks,
Michael Henry
[1]: http://www.vim.org/tips/tip.php?tip_id=1078
Re: Mapping to and doesn't work
Mike Mazur wrote: Hi, I'm running vim in a console using gnome-terminal. I put these mappings in my .vimrc file: map :mksession! ~/.vim/.session map :source ~/.vim/.session Pressing those buttons (CTRL+Q or CTRL+S) doesn't work. What is causing this behavior? Is it the terminal capturing the CTRL+Q and CTRL+S keystrokes before they reach VIM? I can't answer with any authority here; however, I have a reasonable guess. I run KDE on Ubuntu Linux, so I use konsole instead of gnome-terminal. I cannot map or to anything useful either. I wouldn't be surprised if this is because these two characters are historically used for terminal flow control. The CTRL-S character is the ASCII control character XOFF, which pauses the terminal output until an XON character (CTRL-Q) is received. You can see this behavior (using konsole, at least, but I imagine almost any terminal emulator would also work) by executing the following command: find /usr and then, while lots of output is scrolling by, pressing CTRL-S. The scrolling should pause until you press CTRL-Q. You can press CTRL-C to cancel the `find` operation when you grow tired of it. The GUI version of Vim doesn't suffer from this limitation. I have CTRL-S mapped to :update to match the Windows convention of mapping CTRL-S to "Save". Michael Henry
Re: Mapping doesn't work
A.J.Mechelynck wrote:
Thanks for this detailed description. This may mean that on your
terminal, meta-CR is also the start of the key sequence used to
represent some other key. Try the following:
vim -u NONE -N
:set timeout timeoutlen=3000 ttimeoutlen=250
:imap Insert-Meta-CR
Then i or a to start Insert mode, followed by Alt-Enter. Wait at least
one-quarter of a second. Does something get inserted?
1. mac, console-mode Vim: Pressing option-Enter results in the
equivalent of Escape followed by CR (goes to normal mode, then moves to
the next line).
2. mac, GUI Vim: option-CR results in plain CR.
3. Windows, GUI Vim: alt-CR results in plain CR.
4. Ubuntu Linux, console-mode Vim: alt-CR results in Escape, CR.
5. Ubuntu Linux, GUI Vim: alt-CR does nothing at first (waited at least
6 seconds); the next arbitrary keypress inserts A-with-circumflex
regardless of the keypress.
Another experiment (after the above): hit Esc to go back to Normal mode,
then
:redir @"
:map
:redir END
p
Your mapping should get inserted into the current [No Name] buffer. Move
the cursor to the character (black box or anything) representing the
{lhs} of the mapping, then hit
ga
What does Vim reply on the bottom line? (If the {lhs} is represented by
more than one character, repeat it for each of them.)
What is 'encoding' set to? If it is set to some Unicode encoding (such
as utf-8) repeat with g8 instead of ga
(Note: I had to replace the :map command with :imap to get the
insert-mode mappings to show - not sure why.)
1. mac, console-mode Vim: the six characters were inserted into
the buffer (not a single UNICODE character). The line looked like this:
i Insert-Meta-CR
encoding=latin1
2. mac, GUI-mode: same as mac, console-mode. The six characters
were inserted.
encoding=latin1
3. Windows, GUI Vim: The line looked like this:
i {black-box}Insert-Meta-CR
g8 on the black-box character returns 8d. ga shows the following:
<{black-box}> <~M>141, Hex 8d, Octal 215
encoding=latin1
4. Ubuntu Linux, console-mode Vim: The line looked like this:
i <8d>Insert-Meta-CR
g8 on the single-character-wide <8d> showed "c2 8d". ga showed this line:
<<8d>> 141, Hex 008d, Octal 215
encoding=utf-8
5. Ubuntu Linux, GUI Vim: the results were identical to console-mode Vim
on Ubuntu (including the encoding setting).
So my results on Ubuntu match Tony's results on openSUSE. The results
are similar on Windows and mac.
Michael Henry
Re: Mapping doesn't work
Matthew Gilbert wrote:
A.J.Mechelynck wrote:
Matthew Gilbert wrote:
Gene Kwiecinski wrote:
I'm using GVIM on WinXP SP2:
I'm trying to map ALT-ENTER. It doesn't work (I just get enter).
Uhhh, ain't alt-enter trapped by the OS, ie, to switch between
window/console modes?
I'm using GVIM. Also, I can enter CTRL-V_ALT-ENTER and is
inserted at the command line without issue. Thanks though. _matt
This at least means that gvim is getting the alt-enter keystroke all
right.
Can you use at least one of
:inoremap Meta-Carriage-Return
or
:inoremap Alt-Enter
after starting Vim with
gvim -u NONE -N
? If you can, then there is something that overrides it when you use
your usual vimrc and plugins.
Nope. I still get the regular enter behavior (inserts a newline). Thanks
_matt
I also am unable to successfully map . Throughout, I'm using
Tony's suggested clean-startup of Vim:
gvim -u NONE -N
On Windows using gvim 7.0, I get the same behavior described by the
original poster. M-CR comes through in insert mode as plain CR. In
fact, I get plain CR on Windows for insert-, command-line-, and
normal-mode mappings like this:
:inoremap Insert-Meta-CR
:cnoremap Command-line-Meta-CR
:nnoremap Normal-Meta-CR
As with the O.P., I'm able to press CTRL-V M-CR on the command-line and
Vim will insert .
As another oddity, after this mapping:
:inoremap Insert-Meta-CR
I get the following back from the :imap command:
i {black square}* Insert-Meta-CR
where {black square} is a single-character-wide solid black square. It
makes me think that Vim didn't translate the six characters
properly in the initial :inoremap invocation. That would go
along with the fact that pressing CTRL-V M-CR on the command line does
properly convert the M-CR keystroke into the output .
On Ubuntu Linux using vim 7.0.206, starting clean and without any
mappings at all, if I press in insert mode it appears at first
that nothing happens, but whichever key I press next causes a capital-A
with a circumflex to appear. If I execute the following command:
:inoremap Insert-Meta-CR
Nothing seems to change in insert mode (I still get A-with-circumflex on
the keystroke after pressing ). When I look at the mappings with
:imap, I get this:
i {box with "00 0D" and blank}* Insert-Meta-CR
where the curly-braced description represents the outline of a
rectangular box in which are the numbers "00" above "0D", followed by a
blank area still inside the outline.
On Ubuntu Linux, if I press CTRL-V M-CR in command-line-mode, I get
nothing until the next keypress, at which time A-with-circumflex is
inserted.
On the mac using gvim 7.0.206, the keyboard is a little different. Macs
have both an "Alt" key (named "Option") and a "Command" key. Both of
these modifier keys are used in native Mac applications. "Command" is
physically in the same position on a Mac keyboard as "Alt" is on a PC
keyboard; therefore, it's sometimes preferable to map a given function
to "Alt" + Key on a PC and to "Command" + Key on a Mac. The letter "D"
is used in mappings to mean the "Command" modifier. Starting gvim clean
and in insert mode, when I press either Option-CR or Command-CR I appear
to get plain old CR. When I execute the following:
:inoremap Insert-Meta-CR
the key Option-CR still does a plain CR. The :imap command shows the
correct-looking mapping:
i * Insert-Meta-CR
When I try to map Command-CR as follows:
:inoremap Insert-Command-CR
it works properly. Pressing Command-CR in insert mode actually inserts
the string "Insert-Command-CR". Issuing :imap shows the proper mapping
as well:
i * Insert-Command-CR
If I press CTRL-V M-CR on the command-line, I get ^M back (CTRL-M, which
is plain CR). If I press CTRL-V Command-CR, I get .
So on the Mac, it looks like meta-key mapping of CR doesn't work, but
command-key mapping does.
On all three platforms, using A-Enter instead of M-CR seems to make no
discernible difference.
Hopefully this multi-platform test information helps track down the problem.
Thanks,
Michael Henry
Re: IDE's Vim 7 and Apple OS X
Joseph White wrote: While this works fine on Linux; Mac OS X Vim does not recognize or read the $Home/.vim directory, is there an alternate location to place the IDE files? On Windows it is the c:/program files/vim/plugin directory or something close to that. Can't figure what it might be on Mac. This may not be much help, but on my mac running OS X the ~/.vim directory *is* recognized. My runtimepath variable is as follows (shown by typing `:set runtimepath=` and then pressing to populate the current value of the variable; it's convenient for cut-and-paste): ~/.vim,/Applications/Vim.app/Contents/Resources/vim/vimfiles,/A pplications/Vim.app/Contents/Resources/vim/runtime,/Applications/Vim.app/Content s/Resources/vim/vimfiles/after,~/.vim/after I don't believe I did anything special to get runtimepath setup like this. I did compile Vim 7.206 myself, with :version information below. :version VIM - Vi IMproved 7.0 (2006 May 7, compiled Mar 3 2007 15:21:47) MacOS X (unix) version Included patches: 1-206 Compiled by [EMAIL PROTECTED] Huge version with Carbon GUI. Features included (+) or not (-): +arabic +autocmd -balloon_eval +browse ++builtin_terms +byte_offset +cindent -clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv -cscope +cursorshape +dialog_con_gui +diff +digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer +fork() -gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse -mouseshape +mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme -netbeans_intg -osfiletype +path_extra -perl +postscript +printer +profile -python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp -xterm_clipboard -xterm_save system vimrc file: "$VIM/vimrc" user vimrc file: "$HOME/.vimrc" user exrc file: "$HOME/.exrc" system gvimrc file: "$VIM/gvimrc" user gvimrc file: "$HOME/.gvimrc" system menu file: "$VIMRUNTIME/menu.vim" fall-back for $VIM: "/Applications/Vim.app/Contents/Resources/vim" Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MAC -fno-common -fpas cal-strings -Wall -Wno-unknown-pragmas -mdynamic-no-pic -pipe -I. -Iproto -DMACO S_X_UNIX -no-cpp-precomp -I/Developer/Headers/FlatCarbon -g -O Linking: gcc -L/usr/local/lib -o Vim -framework Carbon -lncurses -liconv Michael Henry
