Re: what feature is required to return to last editing position?
On 5/10/07, Micah Cowan [EMAIL PROTECTED] wrote: 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? Couldn't we set up that latter part manually somehow with scripts? Like, if I am root, viminfo is .viminfo-ux and otherwise, viminfo is .viminfo-uy? -fREW
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?
Micah Cowan wrote: 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 belon gs 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. 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. 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. 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. -- From know your smileys: :-| :-| Deja' vu! /// 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: 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?
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: what feature is required to return to last editing position?
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 feature is enabled by some autocommands in vimrc_example.vim, I copied the code into my .vimrc and use it in all platform. It really does work in my WindowsXP gvim, cygwin vim, MacOSX vim, and Ubuntu Dapper vim. 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. Any idea where is the problem, or any hint on how to find where the problem is? 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 Yakov
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: what feature is required to return to last editing position?
[EMAIL PROTECTED] wrote: When opening a file in vim, the cursor will move to the last position when the file was saved. The feature is enabled by some autocommands in vimrc_example.vim, I copied the code into my .vimrc and use it in all platform. It really does work in my WindowsXP gvim, cygwin vim, MacOSX vim, and Ubuntu Dapper vim. 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. Any idea where is the problem, or any hint on how to find where the problem is? -- Sincerely, Pan, Shi Zhu. ext: 2606 IIUC, it requires both +autocmd and +viminfo -- IOW, at least a Normal version. Tiny or small (including the version of vim installed under the name vi by the RedHat package vim-minimal) won't have it. (Sorry, I don't know the Ubuntu package names.) Best regards, Tony. -- APL is a write-only language. I can write programs in APL, but I can't read any of them. -- Roy Keir
Re: what feature is required to return to last editing position?
Hello,
I'm also using vim with an Ubuntu Feisty. Here is what I have in my .vimrc:
Try to restore cursor position when reading a buffer
au BufReadPost * if line('\) | exe normal '\ | endif
It works quite well.
On 5/9/07, A.J.Mechelynck [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
When opening a file in vim, the cursor will move to the last position when
the file was saved.
The feature is enabled by some autocommands in vimrc_example.vim, I
copied the code into my .vimrc and use it in all platform.
It really does work in my WindowsXP gvim, cygwin vim, MacOSX vim, and
Ubuntu Dapper vim.
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.
Any idea where is the problem, or any hint on how to find where the problem
is?
--
Sincerely, Pan, Shi Zhu. ext: 2606
IIUC, it requires both +autocmd and +viminfo -- IOW, at least a Normal
version. Tiny or small (including the version of vim installed under the
name vi by the RedHat package vim-minimal) won't have it. (Sorry, I don't
know the Ubuntu package names.)
Best regards,
Tony.
--
APL is a write-only language. I can write programs in APL, but I
can't read any of them.
-- Roy Keir
Re: what feature is required to return to last editing position?
François Ingelrest wrote:
Hello,
I'm also using vim with an Ubuntu Feisty. Here is what I have in my .vimrc:
Try to restore cursor position when reading a buffer
au BufReadPost * if line('\) | exe normal '\ | endif
It works quite well.
Yeah, that is almost the same as the code in the vimrc_example.vim. The latter
also guards against invalid remembered locations, and doesn't update the jumplist:
When editing a file, always jump to the last known cursor position.
Don't do it when the position is invalid or when inside an event handler
(happens when dropping a file on gvim).
autocmd BufReadPost *
\ if line('\) 0 line('\) = line($) |
\ exe normal! g`\ |
\ endif
So here's what /I/ have in my vimrc, and it works quite well:
runtime vimrc_example.vim
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
224. You set up your own Web page. You set up a Web page for each
of your kids... and your pets.
Re: what feature is required to return to last editing position?
[EMAIL PROTECTED] wrote: When opening a file in vim, the cursor will move to the last position when the file was saved. The feature is enabled by some autocommands in vimrc_example.vim, I copied the code into my .vimrc and use it in all platform. It really does work in my WindowsXP gvim, cygwin vim, MacOSX vim, and Ubuntu Dapper vim. 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. Restore cursor to file position in previous editing session : http://vim.sourceforge.net/tips/tip.php?tip_id=80 The command therein will return your cursor to the same line and column that it was in previously. Regards, Chip Campbell
Re: what feature is required to return to last editing position?
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. -- Sincerely, Pan, Shi Zhu. ext: 2606
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
