I'm re-sending this, since it apparently the first copy got blocked.
/lcd
----- Forwarded message from LCD 47 <[email protected]> -----
From: LCD 47 <[email protected]>
Date: Fri, 17 Oct 2014 22:06:34 +0300
To: Bram Moolenaar <[email protected]>
Cc: [email protected]
Subject: Re: Bug handling balloons when balloonexpr returns a list
On 17 October 2014, Bram Moolenaar <[email protected]> wrote:
>
> 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.
/lcd
----- End forwarded message -----
--
--
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.
