Lcd wrote:
> I'm re-sending this, since it apparently the first copy got blocked.
Looks like @vim.org is working again, Sec fixed the problem.
> > Lcd wrote:
> >
> > > Some background first.
> > >
> > > If you're running a GUI Vim, 'ballooneval' is true and 'balloonexpr'
> > > is set to an expression, whenever the mouse rests for a short while
> > > pointing to a non-blank character the said expression is evaluated
> > > and the result is shown in a "balloon". A number of v: variables are
> > > available for use in the expression, such as the coordinates the mouse
> > > is pointing to.
> > >
> > > The expression is supposed to return either a string, or a list of
> > > strings. There's a bit of fun related to what happens if the underlying
> > > OS can't handle multiline balloons, but let's assume the OS can actually
> > > deal with them.
> > >
> > > Now the problem.
> > >
> > > According to the manual:
> > >
> > > : When they are supported "\n" characters will start a new line. If the
> > > : expression evaluates to a |List| this is equal to using each List item
> > > : as a string and putting "\n" in between them.
> > >
> > > The problem is a trailing "\n" is always added when the expression
> > > evaluates to a list, and this is pretty much never what you want.
> > > Namely, compare the effect of:
> > >
> > > set beval bexpr=['foo']
> > >
> > > to the effect of:
> > >
> > > set beval bexpr='foo'
> > >
> > > This happens because general_beval_cb() in gui_beval.c calls
> > > eval_to_string() to evaluate 'balloonexpr', and that function adds the
> > > trailing "\n". I don't see any non-intrusive fix to this.
> >
> > Well, general_beval_cb() stores the resulting string in "result". It
> > should be easy to remove a trailing newline from it. Assuming this
> > newline is never useful.
>
> I have no idea whether a trailing newline is _always_ unwanted;
> somebody, somewhere, might have some use for it. What is definitely
> unwanted is adding the newline when the user didn't ask for it. Right
> now it's possible to do it both ways using the string form, and removing
> the newline after the fact would affect both the string and the list
> form.
>
> Perhaps a better solution would be to make eval_to_string() skip the
> trailing newline if the last parameter is 2, or something like that.
> But that would still change things all over the place.
I think the simple solution to remove one newline is better, it's what
most users would expect. If someone really wants a trailing newline, he
can add two.
--
GALAHAD: No, please. Please! I can defeat them! There's only a hundred.
GIRLS: He will beat us easily. We haven't a chance.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
