Re: [patch] when 'autochdir' is set, let mksession always use full pathname independently on curdir,sesdir
On Thu, Apr 30, 2009 at 22:11, _sc_ tooth...@swbell.net wrote: On Thursday 30 April 2009 11:19 am, Yakov Lerner wrote: When 'acd' is set, mksession uses short pathname in the typical usage which leads to wrong result (the testcase below). This is biting me every time I use mksession (I always have acd on). The interaction of 'curdir' in sessionoptions and 'set acd' leads to apparently wrong result. This patch adds additional check in ses_fname, the logic is similar to the check for 'did_lcd' which already exists for the same reason. Note: When this option is on some plugins may not work. or maybe it's time we examined the question of whether 'autochdir' is buggy I think the problem is when code tests for did_lcd flag but does not test for p_acd flag. Looks like p_acd should have same effect as did_lcd. When code tests for did_lcd but not for p_acd, it's problematic for acd. So I fixed one case of it, very pinpointed. Maybe setting did_lcd=TRUE should be automatic whenever p_acd is, set will solve more problems ? Maybe. I don't know. So far, I am using acd for many years, I am satified. Before I discovered acd, I used lcd+au as yours, and I had side-effects, too. I switched from lcd to acd. Yakov --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: More request for 2html :)
On Apr 30, 5:11 pm, Wu, Yue vano...@gmail.com wrote: On Thu, Apr 30, 2009 at 07:05:53AM -0700, Ben Fritz wrote: On Apr 29, 10:22 pm, Wu, Yue vano...@gmail.com wrote: Ok, 2html now has supported folding, thanks for nice work, so fantasic! No doubt you're referring to the patch in this thread: http://groups.google.com/group/vim_dev/browse_thread/thread/84bcdc1a7... [snip] I have used it some time too from when you posted a full version here :) Still something I don't like: foldcolumn is too wide, actually I like to hide them at all, and I think if I can click the header text of a level of folding to fold and unfold would be more convenient for using. In the discussions leading up to the patch, people liked the idea of clicking the text to toggle a fold, but we were having trouble figuring out what to do in the case of multiple folds opening on the same line. The problem exists in Vim, too; you can't access all folds if you have multiple folds on the same line when using za. So, I went with the foldcolumn route. Knowing, however, that some may think the foldcolumn is ugly, I provided an option to allow the mouse to open folds simply by hovering over them and the ability to turn off the fold column. I don't know the web relating technology, but I think 2html can use the tag file of the current document, and then make all |foo| and *foo* in the document as a hypertext? Is it hard to implement? I think the heart of the problem is the fact that 2html is designed to work on a single file. Hyperlinking across files would be a very different task. In addition, the file name when saved is left entirely up to the user. It would be very difficult to get this right in all cases. That being said, it should be possible to create an additional plugin that would read the tag file and do a global find and replace to make the hyperlinks, perhaps asking the user for an html file name to correspond to each real file found. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Add support for guidecolumn in VIM
Pankaj Garg wrote: On Apr 30, 9:30=A0am, Ben Fritz fritzophre...@gmail.com wrote: On Apr 29, 11:42=A0am, Bram Moolenaar b...@moolenaar.net wrote: The name 'guidecolumn' starts with gui, which is confusing, since it also works in a terminal. =A0'margincolumn' perhaps? I agree. If a user uses :help guiC-D for example, they would NOT be expecting 'guidecolumn' to show up! I think the value 0 should be used to have a column at 'textwidth'. That way you can see where a line will be broken when it's formatted, without having to set two options. =A0A negative value can be used to disable the column. I think we should try to make this option consistent with other options. 'textwidth' and 'wrapmargin' and others use a value of 0 to disable it, and making this one use negative numbers may get confusing. Is it possible to use string or character values, or can only numbers be entered? I can't think of any options that do this, but things like line() can take several strings with special meaning. Perhaps the guidecolumn could be disabled when set to 0, set to the textwidth when set to tw, and set to the wrap margin when set to wm? I think something like this would be more consistent with other options and therefore more intuitive for users. I didn't have time to check for any problems with this patch, I hope others have tried it out and report any problems noticed. I haven't tried the patch, but I'm certainly interested in the feature. I'd probably use this instead of the autocmds I have set up to use a matchadd() on long lines. What is this option local to? If it's just global at the moment, I think it should be local either to the buffer (because that's what textwidth is local to) or the window. I could see a use case where a user might want a guidecolumn for the file in one window, but turn it off for a window in diff mode in another tab or something. The option is local to window. I agree margincolumn is a better name. I am also fine with a value of 0 meaning textwidth, however as Ben mentioned, that seems a little unintuitive. Should we convert it to string? Are there other example where numeric options are taking string? Please let me know what you prefer and I can do whatever option everyone agrees to. It's possible to use a string, but more difficult to handle. And easier to set a wrong value, thus more error checking is needed. If we want to use zero for off, we could use -1 for using the 'textwidth' value. -- Time flies like an arrow. Fruit flies like a banana. /// Bram Moolenaar -- b...@moolenaar.net -- 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/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Add support for guidecolumn in VIM
On 2009-05-01, Bram Moolenaar wrote: Pankaj Garg wrote: On Apr 30, 9:30=A0am, Ben Fritz fritzophre...@gmail.com wrote: On Apr 29, 11:42=A0am, Bram Moolenaar b...@moolenaar.net wrote: The name 'guidecolumn' starts with gui, which is confusing, since it also works in a terminal. 'margincolumn' perhaps? I agree. If a user uses :help guiC-D for example, they would NOT be expecting 'guidecolumn' to show up! I think the value 0 should be used to have a column at 'textwidth'. That way you can see where a line will be broken when it's formatted, without having to set two options. =A0A negative value can be used to disable the column. I think we should try to make this option consistent with other options. 'textwidth' and 'wrapmargin' and others use a value of 0 to disable it, and making this one use negative numbers may get confusing. Is it possible to use string or character values, or can only numbers be entered? I can't think of any options that do this, but things like line() can take several strings with special meaning. Perhaps the guidecolumn could be disabled when set to 0, set to the textwidth when set to tw, and set to the wrap margin when set to wm? I think something like this would be more consistent with other options and therefore more intuitive for users. I didn't have time to check for any problems with this patch, I hope others have tried it out and report any problems noticed. I haven't tried the patch, but I'm certainly interested in the feature. I'd probably use this instead of the autocmds I have set up to use a matchadd() on long lines. What is this option local to? If it's just global at the moment, I think it should be local either to the buffer (because that's what textwidth is local to) or the window. I could see a use case where a user might want a guidecolumn for the file in one window, but turn it off for a window in diff mode in another tab or something. The option is local to window. I agree margincolumn is a better name. I am also fine with a value of 0 meaning textwidth, however as Ben mentioned, that seems a little unintuitive. Should we convert it to string? Are there other example where numeric options are taking string? Please let me know what you prefer and I can do whatever option everyone agrees to. It's possible to use a string, but more difficult to handle. And easier to set a wrong value, thus more error checking is needed. If we want to use zero for off, we could use -1 for using the 'textwidth' value. If we use any special value, whether character or numeric, to set guidecolumn/margincolumn to the right margin, I suggest that the column be 'textwidth + 1 rather than 'textwidth'. I've been using this patch for a few weeks now and it looks better to me to have the highlighting at the first out-of-bounds column rather than at the last in-bounds column. As for the name, I don't see 'guidecolumn' as being a problem. I doubt that anyone would confuse it with a GUI command. There are lots of English words having the same initial letters but unrelated meanings. :help comm^D shows some examples of this. I see two problems with 'margincolumn'. The first is that highlighting the right margin is but one application for this feature. The second is that 'margincolumn' implies to me that its location automatically tracks the right margin (i.e., 'textwidth' or 'wrapmargin') which it currently doesn't. While that tracking feature may be added following the discussions in this thread, the highlighting will be of the right margin only for a particular value of 'margincolumn'. Regards, Gary --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Add support for guidecolumn in VIM
On Fri, May 1, 2009 at 2:42 PM, Gary Johnson wrote: On 2009-05-01, Bram Moolenaar wrote: Pankaj Garg wrote: On Apr 30, 9:30 am, Ben Fritz wrote: On Apr 29, 11:42 am, Bram Moolenaar wrote: The name 'guidecolumn' starts with gui, which is confusing, since it also works in a terminal. 'margincolumn' perhaps? I agree. If a user uses :help guiC-D for example, they would NOT be expecting 'guidecolumn' to show up! As for the name, I don't see 'guidecolumn' as being a problem. I doubt that anyone would confuse it with a GUI command. There are lots of English words having the same initial letters but unrelated meanings. :help comm^D shows some examples of this. I see two problems with 'margincolumn'. The first is that highlighting the right margin is but one application for this feature. The second is that 'margincolumn' implies to me that its location automatically tracks the right margin (i.e., 'textwidth' or 'wrapmargin') which it currently doesn't. While that tracking feature may be added following the discussions in this thread, the highlighting will be of the right margin only for a particular value of 'margincolumn'. I agree. I think that 'guidecolumn' is a much better name. Whenever people show up in freenode's #vim asking about this feature, the first phrase they use for it is guide column or guide line, presumably this is because that's what other editors call it. Differing because of the aesthetics of having an option whose first 3 letters make it appear with gui options when completing from the help is just going to make things much harder for people looking for a guide column option, not significantly easier for those trying to figure out which of the gui* options they want. Also, I agree with Gary - it's not inconceivable that someone might want two guides at different spots representing different things, which would mean that the margincolumn name is much more misleading. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Add support for guidecolumn in VIM
On Friday 01 May 2009 2:23 pm, Matt Wozniski wrote: I agree. I think that 'guidecolumn' is a much better name. Whenever people show up in freenode's #vim asking about this feature, the first phrase they use for it is guide column or guide line, presumably this is because that's what other editors call it. Differing because of the aesthetics of having an option whose first 3 letters make it appear with gui options when completing from the help is just going to make things much harder for people looking for a guide column option, not significantly easier for those trying to figure out which of the gui* options they want. Also, I agree with Gary - it's not inconceivable that someone might want two guides at different spots representing different things, which would mean that the margincolumn name is much more misleading. looking in my crystal ball, i foresee people tying multiple guide columns to the columns of those variable width tabs that are currently struggling for acceptance, writing scripts to set them both at the same time, and moving them around to suit the width of the data in their tables sc --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
