Re: Terminal-based auto-paste.
On 2006-07-10, Sean Reifschneider <[EMAIL PROTECTED]> wrote: > On Mon, Jul 10, 2006 at 07:38:02AM +, Yakov Lerner wrote: > >package-maintiners and expect them to fine-tune binary packages > >to your inquiries/needs/wishes. Unless you are package-maintiner > > Having an expert tune the packages for the general cases is probably going > to work much better on average than having the layman try to tune it > themselves. A good package maintainer can make it so that a package fits > nearly everyone's needs. I have submitted a suggestion to the Fedora > packager that they extend the "vim-x11" package to include not only "gvim", > but also "xvim", leaving the stock "vim" package being compiled with > --with-x=no. This way you get the fairly minimal package in "vim-minimal", > and users who want vim on a server without X installed are happy. And > users who want enhanced X capabilties can install "vim-x11" and get > enhanced functionality by calling (or aliasing) gvim or xvim. Since you mention aliasing, I think the simplest solution to this would be: alias vim="gvim -v" That will give you a terminal-mode vim with all the X features that were compiled into your gvim. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Resizing the window with very long lines of text.
On Mon, Jul 10, 2006 at 20:52:00 +0100, Ron Blaschke wrote: > Bram Moolenaar wrote: > > Soon-Ping Phang wrote: > > > >> I'm trying to determine whether I should submit a bug > >> report for a problem I encountered or if one was > >> already submitted. > >> > >> Basically, I'm finding that if I paste a long line of > >> text (4650+ characters) into an 80x25 Vim window (v7.0 > >> on WinXP), and then, while leaving the cursor at the > >> end of the line, maximize the window, Vim crashes. > >> > >> Has anyone encountered this before? > > > > I don't think this was reported before. Please describe the environment > > in which this happens. Preferably without any personal settings, start > > Vim with "-u NONE". > > I experienced this too, some time ago, but didn't worry because I rarely > work with such long lines. At least on my system I can reproduce this > with 7.0 on my Windows XP box. > > Start gvim > gvim -u NONE > > Insert 5000 characters, e.g. '-' > 5000 i - > > Vertically enlarge the window about 10 lines. > > That's it. > Unhandled exception at 0x0041226d in gvim.exe: 0xC005: Access > violation writing location 0x734b490a. Crashes on linux as well (GTK2 GUI, 7.0.17). But for crash it is necessary to enlarge the window by at least 5 lines. Enlarging the window by 4 or less lines, and shrinking its size works without problems. Strange, I observed this crash also on another machine (gvim, compiled 8th of May including all the patches till that day, GTK2 GUI) when running locally, but I did not manage to trigger it when running remotely right now. Regards, Peter Cech
Re: Resizing the window with very long lines of text.
Bram Moolenaar wrote:
Soon-Ping Phang wrote:
I'm trying to determine whether I should submit a bug
report for a problem I encountered or if one was
already submitted.
Basically, I'm finding that if I paste a long line of
text (4650+ characters) into an 80x25 Vim window (v7.0
on WinXP), and then, while leaving the cursor at the
end of the line, maximize the window, Vim crashes.
Has anyone encountered this before?
I don't think this was reported before. Please describe the environment
in which this happens. Preferably without any personal settings, start
Vim with "-u NONE".
I was able to duplicate the problem using Fedora Core 5 (linux):
gvim -u NONE
5000i-
(vertically lengthen screen by pulling on bottom of window)
yielded a core dump:
(gdb) where
#0 0x00245410 in __kernel_vsyscall ()
#1 0x00afb546 in ?? ()
#2 0x0813b087 in mch_call_shell (cmd=0x1 ,
options=17625) at os_unix.c:4351
#3 0x0813d028 in mch_settitle (
title=0x818c53b
"\036\b\213\025\214�\037\b��037\b\211ã\204�\037\b�\200�\037\b�|�\037\b\200:",
icon=0x1 ) at os_unix.c:1919
#4 0x08100e28 in prepare_to_exit () at misc1.c:8211
#5
#6 0x00245410 in __kernel_vsyscall ()
#7 0x00afb159 in ?? ()
#8 0x00c01ff4 in ?? ()
#9 0xb7f336b0 in ?? ()
#10 0xbff46e5c in ?? ()
#11 0x00afc6e3 in ?? ()
#12 0x0006 in ?? ()
#13 0xbff46dd0 in ?? ()
#14 0x in ?? ()
(gdb) up
#1 0x00afb546 in ?? ()
(gdb) up
#2 0x0813b087 in mch_call_shell (cmd=0x1 ,
options=17625) at os_unix.c:4351
4351 msg_putchar('\n');
Regards,
Chip Campbell
Re: Resizing the window with very long lines of text.
Bram Moolenaar wrote: > Soon-Ping Phang wrote: > >> I'm trying to determine whether I should submit a bug >> report for a problem I encountered or if one was >> already submitted. >> >> Basically, I'm finding that if I paste a long line of >> text (4650+ characters) into an 80x25 Vim window (v7.0 >> on WinXP), and then, while leaving the cursor at the >> end of the line, maximize the window, Vim crashes. >> >> Has anyone encountered this before? > > I don't think this was reported before. Please describe the environment > in which this happens. Preferably without any personal settings, start > Vim with "-u NONE". I experienced this too, some time ago, but didn't worry because I rarely work with such long lines. At least on my system I can reproduce this with 7.0 on my Windows XP box. Start gvim gvim -u NONE Insert 5000 characters, e.g. '-' 5000 i - Vertically enlarge the window about 10 lines. That's it. Unhandled exception at 0x0041226d in gvim.exe: 0xC005: Access violation writing location 0x734b490a. Ron
Re: vim-7.0.035 linux motif gui crashes immediately (test16)
Raf wrote: > > > on linux-2.6.17.1 (ubuntu-6.06, core duo), vim-7.0.035 with motif/lesstif > > > crashes immediately when :gui or -g is used (e.g. test16). or is it just > > > me? > > > the :version output and two examples are included below. > > > > > > :version > > > VIM - Vi IMproved 7.0 (2006 May 7, compiled Jun 30 2006 18:30:11) > > > Included patches: 1-35 > > > Compiled by [EMAIL PROTECTED] > > > Normal version with X11-Motif GUI. Features included (+) or not (-): > > > > It works fine for me. Perhaps a problem in your X11 setup? > > i don't think so. it crashed in both twm and gnome+metacity. > > this is with lesstif2/motif-2.1 (ubuntu pkg: lesstif2-dev 0.94.4-1). > it also crashed with the latest lesstif (0.95.0) compiled > from source. > > but it does work fine with lesstif/motif-1.2 > (ubuntu pkg: lesstif-dev 0.93.94-12). > > i'm happy with that. Well, I don't get the crash and it happens somewhere deep in X11 library functions, I can't guess what a workaround could be. Since Vim has always worked fine with all kinds of Motif, I would still think it's a problem in the X11 library. Wouldn't be the first time... -- Engineers will go without food and hygiene for days to solve a problem. (Other times just because they forgot.) (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Resizing the window with very long lines of text.
Soon-Ping Phang wrote: > I'm trying to determine whether I should submit a bug > report for a problem I encountered or if one was > already submitted. > > Basically, I'm finding that if I paste a long line of > text (4650+ characters) into an 80x25 Vim window (v7.0 > on WinXP), and then, while leaving the cursor at the > end of the line, maximize the window, Vim crashes. > > Has anyone encountered this before? I don't think this was reported before. Please describe the environment in which this happens. Preferably without any personal settings, start Vim with "-u NONE". -- The fastest way to get an engineer to solve a problem is to declare that the problem is unsolvable. No engineer can walk away from an unsolvable problem until it's solved. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: vim mac close button state patch
Hi, this patch sets the close button state according to "Indicating Changes With the Close Button" in the Apple HIG ( http:// developer.apple.com/documentation/UserExperience/Conceptual/ OSXHIGuidelines/XHIGWindows/chapter_17_section_3.html ). I haven't tried it but it's good to try to make Vim look like other Mac applications. The implementation is rather brute force. I'll try to improve it. I like to add proxy icons as well (see above link too), which deprecates this patch anyways. A proxy icon is a small icon of the current document (ie. active buffer in active tab) in the windows toolbar which you can drag to other programs (for example, to create a link to an opened file, drag its proxy icon to some folder in the finder). You can Command-click the proxy icon to display the path to the current document as well. When the current file isn't saved, the proxy icon is deactivated because it's not predictable for the user what happens when you drag the icon. Sadly, you call the same function to change the close button and to (de)activate the proxy icon, which doesn't work well with multidocument windows. I looked at several other mac text editors; they all set the close button to the "document was modified" state when the active document was modified (to keep the proxy icon for unmodified buffers activated when such a buffer is selected). I will try to add this behaviour to mac vim as well (but it will take me some time, currently I'm busy with exams :-| ). Bye & sorry for the long mail, Nico
Re: Terminal-based auto-paste.
On Mon, Jul 10, 2006 at 07:56:13PM +0300, Yakov Lerner wrote: >Vim is special. I believe that being organic extension of >programmer/sysadmin fingers, it deserves special attitude >that other packages. The point you missed, assuming I was being absurd, is that I can probably find someone on the developers list for the vast majority of those other 1200 packages who says exactly the same thing about that package. We can get it fixed in Fedora, and it helps a lot of users. I recommend using packages wherever possible. As compiling --with-x=yes doesn't, in actuality, solve the problem I was having (that mouse support acts differently than other applications), I don't see any justification for building my own, locally-installed vim and tracking updates. Thanks, Sean -- Brooks's Law of Prototypes: Plan to throw one away, you will anyhow. Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability Back off man. I'm a scientist. http://HackingSociety.org/
Re: Terminal-based auto-paste.
On 7/10/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: I penetrated this barrier once ~ 6 years ago, the barrier between the stock-rpm-vim and self-build-rpm. Correction. I wanted to write: ... the barrier between the stock-rpm-vim and self-build-vim.
Re: Terminal-based auto-paste.
On 7/10/06, Sean Reifschneider <[EMAIL PROTECTED]> wrote: I have submitted a suggestion to the Fedora packager I wish you god luck waiting from Fedora packager. I referred to the possibility of installing vim under $HOME/bin, for one user only, you. (This is possible even if user is root). The other users use stock /usr/bin/vim, but you'll use vim from $HOME/bin/vim. The advantage is that it's built precisely to your taste. Mucking with 1st build takes, maybe, 1/2 hour. Non-first build is seconds of you net time (that if you package it into script as I did; it's one command and then couple of minutes of background work). I don't know exactly how long it takes for changed Fedora package. But I believe there is gain even in you net time. If you know the exercise of (./configure --prefix=$HOME --with-features=huge && make && make install) it's really easy. (It you don't, it's worth learning anyway. For myself, I made a script that downloads the latest vim-src.tgz and builds it all in one invocations exactly with options I like. Rebuild takes 10 seconds of my net time). I never come from this point back to stock-rpm-vim. So, it gives you full control. Quick control. And you don't need to break other users's vim when you install under $HOME/bin. I penetrated this barrier once ~ 6 years ago, the barrier between the stock-rpm-vim and self-build-rpm. I remember my initial hesitation and difficulties, and I understand your hesitation. This conversion, it's worth a mass. Just try it once, and you'll stick with it. I currently have over 1251 packages installed on my system, do you know how long it would take to correctly (let alone optimally) package and build, to say nothing of hunting down and apply updates, for this laptop? You slipped into absurdity here. Nobody suggested that you rebuild 1200 [unrelated] packages because of minor problem with vim rpm. Vim is special. I believe that being organic extension of programmer/sysadmin fingers, it deserves special attitude that other packages. Yakov
Re: BUG: indirect 'configure' invocation hides exit status
(re-send because I forgot to CC vim-dev; sorry)
Bram Moolenaar wrote:
Matthew Woehlke wrote:
[snip]
The indirect 'configure' scripts need to preserve the exit
status.
The fix, which is trivial, I leave as an exercise.
So, what is the fix? I'm lazy.
Goodness, I'll say. :)
vim/configure:
-cd src && ./configure "$@"
+cd src && exec ./configure "$@"
vim/src/configure:
CONFIG_STATUS=auto/config.status \
auto/configure "$@" --srcdir="${srcdir:-.}" \
--cache-file=auto/config.cache
+result=$?
# Stupid autoconf 2.5x causes this file to be left behind.
if test -f configure.lineno; then rm -f configure.lineno; fi
+exit $result
Anyway, when the curses library isn't found configure will continue.
This is because on a few platforms the functionality is included in the
standard libraries and Vim can be build anyway.
Not when using '--with-tlib=ncurses' it won't. However, I consider this
a GOOD thing; if I *tell* it to use ncurses, I expect it to either do
so, or fail. Particularly on HP-UX (at least, I think HP-UX is where I
had the problem), it otherwise wants to fall back on termlib which
results in reduced functionality. Of course, if I /don't/ explicitly use
'--with-tlib', then it's OK for it to fall back on termlib and continue
(and it does, as evidenced by the case where I did get termlib instead
of curses, which is why I started using --with-tlib=ncurses in the first
place).
--
Matthew
DOS Attack: See America Online -- my college room mate
VIM 7.0 scripts, ctags and taglist.vim
VIM 7.0 is known have been extended with rather advanced scripting capabilities
such as complex data structures and object-oriented programming in embryo. So,
now we can define methods for some object type in such a way:
let MyObjectType = {}
function! MyObjectType.method1()
echo 'Hello world from method1!'
endf
function! MyObjectType.method2()
echo 'Hello world from method2!'
endf
However, if one tries to open taglist for such a code one will see:
|- variable
|| MyObjectType
|
|- function
|| MyObjectType
|| MyObjectType
Such a behavior most likely is far from one's expectations. Though, there is no
any riddle here, just the latest version of exuberant ctags cannot parse new
extensions to VIM script.
I've found an easy way to extend the latest version of ctags to make it more
suitable for using with new VIM scripts. With this extension taglist for code
above will look so:
|- class
|| MyObjectType
|
|- function
|| MyObjectType.method1
|| MyObjectType.method2
Here (http://community.livejournal.com/screenshot_vim/4893.html) once more
example.
Note that you will not be able to jump to method definitions using
neither with original ctags nor with patched. Though, with patched version you
will be able to jump to method definition through taglist.
To obtain such a behavior you need to patch latest version of exuberant ctags,
namely file vim.c
1. Download the latest version of ctags (5.6) here:
http://sourceforge.net/project/showfiles.php?group_id=6556
2. Unpack it and go to directory created: tar zxvf ctags-5.6.tar.gz; cd
ctags-5.6
3. Patch file vim.c with this patch:
32c32,34
< K_VARIABLE
---
> K_VARIABLE,
> K_CLASS
>
38a41
> { TRUE, 'c', "class", "class definitions" },
105c108
< } while (isalnum ((int) *cp) || *cp
== '_');
---
> } while (isalnum ((int) *cp) || *cp
> == '_' || *cp == '.' || *cp == '\'' || *cp == '"' || *cp == '[' || *cp ==
> ']');
157c160
< } while (isalnum ((int) *cp) || *cp == '_');
---
> } while (isalnum ((int) *cp) || *cp == '_'||
> *cp == '.' || *cp == '\'' || *cp == '"' || *cp == '[' || *cp == ']');
159c162,176
< makeSimpleTag (name, VimKinds, K_VARIABLE);
---
> while(isspace((int) *cp))
> ++cp;
> if(*cp == '=')
> {
> ++cp;
> while(isspace((int) *cp))
> ++cp;
> if(*cp == '{' || strncmp ((const char*)
> cp, "extend", (size_t) 6) == 0 ||
> strncmp ((const char*) cp,
> "copy", (size_t) 4) == 0 ||
> strncmp ((const char*) cp,
> "deepcopy", (size_t) 8) == 0 ||
> strncmp ((const char*) cp,
> "filter", (size_t) 6) == 0 ||
> strncmp ((const char*) cp,
> "map", (size_t) 3) == 0)
> makeSimpleTag(name, VimKinds,
> K_CLASS);
> else makeSimpleTag (name, VimKinds,
> K_VARIABLE);
> }
4) Build ctags and install:
./configure
make; make install
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.10/383 - Release Date: 7/7/2006
Re: vim-7.0.035 linux motif gui crashes immediately (test16)
Bram Moolenaar wrote: > Raf wrote: > > > on linux-2.6.17.1 (ubuntu-6.06, core duo), vim-7.0.035 with motif/lesstif > > crashes immediately when :gui or -g is used (e.g. test16). or is it just me? > > the :version output and two examples are included below. > > > > :version > > VIM - Vi IMproved 7.0 (2006 May 7, compiled Jun 30 2006 18:30:11) > > Included patches: 1-35 > > Compiled by [EMAIL PROTECTED] > > Normal version with X11-Motif GUI. Features included (+) or not (-): > > It works fine for me. Perhaps a problem in your X11 setup? i don't think so. it crashed in both twm and gnome+metacity. this is with lesstif2/motif-2.1 (ubuntu pkg: lesstif2-dev 0.94.4-1). it also crashed with the latest lesstif (0.95.0) compiled from source. but it does work fine with lesstif/motif-1.2 (ubuntu pkg: lesstif-dev 0.93.94-12). i'm happy with that. cheers, raf
Resizing the window with very long lines of text.
Hi, I'm trying to determine whether I should submit a bug report for a problem I encountered or if one was already submitted. Basically, I'm finding that if I paste a long line of text (4650+ characters) into an 80x25 Vim window (v7.0 on WinXP), and then, while leaving the cursor at the end of the line, maximize the window, Vim crashes. Has anyone encountered this before? Thanks psp -- Soon-Ping Phang [com->yahoo->ingmiorr] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Terminal-based auto-paste.
On Mon, Jul 10, 2006 at 07:38:02AM +, Yakov Lerner wrote: >It is so much easier and predictable to build & install vim from >sources youself, (with exactly the features you need), than hunt I understand that some people believe this, but as a large-scale system administrator I disagree. If I avoid the native packaging system, how will I know when there are (possibly security-related) updates available? I currently have over 1251 packages installed on my system, do you know how long it would take to correctly (let alone optimally) package and build, to say nothing of hunting down and apply updates, for this laptop? Factor in, say, 100 machines in various stages of production or test, and you suddenly have to build an empire just to maintain them. >package-maintiners and expect them to fine-tune binary packages >to your inquiries/needs/wishes. Unless you are package-maintiner Having an expert tune the packages for the general cases is probably going to work much better on average than having the layman try to tune it themselves. A good package maintainer can make it so that a package fits nearly everyone's needs. I have submitted a suggestion to the Fedora packager that they extend the "vim-x11" package to include not only "gvim", but also "xvim", leaving the stock "vim" package being compiled with --with-x=no. This way you get the fairly minimal package in "vim-minimal", and users who want vim on a server without X installed are happy. And users who want enhanced X capabilties can install "vim-x11" and get enhanced functionality by calling (or aliasing) gvim or xvim. Seems like a workable solution that will make everyones lives easier. >yourself, why would they follow your preferences rather than, say, >their own preferences ? A packager is doing the packaging as a community service. They rarely do it to their own preferences. If you are a Fedora packager, you almost never get to consider only your own preferences. This is why there is the review process. >Look like the pat of Sean Reifschneider's problem is that No, my problem is that vim --with-x=no works identically to other applications running in X terms. However, it can't make use of the extremely cool automatic "paste" function. Configuring it so you get automatic pasting causes it to act extremely differently than other xterm applications. --with-x=yes or --with-x=no doesn't matter. The only thing that --with-x=yes fixes is that when you ":set mouse=a" in a vim built --with-x=no, the pasted text comes from, I think, the 0 buffer and not the X selection. My understanding of this is that the problem is that when you ":set mouse=a", it send the escape sequence to tell xterm to send mouse events. So, instead of xterm sending the selection when you click the middle mouse button, it sends a "Middle mouse button pressed" message. Thanks, Sean -- I find that a great part of the information I have was acquired by looking up something and finding something else on the way. -- Franklin P. Adams Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
Re: Terminal-based auto-paste.
On Mon, Jul 10, 2006 at 09:26:54AM +0200, Nikolai Weibull wrote: >Well tell them to fix that, or you'll never get access to "* or "+ from Vim. As I said in the previous message, I've already opened a bug request with Fedora about it. It wasn't until late today that I also tested it on Ubuntu. However, as it's still acting differently than other applications in xterms in some ways, I think there's still a case for the original suggestion. Thanks, Sean -- If I wrote a file-system, it would have a super-duper block. -- Sean Reifschneider, 2003 Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
Re: Terminal-based auto-paste.
On 7/10/06, Nikolai Weibull <[EMAIL PROTECTED]> wrote: On 7/10/06, Sean Reifschneider <[EMAIL PROTECTED]> wrote: >A new feature in vim would make it work extremely well, using the stock >packages as built in Fedora Core and Ubuntu (neither builds --with-x=yes >in the non-gvim version). Well tell them to fix that, or you'll never get access to "* or "+ from Vim. It is so much easier and predictable to build & install vim from sources youself, (with exactly the features you need), than hunt package-maintiners and expect them to fine-tune binary packages to your inquiries/needs/wishes. Unless you are package-maintiner yourself, why would they follow your preferences rather than, say, their own preferences ? Look like the pat of Sean Reifschneider's problem is that he never tried to build vim from the sources despite the fact that it's very easy. Yakov
Re: Terminal-based auto-paste.
On Sat, Jul 08, 2006 at 01:41:26AM +0200, Nikolai Weibull wrote: >But what's the point? Some characters will already have been inserted >and they won't have had 'paste' set. I fail to see how this is a path >to follow. Absolutely, the first N characters of your text may have been pasted incorrectly if they have newlines or the like. On a local machine, N could be as small as 2 (over 100ms that would represent a typing speed of 600cps, which is pretty snappy). Obviously, it couldn't tell the difference between a high priority process gobbling up a bunch of time while you're typing, a laggy network line between you and vim, and probably other things, but it seems like a lot of the time it would work great. Again, this is like what's already what's implemented in other places in vim, so there seems to be some evidence that it's a workable solution. It would be ideal to do read-ahead and if you have a kilobyte of text sitting there ready to read, it's probably a paste, but that gets you into trouble the read-ahead includes ":sh". Of course, some programs do discard type-ahead text, so it wouldn't be unprecedented, but I agree it would be nice not to. Thanks, Sean -- I have never been able to conceive how any rational being could propose happiness to himself from the exercise of power over others. -- Jefferson Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
Re: Terminal-based auto-paste.
On 7/10/06, Sean Reifschneider <[EMAIL PROTECTED]> wrote: A new feature in vim would make it work extremely well, using the stock packages as built in Fedora Core and Ubuntu (neither builds --with-x=yes in the non-gvim version). Well tell them to fix that, or you'll never get access to "* or "+ from Vim. nikolai
Re: Terminal-based auto-paste.
On Mon, Jul 10, 2006 at 07:34:12AM +0200, Pierre Habouzit wrote: >> and that's a workable solution. It's still annoying how clicking and >> selecting text causes vim to move my cursor around and requires me to >> press escape when I'm done selecting. > >maybe you could read :he mouse then (and really do it that time). I've read the help for mouse, selection, and all related things I could find for hours over several weeks. This isn't something that I've just immediately said "Hey, someone else can fix it for me", I've spent probably 8 hours over the last month farting around with trying different things, reading the available documentation, searching on google and the vim site, before I ever posted on this list. If you'd have read this thread nearly as carefully as you are expecting me to have read the documentation, you would know that: The available settings in vim aren't cutting it for me. Yes there are workarounds, none idea, few acceptable, but my original point was... A new feature in vim would make it work extremely well, using the stock packages as built in Fedora Core and Ubuntu (neither builds --with-x=yes in the non-gvim version). I never wanted anyone to help me with fixing it. That's why I posted on the dev list, not the users list. I wanted to register and hopefully discuss a feature request idea. So far, nothing has been said that invalidates the original feature request, the mouse in vim still acts differently under an xterm than under non-vim applications. >it's a pain because you're not used to it, but (1) it works like that in >every terminal-mouse-aware application That's the saving grace is that if I get used to shift left drag to select, it works in other applications. If it didn't, and I had to spend cycles on whether I'm in vim or not to do a selection, I would probably just live with :set paste in vim when I need to do a paste. Converting over to shift-left drag is doable. Still, it would be ideal if it just did what all the other applications do in an xterm. >and (2) you can disable mouse in vim if you don't like it. Obviously. Then I lose the goodness of pastes being handled properly, but I've lived with it that way for 20 years, I can probably continue to do so. >hence the read the damn manual thing: You absolutely misunderstood what I said. Read the damn reply. :-) I know that pastetoggle can be used to map F4 to toggle paste. That's why I said I'm not much of a keymapping person and explained that I'd rather type ":set paste", than hunt around for F4. I can use my mouse to paste while remaining on home row, but F4 breaks my flow more. >ui again. if that's not a shortcut, then bit me. Consider yourself bitten. :-P Again, I'm not looking for a shortcut, I have a way that it could just work, but no time to implement it. BTW: The problem with your shortcut above is that it assumes that I didn't type anything in insert mode other than pasting the text. Often, my pattern is that I type out some stuff, then have something to paste, and undo may do significantly more than just the paste. Is it possible for us to go back to that original discussion, about setting paste in non-X mode, and avoid the misplaced winging about RTFM? I understand it can be frustrating when you think someone has not read the basic documentation, but in this case that is absolutely wrong. Admittedly, I don't know that I'd read about pastetoggle until I saw your original suggestion, but if I haven't read the documentation enough then the documentation is _BROKEN_. Thanks, Sean -- People who interview themselves shouldn't criticize writing styles. -- John Bentley, Programming Pearls Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
