Re: Why bottom-posting is prefered on Vim Mainling List?
[EMAIL PROTECTED] wrote: Steve Hall [EMAIL PROTECTED] 写于 2007-05-29 12:19:43: You could say that top posting is easier to write, but bottom posting is easier to read. The extra effort of one poster saves all the readers the same amount of effort. For a group, bottom posting keeps everyone on track. And if done well, individual posts can stand alone in an archive without a peruser having to go paging through a whole thread. Hi, It seems that top-posters and bottom-posters belongs to different party and no one can convice another. An explaination why top-post is easier to read: When I am viewing an e-mail, the reply is the main part of the message and I usually quite aware of what the original post is. So I should be able to see the reply when I open the message. If the message is bottom post, I will have to scroll down and down to find where the author really start to say something. If the reply starts on line 1000 while the messages ends on line 2000 it will be quite difficult to know line 1000 is the start of reply and I should read from that line. Such an event is usually an indication that far too much context has been provided (the me-too scenario, typically). While for the top-post, I know the first line is the start of reply and I can read the reply without any difficulty. In an active forum, threads grown long quickly, with top-post, we focus on what the message saids and waste no time. Write top-post or bottom-post makes no difference for me, the problem is that I found bottom-post is harder to read since I will have to skim all original messages before I could read the actual reply. Well, since no one could convice another, I'll stick to the community rule. You aren't considering the case where people are posting item-by-item responses (as I have just done). This is absolutely impossible to read when top-posting. This is why bottom-posting is preferred in pretty much any forum where item-wise responses are likely. You can argue about whether a top-post or bottom-post looks better for non-item-wise posts, but the moment someone tries to address individual points separately (which is often a good idea), there is no longer any room for questioning: bottom-posting is the clear winner. I thought that Mark Woodward demonstrated this rather well. Even if you're not posting an item-by-item response, top-posting effectively prevents anyone from writing an item-wise response to your response, since mixed top-and-bottom posting is a clear loser. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: Why bottom-posting is preferred on Vim Mainling List?
[EMAIL PROTECTED] wrote: In the end, what's preferred is personal despite arguments pro and con. However, the preponderant opinion and therefore usage in the Vim group is bottom-posting, though many use interspersed posting and get away with it. If you don't bottom-post, you get told about it by the other, frequent Vim posters and that's enough to sway me to bottom-post in this forum even if I personally don't like it. Unless I completely misunderstand what you mean by the term, interspersed posting /is/ bottom-posting; there is no distinction. If there were no need to intersperse quotes with responses, there'd be little reason at all to bottom-post, and nobody would care enough at any rate to correct people who top-posted. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: manual
linda.s wrote: After clicking the user manuual under help, I wonder which command can be used to open these help txt in the manual? Since you said something about clicking, I'll assume you're using a GUI version of vim. You should be able to simply double-click on any of the help files you see in the main :help file. When you're not using the mouse, you can position your cursor at the link, and type Ctrl-]. Use Ctrl-T or Ctrl-O to back up. This information is actually at the top of that main help file. :) -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/
Re: weird defaults in Feisty
fREW wrote: On 5/22/07, fREW [EMAIL PROTECTED] wrote: On 5/22/07, Gene Kwiecinski [EMAIL PROTECTED] wrote: I just updated to feisty on a samba server machine and a lot of the vim defaults went crazy. For example: Pressing the Up or Down keys in insert mode add new lines with just A or B on them, respectively. Sounds like it stopped recognising arrow keys' ANSI sequences (esc[A and esc[B). Wouldda thought the esc would break out of insert mode, but... That I can live with, but check this out, if I have the following sentence: fREW is a silly guy and my cursor is on the s, and I press cw, it changes to fREW is a sill$ guy and it works just like I had pressed cw and it replaces up the the $ or if I press escape it only has the new text I put in, but it's just so weird! Does anyone know where these new changes in Feisty come Uhh, sounds like what it's supposta do, no? ?? Is there a problem with actually changing the text, or just what's displayed? Dunno the setting offhand, but a slow-redraw will mark to the end of the text to be replaced, eg, if you were to change to the end of the line, you'd still see the whole line, but with a '$' where the last character would be, vs erasing all the text and just leaving the insert-cursor in its place. I find the latter disquieting, and would rather *see* what I'm replacing, but never really paid too much attention to which settings do what. I'm complacent that way... :D I prefer that cw doesn't do this weird $ thing. It bothers me. I might be ok with it if the word I was typing over were a different color, but that is not the case. Also: set nocompatible worked just fine, but I wanted to make this a system wide setting. I think that the problem has to do with vim not sourcing the /etc/vim/vimrc. It appears that that is why things aren't working correctly. Anyone know why it wouldn't source that file? -fREW I figured it out and if anyone else has this problem I am sending out the solution. Basically when I run vi it is running vim.tiny. vim.tiny sources /etc/vim/vimrc.tiny, not /etc/vim/vimrc, also, vim.tiny is pretty crippled, in that it doesn't even have syntax highlighting, so consider whether that's even what you want. This is by design. Note that vimrc.tiny is /only/ sourced when vim.tiny is invoked as vi. This is a Debian/Ubuntu extension; unmodified vim has no notion of vimrc.tiny. As at least one person has noted, there are many users who expect a vi-compatible program when they type vi at the command-line. When this isn't what you want, you really should consider changing your habit to use vim, as that way you are sure to get a featureful vim, if one is installed (vi could get you any one of a number of programs, depending on the system you're on). To switch your vi to pull a real vim, you might consider installing a vim such as vim-gnome or vim-full (these are Debian names), and using update-alternatives to set vi to be one of those instead of vim-tiny. Actually, current default is for vi to point at /usr/bin/vim, so if your update-alternatives has vim set to /usr/bin/vim.gnome or /usr/bin/vim.full, your vi will probably start sourcing vimrc instead of vimrc.tiny. This may change in the future (vi may default to /usr/bin/vim.tiny instead of /usr/bin/vim). Further discussion of this should possibly be moved to the Ubuntu or Debian forums (I'm not certain how much of this may be specific to Ubuntu as opposed to Debian; the source code changes included macro names with DEBIAN, in them, so I'm assuming that most of the decision-making for this was made by Debian developers). -- HTH, Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: Vim to Vi (Was: weird defaults in Feisty)
[EMAIL PROTECTED] wrote: It seems nature to have vim behave like vi, if the Linux distribution choose to do so. The distribution decides everything and it is non-related to vim developers themselves. All you need to do is to: sudo apt-get install vim-gtk, which installs a Big version of vim, and the vim will be replaced with that version. Well... not replaced. They will both be installed. You'll probably need to run update-alternatives to ensure that /usr/bin/vim points at the one you want. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: patch 7.1.002
Bram Moolenaar wrote: Patch 7.1.002 Problem:Oracle Pro*C/C++ files are not detected. Solution: Add the missing star. (Micah J. Cowan) Just to be clear: while I reformatted the solution in patch-form, it was Arturo Olguín Cruz who first found the bug and determined its fix: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/86916 -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim 7.1 and cr/lf interpretation
Thomas Michael Engelke wrote: Hello Tony, and thanks for your extensive answer. Unfortunately, this is what I can report. To make things easier, I'll attach the file I am talking about to this message so that you can either check for yourselves and/or see that I'm telling the truth. What is the current state: Of course, there's one line without 0x13 0x10 at the end, and that is the last line. As I checked using your regex (I'm always forgetting the :word:-syntax is available as well, which makes it difficult as I can never remember how to search for a hex char), I found one single line except the last one without 0x13 0x10 at the end. I removed the line in joining it with the line above (multi line command) and saved the file. I closed it, closed vim and reopened the file again. The problem persists. Now the only line your regex finds is the last one. set fileformats still evaluates to dos,unix. set fileformat after loading the file evaluates to unix. Setting it to dos via set fileformat=dos does not help the issue. It doesn't matter whether it's the very last line or not: if a single line (even at the end) ends in \n without \r, it is unix-format (note that if it the final line had not ended at all, it would have been dos). -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: Problem with digraphs through Putty
Jeenu V wrote: Hi Vimmers, I'm using VIM (version 6.2) through putty. The digraphs that are displayed (either through :dig command or CTRL-K insertions) are all weird characters. When I tried to use digraphs as fold markers, it worked, but the fold markers inserted are still those weird characters. Does any body ever experienced this kind of problem? Any configurations to be done on putty? It sounds to me as though your locale settings are off. That is, vim thinks your terminal locale is other than it is. Please ensure that your LANG and LC_* terminal environment variables match the locale that putty recognizes. -- HTH, Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim 7.1 and cr/lf interpretation
Thomas Michael Engelke wrote: But that's arguing semantics when the core of the problem is known now. I apologize for having a different set of mind and not understanding the problem instantly. This is not a fair remark, considering I pointed out to you, privately, that he made the statement fairly clearly before his last post, which is why he said it all-caps/bold the second time around. It's not that you didn't understand the problem instantly: the problem was explained fairly clearly; it's that you made him repeat his answers, indicating that you hadn't read them. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim 7.1 and cr/lf interpretation
Thomas Michael Engelke wrote: 2007/5/15, Micah Cowan [EMAIL PROTECTED]: Thomas Michael Engelke wrote: But that's arguing semantics when the core of the problem is known now. I apologize for having a different set of mind and not understanding the problem instantly. This is not a fair remark, considering I pointed out to you, privately, that he made the statement fairly clearly before his last post, which is why he said it all-caps/bold the second time around. It's not that you didn't understand the problem instantly: the problem was explained fairly clearly; it's that you made him repeat his answers, indicating that you hadn't read them. Damn. I apologize again, this time for replying your mail on the list. Now I know why there was no Reply to all, which I thought to be a glitch in GMail. Oh. Well, I actually hadn't noticed you'd done that, believe it or not. And I don't mind. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim 7.1 and cr/lf interpretation
Gene Kwiecinski wrote: fileformats=dos,unix, so both formats are available, yet the detection and switching does not seem to work. Are you sure _every_ line ends in ^M? Positive. Every single line shows an ^M at the end. set fileformat gives unix after loading. Setting fileformat to dos doesn't change the files interpretation in vim. Somehow I think I miss something. Uhhh, don't think it *should* automagically delete the ^Ms. I'm always running into that, and in addition to an almost reflexive alt-EIFD to go dos-mode, I *still* always have to ':s/^V^M' to get rid of 'em, and I'm using version 6.4, not even 7.x, so it's definitely been around for a while. If vim opens a file that truly has ^M^J at the end of every line, and fileformats contains dos, then it will automatically convert ^M^J to line ending. If you then set ff=unix, and save the file, it will write those endings out as just ^J. I've used this a few times (also in reverse, when I want to write an SMTP transcript for netcat, but forgot to save with CRLFs the first time :) ). -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
[Patch] proper detection of ProC files.
Fixes an apparent typo in filetype.vim. Per https://bugs.launchpad.net/ubuntu/+source/vim/+bug/86916. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ Index: runtime/filetype.vim === --- runtime/filetype.vim (revision 292) +++ runtime/filetype.vim (working copy) @@ -1286,7 +1286,7 @@ au BufNewFile,BufRead *.it,*.ih setf ppwiz Oracle Pro*C/C++ -au BufNewFile,BufRead .pc setf proc +au BufNewFile,BufRead *.pc setf proc Privoxy actions file au BufNewFile,BufRead *.action setf privoxy signature.asc Description: OpenPGP digital signature
Re: book
linda.s wrote: Hi, I am a beginner in VIM. Wonder whether there is any good book for VIM? Also, what is the difference between vim and latex? Linda, I've personally found the vim tutorial to be a quite-adequate means to learning vim. Just type vimtutor in your terminal, and you're good to go! Comparing vim and latex is somewhat akin to comparing apples to screwdrivers. They're just completely different. Vim is a fully-featured text editor (which is often used to edit input to latex); latex is a typesetting program (or, more pedantically, a format for the TeX typesetting program), which takes text files formatted a particular way, and produces output suitable for printing. -- I hope that helped, Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Bram Moolenaar wrote: Micah Cowan wrote: Following description lifted from bug filed at https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960 [EMAIL PROTECTED]:~$ rm .viminfo [EMAIL PROTECTED]:~$ ln -s /dev/null .viminfo [EMAIL PROTECTED]:~$ ls -l .viminfo lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo - /dev/null [EMAIL PROTECTED]:~$ umask 007 [EMAIL PROTECTED]:~$ /usr/bin/vim.basic -c 'quit' [EMAIL PROTECTED]:~$ ls -l .viminfo -rw-rw-rw- 1 sa sa 509 2007-01-12 17:16 .viminfo As you can see the .viminfo file gets deleted and re-created with permissions 666 by vim. Note that the use of -c 'quit' is just to simplify the bug for transcribing here -- I promise you the same thing happens if you use vim for editing/saving a document as well. I consider this a security bug. vim deletes a file without telling me, and not only that but when it re-creates it, it ignores my umask by making it world writable. This is not what I expected it to do. Do you seriously believe that when you create a symlink to /dev/null that things continue to work normally? Come on... The above were not my words; they were from the bug reporter, as I said (though I didn't make it clear that I didn't report the bug, I suppose). However, to answer your question: I would expect such a common idiom to work, at least in the case of files that are given to vim. Since .viminfo is a file that vim would supposedly generate and manage itself, the case may be less strong. The solution is simple: Don't create a link in place of the .viminfo file. And certainly not to /dev/null. Background info: When Vim finds an existing .viminfo file, it writes the new info into a temp file (since it's still reading from the existing one it can't be overwritten). When finished the temp file is moved in place of the old .viminfo and owner and protection are set to match the original. Vim intentionally doesn't follow symlinks for .viminfo, because that can be used for a symlink attack, a security issue. How so? The user won't be able to attack files he doesn't have write permission to, and other users wouldn't be running from his .viminfo, AFAICT. And the user shouldn't have permission to replace other users' .viminfo's with a symlink... so I'm missing something. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
A.J.Mechelynck wrote: Micah Cowan wrote: Bram Moolenaar wrote: [...] The solution is simple: Don't create a link in place of the .viminfo file. And certainly not to /dev/null. Background info: When Vim finds an existing .viminfo file, it writes the new info into a temp file (since it's still reading from the existing one it can't be overwritten). When finished the temp file is moved in place of the old .viminfo and owner and protection are set to match the original. Vim intentionally doesn't follow symlinks for .viminfo, because that can be used for a symlink attack, a security issue. How so? The user won't be able to attack files he doesn't have write permission to, and other users wouldn't be running from his .viminfo, AFAICT. And the user shouldn't have permission to replace other users' .viminfo's with a symlink... so I'm missing something. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? No, I'm not missing that. Why should that make a difference? It is, after all, a special file; and only root would be able to replace it with something else. Anyway, Bram was saying that it's a general security hole, not just for when /dev/null is the target. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: How to efficiently type polytonic Greek?
Informationen wrote: Hi, could somebody tell me how to type complex Greek characters like ῷ or ἅ. I am using vim7.0 with multibyte and myltilang enabled on Kubuntu 6.06. In other applications I change the language to polytonic greek and use a composer key. Is there a similar way in vim possible, too? How can I enter combinations of more than two characters? You should be able to do it exactly the same way in Vim. I do, in both console and GUI (Ubuntu, not Kubuntu; but still...) -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Bug: .viminfo file gets deleted and re-created with 666 permissions
Following description lifted from bug filed at https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960 [EMAIL PROTECTED]:~$ rm .viminfo [EMAIL PROTECTED]:~$ ln -s /dev/null .viminfo [EMAIL PROTECTED]:~$ ls -l .viminfo lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo - /dev/null [EMAIL PROTECTED]:~$ umask 007 [EMAIL PROTECTED]:~$ /usr/bin/vim.basic -c 'quit' [EMAIL PROTECTED]:~$ ls -l .viminfo -rw-rw-rw- 1 sa sa 509 2007-01-12 17:16 .viminfo As you can see the .viminfo file gets deleted and re-created with permissions 666 by vim. Note that the use of -c 'quit' is just to simplify the bug for transcribing here -- I promise you the same thing happens if you use vim for editing/saving a document as well. I consider this a security bug. vim deletes a file without telling me, and not only that but when it re-creates it, it ignores my umask by making it world writable. This is not what I expected it to do. I was able to confirm this bug, both in Ubuntu's vim-gnome-7.0-164+1ubuntu7 package, and in the latest 7.1b sources. I also have a separate question: is this an appropriate place to post bugs? Specifically, when (a) I am interested in potential discussion related to it, and/or (b) I am interested in possibly implementing the fix for it? :he bugs suggests submitting bugs to [EMAIL PROTECTED], but from the description, it sounds like those go to a single person, and are not tracked (so, no opportunity for discussion, and it's hard to know if a bug has been reported or what it's status is). A subject change may be appropriate for answering this separate question. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
xterm-mouse and terminfo [Re: [PATCH] vim_is_xterm() and screen]
Bram Moolenaar wrote: Micah Cowan wrote: Towards a better solution: how straightforward do you think it'll be to talk the ncurses guys into adding support for some of screen's extensions? AFAIK, the only one I care about is the xterm mouse support; another interesting one is a boolean supports ansi setforeground/setbackground codes; but I usually infer this (if necessary) from the presence of setaf/setbf (not a given, but...). I think you need to talk to more people than ncurses for changing the termcap/terminfo entries. But it's a good start. Well, I'll need to talk to ncurses to get the extensions added; after that, I'll have to get the various terminal emulators, and any other suppliers for terminfo descriptions, to actually /specify/ the extensions; then, it'll take a good while for the various applications (such as vim) to actually check for its presence. Is that what you're referring to? :) -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: what feature is required to return to last editing position?
Copying the dev list. The missing context is that running vim via sudo before having run it as regular user, causes permission problems with the created .viminfo file (and others?). Vincent BEFFARA wrote: Wonderful, the problem really is about permission of .viminfo! I noticed that you considered this to be a bug, but is this bug belongs to sudo or vim? i.e. for non-interactive su of root, vim will save at user $HOME with root permission. FYI, this same issue was discussed at https://bugs.launchpad.net/ubuntu/+bug/58002 From that discussion it would appear that it is a bug of neither, but rather of Ubuntu itself : sudo (as configured there) preserves $HOME, vim sees it and uses it to create .viminfo if it is not there. The natural fix is to put the right option in the sudo config file (always_set_home or something sounding like that). Except that this isn't always what is desired. And, if it's a bug of Ubuntu, it's also a bug of every other distribution I've ever known (thought there probably are some of which I'm aware, that set this). The biggest beef I would have with setting that option is that there doesn't appear to be a way to /disable/ it for individual cases :p ...still, I can't envision a reasonable case where the user couldn't simply type out his own home directory (~user instead of ~?), or if necessary set the environment himself within the sudo command, so it may be a reasonable solution. However, it would be nice of vim to always test that it owns the $HOME directory before creating files there. Would it break anything ? I think this would be a good idea as well. One could argue that if we reason this way for vim, we should reason this way about everything that ever creates config files in the user's home directory; however, not every such thing can be expected to be run as root, and editors--and most particularly vim--are extremely likely to be run as root, so I think it's not unreasonable to ask them to take on this responsibility. Perhaps rather than simply avoiding file creation, in the case of root we could set the file's owner to the real id/gid, instead of the effective one. This option is unavailable when the user is sudoing as non-root, but this seems much less likely to happen before having run it normally, than running under sudo is. Another issue, which was touched on in that Ubuntu bug report, is that vim doesn't warn or anything when it can't open .viminfo. Perhaps it should distinguish between ENOENT and EPERM, and warn in the latter case? It should possibly also warn in the event that it decides to change ownership as above (if this is decided to be a good idea), or when it is not created because of non-root, non-HOME-owner effective user id. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: what feature is required to return to last editing position?
Copying the dev list. The missing context is that running vim via sudo before having run it as regular user, causes permission problems with the created .viminfo file (and others?). Vincent BEFFARA wrote: Wonderful, the problem really is about permission of .viminfo! I noticed that you considered this to be a bug, but is this bug belongs to sudo or vim? i.e. for non-interactive su of root, vim will save at user $HOME with root permission. FYI, this same issue was discussed at https://bugs.launchpad.net/ubuntu/+bug/58002 From that discussion it would appear that it is a bug of neither, but rather of Ubuntu itself : sudo (as configured there) preserves $HOME, vim sees it and uses it to create .viminfo if it is not there. The natural fix is to put the right option in the sudo config file (always_set_home or something sounding like that). Except that this isn't always what is desired. And, if it's a bug of Ubuntu, it's also a bug of every other distribution I've ever known (thought there probably are some of which I'm aware, that set this). The biggest beef I would have with setting that option is that there doesn't appear to be a way to /disable/ it for individual cases :p ...still, I can't envision a reasonable case where the user couldn't simply type out his own home directory (~user instead of ~?), or if necessary set the environment himself within the sudo command, so it may be a reasonable solution. However, it would be nice of vim to always test that it owns the $HOME directory before creating files there. Would it break anything ? I think this would be a good idea as well. One could argue that if we reason this way for vim, we should reason this way about everything that ever creates config files in the user's home directory; however, not every such thing can be expected to be run as root, and editors--and most particularly vim--are extremely likely to be run as root, so I think it's not unreasonable to ask them to take on this responsibility. Perhaps rather than simply avoiding file creation, in the case of root we could set the file's owner to the real id/gid, instead of the effective one. This option is unavailable when the user is sudoing as non-root, but this seems much less likely to happen before having run it normally, than running under sudo is. Another issue, which was touched on in that Ubuntu bug report, is that vim doesn't warn or anything when it can't open .viminfo. Perhaps it should distinguish between ENOENT and EPERM, and warn in the latter case? It should possibly also warn in the event that it decides to change ownership as above (if this is decided to be a good idea), or when it is not created because of non-root, non-HOME-owner effective user id. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: how to open an already opened file into an new tab?
lin q wrote: Great, this works. Another question, :tabe % can open the same file, is there an easy way to open another file which locates in the same or very similar directory of the current file? For example, I am viewing f2 now, and I want to open f3 which is of same directory of f2 and to open f4 whose path is f2 location/../i/f4. Any trick to do this? :tabe %:p:h/f2 | tabe %:p:h/../i/f4 See :he :_% and :h filename-modifiers. -- HTH, Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: what feature is required to return to last editing position?
Bram Moolenaar wrote: Micah Cowan wrote: Vincent BEFFARA wrote: However, it would be nice of vim to always test that it owns the $HOME directory before creating files there. Would it break anything ? I think this would be a good idea as well. One could argue that if we reason this way for vim, we should reason this way about everything that ever creates config files in the user's home directory; however, not every such thing can be expected to be run as root, and editors--and most particularly vim--are extremely likely to be run as root, so I think it's not unreasonable to ask them to take on this responsibility. And what if root always uses $HOME/.viminfo, where $HOME is the only person who can be root? It might be that there is no root home directory. Let's keep it simple: $HOME/.viminfo is the default viminfo file. If you want to use another file you have to tell Vim. I don't think it was suggested that we use a different file. I think it was suggested that vim not automatically create .viminfo with euid's ownership, if $HOME isn't owned by euid. I still think that this part of it (which was Vincent's) is a good idea, despite your good points wrt 'verbose' and giving away files (which was my idea). Perhaps rather than simply avoiding file creation, in the case of root we could set the file's owner to the real id/gid, instead of the effective one. This option is unavailable when the user is sudoing as non-root, but this seems much less likely to happen before having run it normally, than running under sudo is. Giving away a file is a big no-no for security reasons. Root may yank text in a register that a normal user is not supposed to see and this ends up in the viminfo file. Good point. Although, I have a difficult time envisioning how such a scenario could take place, and it not be the same user reading viminfo that was running as the root with HOME set that way. But better safe than sorry. Another issue, which was touched on in that Ubuntu bug report, is that vim doesn't warn or anything when it can't open .viminfo. Perhaps it should distinguish between ENOENT and EPERM, and warn in the latter case? It should possibly also warn in the event that it decides to change ownership as above (if this is decided to be a good idea), or when it is not created because of non-root, non-HOME-owner effective user id. :set verbose=1 When ACLs are used there are many ways reading a file can fail. Just mentioning that it failed should be sufficient, the user will have to figure out why. That's better than a wrong message. Hm... but the typical user isn't going to necessarily going to think to do this. IMO, the user should just be able to run typical commands like sudo vim /some/important/file and have it just work, without having to think to himself Gee, I'd better set my HOME directory properly or better make sure I run it myself first or better put it into verbose mode. Sure, the user would've been better off running sudo -He ... instead, but most users never ever do. It could be argued that this is the user's miseducation; but my philosophy is that when an erroneous usage pattern is common, then the error ceases to lie with the user, and becomes an error in the interface. However, if it were decided that we will have vim balk at creating .viminfos that are mismatched to the root user, then I probably wouldn't care overly much whether vim complains about existing ownership problems overly much. Perhaps an option could be added to control this (in case a user should /want/ a root .viminfo in a regular user home dir, for some reason), with the default set for non-creation. As an alternative, what about vim nusing a uid-based name for .viminfo, when it detects the ownership mismatch? Say, .viminfo-u%d, where %d is vim's euid? -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim_is_xterm() and screen
I wrote:
Therefore, there would seem to be no harm whatsoever in detecting screen
as an xterm-mouse-code-capable terminal, and sending the mouse-mode
sequence (xterm protocol, since AFAIK screen provides no way to detect
the underlying xterm version). If the underlying terminal claims to be
xterm or rxvt, then the user will automatically get the benefit of mouse
support without trouble; otherwise, screen will simply ignore the
sequence and no harm is done to other terminals (such as unrecognized
sequence-emitters, or DEC-mouse-only terminals).
Attached is a proposed patch that effects the change I'm requesting. I
would love to get some feedback/further discussion based on it. They say
code talks, and so here is my concrete expression. :)
--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
Index: os_unix.c
===
--- os_unix.c (revision 276)
+++ os_unix.c (working copy)
@@ -2034,6 +2034,21 @@
|| STRCMP(name, builtin_xterm) == 0);
}
+/*
+ * Return TRUE if name appears to be that of a terminal
+ * known to support the xterm-style mouse protocol.
+ * Relies on term_is_xterm having been set to its correct value.
+ */
+int
+vim_uses_xterm_mouse(name)
+char_u *name;
+{
+if (name == NULL)
+ return FALSE;
+return (STRNICMP(name, screen, 6) == 0
+ || term_is_xterm);
+}
+
#if defined(FEAT_MOUSE_TTY) || defined(PROTO)
/*
* Return non-zero when using an xterm mouse, according to 'ttymouse'.
Index: term.c
===
--- term.c (revision 276)
+++ term.c (working copy)
@@ -1601,6 +1601,9 @@
int try;
int termcap_cleared = FALSE;
#endif
+#if defined(UNIX) || defined(VMS)
+int term_uses_xterm_mouse;
+#endif
int width = 0, height = 0;
char_u *error_msg = NULL;
char_u *bs_p, *del_p;
@@ -1903,6 +1906,7 @@
#if defined(UNIX) || defined(VMS)
term_is_xterm = vim_is_xterm(term);
+term_uses_xterm_mouse = vim_uses_xterm_mouse(term);
#endif
#ifdef FEAT_MOUSE
@@ -1923,7 +1927,7 @@
#endif
clip_init(FALSE);
# endif
- if (term_is_xterm)
+ if (term_uses_xterm_mouse)
{
if (use_xterm_mouse())
p = NULL; /* keep existing value, might be xterm2 */
signature.asc
Description: OpenPGP digital signature
Re: vim_is_xterm() and screen
A.J.Mechelynck wrote: Micah Cowan wrote: Attached is a proposed patch that effects the change I'm requesting. I would love to get some feedback/further discussion based on it. They say code talks, and so here is my concrete expression. :) Shouldn't it rather use the 'ttymouse' option? It does. :) ...or rather, my code is what would be used to set ttymouse's default based on the detected terminal. IIUC, that option is supposed to be set to either xterm or xterm2 at startup if the terminal is known to support xterm mouse codes. My code is used at the spot where the value of the 'ttymouse' option is set automatically by setting the 'term' option: both at startup, and whenever the user sets it manually via :set term=. This is done as a result of sending the t_RV code and receiving an answer for it, which happens after the first file has been loaded and all -c commands have been processed: probably just before or just after the VimEnter event. IOW, you cannot test them in your vimrc or even in a global plugin (they are sourced too early). At the VimEnter event might be late enough but I haven't tested it What happens, to the best of my reading, is: 1. If the terminal is detected as supporting t_RV (which basically means that it has been detected as fully compatible), it issues that sequence and checks for a result. If it gets an expected response, it will set ttymouse appropriately. 2. Sometime later, but before the first file is loaded, etc, the term option is automatically set based on the TERM environment variable. The term option is a magic option which causes it to check a bunch of things, including whether xterm mouse support is enabled (at the point where I set the term_uses_xterm_mouse var). 3. If the tty is xterm-mouse capable (before patch, if it is a full xterm implementation), then it sets ttymouse to xterm: but only if ttymouse doesn't already contain a setting that works for the current terminal (thus, if t_RV is set and the xterm said it was xterm2-compliant, ttymouse will already have been set to xterm2). Screen is actually quite capable of understanding and transmitting xterm2 protocol, but it doesn't provide t_RV, and so has no way of telling vim whether it's on an xterm2-supporting xterm or not. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim_is_xterm() and screen
A.J.Mechelynck wrote: This is done as a result of sending the t_RV code and receiving an answer for it, which happens after the first file has been loaded and all -c commands have been processed: probably just before or just after the VimEnter event. IOW, you cannot test them in your vimrc or even in a global plugin (they are sourced too early). At the VimEnter event might be late enough but I haven't tested it. Sorry, I meant to address this more explicitly: I tested, and under xterm, .vimrc sees term=xterm, ttymouse=xterm (note that ttymouse later becomes xterm2). Same for screen (except ttymouse doesn't change later). So I was probably a little wrong about the order in which things take place. Regardless, the code change seems to be consistent with the current process. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim_is_xterm() and screen
Micah Cowan wrote: A.J.Mechelynck wrote: This is done as a result of sending the t_RV code and receiving an answer for it, which happens after the first file has been loaded and all -c commands have been processed: probably just before or just after the VimEnter event. IOW, you cannot test them in your vimrc or even in a global plugin (they are sourced too early). At the VimEnter event might be late enough but I haven't tested it. Sorry, I meant to address this more explicitly: I tested, and under xterm, .vimrc sees term=xterm, ttymouse=xterm (note that ttymouse later becomes xterm2). Same for screen (except ttymouse doesn't change later). And, of course, term=screen, rather than xterm. :) -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
[PATCH] vim_is_xterm() and screen
Sorry for the repost; but I realized I should've drawn more attention to
the message with the patch in it, both so other lurkers know the thread
now includes a proposed patch, and so that we know what message to go
back to if we want to refer to the code we're discussing.
I have made a slight adjustment to the patch, swapping the order of
STRICMP and term_is_xterm within vim_uses_xterm_mouse(). I was using
vim_is_xterm() instead of term_is_xterm at first, but afterwards
replaced it for efficiency, but left the order as it was.
--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
Index: os_unix.c
===
--- os_unix.c (revision 276)
+++ os_unix.c (working copy)
@@ -2034,6 +2034,21 @@
|| STRCMP(name, builtin_xterm) == 0);
}
+/*
+ * Return TRUE if name appears to be that of a terminal
+ * known to support the xterm-style mouse protocol.
+ * Relies on term_is_xterm having been set to its correct value.
+ */
+int
+vim_uses_xterm_mouse(name)
+char_u *name;
+{
+if (name == NULL)
+ return FALSE;
+return (term_is_xterm
+ || STRNICMP(name, screen, 6) == 0);
+}
+
#if defined(FEAT_MOUSE_TTY) || defined(PROTO)
/*
* Return non-zero when using an xterm mouse, according to 'ttymouse'.
Index: term.c
===
--- term.c (revision 276)
+++ term.c (working copy)
@@ -1601,6 +1601,9 @@
int try;
int termcap_cleared = FALSE;
#endif
+#if defined(UNIX) || defined(VMS)
+int term_uses_xterm_mouse;
+#endif
int width = 0, height = 0;
char_u *error_msg = NULL;
char_u *bs_p, *del_p;
@@ -1903,6 +1906,7 @@
#if defined(UNIX) || defined(VMS)
term_is_xterm = vim_is_xterm(term);
+term_uses_xterm_mouse = vim_uses_xterm_mouse(term);
#endif
#ifdef FEAT_MOUSE
@@ -1923,7 +1927,7 @@
#endif
clip_init(FALSE);
# endif
- if (term_is_xterm)
+ if (term_uses_xterm_mouse)
{
if (use_xterm_mouse())
p = NULL; /* keep existing value, might be xterm2 */
signature.asc
Description: PGP signature
signature.asc
Description: OpenPGP digital signature
Re: [Announcement] Subversion repository location changed
Yakov Lerner wrote: On 5/9/07, Edward L. Fox [EMAIL PROTECTED] wrote: If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 This switch command gives me error: $ cd vim7 $ svn info Path: . URL: https://svn.sourceforge.net/svnroot/vim/vim7 Repository Root: https://svn.sourceforge.net/svnroot/vim Repository UUID: 2a77ed30-b011-0410-a7ad-c7884a0aa172 Revision: 263 Node Kind: directory Schedule: normal Last Changed Author: edyfox Last Changed Rev: 263 Last Changed Date: 2007-05-06 23:13:56 -0400 (Sun, 06 May 2007) $ svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 svn: 'https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1' is not the same repository as 'https://svn.sourceforge.net/svnroot/vim' What am I doign wrong ? Yakov The vim.svn vs svn... . https://svn.sourceforge.net/svnroot/vim/branches/vim7.1 (no vim) works for me. I've a question, though: isn't bleeding-edge development done in https://svn.sourceforge.net/svnroot/vim/trunk ? That /would/ be the appropriate line for the latest sources, right? -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: [PATCH] vim_is_xterm() and screen
Bram Moolenaar wrote: Micah Cowan wrote: Sorry for the repost; but I realized I should've drawn more attention to the message with the patch in it, both so other lurkers know the thread now includes a proposed patch, and so that we know what message to go back to if we want to refer to the code we're discussing. I have made a slight adjustment to the patch, swapping the order of STRICMP and term_is_xterm within vim_uses_xterm_mouse(). I was using vim_is_xterm() instead of term_is_xterm at first, but afterwards replaced it for efficiency, but left the order as it was. Looks OK to me. Terrific! Does that mean it'll go in? :) If I understood your other message correctly then using xterm2 for 'ttymouse' would not work for screen. Well... manually setting it to xterm2 will work fine (assuming screen is running under a supporting version of xterm): I get the full dragging effect, etc. But screen doesn't do t_RV, and I don't know how else you'd determine support for xterm2, so there doesn't seem to be a safe way to set ttymouse to it automatically, for screen. Towards a better solution: how straightforward do you think it'll be to talk the ncurses guys into adding support for some of screen's extensions? AFAIK, the only one I care about is the xterm mouse support; another interesting one is a boolean supports ansi setforeground/setbackground codes; but I usually infer this (if necessary) from the presence of setaf/setbf (not a given, but...). -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: [PATCH] vim_is_xterm() and screen
Gary Johnson wrote: On 2007-05-09, Micah Cowan [EMAIL PROTECTED] wrote: Towards a better solution: how straightforward do you think it'll be to talk the ncurses guys into adding support for some of screen's extensions? AFAIK, the only one I care about is the xterm mouse support; another interesting one is a boolean supports ansi setforeground/setbackground codes; but I usually infer this (if necessary) from the presence of setaf/setbf (not a given, but...). The ncurses guys is Thomas Dickey, who frequents a number of lists and newsgroups, and who would probably be willing to discuss it with you. Contact information is here: http://www.gnu.org/software/ncurses/ Look for Who's Who and What's What. You might also consider joining the bug-ncurses-request mailing list, which is open to anyone interested in helping with the development and testing of this package. Thanks for that! I would imagine the process would be more a matter of convincing Thomas to accept the concept, the design, and any patches you would submit, rather than the ncurses guys adding this support themselves. Fair enough. :) -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: what feature is required to return to last editing position?
Yakov Lerner wrote: On 5/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: When opening a file in vim, the cursor will move to the last position when the file was saved. The simplest way to fix this is to add this line to your .vimrc: $VIMRUNTIME/vimrc_example.vim Another, more difficult method is documented under :help restore-cursor :help restore-position :) -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: is there a list-administrator ?
A.J.Mechelynck wrote: AFAIK, there is no list-admin; just the mail robot. Or if there is one, he only reads the list when the moon is blue on the 4th Thursday of a week, and I don't know his phone number (if any). The Vim mailing list page (http://www.vim.org/maillist.php) mentions [EMAIL PROTECTED], but moon is blue on the 4th Thursday of a week might still apply... -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: [Announcement] Subversion repository location changed
Yakov Lerner wrote: On 5/9/07, Edward L. Fox [EMAIL PROTECTED] wrote: If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 This switch command gives me error: $ cd vim7 $ svn info Path: . URL: https://svn.sourceforge.net/svnroot/vim/vim7 Repository Root: https://svn.sourceforge.net/svnroot/vim Repository UUID: 2a77ed30-b011-0410-a7ad-c7884a0aa172 Revision: 263 Node Kind: directory Schedule: normal Last Changed Author: edyfox Last Changed Rev: 263 Last Changed Date: 2007-05-06 23:13:56 -0400 (Sun, 06 May 2007) $ svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 svn: 'https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1' is not the same repository as 'https://svn.sourceforge.net/svnroot/vim' What am I doign wrong ? Yakov The vim.svn vs svn... . https://svn.sourceforge.net/svnroot/vim/branches/vim7.1 (no vim) works for me. I've a question, though: isn't bleeding-edge development done in https://svn.sourceforge.net/svnroot/vim/trunk ? That /would/ be the appropriate line for the latest sources, right? -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: what feature is required to return to last editing position?
[EMAIL PROTECTED] wrote: Vincent BEFFARA [EMAIL PROTECTED] 写于 2007-05-09 23:54:27: Hi, Recently I installed Ubuntu Feisty and the feature seems to have gone (I installed vim-gnome version 7.0.135). Since I use the same .vimrc in all platform, it is unlikely to be the fault of my .vimrc script, the problem is I do not know how to debug vim script, and I don't know why that autocommand does not work. Just in case - might it be that you don't have right permissions to your own ~/.viminfo ? I had a similar problem : on a new install, typically you might go and edit some files using sudo vim /etc/whatever, this creates .viminfo belonging to root, and then vim as a normal user cannot use it, and fails silently. Only happens if there is no .viminfo to start with, vim does the sane thing and does not overwrite, but still might be considered a bug ... hth, /vincent -- Vincent Beffara Wonderful, the problem really is about permission of .viminfo! I noticed that you considered this to be a bug, but is this bug belongs to sudo or vim? i.e. for non-interactive su of root, vim will save at user $HOME with root permission. FYI, this same issue was discussed at https://bugs.launchpad.net/ubuntu/+bug/58002 -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
vim_is_xterm() and screen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Some folks who like to use vim under GNU screen, myself included, would like the ability for vim to automatically support xterm mouse escape sequences. Would it be a workable solution for vim to include screen as one of the initial strings for terms that trigger truth for vim_is_xterm()? I'm guessing that a problem for this, might be the fact that if vim detects xterm-ish terminals, it automatically tries the t_RV sequence out, which isn't dependably valid for screen. If this is the case, perhaps there could be a vim_might_be_xterm(), which could set ttymouse to xterm, on the off-chance that the terminal may send it xterm-style mouse sequences, but leave t_RV empty so that it doesn't risk sending unrecognized stuff that the terminal may choose to display directly? The thing is, is that users of screen are able to use some other programs, such as elinks, and will wonder why vim can't work just as well. Are there any real impediments to it doing so? I suspect that my solution could actually be made much more simple by simply assuming that all terms might be xterm, thus eliminating the need to actually implement a function (just set ttymouse to xterm by default, again leaving t_RV). Thanks for your feedback. References: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214083 https://bugs.launchpad.net/ubuntu/+source/vim/+bug/113227 - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGQBn/7M8hyUobTrERAh1OAJ4ryRB55gWXGwmErt2gHkSVRkIOdwCfSwi8 qD+sS9zpdm3I/Wpsp+hcWHY= =8CI4 -END PGP SIGNATURE-
Re: vim_is_xterm() and screen
Doh! I accidentally sent this directly to Bram, instead of to list :/ Bram Moolenaar wrote: I'm guessing that a problem for this, might be the fact that if vim detects xterm-ish terminals, it automatically tries the t_RV sequence out, which isn't dependably valid for screen. If this is the case, perhaps there could be a vim_might_be_xterm(), which could set ttymouse to xterm, on the off-chance that the terminal may send it xterm-style mouse sequences, but leave t_RV empty so that it doesn't risk sending unrecognized stuff that the terminal may choose to display directly? The thing is, is that users of screen are able to use some other programs, such as elinks, and will wonder why vim can't work just as well. Are there any real impediments to it doing so? I suspect that my solution could actually be made much more simple by simply assuming that all terms might be xterm, thus eliminating the need to actually implement a function (just set ttymouse to xterm by default, again leaving t_RV). There doesn't appear to be a standard for mouse escape sequences. And termcap/terminfo is too limited for the features of modern terminal emulaters. That means the only choice for Vim is to implement mouse support for each terminal separately. If screen uses the same codes as xterm then this should be relatively simple. The de facto standard (aside from the limited support that /is/ offered via terminfo) would seem to be xterm... plus maybe whatever it is that gpm uses. It's about time termcap/terminfo gets updated to support the features we need, instead of hacking solutions in all programs. I'm afraid I don't have time for this (the original development of termcap was closely related to the early development of vi). But you already have hacked support into your programs for mouse support. Now that you've done that, couldn't you just open it up a bit? Is there anything wrong with always recognizing the appropriate xterm sequences (provided that they don't first match a valid terminfo entry)? This is the approach that elinks seems to take, and I don't see any particular reason why vim couldn't do this as well. I agree that fixing terminfo is the right solution, but that doesn't mean you shouldn't hack the working solution in now. You have already done so, or you wouldn't have any mouse support for the various xterm-like consoles in the first place. I'd be happy to write the patch (it should be pretty straightforward); I just want to get some agreement on the correct action to take. -- Thanks, Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim_is_xterm() and screen
A.J.Mechelynck wrote: Micah Cowan wrote: [...] But you already have hacked support into your programs for mouse support. Now that you've done that, couldn't you just open it up a bit? Is there anything wrong with always recognizing the appropriate xterm sequences (provided that they don't first match a valid terminfo entry)? This is the approach that elinks seems to take, and I don't see any particular reason why vim couldn't do this as well. [...] There are conflicts between xterm mouse codes and DEC mouse codes. See :help 'ttymouse' for details (and, maybe, for a way of telling Vim which mouse is installed). Hrm, yes, that could be a problem. I'm guessing the conflict has to do with vim needing to actually signal to the terminal which style of mouse code to send? (I had forgotten that this signal was necessary, which is silly, since bad things would happen if it wasn't.) Alright, then, looks like the only way forward is to fix terminfo, as Bram has suggested. I just noticed that the screen info manual has a section on termcap extensions that it supports, including a XT boolean to indicate support for xterm mouse and OSC (with which I'm not familiar). Perhaps that would be appropriate to prod the ncurses guys to support... Except, if it really is a conflict, I'm wondering how does elinks manages to do it? -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim_is_xterm() and screen
A.J.Mechelynck wrote: Micah Cowan wrote: [...] But you already have hacked support into your programs for mouse support. Now that you've done that, couldn't you just open it up a bit? Is there anything wrong with always recognizing the appropriate xterm sequences (provided that they don't first match a valid terminfo entry)? This is the approach that elinks seems to take, and I don't see any particular reason why vim couldn't do this as well. [...] There are conflicts between xterm mouse codes and DEC mouse codes. See :help 'ttymouse' for details (and, maybe, for a way of telling Vim which mouse is installed). I did some digging in the screen source code, and determined that when screen receives DECSET with one of the mouse-reporting params (9, 1000, 1001), it first checks (using the stupid name magic, unless the user happens to be using termcap instead of terminfo, and has the special screen extension for xterm included) which of the terminals connected to a session (there may be more than one) support the xterm controls, and then sets mouse mode on the terminals that have been detected as xterms corresponding to the sequence it got. Then all sequences that the terminal sends get passed through to the application. For those terminals that are not detected as xterms (have either the string xterm or rxvt in the terminal name), the mode is not sent through at all. Therefore, there would seem to be no harm whatsoever in detecting screen as an xterm-mouse-code-capable terminal, and sending the mouse-mode sequence (xterm protocol, since AFAIK screen provides no way to detect the underlying xterm version). If the underlying terminal claims to be xterm or rxvt, then the user will automatically get the benefit of mouse support without trouble; otherwise, screen will simply ignore the sequence and no harm is done to other terminals (such as unrecognized sequence-emitters, or DEC-mouse-only terminals). I propose that rather than using vim_is_xterm() to determine xterm-style mouse support, a separate function, vim_supports_xterm_mouse() [or somesuch] be used, which would currently return (vim_is_xterm() || terminal is screen). -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
