Re: [patch] when 'autochdir' is set, let mksession always use full pathname independently on curdir,sesdir

Re: More request for 2html :)

On Apr 30, 5:11 pm, "Wu, Yue" <vano... <at> 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... <at> 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... <at> gmail.com> wrote:
> > On Apr 29, 11:42=A0am, Bram Moolenaar <B... <at> 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 gui<C-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 -- Bram <at> 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... <at> gmail.com> wrote:
> > > On Apr 29, 11:42=A0am, Bram Moolenaar <B... <at> 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 gui<C-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: More request for 2html :)

On Fri, May 01, 2009 at 06:45:55AM -0700, Ben Fritz wrote:
> 
> >
> > 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 think there are more cases that user need to access all folds in a
time than open folds one level by one level. So it's not a problem from my
view.

> 
> >
> > 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.

Hmm, got it, I think you can create an option 'g:2html_tagfile' then user can
configure it and let 2html do the translation work?

--

-- 
Hi,
Wu, Yue

--~--~---------~--~----~------------~-------~--~----~
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 gui<C-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
-~----------~----~----~----~------~----~------~--~---

Re: [patch] when 'autochdir' is set, let mksession always use full pathname independently on curdir,sesdir

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.
> 
> Testcase:
> 
> echo abc >/tmp/xxx
> vim -u NONE -U NONE /tmp/xxx
> :set acd
> :he help
> :mksession! ~/xxx
> :qall!
> 
> vim -u NONE -U NONE -S ~/xxx
> ^^^ bug: upper window is empty ^^^

Thanks, I'll look into it later.

--

-- 
       [Autumn changed into Winter ... Winter changed into Spring ...  Spring
       changed back into Autumn and Autumn gave Winter and Spring a miss and
       went straight on into Summer ...  Until one day ...]
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- Bram <at> 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: merge farsi handling into arabic.c

Ali Gholami Rudi wrote:

> Farsi is quite similar to arabic except for a few letters.  This patch
> merges farsi support into arabic.c.  AFAICS, farsi.c and fkmap option
> seem to be obsolete (unless someone is still using the pcf fonts).
> 
> Also it might make sense to add a new farsi option, just like the arabic
> option, that when set implies "set rl" and "set keymap=persian".

I don't use these languages, thus I need to rely on others to tell me
what works best.  After including this patch, can we drop farsi.c?

There should also be an update to the documentation, most users don't
look at the source code to figure out what to do .

- Bram

--

-- 
TIM: To the north there lies a cave,  the cave of Caerbannog, wherein, carved
     in mystic runes, upon the very living rock, the last words of Olfin
     Bedwere of Rheged make plain the last resting place of the most Holy
     Grail.
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- Bram <at> 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 30/04/09 18:30, Ben Fritz wrote:
>
>
>
> On Apr 29, 11:42 am, Bram Moolenaar<B... <at> 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 gui<C-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.  A 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.
[...]

The problem with that approach is that the option would then be a String 
option, with the consequence that set+= and set-= etc. would work in a 
way which is unexpected for a numeric value. Examples, each of them with 
a starting value of 60:

	:set margincolumn+=5

makes it become 605, not 65

	:set margincolumn-=6

makes it become 0, not 54

	:set margincolumn^=2

makes it become 260, not 120

OTOH, you could use an algebraic number, always relative to the 
textwidth/wrapmargin. Then use a very large negative value to disable 
it, i.e.

	:set margincolumn=0

use 'textwidth' if set, otherwise use (window width - 'wrapmargin') if 
set, otherwise use column zero (disabled).

	:set margincolumn=-10

use 'textwidth' - 10 if set, otherwise use (window width - wrapmargin - 
10) if set, otherwise disabled

	:set margincolumn=-9999

always disabled (assuming you won't have 9999 columns of window width).

Just a thought: Maybe use the opposite sign convention, and subtract 
from 'tw' when this option is positive -- since we'll more often want to 
be warned when we approach the margin, as with a typewriter bell, rather 
than when we exceed it by a given amount?

Best regards,
Tony.
--

-- 
"I am the mother of all things, and all things should wear a sweater."

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---