Re: MANPAGER can't handle man pages with upper case letters in name
On 14 October 2017, Kazunobu Kuriyama wrote: > 2017-10-13 23:54 GMT+09:00 LCD 47 : > > > On 13 October 2017, Kazunobu Kuriyama > > wrote: > > > 2017-10-13 23:24 GMT+09:00 LCD 47 : > > > > "man-db", which is a "man" implementation used on some Linux > > > > distributions, sets the environment variable MAN_PN to something > > > > like "ls(1)", and passes it to programs run from $MANPAGER. To the > > > > best of my knowledge no other "man" implementation does that. > > > > > > > > The manual asks you to set MAN_PN to 1. If it's still 1 (as > > > > opposed to something like "ls(1)") when Vim is run from $MANPAGER, > > > > your "man" didn't set MAN_PN to anything useful. When that happens, > > > > Vim tries to parse the name and the section of the man page from > > > > the first line in the formatted page. However, said line looks > > > > something like this: > > > > > > > > LS(1) General Commands Manual > > > > LS(1) > > > > > > > > To get from "LS(1)" to "ls(1)" Vim uses tolower(). That breaks > > > > for man pages such as "Xorg", or "Net::DNS". This is the problem > > > > I'm trying to address. > > > > > > > > > > What I found was that your solution wasn't enough for Mac. The header > > > which begins with something like LS(1) is not always on line 1 for > > > Mac. And the proposed logic making everything lower via tolower() > > > doesn't work for handling Xorg or Net::DNS for Mac. > > > > That isn't my solution, it's what Vim does, regardless of my patch. > > My solution is to not mutilate "ls(1)" when parsing it from $MAN_PN. > > This has nothing to do with the first line in the formatted page. > > > > > My patch is an compliment to yours. > > > > Here we agree: your patch and mine fix unrelated problems. _shrug_ > > > > IIUC, sounds like you don't care about making your patch work on various > system. OK, I take all that back. Ok, this is my last message on this topic. I explained in great detail what my patch is trying to fix and why. You have the non-MAN_PN case, you aren't affected by my patch at all. On the other hand, I don't have a MacOS and I can't reproduce the problem you're describing in the non-MAN_PN case. Please submit your own fix for your problem, and let me deal with my unrelated problem, thank you. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: MANPAGER can't handle man pages with upper case letters in name
On 13 October 2017, Kazunobu Kuriyama wrote: > 2017-10-13 23:24 GMT+09:00 LCD 47 : > > "man-db", which is a "man" implementation used on some Linux > > distributions, sets the environment variable MAN_PN to something > > like "ls(1)", and passes it to programs run from $MANPAGER. To the > > best of my knowledge no other "man" implementation does that. > > > > The manual asks you to set MAN_PN to 1. If it's still 1 (as > > opposed to something like "ls(1)") when Vim is run from $MANPAGER, > > your "man" didn't set MAN_PN to anything useful. When that happens, > > Vim tries to parse the name and the section of the man page from > > the first line in the formatted page. However, said line looks > > something like this: > > > > LS(1) General Commands Manual > > LS(1) > > > > To get from "LS(1)" to "ls(1)" Vim uses tolower(). That breaks > > for man pages such as "Xorg", or "Net::DNS". This is the problem > > I'm trying to address. > > > > What I found was that your solution wasn't enough for Mac. The header > which begins with something like LS(1) is not always on line 1 for > Mac. And the proposed logic making everything lower via tolower() > doesn't work for handling Xorg or Net::DNS for Mac. That isn't my solution, it's what Vim does, regardless of my patch. My solution is to not mutilate "ls(1)" when parsing it from $MAN_PN. This has nothing to do with the first line in the formatted page. > My patch is an compliment to yours. Here we agree: your patch and mine fix unrelated problems. _shrug_ /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: MANPAGER can't handle man pages with upper case letters in name
On 13 October 2017, Kazunobu Kuriyama
wrote:
> 2017-10-13 22:25 GMT+09:00 LCD 47 :
[...]
> > I don't think the MANPAGER way can be salvaged without MAN_PN
> > (i.e. the problem of "man Xorg" and "man Net::DNS" can't be solved
> > reasonably without it). That's why my patch only addresses the case
> > where "man" sets $MAN_PN. That only covers some Linux systems. On
> > other systems I suggest using a wrapper script instead, that tries
> > to syntesize a $MAN_PN before running "man".
> >
>
> I didn't try addressing the issue for systems not having MAN_PN.
>
> But, according to :h manpager, it clams that it works for macOS with
>
> export MANPAGER="env MAN_PN=1 vim -M +MANPAGER -"
>
> Since macOS doesn't has MAN_PN, I have no idea as to what it is and
> what it is for, and I hadn't known about the mentioned wrapper script
> solution until you told me. True, macOS doesn't have MAN_PN, but the
> help asks to set it to 1, and I'm following the instructions...
"man-db", which is a "man" implementation used on some Linux
distributions, sets the environment variable MAN_PN to something like
"ls(1)", and passes it to programs run from $MANPAGER. To the best of
my knowledge no other "man" implementation does that.
The manual asks you to set MAN_PN to 1. If it's still 1 (as opposed
to something like "ls(1)") when Vim is run from $MANPAGER, your "man"
didn't set MAN_PN to anything useful. When that happens, Vim tries to
parse the name and the section of the man page from the first line in
the formatted page. However, said line looks something like this:
LS(1) General Commands Manual LS(1)
To get from "LS(1)" to "ls(1)" Vim uses tolower(). That breaks for
man pages such as "Xorg", or "Net::DNS". This is the problem I'm trying
to address.
[...]
> >
> > It isn't that I don't _like_ it. Your patch changes the
> > non-MAN_PN branch, it's unrelated to mine. As I said, I'm
> > suggesting the wrapper script as a possibly better solution for that
> > ("better" as in, it solves the "man Xorg" and "man Net::DNS" problem
> > I described in my first message).
>
> No, my patch actually changes the MAN_PN branch ("if MAN_PN is 1"),
> and now I can use Vim as a stand-alone man pager which can work nicely
> with both "man Xorg" and "man Net::DNS", which I think shares the same
> goal of your patch.
As I explained above, "$MAN_PN is 1" is the non-MAN_PN case.
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: MANPAGER can't handle man pages with upper case letters in name
On 13 October 2017, Christian Brabandt wrote:
>
> On Fr, 13 Okt 2017, LCD 47 wrote:
>
> > It isn't that I don't _like_ it. Your patch changes the
> > non-MAN_PN branch, it's unrelated to mine. As I said, I'm
> > suggesting the wrapper script as a possibly better solution for that
> > ("better" as in, it solves the "man Xorg" and "man Net::DNS" problem
> > I described in my first message).
>
> Did you contact the maintainer of the plugin?
Nope. Should I?
> Also, and I realize this may be totally unrelated, but did anybody
> check if this works with the manpager plugin from the neovim project?
Neovim has a different approach, but as far as I can tell it has a
similar problem as manpager.vim (not quite the same).
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: MANPAGER can't handle man pages with upper case letters in name
On 13 October 2017, Kazunobu Kuriyama
wrote:
> 2017-10-13 21:04 GMT+09:00 LCD 47 :
>
> > On 13 October 2017, Kazunobu Kuriyama
> > wrote:
> > > HI,
> > >
> > > To get your patch to work for macOS, I needed to add some tweaks
> > > to that. Please find the attached patch and consider merging it
> > > into yours. Of course, it's fine to me that you reject or modify
> > > it freely; I leave that to you.
> > >
> > > More precisely, contrary to the description it claims (:h
> > > manpager), I haven't been able to get manpager.vim to work for
> > > macOS since it was introduced. As Bram asked for confirmation if
> > > your patch worked for other platforms, I looked into the issue and
> > > found a way to have it work properly for the OS.
> > >
> > > Hopefully, with your patch, the issue is all fixed for the BSD
> > > clan.
> >
> > Sorry, my patch only fixes how manpager.vim works on systems
> > that set $MAN_PN, i.e. _some_ Linuxes.
> >
>
> Did you mean you didn't want to go further beyond those Linuxes? Oh
> my...I thought Bram's word "various systems" meant systems other than
> Linux.
I don't think the MANPAGER way can be salvaged without MAN_PN (i.e.
the problem of "man Xorg" and "man Net::DNS" can't be solved reasonably
without it). That's why my patch only addresses the case where "man"
sets $MAN_PN. That only covers some Linux systems. On other systems
I suggest using a wrapper script instead, that tries to syntesize a
$MAN_PN before running "man".
I tried to explain all this in the previous messages. But I suppose
nobody can really decrypt what I'm trying to say. :)
> OK, if you don't like my patch, it's also fine to me that I send it
> here again separately, though I'm still wondering if we should go
> separately.
[...]
It isn't that I don't _like_ it. Your patch changes the non-MAN_PN
branch, it's unrelated to mine. As I said, I'm suggesting the wrapper
script as a possibly better solution for that ("better" as in, it solves
the "man Xorg" and "man Net::DNS" problem I described in my first
message).
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: MANPAGER can't handle man pages with upper case letters in name
On 13 October 2017, Kazunobu Kuriyama wrote:
> HI,
>
> To get your patch to work for macOS, I needed to add some tweaks to that.
> Please find the attached patch and consider merging it into yours. Of
> course, it's fine to me that you reject or modify it freely; I leave that
> to you.
>
> More precisely, contrary to the description it claims (:h manpager), I
> haven't been able to get manpager.vim to work for macOS since it was
> introduced. As Bram asked for confirmation if your patch worked for other
> platforms, I looked into the issue and found a way to have it work properly
> for the OS.
>
> Hopefully, with your patch, the issue is all fixed for the BSD clan.
Sorry, my patch only fixes how manpager.vim works on systems that
set $MAN_PN, i.e. _some_ Linuxes.
On OpenBSD I'm using this script instead of the MANPAGER thing:
#! /bin/sh
PATH=/usr/local/bin:/bin:/usr/bin
if [ x"$real_man" = x ]; then
export real_man=$(PATH=/bin:/usr/bin which man)
fmt=$("$real_man" -w "$@" | head -1)
fmt=${fmt##*/}
fmt=${fmt%.Z}
fmt=${fmt%.gz}
export MAN_PN="${fmt%.*}(${fmt##*.})"
export MANPAGER='vim -M +MANPAGER'
fi
exec "$real_man" "$@"
I named this "man" and put it in ~/bin (i.e. a directory in $PATH
that comes before /usr/bin where the real "man" lives). Maybe this can
also work for you on Mac.
> Please note that the patch was made against the the version prior to the
> above, since I found it didn't work with \(bu (^H appears next to it).
I'm afraid I can't parse what you're saying here. Does something
like ":Man ls" work for you (without MANPAGER and without my patch)?
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: MANPAGER can't handle man pages with upper case letters in name
On 12 October 2017, Bram Moolenaar wrote:
>
> Lcd wrote:
>
> > On 10 October 2017, LCD 47 wrote:
> > > On 10 October 2017, Bram Moolenaar wrote:
> > > >
> > > > lcd wrote:
> > > >
> > > > > Per title: if MANPAGER is set to "env MAN_PN=1 vim -M +MANPAGER
> > > > > -",
> > > > > running "man Xorg" results in a message "Cannot find a 'xorg'.".
> > > > >
> > > > > The culprit is a "tolower()" in plugin/manpager.vim. Man page
> > > > > names
> > > > > are case-sensitive on most UNIX systems. The patch below seems to fix
> > > > > the problem.
> > > > >
> > > > > /lcd
> > > > >
> > > > >
> > > > > diff --git a/runtime/plugin/manpager.vim b/runtime/plugin/manpager.vim
> > > > > index be6e30b70..9d30fab2f 100644
> > > > > --- a/runtime/plugin/manpager.vim
> > > > > +++ b/runtime/plugin/manpager.vim
> > > > > @@ -20,7 +20,7 @@ function! s:MANPAGER()
> > > > > let manpage = expand('$MAN_PN')
> > > > >endif
> > > > >
> > > > > - let page_sec = matchlist(tolower(manpage), '^' . pagesec_pattern
> > > > > . '$')
> > > > > + let page_sec = matchlist(manpage, '^' . pagesec_pattern . '$')
> > > > >
> > > > >bwipe!
> > > >
> > > > Can you try this instead:
> > > > let page_sec = matchlist(tolower(manpage), '^' .
> > > > tolower(pagesec_pattern) . '$')
> > >
> > > It doesn't help, "Xorg" still gets converted to "xorg".
> > >
> > > As I understand it, what's going on is something like this: Vim
> > > receives the formatted man page via MANPAGER, but this is not directly
> > > usable, so Vim needs to run "man" again. However at that point the
> > > original "man" options are not available, so Vim tries to infer them
> > > from the first line in the formatted man page.
> > >
> > > Now, some man pages preserve the case of the name of the utility
> > > they document (such as "Xorg(1)"), others uppercase it (f.i. "LS(1)").
> > > That's why Vim calls tolower(). This works for most man pages,
> > > because the names are all lower-case, but fails for things like "Xorg"
> > > and "Net::DNS". Please note that the ":Man" command is not affected,
> > > it's only the MANPAGER mechanism that has this problem.
> > [...]
> >
> > I'm attaching a better partial fix.
> >
> > The patch to plugin/manpager.vim fixes two issues:
> >
> > (1) man pages with ":" in names (such as Net::DNS) are not recognized;
> > (2) man pages with upper case letters in names (f.i. "Xorg") are not
> > recognized.
> >
> > The fix is partial because it only addresses (2) when MAN_PN is
> > set. Sadly BSD "man" and "man" on most commercial UNIX systems don't do
> > that, only "man-db" on Linux does. On systems where "man" doesn't set
> > MAN_PN the patch falls back to reading the first line in the formatted
> > man page. On these systems it's possible to write a wrapper script for
> > "man" that sets MAN_PN before actually running "man", but the details
> > are necessarily OS-dependent.
> >
> > The other patch, to ftplugin/man.vim, is unrelated, and is a minor
> > optimisation. There is no need for "col -b", a simple %s/.\b//g does
> > the exact same thing inside Vim.
>
> I would appreciate a few people trying this out on various systems.
A slightly more polished version attached below.
/lcd
diff --git a/runtime/ftplugin/man.vim b/runtime/ftplugin/man.vim
index c7fc3bbdf..83f8a893b 100644
--- a/runtime/ftplugin/man.vim
+++ b/runtime/ftplugin/man.vim
@@ -22,7 +22,8 @@ if &filetype == "man"
endif
" allow dot and dash in manual page name.
- setlocal iskeyword+=\.,-
+ setlocal iskeyword+=\.,-,:
+ setlocal isfname+=:
" Add mappings, unless the user didn't want this.
if !exists("no_plugin_maps") && !exists("no_man_maps")
@@ -40,7 +41,7 @@ if &filetype == "man"
setlocal foldmethod=indent foldnestmax=1 f
Re: MANPAGER can't handle man pages with upper case letters in name
On 10 October 2017, LCD 47 wrote:
> On 10 October 2017, Bram Moolenaar wrote:
> >
> > lcd wrote:
> >
> > > Per title: if MANPAGER is set to "env MAN_PN=1 vim -M +MANPAGER -",
> > > running "man Xorg" results in a message "Cannot find a 'xorg'.".
> > >
> > > The culprit is a "tolower()" in plugin/manpager.vim. Man page names
> > > are case-sensitive on most UNIX systems. The patch below seems to fix
> > > the problem.
> > >
> > > /lcd
> > >
> > >
> > > diff --git a/runtime/plugin/manpager.vim b/runtime/plugin/manpager.vim
> > > index be6e30b70..9d30fab2f 100644
> > > --- a/runtime/plugin/manpager.vim
> > > +++ b/runtime/plugin/manpager.vim
> > > @@ -20,7 +20,7 @@ function! s:MANPAGER()
> > > let manpage = expand('$MAN_PN')
> > >endif
> > >
> > > - let page_sec = matchlist(tolower(manpage), '^' . pagesec_pattern .
> > > '$')
> > > + let page_sec = matchlist(manpage, '^' . pagesec_pattern . '$')
> > >
> > >bwipe!
> >
> > Can you try this instead:
> > let page_sec = matchlist(tolower(manpage), '^' . tolower(pagesec_pattern)
> > . '$')
>
> It doesn't help, "Xorg" still gets converted to "xorg".
>
> As I understand it, what's going on is something like this: Vim
> receives the formatted man page via MANPAGER, but this is not directly
> usable, so Vim needs to run "man" again. However at that point the
> original "man" options are not available, so Vim tries to infer them
> from the first line in the formatted man page.
>
> Now, some man pages preserve the case of the name of the utility
> they document (such as "Xorg(1)"), others uppercase it (f.i. "LS(1)").
> That's why Vim calls tolower(). This works for most man pages,
> because the names are all lower-case, but fails for things like "Xorg"
> and "Net::DNS". Please note that the ":Man" command is not affected,
> it's only the MANPAGER mechanism that has this problem.
[...]
I'm attaching a better partial fix.
The patch to plugin/manpager.vim fixes two issues:
(1) man pages with ":" in names (such as Net::DNS) are not recognized;
(2) man pages with upper case letters in names (f.i. "Xorg") are not
recognized.
The fix is partial because it only addresses (2) when MAN_PN is
set. Sadly BSD "man" and "man" on most commercial UNIX systems don't do
that, only "man-db" on Linux does. On systems where "man" doesn't set
MAN_PN the patch falls back to reading the first line in the formatted
man page. On these systems it's possible to write a wrapper script for
"man" that sets MAN_PN before actually running "man", but the details
are necessarily OS-dependent.
The other patch, to ftplugin/man.vim, is unrelated, and is a minor
optimisation. There is no need for "col -b", a simple %s/.\b//g does
the exact same thing inside Vim.
/lcd
diff --git a/runtime/ftplugin/man.vim b/runtime/ftplugin/man.vim
index c7fc3bbdf..49f2025a5 100644
--- a/runtime/ftplugin/man.vim
+++ b/runtime/ftplugin/man.vim
@@ -176,7 +176,8 @@ func GetPage(...)
let $MANWIDTH = winwidth(0)
let unsetwidth = 1
endif
- silent exec "r !man ".s:GetCmdArg(sect, page)." | col -b"
+ silent exec "r !man ".s:GetCmdArg(sect, page)
+ silent keepj %s/.\b//ge
if unsetwidth
let $MANWIDTH = ''
endif
diff --git a/runtime/plugin/manpager.vim b/runtime/plugin/manpager.vim
index be6e30b70..939f33ec5 100644
--- a/runtime/plugin/manpager.vim
+++ b/runtime/plugin/manpager.vim
@@ -10,17 +10,17 @@ endif
command! -nargs=0 MANPAGER call s:MANPAGER() | delcommand MANPAGER
function! s:MANPAGER()
- let page_pattern = '\v\w+%([-_.]\w+)*'
+ let page_pattern = '\v\w[-_.:0-9A-Za-z]*'
let sec_pattern = '\v\w+%(\+\w+)*'
let pagesec_pattern = '\v(' . page_pattern . ')\((' . sec_pattern . ')\)'
if $MAN_PN is '1'
-let manpage = matchstr( getline(1), '^' . pagesec_pattern )
+let manpage = tolower(matchstr( getline(1), '^' . pagesec_pattern ))
else
-let manpage = expand('$MAN_PN')
+let manpage = $MAN_PN
endif
- let page_sec = matchlist(tolower(manpage), '^' . pagesec_pattern . '$')
+ let page_sec = matchlist(manpage, '^' . pagesec_pattern . '$')
bwipe!
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: MANPAGER can't handle man pages with upper case letters in name
On 10 October 2017, Bram Moolenaar wrote:
>
> lcd wrote:
>
> > Per title: if MANPAGER is set to "env MAN_PN=1 vim -M +MANPAGER -",
> > running "man Xorg" results in a message "Cannot find a 'xorg'.".
> >
> > The culprit is a "tolower()" in plugin/manpager.vim. Man page names
> > are case-sensitive on most UNIX systems. The patch below seems to fix
> > the problem.
> >
> > /lcd
> >
> >
> > diff --git a/runtime/plugin/manpager.vim b/runtime/plugin/manpager.vim
> > index be6e30b70..9d30fab2f 100644
> > --- a/runtime/plugin/manpager.vim
> > +++ b/runtime/plugin/manpager.vim
> > @@ -20,7 +20,7 @@ function! s:MANPAGER()
> > let manpage = expand('$MAN_PN')
> >endif
> >
> > - let page_sec = matchlist(tolower(manpage), '^' . pagesec_pattern . '$')
> > + let page_sec = matchlist(manpage, '^' . pagesec_pattern . '$')
> >
> >bwipe!
>
> Can you try this instead:
> let page_sec = matchlist(tolower(manpage), '^' . tolower(pagesec_pattern)
> . '$')
It doesn't help, "Xorg" still gets converted to "xorg".
As I understand it, what's going on is something like this: Vim
receives the formatted man page via MANPAGER, but this is not directly
usable, so Vim needs to run "man" again. However at that point the
original "man" options are not available, so Vim tries to infer them
from the first line in the formatted man page.
Now, some man pages preserve the case of the name of the utility
they document (such as "Xorg(1)"), others uppercase it (f.i. "LS(1)").
That's why Vim calls tolower(). This works for most man pages, because
the names are all lower-case, but fails for things like "Xorg" and
"Net::DNS". Please note that the ":Man" command is not affected, it's
only the MANPAGER mechanism that has this problem.
Trying to infer the real name from the title of a man page is a
losing battle, and running "man" again from MANPAGER is wasteful anyway.
I think a better approach would be to write a wrapper script around
"man", which would do some minimal option parsing, adjust options to
suit Vim, save the original options, run "man", and then pass the result
to Vim along with the options. This would then bypass manpager.vim
completely, and since the options were adjusted there would be no need
to run "man" again, so a part of man.vim would also be bypassed.
Basically most of the job of man.vim would be done by the script
(but man.vim would still be needed, for the ":Man" command). The only
problem I see are that passing options to Vim from the script is not
easy, it would involve writing something like
-c 'let man_opts = ["ls", "1"]'
and quoting everything properly could get interesting. Also I'm not
sure how feasible this is on Windows.
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: MANPAGER can't handle man pages with upper case letters in name
On 10 October 2017, LCD 47 wrote:
> Per title: if MANPAGER is set to "env MAN_PN=1 vim -M +MANPAGER -",
> running "man Xorg" results in a message "Cannot find a 'xorg'.".
>
> The culprit is a "tolower()" in plugin/manpager.vim. Man page names
> are case-sensitive on most UNIX systems. The patch below seems to fix
> the problem.
>
> /lcd
>
>
> diff --git a/runtime/plugin/manpager.vim b/runtime/plugin/manpager.vim
> index be6e30b70..9d30fab2f 100644
> --- a/runtime/plugin/manpager.vim
> +++ b/runtime/plugin/manpager.vim
> @@ -20,7 +20,7 @@ function! s:MANPAGER()
> let manpage = expand('$MAN_PN')
>endif
>
> - let page_sec = matchlist(tolower(manpage), '^' . pagesec_pattern . '$')
> + let page_sec = matchlist(manpage, '^' . pagesec_pattern . '$')
>
>bwipe!
The fix is wrong, this now breaks for man pages that have things
like "LS(1)" in the title. But the problem stands, "tolower()" is
equally wrong.
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
MANPAGER on OpenBSD
On OpenBSD the argument for the man pager is always passed as a file. This means the environment variable MANPAGER has to be adjusted like this: export MANPAGER="env MAN_PN=1 vim -M +MANPAGER" I haven't checked the sources for unexpected side effects, but it seems to work. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
MANPAGER can't handle man pages with upper case letters in name
Per title: if MANPAGER is set to "env MAN_PN=1 vim -M +MANPAGER -",
running "man Xorg" results in a message "Cannot find a 'xorg'.".
The culprit is a "tolower()" in plugin/manpager.vim. Man page names
are case-sensitive on most UNIX systems. The patch below seems to fix
the problem.
/lcd
diff --git a/runtime/plugin/manpager.vim b/runtime/plugin/manpager.vim
index be6e30b70..9d30fab2f 100644
--- a/runtime/plugin/manpager.vim
+++ b/runtime/plugin/manpager.vim
@@ -20,7 +20,7 @@ function! s:MANPAGER()
let manpage = expand('$MAN_PN')
endif
- let page_sec = matchlist(tolower(manpage), '^' . pagesec_pattern . '$')
+ let page_sec = matchlist(manpage, '^' . pagesec_pattern . '$')
bwipe!
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.0.1006
On 31 August 2017, Yegappan Lakshmanan wrote:
> Hi,
>
> On Thu, Aug 31, 2017 at 9:02 AM, LCD 47 wrote:
> > On 27 August 2017, Bram Moolenaar wrote:
> >>
> >> Patch 8.0.1006
> >> Problem:Cannot parse text with 'erroformat' without changing a quickfix
> >> list.
> >> Solution: Add the "text" argument to getqflist(). (Yegappan Lakshmanan)
> >> Files: runtime/doc/eval.txt, src/evalfunc.c, src/proto/quickfix.pro,
> >> src/quickfix.c, src/testdir/test_quickfix.vim
> >
> > It's awesome that this feature has been added, however the interface
> > is confusing:
> >
> > [...]
> >> + textuse 'errorformat' to extract items from the
> >> + text and return the resulting entries. The
> >> + value can be a string with one line or a list
> >> + with multiple lines. The current quickfix
> >> list
> >> + is not modified.
> > [...]
> >> + When 'text' is specified, all the other items are ignored.
> >> The
> >> + returned dictionary contains the entry 'items' with the list
> >> + of entries.
> >> In case of error processing {what}, an empty dictionary is
> >> returned.
> > [...]
> >
> > What is the point in reusing getqflist() for this instead of
> > writing a new function? It makes no sense: when "text" is used
> > the other arguments are silently ignored, and the {"items": ...}
> > around the qflist is useless. Why not a function getexpr(list),
> > that returns a list?
> >
>
> It made sense to use the getqflist() function to either return an
> existing list from the quickfix stack or a new list from the supplied
> text.
This might well be, but the end user it still doesn't make sense.
When "text" is usedi all other arguments are ignored, and the result is
always a new list. The use case of getqflist() with "text" genuinely
has almost nothing in common with calling it without "text".
> It also avoids adding many functions for dealing with the quickfix
> lists.
Then perhaps a number of functions could have been refactored. I do
understand that this can break things and can result in a much bigger
mess, but as I said, from the point of view of the end user what came
out was is than great. _shrug_
> > The return value is inconsistent: getqflist("text": []) returns {}
> > rather than {"items": []}, which is indistinguishable from an error.
> >
>
> The attached patch fixes this problem.
That's good to hear, thank you.
> > The fact that unknown keys in the input dictionary are silently
> > ignored means among other things that there is no way to test for
> > the new feature. Compare to:
> >
>
> You can check for a particular patch [has("patch-8.0.1006")].
[...]
Yes, but that has its own set of problems, one of the main ones
being that this kind of tests mean nothing with Neovim.
On 31 August 2017, Bram Moolenaar wrote:
> As Yegappan mentioned, using a separate function means a lot of the
> arguments need to be duplicated. It's not idea, but considering these
> functions will be used in scripts and won't be typed it's not that
> important.
Well, it isn't a show stopper by any means, but it's still confusing
and really, really ugly. A good API should make things easy for the end
user, rather than for people writing the API. Just saying.
> > The return value is inconsistent: getqflist("text": []) returns {}
> > rather than {"items": []}, which is indistinguishable from an error.
> >
> > The fact that unknown keys in the input dictionary are silently
> > ignored means among other things that there is no way to test for the
> > new feature. Compare to:
> >
> > if exists("*getexpr")
> > let qflist = getexpr(['some input'])
> > else
> > " do it the old way
> > endif
> >
> > or
> >
> > try
> > let qflist = getexpr(['some input'])
> > catch /\m^Vim\%((\a\+)\)\=:E117/
> > " do it the old way
> > endif
>
> You can come up with a call that would return a known result, if it
> instead returns an empty list you know it doesn't wor
Re: Patch 8.0.1006
On 27 August 2017, Bram Moolenaar wrote:
>
> Patch 8.0.1006
> Problem:Cannot parse text with 'erroformat' without changing a quickfix
> list.
> Solution: Add the "text" argument to getqflist(). (Yegappan Lakshmanan)
> Files: runtime/doc/eval.txt, src/evalfunc.c, src/proto/quickfix.pro,
> src/quickfix.c, src/testdir/test_quickfix.vim
It's awesome that this feature has been added, however the interface
is confusing:
[...]
> + textuse 'errorformat' to extract items from the
> + text and return the resulting entries. The
> + value can be a string with one line or a list
> + with multiple lines. The current quickfix list
> + is not modified.
[...]
> + When 'text' is specified, all the other items are ignored. The
> + returned dictionary contains the entry 'items' with the list
> + of entries.
> In case of error processing {what}, an empty dictionary is
> returned.
[...]
What is the point in reusing getqflist() for this instead of writing
a new function? It makes no sense: when "text" is used the other
arguments are silently ignored, and the {"items": ...} around the qflist
is useless. Why not a function getexpr(list), that returns a list?
The return value is inconsistent: getqflist("text": []) returns {}
rather than {"items": []}, which is indistinguishable from an error.
The fact that unknown keys in the input dictionary are silently
ignored means among other things that there is no way to test for the
new feature. Compare to:
if exists("*getexpr")
let qflist = getexpr(['some input'])
else
" do it the old way
endif
or
try
let qflist = getexpr(['some input'])
catch /\m^Vim\%((\a\+)\)\=:E117/
" do it the old way
endif
Finally, there's also a confusion about "text" being a key on
input, and also a key with a completely different meaning on output.
Seriously: did anybody actually stop to think for 5 minutes about
the user interface of this function?
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: include seoul256 colorscheme with Vim
On 3 August 2017, Christian Brabandt wrote: > > On Do, 03 Aug 2017, Bram Moolenaar wrote: > > > > > I wrote: > > > > > Christian wrote: > > > > > > > as requested in #1665 (distribute more colorschemes with Vim). Here is > > > > the seoul256 colorscheme. The author explicitly gives permission to > > > > distribute this file with Vim: > > > > https://github.com/junegunn/seoul256.vim/issues/46 > > > > (license: MIT) > > > > > > > > This version has been cloned from the official seoul256 repository > > > > https://github.com/junegunn/seoul256.vim and is the latest version > > > > from May 1st 2017, Commit SHA: 2309b5c8724970c4ad16a751 > > > > > > There are two things we need to discuss first: > > > > > > 1. There must be hundreds of colorschemes out there. I'm sure every > > > user has its own favorite. But some are liked by more users than > > > others. In the distribution, I would rather have a limited set, ones > > > we can recomment to users. And a varied set, not two colorschemes that > > > are nearly the same. So we should find a way to make a top-10 of > > > colorschemes to include. > > > > Perhaps someone can start a poll that we run for a few weeks, to have > > users vote on their favorite color theme? > > I asked at vim-reddit: > https://www.reddit.com/r/vim/comments/6rf9z6/what_is_your_favorite_colorscheme/ Not sure a popularity contest is the best idea here. Take f.i. the solarized scheme: it's probably the most popular scheme out there, but it's also the scheme generating the most requests for support, for reasons related to terminals, curses, X configuration etc. Do you really want all these requests redirected to Vim? /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch to add support for parsing lines using setqflist()
On 20 July 2017, Yegappan Lakshmanan wrote: > Hi, > > On Thu, Jul 20, 2017 at 6:59 AM, Yegappan Lakshmanan > wrote: > > Hi, > > > > I am investigating a memory leak reported by valgrind with this > > patch. > > > > I am attaching an updated patch with the fix for this memory leak and > additional tests. > > Once this patch is incorporated, output can be parsed using > 'errorformat' and resulting entries can be added to any > quickfix/location list by using setqflist(). Sadly, this still won't allow one to parse errors with errorformat to a list in memory, disconnected from the stack. You see, the problem with the stack is that in order to use it in a plugin beyond basic lolder / lnewer navigation, you need to assume your plugin is the only one manipulating said stack. If another plugin comes into picture and you try to accomodate it, it immediately becomes an uphill battle. There is no way to keep track which loclist belong to which plugin, and there is basically no way to tell the state of the stack. The other plugin can add or remove entries, and there is no way for you to detect that. You could look at the number of elements, but once the stack gets full that number becomes useless. You could hook to autocmds, but quickfix commands can be run silent. You could keep track of the stack pointer, but the other plugin can play tricks with the stack pointer too. In fact I'd be very curious to see a plugin do something useful with the quickfix / loclist stack without asserting exclusive ownership to it. As it is, it's simply too user-hostile. Ok, I'll crawl under my rock now, this is likely to be my last message on this topic. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Updating two quickfix lists simultaneously
On 2 July 2017, Yegappan Lakshmanan wrote: > Hi, > > On Sun, Jul 2, 2017 at 12:11 PM, LCD 47 wrote: > >> >> > >> >> When one plugin is asynchronously updating a quickfix list, > >> >> currently it is not possible for another plugin to update another > >> >> quickfix list synchronously or asynchronously using the cexpr, > >> >> cfile, and other commands. The setqflist() function can update any > >> >> quickfix list in the stack. But this function currently doesn't > >> >> support parsing output using 'errorformat'. > >> >> > >> >> For example, let us say one plugin asynchronously updates the > >> >> quickfix list with a build tool output. Now if the user runs a > >> >> query command to create and update another quickfix list, then both > >> >> the plugins will end up updating the same quickfix list. > >> > > >> > What do you mean by "asynchronously" in this context? Vim is > >> > single threaded, as far as I can tell there is no way to run f.i. > >> > two cexpr commands at the same time. Do you have an ecxample of > >> > code that fails this way? > >> > > >> > >> A plugin can use ":caddexpr" command to add entries to a quickfix > >> list. For example, a plugin can start a build process (which > >> takes a long time to complete) in the background using the job > >> functionality. As the output lines are available, the plugin can use > >> caddexpr to parse the output and add the resulting entries to the > >> quickfix list. > >> > >> While this is running, if the user issues another command (either > >> from another plugin or directly using the Vim quickfix commands) that > >> creates/updates the quickfix list then the wrong quickfix list will be > >> updated by the previous command. This is because the caddexpr command > >> can add entires only to the last quickfix list in the stack. > > > > Ok, so the problem is not cexpr, which creates the full quickfix > > list in a single run, but rather interspersed calls to caddexpr (and > > friends) from different plugins, each plugin trying to update its > > own quickfix list on the fly. > > > > Yes. > > > > > Then perhaps what's missing is a set of functions that can create / edit > > / delete quickfix lists outside the stack altogether. > > > > This is already possible using the setqflist() function. A particular > quickfix list can be updated by specifying the list number using the > "nr" key in the dictionary. setqflist() affects quickfix lists on the stack. I'm talking about lists in memory, unrelated to the stack. > You can add entries using the "items" key. The missing functionality > is parsing output using 'errorformat'. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Updating two quickfix lists simultaneously
On 2 July 2017, Yegappan Lakshmanan wrote: > Hi, > > On Sun, Jul 2, 2017 at 6:45 AM, LCD 47 wrote: > > On 1 July 2017, Yegappan Lakshmanan wrote: > >> Hi all, > >> > >> When one plugin is asynchronously updating a quickfix list, > >> currently it is not possible for another plugin to update another > >> quickfix list synchronously or asynchronously using the cexpr, > >> cfile, and other commands. The setqflist() function can update any > >> quickfix list in the stack. But this function currently doesn't > >> support parsing output using 'errorformat'. > >> > >> For example, let us say one plugin asynchronously updates the > >> quickfix list with a build tool output. Now if the user runs a > >> query command to create and update another quickfix list, then both > >> the plugins will end up updating the same quickfix list. > > > > What do you mean by "asynchronously" in this context? Vim is > > single threaded, as far as I can tell there is no way to run f.i. > > two cexpr commands at the same time. Do you have an ecxample of > > code that fails this way? > > > > A plugin can use ":caddexpr" command to add entries to a quickfix > list. For example, a plugin can start a build process (which > takes a long time to complete) in the background using the job > functionality. As the output lines are available, the plugin can use > caddexpr to parse the output and add the resulting entries to the > quickfix list. > > While this is running, if the user issues another command (either > from another plugin or directly using the Vim quickfix commands) that > creates/updates the quickfix list then the wrong quickfix list will be > updated by the previous command. This is because the caddexpr command > can add entires only to the last quickfix list in the stack. Ok, so the problem is not cexpr, which creates the full quickfix list in a single run, but rather interspersed calls to caddexpr (and friends) from different plugins, each plugin trying to update its own quickfix list on the fly. Then perhaps what's missing is a set of functions that can create / edit / delete quickfix lists outside the stack altogether. This would be quite useful, it would allow "preprocessing" errors before "publishing" them. Just being able to change things on the stack only at well-defined checkpoints would be a lot more hygienic for the plugin writers, IMO. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Updating two quickfix lists simultaneously
On 1 July 2017, Yegappan Lakshmanan wrote: > Hi all, > > When one plugin is asynchronously updating a quickfix list, currently it > is not possible for another plugin to update another quickfix list > synchronously or asynchronously using the cexpr, cfile, and other > commands. The setqflist() function can update any quickfix list in the > stack. But this function currently doesn't support parsing output using > 'errorformat'. > > For example, let us say one plugin asynchronously updates the quickfix > list with a build tool output. Now if the user runs a query command to > create and update another quickfix list, then both the plugins will end > up updating the same quickfix list. What do you mean by "asynchronously" in this context? Vim is single threaded, as far as I can tell there is no way to run f.i. two cexpr commands at the same time. Do you have an ecxample of code that fails this way? /lcd > This is because the commands like cexpr, cfile, etc. use the > qf_init_ext() function to parse the output and add entries to the > quickfix list. The qf_init_ext() function supports updating only the > last quickfix list. > > This problem can be solved by changing the qf_init_ext() function to > operate on any quickfix list in the stack. But this function currently > saves state information across multiple invocations to support > directory/file stack and multi-line error output. This state information > is stored in qf_info_S (entire quickfix stack) instead of qf_list_T (per > list). This state information needs to be stored per quickfix list by > moving to qf_list_T. Does anyone see any issues with this or any other > suggestions? -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] quickfix entry with &efm='%m' from cgetexpr is valid, but invalid with setqflist (#1642)
On 20 April 2017, Yegappan Lakshmanan wrote: > Hi, > > On Wed, Apr 19, 2017 at 4:23 PM, Daniel Hahler > wrote: > > It might also be possible to allow for setting valid?! > > > > Are you referring to changing the setqflist() function to accept the > > valid flag field and not checking for a valid file name and a line > > number? > > > > Yes. This way you could set this flag yourself in general, but it > > would fix the issue at hand (since valid is contained already, and > > would be used as-is when passing it to setqflist()). > > > > The attached patch implements the support for setting the 'valid' flag > using the setqflist() function and tests for this functionality. +1, this makes sense. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
JSON parsing problems
Today I stumbled upon this article about JSON:
http://seriot.ch/parsing_json.php
The article links to a set of tests:
https://github.com/nst/JSONTestSuite
A quick run of the "y" and "n" tests against Vim's json_decode()
finds a few problems. Not particularly ground-breaking, but perhaps
worth fixing:
* These should be accepted, but aren't:
json_decode('{"a":"b","a":"c"}')" E685
json_decode('{"a":"b","a":"b"}')" E685
json_decode('{"":0}') " E474
* These should be rejected, but aren't:
json_decode('["",]')" ['']
json_decode('[1,]') " [1]
json_decode('{1:1}')" {'1': 1}
json_decode('{"id":0,}')" {'id': 0}
json_decode('["\uD800\u"]') " ['']
json_decode('["\uD800\u1"]')" ['<01>']
json_decode('["\uD800\u1x"]') " ['<01>x']
json_decode('["\x00"]') " ['x00']
json_decode('["\a"]') " ['a']
json_decode('[True]') " [v:true]
* There is even a segfault:
json_decode(repeat('[', 10))" segfault
There are others, the above are just the main ones. Also, for the
"n" tests I was just checking that json_decode() rises an exception, not
that the exception rised actually makes sense.
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Typo in the manual
Pretty much self-explanatory. /lcd diff --git a/runtime/doc/windows.txt b/runtime/doc/windows.txt index 0ef1a8b..ba0075d 100644 --- a/runtime/doc/windows.txt +++ b/runtime/doc/windows.txt @@ -295,8 +295,8 @@ CTRL-W CTRL-Q *CTRL-W_CTRL-Q* :1quit " quit the first window :$quit " quit the last window :9quit " quit the last window -" if there are less than 9 windows opened - :-quit " quit the previews window + " if there are less than 9 windows opened + :-quit " quit the previous window :+quit " quit the next window :+2quit " quit the second next window < -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] improve ended-job check
On 14 October 2016, Bram Moolenaar wrote: > > Ozaki Kiichi wrote: > > > Currently, vim checks ended-job every 10 second; thus exit_cb is delayed > > 10 seconds at the maximum. > > > > I propose the following: > > > > https://gist.github.com/ichizok/fe9743f46822a9015ed2f7d65238c5db > > > > os_unix: check by waitpid(-1, _, WNOHANG). > > os_win32: check by WaitForMultipleObjects(), > > "the number of active jobs" / MAXIMUM_WAIT_OBJECTS (==64) times. > > > > They suppress the count of calling syscall to be nearly constant regardless > > of the number of active jobs. > > > > # I set MAX_ENDED_JOB_COUNT (the maximum number of detections > > # in job_check_ended()) to 8, but this may require consideration. > > Looks useful. > > The JOB_WAITED value does not have a clear meaning. It looks like we > know the job has ended, but has not been cleaned up yet. Perhaps call > it JOB_EXITED ? On a side note: a Vim function job_wait() that would do a blocking wait for a given job would be useful, too. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Quickfix: Problem if first pattern is an ignored multiline pattern (#1126)
On 8 October 2016, Bram Moolenaar wrote:
>
> > Lcd wrote:
> >
> > On 7 October 2016, Gerd Wachsmuth wrote:
> > > > The issue is that the multiline error is started by %W and ends with %Z
> > > > without adding any errors.
> > > In my opinion, it is not the issue that no `%C` is present:
> > > With
> > >
> > > set efm=%+Eerror\ %l,%-Winfo\ %m\ %l,%+Ceven\ more\ %m,%Zmore\ info
> > > (note the `%C` line)
> > > and the errorfile
> > >
> > > info bla 3
> > > even more info
> > > more info
> > > error 2
> > >
> > > we do not see `error 2` in the quickfix window.
> >
> > What seems to be going on here is that the first line gets matched
> > as `%-W` and `qf_parse_line()` returns `QF_IGNORE_LINE`. Then the
> > second line gets matched as `%+C`, it sets `%m`, but then it can't
> > find a previous line to continue since the previous line was ignored.
> > Consequently `qf_parse_line()` returns `QF_FAIL`, and `qf_init_ext()`
> > bails out at that point, silently ignoring any remaining input.
> >
> > Possible solution:
> >
> > ```diff
> > diff --git a/src/quickfix.c b/src/quickfix.c
> > index 52abbeb..9139663 100644
> > --- a/src/quickfix.c
> > +++ b/src/quickfix.c
> > @@ -1010,6 +1010,8 @@ restofline:
> > }
> > else if (vim_strchr((char_u *)"CZ", idx) != NULL)
> > { /* continuation of multi-line msg */
> > + if (!qi->qf_multiignore)
> > + {
> > qfline_T *qfprev = qi->qf_lists[qi->qf_curlist].qf_last;
> >
> > if (qfprev == NULL)
> > @@ -1043,6 +1045,7 @@ restofline:
> > ? fields->namebuf
> > : qi->qf_currfile != NULL && fields->valid
> > ? qi->qf_currfile : 0);
> > + }
> > if (idx == 'Z')
> > qi->qf_multiline = qi->qf_multiignore = FALSE;
> > line_breakcheck();
> > ```
>
> Could you write a test that covers this?
Done:
https://gist.github.com/lcd047/4d4adb7e77fe29d9a8313c27fd42db25
(the diff is a lot bigger because of re-indentation).
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Quickfix: Problem if first pattern is an ignored multiline pattern (#1126)
On 7 October 2016, Gerd Wachsmuth wrote:
> > The issue is that the multiline error is started by %W and ends with %Z
> > without adding any errors.
> In my opinion, it is not the issue that no `%C` is present:
> With
>
> set efm=%+Eerror\ %l,%-Winfo\ %m\ %l,%+Ceven\ more\ %m,%Zmore\ info
> (note the `%C` line)
> and the errorfile
>
> info bla 3
> even more info
> more info
> error 2
>
> we do not see `error 2` in the quickfix window.
What seems to be going on here is that the first line gets matched
as `%-W` and `qf_parse_line()` returns `QF_IGNORE_LINE`. Then the
second line gets matched as `%+C`, it sets `%m`, but then it can't
find a previous line to continue since the previous line was ignored.
Consequently `qf_parse_line()` returns `QF_FAIL`, and `qf_init_ext()`
bails out at that point, silently ignoring any remaining input.
Possible solution:
```diff
diff --git a/src/quickfix.c b/src/quickfix.c
index 52abbeb..9139663 100644
--- a/src/quickfix.c
+++ b/src/quickfix.c
@@ -1010,6 +1010,8 @@ restofline:
}
else if (vim_strchr((char_u *)"CZ", idx) != NULL)
{ /* continuation of multi-line msg */
+ if (!qi->qf_multiignore)
+ {
qfline_T *qfprev = qi->qf_lists[qi->qf_curlist].qf_last;
if (qfprev == NULL)
@@ -1043,6 +1045,7 @@ restofline:
? fields->namebuf
: qi->qf_currfile != NULL && fields->valid
? qi->qf_currfile : 0);
+ }
if (idx == 'Z')
qi->qf_multiline = qi->qf_multiignore = FALSE;
line_breakcheck();
```
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.2200
On 27 September 2016, Yegappan Lakshmanan wrote:
> Hi,
>
> On Fri, Sep 16, 2016 at 11:32 PM, LCD 47 wrote:
> > On 16 September 2016, Yegappan Lakshmanan wrote:
> >> Hi,
> >>
> >> On Sun, Sep 11, 2016 at 4:08 AM, LCD 47 wrote:
> >> > On 12 August 2016, Bram Moolenaar wrote:
> >> >>
> >> >> Patch 7.4.2200
> >> >> Problem:Cannot get all information about a quickfix list.
> >> >> Solution: Add an optional argument to get/set loc/qf list(). (Yegappan
> >> >> Lakshmanan)
> >> >
> >> > Another possible solution would be to track the current
> >> > loclist using the "nr" above, which is essentially the index
> >> > of the current loclist in the loclist stack. This is more
> >> > problematic, as the current interface is incomplete. It isn't
> >> > possible to get the current depth of the stack, and the only way
> >> > to get the "nr" for the current loclist is to query for "all" and
> >> > ignore the irrelevant fields in the result.
> >> >
> >>
> >> You can set the 'nr' key to -1 when calling the
> >> getqflist()/getloclist() function to use the current list.
> >
> > This doesn't seem to work, getloclist(0, {'nr': -1}) always
> > seems to return an error:
> >
> > :echo getloclist(0, {'all': 1})
> > {'nr': 2, 'winid': 1001, 'title': ':SyntasticCheck gcc (c)'}
> >
> > :echo getloclist(0, {'nr': -1})
> > {}
> >
>
> I am attaching a patch to return information about the current
> quickfix/location list, if the 'nr' field is set to zero.
>
> Without this change, to get the current quickfix/location list number,
> you need to set 'all' to 1, leave out 'nr' and then parse the returned
> information (as you suggested above).
Works as expected, thank you!
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: highlighting text
On 23 September 2016, Christian Brabandt wrote:
> Hi Markus!
>
> On Fr, 23 Sep 2016, Markus Knecht wrote:
>
> > Thanks, matchaddops seems to be exactly the functionality i need,
> > sadly I get a failure that the function matchaddpos is unknown,
> > probably I'm missing something obvious
>
> You need to update your vim, or you can use a translate the
> matchaddpos() calls to matchadd() calls using the regular expression
> atoms /\%l and /\%c and a like (see the help). But since Vim 8.0 was
> just recently released, I would go with Vim 8.0
Right, same thing without matchaddpos():
function! HL(group, lstart, cstart, lend, cend)
if a:lstart > a:lend
return
elseif a:lstart == a:lend
call matchadd(a:group, printf('\%%%dl\%%>%dc\%%<%dc',
\ a:lstart, a:cstart - 1, a:cend + 1))
else
call matchadd(a:group, printf('\%%%dl\%%>%dc', a:lstart,
a:cstart - 1))
for line in range(a:lstart + 1, a:lend - 1)
call matchadd(a:group, printf('\%%%dl', line))
endfor
call matchadd(a:group, printf('\%%%dl\%%<%dc', a:lend, a:cend +
1))
endif
endfunction
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: highlighting text
On 21 September 2016, Markus Knecht wrote:
> Hello,
>
> For a project I have to import some markings into vim and for that I'm
> writing a plugin. These markings are in the form of:
> line start,
> coloumn start, //the start character index
> line end,
> coloumn end, //the end character index
> message
>
> over the signs I have managed to mark the lines and display the
> message when the cursor is on the line. But now I need to highlight
> the characters, like a search does it when hlsearch is enabled, and
> the only thing i found is the matchadd() methode and commands like
> :match, but all of these work with a pattern. But i just need a
> straight forward mark exactly that mechanism which works on a line
> coloumn basis. I would much apriciate it if someone could point me in
> the right direction.
One way to do it:
function! HL(group, lstart, cstart, lend, cend)
if a:lstart > a:lend
return
elseif a:lstart == a:lend
call matchaddpos(a:group, [[a:lstart, a:cstart, a:cend -
a:cstart + 1]])
else
call matchadd(a:group, printf('\%%%dl\%%>%dc', a:lstart,
a:cstart - 1))
for line in range(a:lstart + 1, a:lend - 1)
call matchaddpos(a:group, [line])
endfor
call matchadd(a:group, printf('\%%%dl\%%<%dc', a:lend, a:cend +
1))
endif
endfunction
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.2200
On 16 September 2016, Yegappan Lakshmanan wrote:
> Hi,
>
> On Sun, Sep 11, 2016 at 4:08 AM, LCD 47 wrote:
> > On 12 August 2016, Bram Moolenaar wrote:
> >>
> >> Patch 7.4.2200
> >> Problem:Cannot get all information about a quickfix list.
> >> Solution: Add an optional argument to get/set loc/qf list(). (Yegappan
> >> Lakshmanan)
> > [...]
> >> + If the optional {what} dictionary argument is supplied, then
> >> + returns only the items listed in {what} as a dictionary. The
> >> + following string items are supported in {what}:
> >> + nr get information for this quickfix list
> >> + title get list title
> >> + winid get window id (if opened)
> >> + all all of the above quickfix properties
> >> + Non-string items in {what} are ignored. If "nr" is
> >> + not present then the current quickfix list is used.
> > [...]
> >
> > I'm trying to make sure a plugin is not messing with some other
> > plugin's loclists. Towards that purpose, being able to set and get
> > a loclist's title is useful but not enough.
> >
>
> I am working on additional changes to getqflist/getloclist() and
> setqflist/setloclist() to get and set the list items. Along with the
> pending patch for getting/setting the context, you can use this to
> save and restore any quickfix/location list. I am also working on a
> patch for getting/setting the stack. Now that Vim 8.0 is out, Bram
> may not include any major changes for quite some time (based on past
> precedence).
>
> >
> > One possible solution would be for loclists (and quickfix lists)
> > to have globally unique IDs. This ID could be as simple as a
> > global, always increasing sequence number that would be assigned to
> > loclists upon their creation, independently of the starting window.
> > Of course, getloclist() should be able to return this number upon
> > request.
> >
> > Another possible solution would be to track the current loclist
> > using the "nr" above, which is essentially the index of the current
> > loclist in the loclist stack. This is more problematic, as the
> > current interface is incomplete. It isn't possible to get the
> > current depth of the stack, and the only way to get the "nr" for
> > the current loclist is to query for "all" and ignore the irrelevant
> > fields in the result.
> >
>
> You can set the 'nr' key to -1 when calling the
> getqflist()/getloclist() function to use the current list.
This doesn't seem to work, getloclist(0, {'nr': -1}) always seems
to return an error:
:echo getloclist(0, {'all': 1})
{'nr': 2, 'winid': 1001, 'title': ':SyntasticCheck gcc (c)'}
:echo getloclist(0, {'nr': -1})
{}
> > These could be addressed by adding a new field, say "max", that
> > would return the current stack depth, and by making a query for {
> > "nr": 0 } return (just) the "nr" of the current loclist.
> >
>
> What do you think about modifying the getqflist()/getloclist()
> functions to use the top of the list if 'nr' is set to a value large
> than (10)?
As I see it, the main problem with "nr" right now is that you can't
get any clue about its possible values. That's why it would be useful
to get information about the stack (mainly current and maximum depth,
and current pointer).
Using the top of the list when "nr" is too large is just a
convention. It may or may not be the right thing to do (I can't really
put it in a context to get an idea about its usefulness), but adding
more conventions and magic numbers won't solve the problem of finding
where you are on the stack.
/lcd
> >
> > More seriously however, there is no way to tell when the stack
> > is full, and when some older loclists have been recycled. I also
> > don't think there is any way to explicitly discard a specific
> > loclist. Doing something like
> >
> > call setloclist(0, [], 'r')
> >
> > might have that effect (I haven't checked), but some more direct
> > cleanup mechanism that would free() all structures involved would be
> > nice.
> >
> > Yet another possible solution would be to add to loclists (and
> > quickfix lists) a field named, say, "owner" that would be get-able
> > and set-able. I think an unique ID would be preferrable though.
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Vim 8.0 released!
On 12 September 2016, Bram Moolenaar wrote: > > > Hello Vim users! > > > Announcing: Vim (Vi IMproved) version 8.0 [...] Congratulations! /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.2200
On 11 September 2016, Bram Moolenaar wrote:
>
> Lcd wrote:
>
> > On 12 August 2016, Bram Moolenaar wrote:
> > >
> > > Patch 7.4.2200
> > > Problem:Cannot get all information about a quickfix list.
> > > Solution: Add an optional argument to get/set loc/qf list(). (Yegappan
> > > Lakshmanan)
> > [...]
> > > + If the optional {what} dictionary argument is supplied,
> > > then
> > > + returns only the items listed in {what} as a
> > > dictionary. The
> > > + following string items are supported in {what}:
> > > + nr get information for this quickfix list
> > > + title get list title
> > > + winid get window id (if opened)
> > > + all all of the above quickfix properties
> > > + Non-string items in {what} are ignored.
> > > + If "nr" is not present then the current quickfix list
> > > is used.
> > [...]
> >
> > I'm trying to make sure a plugin is not messing with some other
> > plugin's loclists. Towards that purpose, being able to set and get
> > a loclist's title is useful but not enough.
> >
> > One possible solution would be for loclists (and quickfix lists)
> > to have globally unique IDs. This ID could be as simple as a
> > global, always increasing sequence number that would be assigned to
> > loclists upon their creation, independently of the starting window.
> > Of course, getloclist() should be able to return this number upon
> > request.
> >
> > Another possible solution would be to track the current loclist
> > using the "nr" above, which is essentially the index of the current
> > loclist in the loclist stack. This is more problematic, as the
> > current interface is incomplete. It isn't possible to get the
> > current depth of the stack, and the only way to get the "nr" for
> > the current loclist is to query for "all" and ignore the irrelevant
> > fields in the result. These could be addressed by adding a new
> > field, say "max", that would return the current stack depth, and by
> > making a query for { "nr": 0 } return (just) the "nr" of the current
> > loclist.
> >
> > More seriously however, there is no way to tell when the stack
> > is full, and when some older loclists have been recycled. I also
> > don't think there is any way to explicitly discard a specific
> > loclist. Doing something like
> >
> > call setloclist(0, [], 'r')
> >
> > might have that effect (I haven't checked), but some more direct
> > cleanup mechanism that would free() all structures involved would be
> > nice.
> >
> > Yet another possible solution would be to add to loclists (and
> > quickfix lists) a field named, say, "owner" that would be get-able
> > and set-able. I think an unique ID would be preferrable though.
>
> Makes sense. For the same reason we added the window ID. So next to
> the title we can have a unique ID.
>
> I suppose we should then also have a function to get the list of IDs.
> In a way it maps to the index number.
A function to manipulate the stack could handle that. Christian
Brabandt posted something like that a while ago, but had a number of
bugs, and it tried to return the contents of the loclists, which could
be potentially huge. I think something that would just dump the list of
IDs, move the stack pointer around would be enough for most uses. Pop
would be nice too, but push probably doesn't make complete sense.
That would solve the problem of finding out when some loclists have
been recycled.
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.2200
On 12 August 2016, Bram Moolenaar wrote:
>
> Patch 7.4.2200
> Problem:Cannot get all information about a quickfix list.
> Solution: Add an optional argument to get/set loc/qf list(). (Yegappan
> Lakshmanan)
[...]
> + If the optional {what} dictionary argument is supplied, then
> + returns only the items listed in {what} as a dictionary. The
> + following string items are supported in {what}:
> + nr get information for this quickfix list
> + title get list title
> + winid get window id (if opened)
> + all all of the above quickfix properties
> + Non-string items in {what} are ignored.
> + If "nr" is not present then the current quickfix list is used.
[...]
I'm trying to make sure a plugin is not messing with some other
plugin's loclists. Towards that purpose, being able to set and get a
loclist's title is useful but not enough.
One possible solution would be for loclists (and quickfix lists)
to have globally unique IDs. This ID could be as simple as a global,
always increasing sequence number that would be assigned to loclists
upon their creation, independently of the starting window. Of course,
getloclist() should be able to return this number upon request.
Another possible solution would be to track the current loclist
using the "nr" above, which is essentially the index of the current
loclist in the loclist stack. This is more problematic, as the current
interface is incomplete. It isn't possible to get the current depth of
the stack, and the only way to get the "nr" for the current loclist is
to query for "all" and ignore the irrelevant fields in the result.
These could be addressed by adding a new field, say "max", that would
return the current stack depth, and by making a query for { "nr": 0 }
return (just) the "nr" of the current loclist.
More seriously however, there is no way to tell when the stack is
full, and when some older loclists have been recycled. I also don't
think there is any way to explicitly discard a specific loclist. Doing
something like
call setloclist(0, [], 'r')
might have that effect (I haven't checked), but some more direct cleanup
mechanism that would free() all structures involved would be nice.
Yet another possible solution would be to add to loclists (and
quickfix lists) a field named, say, "owner" that would be get-able and
set-able. I think an unique ID would be preferrable though.
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.2299
On 3 September 2016, Bram Moolenaar wrote:
>
> Lcd wrote:
>
> > > > On 1 September 2016, Bram Moolenaar wrote:
> > > > >
> > > > > Patch 7.4.2299 Problem: QuickFixCmdPre and QuickFixCmdPost
> > > > > autocommands are not always triggered. Solution: Also
> > > > > trigger on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan)
> > > > > Files: src/quickfix.c, src/testdir/test_quickfix.vim
> > > > [...]
> > > >
> > > > Sadly, this breaks the interaction of "syntastic" with all
> > > > plugins that hook to QuickFixCmdPre or QuickFixCmdPost. An
> > > > example of such plugin is "ferret". These plugins now have to
> > > > be fixed to be aware that they may be called from things like
> > > > :lgetexpr. I'd argue that running QuickFixCmd* for :lgetexpr
> > > > makes little sense, since :lgetexpr is almost never called run
> > > > interactively. So, was there an actual reason for this change,
> > > > right before the release of Vim 8?
> > >
> > > Can you give more details about what breaks? The autocommands are
> > > there to allow plugins to deal with changes in the Quickfix list.
> > > I hope it's not actually being used for something else.
> >
> > As I said in another message, people do thinge like this:
> >
> > if has('autocmd')
> > augroup Ferret
> > autocmd!
> > autocmd QuickFixCmdPost [^l]* nested cwindow
> > autocmd QuickFixCmdPost l* nested lwindow
> > augroup END
> > endif
> >
> > This is fine for opening grep windows automatically and what
> > not, but the loclists created by things like lgetexpr are typically
> > parsing in progress, and are never meant to be displayed at that
> > stage. Plugins calling lgetexpr are now all of a sudden calling
> > autocmds from unrelated plugins.
> >
> > As Christian Brabandt points out, this can be prevented by
> > doing something like "noautocmd lgetexpr ...", and thus fixing
> > something that was never broken. Or it can be prevented by adding
> > a more restrictive pattern in autocmd QuickFixCmd, and thus
> > avoiding a pitfall that didn't exist before 7.4.2299. _shrug_
>
> I would say that you have just been lucky that the way the quickfix
> list was created didn't trigger an autocommand. These Ferret
> autocommands just do what they are supposed to do: open a quickfix
> window when there is a quickfix list. And syntastic creates a
> quickfix list, thus it works as intended.
These Ferret autocommands shouldn't mess with quickfix lists created
by other plugins. Sadly, the QuickFixCmd* autocommands have no way
to tell what created the lists they act on, nor is there any way for
applications to pass them this information. Recent versions might use
the new title field for that purpose, but that feature is only a few
weeks old, it can't be relied on for the next year or so.
> Why is it that the quickfix list that syntastic creates must not be in
> a quickfix window?
Because it's just an intermediate result that needs to be massaged
before it can be usefully displayed. Some linters produce simple-minded
error messages:
foo.c:33:7: Error: "bar" not found, oh what to do, what to do!
These messages can be parsed with a single line of errorformat,
and everybody lives happily ever after. Other linters however are a
lot more creative than that. For example they might produce 0-based
line numbers while Vim wants them 1-based, so the numbers need to be
adjusted. Line numbers might point beyond the file's end, and they also
need to be adjusted. Messages might have a different encoding than the
current one (hello, Haskell) and they need to be converted. They might
contain XML entities that need to be decoded. Invalid errors need to be
purged. Some other errors need to be removed because the user doesn't
care to see them. The list might need to be re-sorted. Other things
might need to be normalised, fixed, or otherwise transmogrified. And so
on, and so forth. The bottom line is, the result of :lgetexpr is not
directly usable, it needs to be processed first.
Unrelated, syntastic has a mode where it tries not to mess with the
current loclists, to minimise conflicts with third-party plugins. In
that mode the list is copied elsewhere and the original is discarded
with :lolder. It never displays the list in a window.
(On a side note: :lolder, :lnewer and friends still don't trigger
the QuickFixCmd* autocommands. I presume the very same people that
asked for :lgetexpr to trigger them will hurry to make a case for adding
autocommands to :lolder etc. too, in the name of further consistency.)
Normally :lgetexpr shouldn't be used for parsing error messages like
this. If Vim regexps had named subexpressions as other languages, all
the errorformat horrors could have been avoided and parsing would go
something like this:
while(<>) {
...
m/^(?[^:]+):(?\d+):(?\d+): (?[EW])(?:rror|arning):
(?.+)/;
...
}
This would be substantia
Re: Patch 7.4.2299
On 2 September 2016, Bram Moolenaar wrote:
>
> Lcd wrote:
>
> > On 1 September 2016, Bram Moolenaar wrote:
> > >
> > > Patch 7.4.2299 Problem: QuickFixCmdPre and QuickFixCmdPost
> > > autocommands are not always triggered. Solution: Also trigger
> > > on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan) Files:
> > > src/quickfix.c, src/testdir/test_quickfix.vim
> > [...]
> >
> > Sadly, this breaks the interaction of "syntastic" with all
> > plugins that hook to QuickFixCmdPre or QuickFixCmdPost. An example
> > of such plugin is "ferret". These plugins now have to be fixed to
> > be aware that they may be called from things like :lgetexpr. I'd
> > argue that running QuickFixCmd* for :lgetexpr makes little sense,
> > since :lgetexpr is almost never called run interactively. So, was
> > there an actual reason for this change, right before the release of
> > Vim 8?
>
> Can you give more details about what breaks? The autocommands are
> there to allow plugins to deal with changes in the Quickfix list. I
> hope it's not actually being used for something else.
As I said in another message, people do thinge like this:
if has('autocmd')
augroup Ferret
autocmd!
autocmd QuickFixCmdPost [^l]* nested cwindow
autocmd QuickFixCmdPost l* nested lwindow
augroup END
endif
This is fine for opening grep windows automatically and what not,
but the loclists created by things like lgetexpr are typically parsing
in progress, and are never meant to be displayed at that stage. Plugins
calling lgetexpr are now all of a sudden calling autocmds from unrelated
plugins.
As Christian Brabandt points out, this can be prevented by doing
something like "noautocmd lgetexpr ...", and thus fixing something that
was never broken. Or it can be prevented by adding a more restrictive
pattern in autocmd QuickFixCmd, and thus avoiding a pitfall that
didn't exist before 7.4.2299. _shrug_
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.2299
On 2 September 2016, Christian Brabandt wrote: > Hi LCD! > > On Fr, 02 Sep 2016, LCD 47 wrote: > > > On 2 September 2016, Ingo Karkat wrote: > > > On 09/02/2016 09:51 PM, LCD 47 wrote: > > > > On 1 September 2016, Bram Moolenaar wrote: > > > >> > > > >> Patch 7.4.2299 Problem: QuickFixCmdPre and QuickFixCmdPost > > > >> autocommands are not always triggered. Solution: Also trigger > > > >> on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan) Files: > > > >> src/quickfix.c, src/testdir/test_quickfix.vim > > > > [...] > > > > > > > > Sadly, this breaks the interaction of "syntastic" with all > > > > plugins that hook to QuickFixCmdPre or QuickFixCmdPost. An > > > > example of such plugin is "ferret". These plugins now have to > > > > be fixed to be aware that they may be called from things like > > > > :lgetexpr. I'd argue that running QuickFixCmd* for :lgetexpr > > > > makes little sense, since :lgetexpr is almost never called run > > > > interactively. So, was there an actual reason for this change, > > > > right before the release of Vim 8? > > > > > > I use the QuickFixCmdPre/Post to automatically open / adapt the > > > size of / close the quickfix window, and therefore appreciate that > > > all quickfix-manipulating commands are covered. > > > > > > The fix of Syntastic should be pretty easy, as one can use the > > > autocmd pattern to exclude [cl]getexpr, right? > > > > Syntastic is at the receiving end of this game, it just runs > > :lgetexpr. All of a sudden :lgetexpr now triggers autocmds in other > > plugins, and there isn't anything syntastic can do about that. Said > > plugins need to become aware of the new scope of their harmless > > little autocmds, become aware that they are now called from > > other plugins' code, and fix the calls, as you say, to exclude > > [cl]getexpr. I'm sure they are all going to be fixed in no time. :) > > Hm, can't you call noa lgetexpr ... ? Hmm, I wasn't aware of :noautocmd. Thank you so much, this does provide a workaround for syntastic. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.2299
On 2 September 2016, LCD 47 wrote:
> On 2 September 2016, Ingo Karkat wrote:
> > On 09/02/2016 09:51 PM, LCD 47 wrote:
> > > On 1 September 2016, Bram Moolenaar wrote:
> > >>
> > >> Patch 7.4.2299 Problem: QuickFixCmdPre and QuickFixCmdPost
> > >> autocommands are not always triggered. Solution: Also trigger
> > >> on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan) Files:
> > >> src/quickfix.c, src/testdir/test_quickfix.vim
> > > [...]
> > >
> > > Sadly, this breaks the interaction of "syntastic" with all
> > > plugins that hook to QuickFixCmdPre or QuickFixCmdPost. An
> > > example of such plugin is "ferret". These plugins now have to
> > > be fixed to be aware that they may be called from things like
> > > :lgetexpr. I'd argue that running QuickFixCmd* for :lgetexpr
> > > makes little sense, since :lgetexpr is almost never called run
> > > interactively. So, was there an actual reason for this change,
> > > right before the release of Vim 8?
> >
> > I use the QuickFixCmdPre/Post to automatically open / adapt the size
> > of / close the quickfix window, and therefore appreciate that all
> > quickfix-manipulating commands are covered.
> >
> > The fix of Syntastic should be pretty easy, as one can use the
> > autocmd pattern to exclude [cl]getexpr, right?
>
> Syntastic is at the receiving end of this game, it just runs
> :lgetexpr. All of a sudden :lgetexpr now triggers autocmds in other
> plugins, and there isn't anything syntastic can do about that. Said
> plugins need to become aware of the new scope of their harmless little
> autocmds, become aware that they are now called from other plugins'
> code, and fix the calls, as you say, to exclude [cl]getexpr. I'm sure
> they are all going to be fixed in no time. :)
An example: ferret does this:
if has('autocmd')
augroup Ferret
autocmd!
autocmd QuickFixCmdPost [^l]* nested cwindow
autocmd QuickFixCmdPost l* nested lwindow
augroup END
endif
There are people recommending this setting on StackOverflow and
friends, presumably because the point of quicklfix lists is to be
opened, so this is probably a pretty popular setting by now. In the
mean time, "syntastic no longer works under Vim 8".
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.2299
On 2 September 2016, Ingo Karkat wrote: > On 09/02/2016 09:51 PM, LCD 47 wrote: > > On 1 September 2016, Bram Moolenaar wrote: > >> > >> Patch 7.4.2299 Problem: QuickFixCmdPre and QuickFixCmdPost > >> autocommands are not always triggered. Solution: Also trigger > >> on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan) Files: > >> src/quickfix.c, src/testdir/test_quickfix.vim > > [...] > > > > Sadly, this breaks the interaction of "syntastic" with all > > plugins that hook to QuickFixCmdPre or QuickFixCmdPost. An example > > of such plugin is "ferret". These plugins now have to be fixed to > > be aware that they may be called from things like :lgetexpr. I'd > > argue that running QuickFixCmd* for :lgetexpr makes little sense, > > since :lgetexpr is almost never called run interactively. So, was > > there an actual reason for this change, right before the release of > > Vim 8? > > I use the QuickFixCmdPre/Post to automatically open / adapt the size > of / close the quickfix window, and therefore appreciate that all > quickfix-manipulating commands are covered. > > The fix of Syntastic should be pretty easy, as one can use the autocmd > pattern to exclude [cl]getexpr, right? Syntastic is at the receiving end of this game, it just runs :lgetexpr. All of a sudden :lgetexpr now triggers autocmds in other plugins, and there isn't anything syntastic can do about that. Said plugins need to become aware of the new scope of their harmless little autocmds, become aware that they are now called from other plugins' code, and fix the calls, as you say, to exclude [cl]getexpr. I'm sure they are all going to be fixed in no time. :) /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.2299
On 1 September 2016, Bram Moolenaar wrote: > > Patch 7.4.2299 > Problem:QuickFixCmdPre and QuickFixCmdPost autocommands are not always > triggered. > Solution: Also trigger on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan) > Files: src/quickfix.c, src/testdir/test_quickfix.vim [...] Sadly, this breaks the interaction of "syntastic" with all plugins that hook to QuickFixCmdPre or QuickFixCmdPost. An example of such plugin is "ferret". These plugins now have to be fixed to be aware that they may be called from things like :lgetexpr. I'd argue that running QuickFixCmd* for :lgetexpr makes little sense, since :lgetexpr is almost never called run interactively. So, was there an actual reason for this change, right before the release of Vim 8? /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Of bufnr() and other demons
On 2 September 2016, Justin M. Keyes wrote:
> On Thu, Sep 1, 2016 at 4:20 PM, LCD 47 wrote:
> > On 1 September 2016, Nikolay Aleksandrovich Pavlov
> > wrote:
> >> 2016-09-01 15:47 GMT+03:00 LCD 47 :
> >> > What is the recommended way to get the buffer number of a file
> >> > starting from the filename?
> >> >
> > [...]
> >> > Based on the above (and taking a peek at the sources), I came up
> >> > with this attempt:
> >> >
> >> > function! Name2Buf(fname) abort
> >> > if exists('+shellslash')
> >> > let old_shellslash = &shellslash
> >> > let &shellslash = 1
> >> > let buf = bufnr(escape( fnamemodify(a:fname, ':p'),
> >> > '\*?,{}[' ))
> >> > let &shellslash = old_shellslash
> >> > else
> >> > let buf = bufnr(escape( fnamemodify(a:fname, ':p'),
> >> > '\*?,{}[' ))
> >> > endif
> >> >
> >> > return buf
> >> > endfunction
> >> >
> >> > It mostly works, until I try it on a file named a,b\{2,3\}.txt:
> >> >
> >> > :echo expand('%:p')
> >> > /home/lcd047/tmp/a,b\{3.4}.txt
> >> >
> >> > :Name2Buf(expand('%:p'))
> >> > -1
> >> >
> >> > However the naive bufnr(expand('%:p')) works, but it shouldn't,
> >> > because of the two commas ",":
> >> >
> >> > echomsg bufnr(expand('%:p'))
> >> > 1
> >> >
> >> > So, what _is_ the right way to do this?
> >>
> >> I would go with `fnameescape()`, but this does not work with your
> >> file name either. Additional problem is that `fnameescape()` does
> >> not work correctly on Windows.
> >
> > fnameescape() is definitely wrong here, it escapes characters
> > that have nothing to do with the "file-pattern" set (f.i. '%' and
> > '#'). Looking at the code, the "bad" characters are a mixture of
> > glob characters with regexp characters. I don't think it's possible
> > to disarm them all with a simple escape(). I wonder why it's
> > possible to do all those weird globbing in bufnr() (does anybody
> > actually use them?), but it isn't possible to do an exact string
> > match.
>
> I use basic regex with bufnr(), to *avoid* bufnr() useless magic:
>
> https://github.com/justinmk/vim-dirvish/blob/master/autoload/dirvish.vim#L306-L330
Sadly the "^ ... $" pattern still fails for a,b\{3.4}.txt:
:echo expand('%:p')
/home/lcd047/tmp/a,b\{3.4}.txt
:echo bufnr('^' . expand('%:p') . '$')
-1
But it succeeds without the anchors:
:echo bufnr(expand('%:p'))
1
> It seems to me that long ago the decision should have been to only
> have "magic" in _commands_, not functions. Plugin authors (and
> vimrc authors) usually do not want user-configured behavior, it is
> a headache. E.g. there is zero reason that substitute() should care
> about any global option. For typical editing one invokes :substitute,
> not substitute().
Absolutely, this is a long-time gripe of mine, too. Among other
things, all regexps in scripts have to be littered with "\m" or "\v",
because somebody, somewhere (presumably under a heavy rock), _might_
be running with "set nomagic". And it goes only half way in the other
direction too, since there is no such thing as "set verymagic", for
those of us that aren't so fond of ye olde BRE syntax.
> This sort of inconsistency was not "inherited from Vi", since
> FEAT_EVAL was not in Vi.
Sadly it's still 20+ years too late to fix now.
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Of bufnr() and other demons
On 1 September 2016, Nikolay Aleksandrovich Pavlov
wrote:
> 2016-09-01 15:47 GMT+03:00 LCD 47 :
> > What is the recommended way to get the buffer number of a file
> > starting from the filename?
> >
[...]
> > Based on the above (and taking a peek at the sources), I came up
> > with this attempt:
> >
> > function! Name2Buf(fname) abort
> > if exists('+shellslash')
> > let old_shellslash = &shellslash
> > let &shellslash = 1
> > let buf = bufnr(escape( fnamemodify(a:fname, ':p'),
> > '\*?,{}[' ))
> > let &shellslash = old_shellslash
> > else
> > let buf = bufnr(escape( fnamemodify(a:fname, ':p'),
> > '\*?,{}[' ))
> > endif
> >
> > return buf
> > endfunction
> >
> > It mostly works, until I try it on a file named a,b\{2,3\}.txt:
> >
> > :echo expand('%:p')
> > /home/lcd047/tmp/a,b\{3.4}.txt
> >
> > :Name2Buf(expand('%:p'))
> > -1
> >
> > However the naive bufnr(expand('%:p')) works, but it shouldn't,
> > because of the two commas ",":
> >
> > echomsg bufnr(expand('%:p'))
> > 1
> >
> > So, what _is_ the right way to do this?
>
> I would go with `fnameescape()`, but this does not work with your file
> name either. Additional problem is that `fnameescape()` does not work
> correctly on Windows.
fnameescape() is definitely wrong here, it escapes characters
that have nothing to do with the "file-pattern" set (f.i. '%' and
'#'). Looking at the code, the "bad" characters are a mixture of glob
characters with regexp characters. I don't think it's possible to
disarm them all with a simple escape(). I wonder why it's possible
to do all those weird globbing in bufnr() (does anybody actually use
them?), but it isn't possible to do an exact string match.
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Of bufnr() and other demons
What is the recommended way to get the buffer number of a file
starting from the filename?
This is what the help has to say about bufnr():
: bufnr({expr} [, {create}])
: The result is the number of a buffer, as it is displayed by
: the ":ls" command. For the use of {expr}, see |bufname()|
: above.
The help for bufname() explains:
: If {expr} is a String, it is used as a |file-pattern| to match
: with the buffer names. This is always done like 'magic' is
: set and 'cpoptions' is empty. When there is more than one
: match an empty string is returned.
: "" or "%" can be used for the current buffer, "#" for the
: alternate buffer.
: A full match is preferred, otherwise a match at the start, end
: or middle of the buffer name is accepted. If you only want a
: full match then put "^" at the start and "$" at the end of the
: pattern.
: Listed buffers are found first. If there is a single match
: with a listed buffer, that one is returned. Next unlisted
: buffers are searched for.
And then the help for file-pattern:
: *file-pattern*
: The pattern is interpreted like mostly used in file names:
: * matches any sequence of characters; Unusual: includes path
: separators
: ? matches any single character
: \? matches a '?'
: . matches a '.'
: ~ matches a '~'
: , separates patterns
: \, matches a ','
: { } like \( \) in a |pattern|
: , inside { }: like \| in a |pattern|
: \} literal }
: \{ literal {
: \\\{n,m\} like \{n,m} in a |pattern|
: \ special meaning like in a |pattern|
: [ch]matches 'c' or 'h'
: [^ch] match any character but 'c' and 'h'
:
: Note that for all systems the '/' character is used for path separator (even
: MS-DOS and OS/2). This was done because the backslash is difficult to use
: in a pattern and to make the autocommands portable across different systems.
Based on the above (and taking a peek at the sources), I came up
with this attempt:
function! Name2Buf(fname) abort
if exists('+shellslash')
let old_shellslash = &shellslash
let &shellslash = 1
let buf = bufnr(escape( fnamemodify(a:fname, ':p'), '\*?,{}[' ))
let &shellslash = old_shellslash
else
let buf = bufnr(escape( fnamemodify(a:fname, ':p'), '\*?,{}[' ))
endif
return buf
endfunction
It mostly works, until I try it on a file named a,b\{2,3\}.txt:
:echo expand('%:p')
/home/lcd047/tmp/a,b\{3.4}.txt
:Name2Buf(expand('%:p'))
-1
However the naive bufnr(expand('%:p')) works, but it shouldn't,
because of the two commas ",":
echomsg bufnr(expand('%:p'))
1
So, what _is_ the right way to do this?
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
On 18 August 2016, Luc Hermitte wrote: > > On 18 August 2016, Luc Hermitte wrote: > > > Another point on the qflist topic is bugging me. IIRC, when an > > > error is detected, the type flag is set to 'E'. But how is error > > > detection done? Is it when the message 'error:' is detected? What > > > about when the locale is in another language like 'fr_FR'? In > > > this case, the error messages start with "erreur: ", warnings with > > > "attention: ". I guess similar issues may happen in all other > > > languages. > > > > > > Has anybody an idea how to solve error/warning detection when the > > > system is not in English? (My ultimate objective is to fill the > > > error and message counters displayed by the airline plugin in the > > > qf window status line) > > > > Set LC_MESSAGES to C before running your program: > > > > https://goo.gl/tMPUdV > > > > Less than ideal, but it makes parsing possible. > > Of course, I'm aware of this solution -- which I use regularly as I > can't stand the translation of compilation errors. > > What I was hoping, is a end-user friendly solution: one that implies > as few tweaks as possible to fully take advantage of my plugin. Well, let me put it like this: (1) To parse something you need to make assumptions about the syntax of the text you're trying to parse; (2) Translations break most (if not all) assumptions about the syntax of the translated text. You could, of course, try to "undo" the translation before parsing error messages, perhaps based on the .po files of the application producing the errors. This would stand some chances to work for applications that create error through a centralized set of functions, and would break horribly for applications that produce ad-hoc errors. And then there are exceptions, and stack traces from third-party libraries. But if you manage to do it, it would be user-friendly. :) /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
On 18 August 2016, Luc Hermitte wrote: > Another point on the qflist topic is bugging me. IIRC, when an error > is detected, the type flag is set to 'E'. But how is error detection > done? Is it when the message 'error:' is detected? What about when the > locale is in another language like 'fr_FR'? In this case, the error > messages start with "erreur: ", warnings with "attention: ". I guess > similar issues may happen in all other languages. > > Has anybody an idea how to solve error/warning detection when the > system is not in English? (My ultimate objective is to fill the error > and message counters displayed by the airline plugin in the qf window > status line) Set LC_MESSAGES to C before running your program: https://goo.gl/tMPUdV Less than ideal, but it makes parsing possible. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
On 17 August 2016, Yegappan Lakshmanan wrote: > Hi, > > On Wed, Aug 17, 2016 at 1:48 AM, LCD 47 wrote: > > On 16 August 2016, Yegappan Lakshmanan wrote: > >> I am in particular interested in any comments/suggestions about the > >> following new functions: [...] > >> getqflist() > > > > The manual could use some rephrasing. As it is, it sounds > > unnatural even to my broken English. > > > > Any particular text in the help that is confusing? [...] I didn't say it was confusing. Not trying to nitpick, but take f.i. these two phrases: : When there is no error list or it's empty an empty list is : returned. Quickfix list entries with non-existing buffer : number are returned with "bufnr" set to zero. The rest of the entry doesn't seem substantially better, either. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
On 16 August 2016, Yegappan Lakshmanan wrote:
> I am in particular interested in any comments/suggestions about the following
> new functions:
>
> getbufinfo()
From the manual:
: Each returned List item is a dictionary with the following
: entries:
: changed TRUE if the buffer is modified.
: changedtick number of changes made to the buffer.
: hidden TRUE if the buffer is hidden.
: listed TRUE if the buffer is listed.
: lnumcurrent line number in buffer.
: loaded TRUE if the buffer is loaded.
: namefull path to the file in the buffer.
: nr buffer number.
: options dictionary of buffer local options.
: signs list of signs placed in the buffer.
: Each list item is a dictionary with
: the following fields:
: idsign identifier
: lnum line number
: name sign name
: variables dictionary of buffer local variables.
: windows list of window IDs with this buffer
"options", "signs", and "variables" return lists that are potentially
huge. Perhaps there should be a way to tell getbufinfo() to skip these lists;
otherwise plugins would just avoid calling this function, for performance
reasons.
On the other hand, finding the number of lines in a buffer as "line('$')"
is very inefficient, so maybe this would be a good place to return it. But
again, as an option, since it would involve loading the buffer.
> gettabinfo()
> getwininfo()
From the manual:
: Each List item is a Dictionary with the following entries:
: bufnum number of buffer in the window
: height window height
: loclist 1 if showing a location list
: {only with the +quickfix feature}
: nr window number
: options dictionary of window local options
: quickfix1 if quickfix or location list window
: {only with the +quickfix feature}
: tpnrtab page number
: variables dictionary of window local variables
: width window width
: winid window ID
Perhaps "tpnr" should be renamed to something more suggestive, such as
"tabnr"?
> getqflist()
The manual could use some rephrasing. As it is, it sounds unnatural even
to my broken Engrish.
> setqflist()
> getcompletion()
Again, getcompletion() can return some potentially huge lists. Being able
to restrict results to smaller subsets could make this function a lot lighter.
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Quickfix List vs Location List
On 8 August 2016, Kent Sibilev wrote:
> On Monday, August 8, 2016 at 4:03:22 AM UTC-4, LCD 47 wrote:
>
> >
> > Wait, isn't the title already supposed to tell you that?
> >
>
> What do you mean by title?
From the manual (":h :copen"):
: The window will have the w:quickfix_title variable set
: which will indicate the command that produced the
: quickfix list. This can be used to compose a custom
: status line if the value of 'statusline' is adjusted
: properly.
By default the status line of the quickfix open shows "[Quickfix
List]" or "[Location List]", followed by the w:quickfix_title variable
described above. Some of the plugins that customize status lines choose
to ignore that information. I don't think this is something that needs
to be fixed in Vim.
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Quickfix List vs Location List
On 7 August 2016, Kent Sibilev wrote:
> On Saturday, August 6, 2016 at 1:02:18 PM UTC-4, Bram Moolenaar wrote:
> >
> > The problem with this solution is that the names are translated. A
> > more direct solution would be better.
> >
> > The 'buftype' option is "quickfix" for both quickfix and location
> > list. We can't change that without causing problems.
> >
> > Perhaps we should add a buftype({expr}) function, that can get the
> > buffer type of any buffer, and make a difference between "quickfix"
> > and "loclist".
>
> I see. Even though it's quite awkward to add a new function just
> to accommodate this particular case, i'm attaching my attempt to
> implement it.
Wait, isn't the title already supposed to tell you that?
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: quickfix information
On 27 July 2016, Yegappan Lakshmanan wrote:
> Hi,
>
> On Tue, Jul 26, 2016 at 10:15 PM, LCD 47 wrote:
> > On 26 July 2016, Bram Moolenaar wrote:
> >>
> >> Lcd wrote:
> >>
> >> > On 25 July 2016, Yegappan Lakshmanan wrote:
> >> > > Hi,
> >> > >
> >> > > On Mon, Jul 25, 2016 at 12:27 AM, LCD 47 wrote:
> >> > > > On 24 July 2016, Yegappan Lakshmanan
> >> > > > wrote:
> >> > > >> I am attaching a patch to enhance the getqflist/getloclist()
> >> > > >> functions to return the title string and the
> >> > > >> setqflist()/setloclist() functions to set the title string.
> >> > > >>
> >> > > >> After this patch is incorporated, it will be easy to add the
> >> > > >> additional items (e.g. context, items, number, stack, etc.).
> >> > > >>
> >> > > >> The getqflist/setqflist functions now accept an optional
> >> > > >> dictionary parameter. The dictionary parameter specifies
> >> > > >> which items to get or set. If the {dict} argument is
> >> > > >> specified, then the getqflist function returns a dictionary.
> >> > > >
> >> > > > Why a dictionary (where values are ignored), rather than
> >> > > > a list, or a string of, say, comma-separated names? Or both?
> >> > > >
> >> > >
> >> > > This is to be consistent between the getqflist()/getloclist()
> >> > > and the setqflist()/setloclist() functions. In the setqflist()
> >> > > function, the value of a dictionary key specifies the value
> >> > > to set. In the getqflist() function, it specifies the value
> >> > > to return. For example, the following call sets the quickfix
> >> > > title:
> >> > >
> >> > > call setqflist([], 'a', {'title' : 'example'})
> >> > >
> >> > > The following call returns the quickfix title:
> >> > >
> >> > > call getqflist({'title' : 1})
> >> >
> >> > The arguments of setqflist() are already different from those
> >> > of getqflist(), so why does an extra argument has to be the same?
> >> > Why not something like this:
> >> >
> >> > call getqflist('title,context,nr')
> >> > or
> >> > call getqflist(['title', 'context', 'nr'])
> >> >
> >> > vs.
> >> >
> >> > call setqflist(errors, 'r',
> >> > \ { 'title': 'My preciousss', 'context': ctx, 'nr': -1 })
> >> >
> >> > (BTW, { 'nr': -1 } could mean last).
> >>
> >> Although we can probably do a lot with a list of strings, there
> >> is a tendency for builtin-functions to use a dictionary to
> >> pass optional extra argumens through a dict. A list can only
> >> use "present" flags, a dictionary can also use values for the
> >> arguments.
> >
> > So basically you want all plugins daring enough to use the new
> > features to carry along dicts with useless values, just because some
> > of these values might become useful at some unspecified point in the
> > future? Vim can nicely deal with changing the type of an argument,
> > so why not use lists for now, and add dict arguments when and if
> > there is an actual use for those?
> >
>
> I did make the changes to use a list argument for the getqflist()
> function. Then realized that with a list, you cannot specify the
> quickfix list number (to pick a specific list in the stack). With a
> dict, you can modify a specific quickfix list in the stack.
After pondering about this for a while, I believe the stack pointer
is the only one that needs a value in both getqflist() and setqflist(),
so you could in principle encode it as simply a number. That is, a
number in the list would refer to the stack pointer, as opposed to the
other names that would be alphabetic. But that would be even worse than
having a dict with dummy values. So yes, this is probably a good reason
for using dicts.
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: quickfix information
On 26 July 2016, Bram Moolenaar wrote:
>
> Lcd wrote:
>
> > On 25 July 2016, Yegappan Lakshmanan wrote:
> > > Hi,
> > >
> > > On Mon, Jul 25, 2016 at 12:27 AM, LCD 47 wrote:
> > > > On 24 July 2016, Yegappan Lakshmanan
> > > > wrote:
> > > >> I am attaching a patch to enhance the getqflist/getloclist()
> > > >> functions to return the title string and the
> > > >> setqflist()/setloclist() functions to set the title string.
> > > >>
> > > >> After this patch is incorporated, it will be easy to add the
> > > >> additional items (e.g. context, items, number, stack, etc.).
> > > >>
> > > >> The getqflist/setqflist functions now accept an optional
> > > >> dictionary parameter. The dictionary parameter specifies which
> > > >> items to get or set. If the {dict} argument is specified, then
> > > >> the getqflist function returns a dictionary.
> > > >
> > > > Why a dictionary (where values are ignored), rather than a
> > > > list, or a string of, say, comma-separated names? Or both?
> > > >
> > >
> > > This is to be consistent between the getqflist()/getloclist()
> > > and the setqflist()/setloclist() functions. In the setqflist()
> > > function, the value of a dictionary key specifies the value to
> > > set. In the getqflist() function, it specifies the value to
> > > return. For example, the following call sets the quickfix title:
> > >
> > > call setqflist([], 'a', {'title' : 'example'})
> > >
> > > The following call returns the quickfix title:
> > >
> > > call getqflist({'title' : 1})
> >
> > The arguments of setqflist() are already different from those of
> > getqflist(), so why does an extra argument has to be the same? Why
> > not something like this:
> >
> > call getqflist('title,context,nr')
> > or
> > call getqflist(['title', 'context', 'nr'])
> >
> > vs.
> >
> > call setqflist(errors, 'r',
> > \ { 'title': 'My preciousss', 'context': ctx, 'nr': -1 })
> >
> > (BTW, { 'nr': -1 } could mean last).
>
> Although we can probably do a lot with a list of strings, there is a
> tendency for builtin-functions to use a dictionary to pass optional
> extra argumens through a dict. A list can only use "present" flags, a
> dictionary can also use values for the arguments.
So basically you want all plugins daring enough to use the new
features to carry along dicts with useless values, just because some
of these values might become useful at some unspecified point in the
future? Vim can nicely deal with changing the type of an argument, so
why not use lists for now, and add dict arguments when and if there is
an actual use for those?
> Usually the argument dicts are short: {'title': 1}. If they do get
> long and all the values are one, you could use a list and turn it into
> a dict. Hmm, we don't have a function for that...
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: quickfix information
On 25 July 2016, Yegappan Lakshmanan wrote:
> Hi,
>
> On Mon, Jul 25, 2016 at 12:27 AM, LCD 47 wrote:
> > On 24 July 2016, Yegappan Lakshmanan wrote:
> >> I am attaching a patch to enhance the getqflist/getloclist()
> >> functions to return the title string and the
> >> setqflist()/setloclist() functions to set the title string.
> >>
> >> After this patch is incorporated, it will be easy to add the
> >> additional items (e.g. context, items, number, stack, etc.).
> >>
> >> The getqflist/setqflist functions now accept an optional dictionary
> >> parameter. The dictionary parameter specifies which items to get
> >> or set. If the {dict} argument is specified, then the getqflist
> >> function returns a dictionary.
> >
> > Why a dictionary (where values are ignored), rather than a list,
> > or a string of, say, comma-separated names? Or both?
> >
>
> This is to be consistent between the getqflist()/getloclist() and
> the setqflist()/setloclist() functions. In the setqflist() function,
> the value of a dictionary key specifies the value to set. In the
> getqflist() function, it specifies the value to return. For example,
> the following call sets the quickfix title:
>
> call setqflist([], 'a', {'title' : 'example'})
>
> The following call returns the quickfix title:
>
> call getqflist({'title' : 1})
The arguments of setqflist() are already different from those of
getqflist(), so why does an extra argument has to be the same? Why not
something like this:
call getqflist('title,context,nr')
or
call getqflist(['title', 'context', 'nr'])
vs.
call setqflist(errors, 'r',
\ { 'title': 'My preciousss', 'context': ctx, 'nr': -1 })
(BTW, { 'nr': -1 } could mean last).
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: quickfix information
On 24 July 2016, Yegappan Lakshmanan wrote:
> I am attaching a patch to enhance the getqflist/getloclist() functions
> to return the title string and the setqflist()/setloclist() functions
> to set the title string.
>
> After this patch is incorporated, it will be easy to add the
> additional items (e.g. context, items, number, stack, etc.).
>
> The getqflist/setqflist functions now accept an optional dictionary
> parameter. The dictionary parameter specifies which items to get or
> set. If the {dict} argument is specified, then the getqflist function
> returns a dictionary.
Why a dictionary (where values are ignored), rather than a list, or
a string of, say, comma-separated names? Or both?
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: quickfix information
On 17 July 2016, Yegappan Lakshmanan wrote: > Hi, > > On Sun, Jul 17, 2016 at 10:00 PM, LCD 47 wrote: > > On 17 July 2016, Yegappan Lakshmanan wrote: > >> Hi, > >> > >> On Mon, Apr 13, 2015 at 5:04 AM, wrote: > >> > Hello, > >> > > >> > I did not expect that many reactions. This is nice. Thank you > >> > all for your interest in the matter. > >> > > >> >> > Ah, but as long as you are OK with that information showing up > >> >> > in the title, if you can set w:quickfix_title to an arbitrary > >> >> > string, then you *can* store arbitrary data associated with a > >> >> > given quickfix list. > >> >> > >> >> Being able to save "ancillary" data in quickfix lists / > >> >> loclists as the OP suggests would be quite useful too. Then > >> >> w:quickfix_title could be saved there, and that would be easier > >> >> to implement than keeping track of updates to w:quickfix_title. > >> > > >> > Indeed, having "ancillary" data would be much more easier to > >> > use. Storing several variables in the w:quickfix_title wouldn't > >> > very practical. Actually, I want to export several buffer-local > >> > variables to the quickfix buffer. I use some of them to conceal > >> > part of the generated error messages, other like &l:tags are > >> > required to be able to jump on definition/declaration from > >> > identifiers found in the error messages, &l:makeprg will be > >> > needed in order to have > >> > :make compile the same thing, others variables (like project and > >> > compilation mode) will be displayed in the status(air)line, etc. > >> > > >> > Moreover, I've experienced some odd behaviours regarding the > >> > w:quickfix_title -- as it's automatically set to things like > >> > "setqflist()". > >> > > >> > [I can't really comment on the other internal ways of handling > >> > quickfix data] > >> > > >> > Thus, I take notice so far that there is no neat way to store > >> > variables along with a quickfix list. An optional data field > >> > would do the trick. I guess it would be more expensive than what > >> > I need, but it would do the trick. > >> > > >> > Thank you all anyway. > >> > > >> > I'll try to override the meaning of "nr" field for my needs. > >> > > >> > >> I am attaching a patch to add the following functions to store and > >> retrieve a context from a location/quickfix list: > >> > >> setqflistctx() > >> getqflistctx() > >> setloclistctx() > >> getloclistctx() > >> > >> The context can be any Vim variable type. > >> > >> The patch also adds the following functions to set/get the title > >> string: > >> > >> setqflisttitle() > >> getqflisttitle() > >> setloclisttitle() > >> getloclisttitle() > >> > >> Let me know if you have any comments/suggestions on these > >> functions. > > > > Since you ask: in my opinion this is designed from the > > perspective of a Vim's patcher, not from that of a Vim's user. The > > "ancillary" data should be a special field in the location/quickfix > > list, and it should be accessible as such, not through special > > getters and setters. > > > > The 'ancillary' data is a special field in the internal > location/quickfix list. > > Are you looking for setting the context using the setqflist() and > setloclist() functions? These functions can be extended to take the > context. > > But it will be difficult to extend the getqflist() function to return > the context though. The getqflist() function currently returns a list. > I am not sure how to extend this function to return the entries and > context without breaking backward compatibility. I believe this has been discussed in some detail in the past. There are two kinds of ancillary data that would be useful, a per-item extra field, and a per-list variable (what you call "context"). In my experience the per-item version would be far more useful than the per-list one, but it would be tricky to implement since it would turn a list (the location/quickfix list) into a sort of mixture between a list and a dictionary (per-item data would need reference counts and so o
Re: quickfix information
On 17 July 2016, Yegappan Lakshmanan wrote: > Hi, > > On Mon, Apr 13, 2015 at 5:04 AM, wrote: > > Hello, > > > > I did not expect that many reactions. This is nice. Thank you all > > for your interest in the matter. > > > >> > Ah, but as long as you are OK with that information showing up > >> > in the title, if you can set w:quickfix_title to an arbitrary > >> > string, then you *can* store arbitrary data associated with a > >> > given quickfix list. > >> > >> Being able to save "ancillary" data in quickfix lists / loclists as > >> the OP suggests would be quite useful too. Then w:quickfix_title > >> could be saved there, and that would be easier to implement than > >> keeping track of updates to w:quickfix_title. > > > > Indeed, having "ancillary" data would be much more easier to > > use. Storing several variables in the w:quickfix_title wouldn't > > very practical. Actually, I want to export several buffer-local > > variables to the quickfix buffer. I use some of them to conceal part > > of the generated error messages, other like &l:tags are required to > > be able to jump on definition/declaration from identifiers found > > in the error messages, &l:makeprg will be needed in order to have > > :make compile the same thing, others variables (like project and > > compilation mode) will be displayed in the status(air)line, etc. > > > > Moreover, I've experienced some odd behaviours regarding the > > w:quickfix_title -- as it's automatically set to things like > > "setqflist()". > > > > [I can't really comment on the other internal ways of handling > > quickfix data] > > > > Thus, I take notice so far that there is no neat way to store > > variables along with a quickfix list. An optional data field would > > do the trick. I guess it would be more expensive than what I need, > > but it would do the trick. > > > > Thank you all anyway. > > > > I'll try to override the meaning of "nr" field for my needs. > > > > I am attaching a patch to add the following functions to store and > retrieve a context from a location/quickfix list: > > setqflistctx() > getqflistctx() > setloclistctx() > getloclistctx() > > The context can be any Vim variable type. > > The patch also adds the following functions to set/get the title > string: > > setqflisttitle() > getqflisttitle() > setloclisttitle() > getloclisttitle() > > Let me know if you have any comments/suggestions on these functions. Since you ask: in my opinion this is designed from the perspective of a Vim's patcher, not from that of a Vim's user. The "ancillary" data should be a special field in the location/quickfix list, and it should be accessible as such, not through special getters and setters. Having to access the data through getters and setters reminds me of code for embedded appliances, where in order to set a variable to a 16-bits integer you need to write the first 12 bits in machine order to port 25, and the last 3 bits in big endian order to port 31. It works, sort of, but it's a pain for the user, and it makes Java code look concise. > I will add the tests for these functions later. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
":" in &iskeyword for VimL
Is there any particular reason for not including colons ":" in &iskeyword for VimL? The current default makes it impossible to jump to definitions of file-scoped functions and variables. Common ctags implementations produce tags like this: s:diff_ms autoload/peekaboo.vim /^function! s:diff_ms(since)$/;" f s:peekaboo autoload/peekaboo.vim /^let s:peekaboo = 0$/;"v But these tag can't be "seen" by Ctrl-t because &iskeyword doesn't include ":". /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim function argument default value
On 13 July 2016, Yang Luo wrote:
>
> I write a function like this:
> function InsertNumber(start, end, step)
>
> let i = a:start
>
> let curr_line = 0
>
> while i <= a:end
> if a:step <= 0
> echo "Error: step cannot <=0."
> break
> endif
>
> call append(curr_line, i)
>
> let i += a:step
>
> let curr_line += 1
>
> endwhile
> endfunction
>
>
> when I call this function, I type this:
> :echo InsertNumber(8,10,1)
> 8
> 9
> 10
>
>
> 1) How can I give arguement "step" a default value(eg: 1) when define the
> function?
> like a C function:
> void C_func(int a, int b_have_default_val = 1)
> {
>
> ;
> }
Use optional arguments:
function! InsertNumber(start, end, ...)
let step = a:0 > 0 ? a:1 : 1
...
endfunction
> 2)
> I want to print number like this, how to do it?
> 08
> 09
> 10
call append(curr_line, printf("%02d", i))
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Using file name with quickfix commands
On 10 July 2016, Bram Moolenaar wrote:
>
> Lcd wrote:
>
[...]
> > Currently an error item from loclist looks like this:
> >
> > {
> > 'lnum': 148,
> > 'bufnr': 1,
> > 'col': 7,
> > 'valid': 1,
> > 'vcol': 0,
> > 'nr': -1,
> > 'type': 'W',
> > 'pattern': ',
> > 'text': '(3) CodeLayout::ProhibitHardTabs: Hard tabs used (See
> > page 20 of PBP)'
> > }
> >
> > If I want to place a sign at the file, I can do this:
> >
> > sign place 12345 line=148 name=SyntasticError buffer=1
> >
> > This works regardless if the fuffer is hidden or not, and can be
> > done before the user jumps to the error.
> >
> > How would I do the same starting only with a filename, assuming
> > the user hasn't jumped to the error yet, or opened the file?
>
> Yeah, when using getqflist() or getloclist() we currently only get the
> "bufnr". This I would think, by default the file name is changed to
> a buffer at that point. Since this can be expensive, we could add an
> argument to return the file name instead of a buffer number.
>
> So we have a dilemma: For the plugin that intentionally avoids
> creating a buffer for every error, it can have these extra options
> to make it (a lot) faster. But as soon as another plugin comes into
> play, which depends on the buffer, things fall back to how they were.
> I think that is unavoidable.
So functions that create qflists and loclists (make, cgetexpr etc.)
would create them with filenames, and it would be up to getqflist()
and getloclist() to request the corresponding files to be loaded
into buffers (with the default being to load files, for backwards
compatibility). Also, the results could be cached. That would work
nicely, and it wouldn't be slower for plugins that want old-style
qflists and loclists.
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Using file name with quickfix commands
On 9 July 2016, Bram Moolenaar wrote:
>
> Lcd wrote:
>
> > > > > > On 7 July 2016, Bram Moolenaar wrote:
> > [...]
> > > > > I don't understand. What does "access to a buffer" mean?
> > > >
> > > > Syntastic is a sort of generalised compiler set, it runs
> > > > external compilers, and shows the results in a loclist. Except
> > > > it does a lot more than just open the loclist: it places signs,
> > > > adds highlighting patterns, shows errors in balloons, shows the
> > > > nearest error, and so on. There is some bookkeeping involved,
> > > > and syntastic needs actual buffers to set local options, local
> > > > variables, place signs, munge error messages according to
> > > > context, check that error lines are not outside the file, and
> > > > the like. Could all that be done starting from filenames?
> > > > Probably, with a rewrite from scratch of the core. Somebody
> > > > else might even take up that task some day.
> > > >
> > > > > Anyway, the idea was that this is only used for specific
> > > > > purposes where a buffer is not needed, e.g. a list of matches
> > > > > for "grep".
> > > >
> > > > The point is, there will be two kinds of loclists: "rich"
> > > > ones (with buffers), and "poor" ones (with filenames).
> > > > Syntastic would need to deal with both.
> > >
> > > I don't see the problem. If syntastic wants to do something that
> > > requires a buffer, then it opens that buffer. The only difference
> > > is that the buffer is created later, not when the item is added to
> > > the quickfix list.
> >
> > As I said, doing that would involve rewriting the core from
> > scratch.
> >
> > Admitting for the sake of the argument that rewriting wouldn't
> > be a problem, let's say there's a file "example.c" that's mentioned
> > in the list of errors, and I want to place a sign in it. The file
> > is not open, how would I do that? Let's say I open the file and
> > place the sign. Would jumping to the file from the loclist re-use
> > my buffer?
>
> Sorry, I still don't see a problem. As soon as it tries to get the
> buffer it will exist. How does it currently get the buffer?
Currently an error item from loclist looks like this:
{
'lnum': 148,
'bufnr': 1,
'col': 7,
'valid': 1,
'vcol': 0,
'nr': -1,
'type': 'W',
'pattern': ',
'text': '(3) CodeLayout::ProhibitHardTabs: Hard tabs used (See page
20 of PBP)'
}
If I want to place a sign at the file, I can do this:
sign place 12345 line=148 name=SyntasticError buffer=1
This works regardless if the fuffer is hidden or not, and can be
done before the user jumps to the error.
How would I do the same starting only with a filename, assuming the
user hasn't jumped to the error yet, or opened the file?
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Using file name with quickfix commands
On 9 July 2016, Bram Moolenaar wrote: > > Lcd wrote: > > > > > On 7 July 2016, Bram Moolenaar wrote: [...] > > > I don't understand. What does "access to a buffer" mean? > > > > Syntastic is a sort of generalised compiler set, it runs > > external compilers, and shows the results in a loclist. Except it > > does a lot more than just open the loclist: it places signs, adds > > highlighting patterns, shows errors in balloons, shows the nearest > > error, and so on. There is some bookkeeping involved, and syntastic > > needs actual buffers to set local options, local variables, place > > signs, munge error messages according to context, check that error > > lines are not outside the file, and the like. Could all that be > > done starting from filenames? Probably, with a rewrite from scratch > > of the core. Somebody else might even take up that task some day. > > > > > Anyway, the idea was that this is only used for specific purposes > > > where a buffer is not needed, e.g. a list of matches for "grep". > > > > The point is, there will be two kinds of loclists: "rich" ones > > (with buffers), and "poor" ones (with filenames). Syntastic would > > need to deal with both. > > I don't see the problem. If syntastic wants to do something that > requires a buffer, then it opens that buffer. The only difference is > that the buffer is created later, not when the item is added to the > quickfix list. As I said, doing that would involve rewriting the core from scratch. Admitting for the sake of the argument that rewriting wouldn't be a problem, let's say there's a file "example.c" that's mentioned in the list of errors, and I want to place a sign in it. The file is not open, how would I do that? Let's say I open the file and place the sign. Would jumping to the file from the loclist re-use my buffer? /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] E36 from quickfix list (smaller than 3 lines) with noequalalways and buftype=nofile (#908)
On 9 July 2016, Dominique Pellé wrote: > LCD 47 wrote: > > > On 9 July 2016, Christian Brabandt wrote: > >> On Fr, 08 Jul 2016, LCD 47 wrote: > >> > >> > Not recent, but do you remember the problem introduced by > >> > 1640? It's still with us. _shrug_ > >> > >> I don't follow. That was a bugfix for a crash and I believe it > >> fixed a crash that you reported some time ago or so about accessing > >> invalid memory when loading a quickfix item. > > > > Patch 1640 was a fix for an unrelated crash. It also "fixed" a > > crash I reported earlier, by making it illegal to set loclists from > > autocmds. > > > > As I explained at the time, that was the wrong fix, and it > > affected a few existing plugins. I suggested a different approach, > > but by then everybody was too tired of the discussion to try to > > consider what I was saying. _shrug_ > > > > /lcd > > > Hi Lcd > > Everybody wants to help, but the problem is, nobody knows how to > reproduce the crash that you describe. Can you post a script that > makes Vim crash? Or can you try to reproduce it with valgrind to have > more information. There is no crash any longer. I have a problem with the fix adopted for a (now well-understood) crash, not with the crash itself. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] E36 from quickfix list (smaller than 3 lines) with noequalalways and buftype=nofile (#908)
On 9 July 2016, Christian Brabandt wrote: > On Fr, 08 Jul 2016, LCD 47 wrote: > > > Not recent, but do you remember the problem introduced by 1640? > > It's still with us. _shrug_ > > I don't follow. That was a bugfix for a crash and I believe it fixed > a crash that you reported some time ago or so about accessing invalid > memory when loading a quickfix item. Patch 1640 was a fix for an unrelated crash. It also "fixed" a crash I reported earlier, by making it illegal to set loclists from autocmds. As I explained at the time, that was the wrong fix, and it affected a few existing plugins. I suggested a different approach, but by then everybody was too tired of the discussion to try to consider what I was saying. _shrug_ /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1997
On 8 July 2016, LCD 47 wrote: > On 8 July 2016, Bram Moolenaar wrote: > > > > Lcd wrote: > > > > > On 7 July 2016, Bram Moolenaar wrote: > > > > > > > > Patch 7.4.1997 > > > > Problem:Cannot easily scroll the quickfix window. > > > > Solution: Add ":cbottom". > > > [...] > > > > > > This doesn't seem to work with loclist windows. For what it's > > > worth. > > > > Example? Possibly in a form we can add a test. > > Running Vim in the source tree: > > :lv /a/ *.txt > :lopen > :cbottom > > (nothing happens). > > The same thing with quickfix windows seems to work as expected: > > :vim /a/ *.txt > :copen > :cbottom > > (the cursor moves to the last quickfix entry). This is fixed by 7.4.2010, :lbottom does the job for loclists. Thank you. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] E36 from quickfix list (smaller than 3 lines) with noequalalways and buftype=nofile (#908)
On 8 July 2016, Yegappan Lakshmanan wrote:
> Hi,
>
> On Thu, Jul 7, 2016 at 7:31 AM, Yegappan Lakshmanan
> wrote:
> > Hi,
> >
> > On Thu, Jul 7, 2016 at 1:09 AM, LCD 47 wrote:
> >> On 6 July 2016, Yegappan Lakshmanan wrote:
> >>> Hi,
> >>>
> >>> On Wed, Jul 6, 2016 at 2:18 PM, Daniel Hahler
> >>> wrote:
> >>> >
> >>> > set buftype=nofile
> >>> > set noequalalways
> >>> > call setqflist([{'lnum': 1, 'bufnr': 1, 'col': 0, 'valid': 1, 'vcol': 0,
> >>> 'nr': 0, 'type': 'E', 'pattern': '', 'text': 'msg'}])
> >>> > copen
> >>> > resize 1
> >>> > % vim -u minimal.vim
> >>> >
> >>> > Now going to the quickfix list (C-w j) and pressing Enter will
> >>> > result in "E36: Not enough room". This happens because the "nofile"
> >>> > buffer will not be re-used to display the error,
> >>> >
> >>>
> >>> Yes. This is by design.
> >>
> >> Any particular reason why your designs tend to break things
> >> that worked fine for 10+ years? Just wondering.
> >>
> >
> > This is the behavior of Vim for more than 10 years or so. I am able
> > to reproduce this behavior even in vim 7.0. The recent changes to
> > quickfix didn't change this behavior.
> >
> > Can you describe the quickfix functionality that was broken/changed
> > by the recent changes?
> >
>
> BTW, the majority of the recent changes related to the
> quickfix/location list feature are for adding unit tests. When I
> developed the location list feature for Vim 7.0, majority of the
> quickfix features were not unit tested. The recent changes addressed
> this and now around 85% of the quickfix and location list code is
> under test.
>
> Let us know if you see any of the recent changes break the previous
> quickfix/location list functionality.
Not recent, but do you remember the problem introduced by 1640?
It's still with us. _shrug_
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Using file name with quickfix commands
On 8 July 2016, Bram Moolenaar wrote:
>
> Lcd wrote:
>
> > On 7 July 2016, Bram Moolenaar wrote:
> > >
> > > Christian Brabandt wrote:
> > >
> > > > On Do, 07 Jul 2016, Bram Moolenaar wrote:
> > > >
> > > > >
> > > > > There has been a request that when adding items to the
> > > > > quickfix list, no buffer is created to hold the file name.
> > > > >
> > > > > The reason is that when there are many different file names
> > > > > this causes the buffer list to get very long, which then
> > > > > causes various operations to become slow. Including finding
> > > > > the buffer for a file name.
> > > > >
> > > > > Instead of using a buffer, where the file name is stored, and
> > > > > then using the buffer number, the file name itself could be
> > > > > remembered.
> > > > >
> > > > > Since there are so many quickfix commands, adding a flag to
> > > > > every one of them would be creating quite a mess. We could
> > > > > add an option, but that has the danger of forgetting to reset
> > > > > the option after the operation. And it requires three more
> > > > > statements (save current value, set the option, restore th
> > > > > option). So I was thinking of using a command modifier:
> > > > >
> > > > > :usefname caddexpr {expr}
> > > > >
> > > > > How about that?
> > > >
> > > > That means, the buffer would only be created once you are
> > > > jumping to the file?
> > >
> > > Yes.
> > [...]
> >
> > This would be a huge setback for plugins that expect error
> > items to always have access to a buffer if they refer to a file
> > at all. Essentially it would be the end of filtering operations
> > for syntastic (and probably the end of life for syntastic on newer
> > versions of Vim).
>
> I don't understand. What does "access to a buffer" mean?
Syntastic is a sort of generalised compiler set, it runs external
compilers, and shows the results in a loclist. Except it does a lot
more than just open the loclist: it places signs, adds highlighting
patterns, shows errors in balloons, shows the nearest error, and so
on. There is some bookkeeping involved, and syntastic needs actual
buffers to set local options, local variables, place signs, munge error
messages according to context, check that error lines are not outside
the file, and the like. Could all that be done starting from filenames?
Probably, with a rewrite from scratch of the core. Somebody else might
even take up that task some day.
> Anyway, the idea was that this is only used for specific purposes
> where a buffer is not needed, e.g. a list of matches for "grep".
The point is, there will be two kinds of loclists: "rich" ones (with
buffers), and "poor" ones (with filenames). Syntastic would need to
deal with both.
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1997
On 8 July 2016, Bram Moolenaar wrote: > > Lcd wrote: > > > On 7 July 2016, Bram Moolenaar wrote: > > > > > > Patch 7.4.1997 > > > Problem:Cannot easily scroll the quickfix window. > > > Solution: Add ":cbottom". > > [...] > > > > This doesn't seem to work with loclist windows. For what it's > > worth. > > Example? Possibly in a form we can add a test. Running Vim in the source tree: :lv /a/ *.txt :lopen :cbottom (nothing happens). The same thing with quickfix windows seems to work as expected: :vim /a/ *.txt :copen :cbottom (the cursor moves to the last quickfix entry). /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Using file name with quickfix commands
On 7 July 2016, Bram Moolenaar wrote:
>
> Christian Brabandt wrote:
>
> > On Do, 07 Jul 2016, Bram Moolenaar wrote:
> >
> > >
> > > There has been a request that when adding items to the quickfix
> > > list, no buffer is created to hold the file name.
> > >
> > > The reason is that when there are many different file names this
> > > causes the buffer list to get very long, which then causes various
> > > operations to become slow. Including finding the buffer for a
> > > file name.
> > >
> > > Instead of using a buffer, where the file name is stored, and then
> > > using the buffer number, the file name itself could be remembered.
> > >
> > > Since there are so many quickfix commands, adding a flag to every
> > > one of them would be creating quite a mess. We could add an
> > > option, but that has the danger of forgetting to reset the option
> > > after the operation. And it requires three more statements (save
> > > current value, set the option, restore th option). So I was
> > > thinking of using a command modifier:
> > >
> > > :usefname caddexpr {expr}
> > >
> > > How about that?
> >
> > That means, the buffer would only be created once you are jumping to
> > the file?
>
> Yes.
[...]
This would be a huge setback for plugins that expect error items
to always have access to a buffer if they refer to a file at all.
Essentially it would be the end of filtering operations for syntastic
(and probably the end of life for syntastic on newer versions of Vim).
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1997
On 7 July 2016, Bram Moolenaar wrote: > > Patch 7.4.1997 > Problem:Cannot easily scroll the quickfix window. > Solution: Add ":cbottom". [...] This doesn't seem to work with loclist windows. For what it's worth. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] E36 from quickfix list (smaller than 3 lines) with noequalalways and buftype=nofile (#908)
On 6 July 2016, Yegappan Lakshmanan wrote:
> Hi,
>
> On Wed, Jul 6, 2016 at 2:18 PM, Daniel Hahler
> wrote:
> >
> > set buftype=nofile
> > set noequalalways
> > call setqflist([{'lnum': 1, 'bufnr': 1, 'col': 0, 'valid': 1, 'vcol': 0,
> 'nr': 0, 'type': 'E', 'pattern': '', 'text': 'msg'}])
> > copen
> > resize 1
> > % vim -u minimal.vim
> >
> > Now going to the quickfix list (C-w j) and pressing Enter will
> > result in "E36: Not enough room". This happens because the "nofile"
> > buffer will not be re-used to display the error,
> >
>
> Yes. This is by design.
Any particular reason why your designs tend to break things that
worked fine for 10+ years? Just wondering.
/lcd
> When opening a file from the quickfix window, windows/buffers with
> 'buftype' set to "nofile" will be skipped. Many plugins set the
> 'buftype' to 'nofile' and use the buffer to display some content.
> Reusing that window for showing a selected file will impact the
> plugin.
>
> >
> > and when creating a new split apparently :1sp (or even :0sp?!) will
> > be used.
> >
>
> This is the expected behavior of the 'noequalalways' option.
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Manpager bug
Parse::RecDescent(3) is a valid man page on UNIX (comming from the Perl module Parse::RecDescent), and it's case-sensitive. Running it through Vim's MANPAGER produces the following errors: Error detected while processing function 136_MANPAGER: line 16: E684: list index out of range: 2 E15: Invalid expression: page_sec[2] page_sec[1] There are two reasons for these errors: (1) MANPAGER doesn't accept ":" in man page names (2) MANPAGER changes man page names to lower case. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: runtime/ftplugin/perl.vim is not up to date
On 10 June 2016, Ramel Eshed wrote: > Hi, > > There were few updates to this file in > https://github.com/vim-perl/vim-perl/blob/master/ftplugin/perl.vim > since Jul 2013. The version distributed with Vim sets the global > value of iskeyword. It already fixed in Oct 2013. +1, there are many other problems that have been fixed a few years ago in the repo yet they're still broken in Vim's runtime. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: umask problem in vim_tempname()
On 4 June 2016, Bram Moolenaar wrote:
>
> Lcd wrote:
>
> > > > Scenario:
> > > >
> > > > (1) umask 0177
> > > > (2) run Vim
> > > > (3) in Vim run system(), say:
> > > >
> > > > :echo system('ls')
> > > >
> > > > On Linux machines the result is:
> > > >
> > > > E484: Can't open file /tmp/viEkD0f/2
> > > >
> > > > It's easy to see why:
> > > >
> > > > $ ls -ld /tmp/viEkD0f
> > > > drw--- 2 1034 1023 40 Jun 4 13:32 /tmp/viEkD0f/
> > > >
> > > > The code has provisions to deal with this situation, but only on
> > > > systems that don't have mkdtemp(3). Glibc has mkdtemp(3).
> > >
> > > Setting umask to that value is like shooting yourself in the foot.
> > > I would not call this a Vim problem.
> >
> > Sure, it's useless in a login shell. It isn't as clear cut whether
> > it's always useless in a script. And Vim's system() shouldn't stop
> > working because of it. I'm actually just relaying the report here,
> > since some people seem to have a use for that umask, and blaming me for
> > the results:
> >
> > https://github.com/scrooloose/syntastic/issues/1781
>
> Actually, Vim already has code to work around that, see the use of
> vim_mkdir() in vim_tempname(). But somehow it doesn't work...
> Ah, when the use of mkdtemp() was added this part was omitted.
> That can be fixed.
The problem is indeed fixed in 7.4.1889, thank you.
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: umask problem in vim_tempname()
On 4 June 2016, Bram Moolenaar wrote:
>
> Lcd wrote:
>
> > Scenario:
> >
> > (1) umask 0177
> > (2) run Vim
> > (3) in Vim run system(), say:
> >
> > :echo system('ls')
> >
> > On Linux machines the result is:
> >
> > E484: Can't open file /tmp/viEkD0f/2
> >
> > It's easy to see why:
> >
> > $ ls -ld /tmp/viEkD0f
> > drw--- 2 1034 1023 40 Jun 4 13:32 /tmp/viEkD0f/
> >
> > The code has provisions to deal with this situation, but only on
> > systems that don't have mkdtemp(3). Glibc has mkdtemp(3).
>
> Setting umask to that value is like shooting yourself in the foot.
> I would not call this a Vim problem.
Sure, it's useless in a login shell. It isn't as clear cut whether
it's always useless in a script. And Vim's system() shouldn't stop
working because of it. I'm actually just relaying the report here,
since some people seem to have a use for that umask, and blaming me for
the results:
https://github.com/scrooloose/syntastic/issues/1781
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
umask problem in vim_tempname()
Scenario:
(1) umask 0177
(2) run Vim
(3) in Vim run system(), say:
:echo system('ls')
On Linux machines the result is:
E484: Can't open file /tmp/viEkD0f/2
It's easy to see why:
$ ls -ld /tmp/viEkD0f
drw--- 2 1034 1023 40 Jun 4 13:32 /tmp/viEkD0f/
The code has provisions to deal with this situation, but only on
systems that don't have mkdtemp(3). Glibc has mkdtemp(3).
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Can't compile with Perl v5.22.2
On 2 May 2016, Damien wrote: > Le Sun, May 01, 2016 at 09:23:04PM +0300, LCD 47 a écrit : > > This seems to be a recent change in Perl rather than Vim: > > > > clang -c -I. -Iproto -DHAVE_CONFIG_H -pipe -O2 -U_FORTIFY_SOURCE > > -D_FORTIFY_SOURCE=1 -I/usr/include/python3.5m > > -DPYTHON3_HOME='L"/usr"' -pthread > > -DDYNAMIC_PYTHON3_DLL=\"libpython3.5m.so.1.0\" -o objects/if_python3.o > > if_python3.c > > In file included from if_perl.xs:610: > > /usr/lib/perl5/CORE/inline.h:20:5: error: use of undeclared identifier > > 'PERL_ARGS_ASSERT_AV_TOP_INDEX' > > PERL_ARGS_ASSERT_AV_TOP_INDEX; > > ^ > > /usr/lib/perl5/CORE/inline.h:242:5: error: use of undeclared identifier > > 'PERL_ARGS_ASSERT_APPEND_UTF8_FROM_NATIVE_BYTE' > > PERL_ARGS_ASSERT_APPEND_UTF8_FROM_NATIVE_BYTE; > > ^ > > /usr/lib/perl5/CORE/inline.h:274:5: error: use of undeclared identifier > > 'PERL_ARGS_ASSERT__IS_UTF8_CHAR_SLOW' > > PERL_ARGS_ASSERT__IS_UTF8_CHAR_SLOW; > > ^ > > /usr/lib/perl5/CORE/inline.h:305:5: error: use of undeclared identifier > > 'PERL_ARGS_ASSERT_IS_SAFE_SYSCALL' > > PERL_ARGS_ASSERT_IS_SAFE_SYSCALL; > > ^ > > /usr/lib/perl5/CORE/inline.h:390:5: error: use of undeclared identifier > > 'PERL_ARGS_ASSERT_SV_ONLY_TAINT_GMAGIC' > > PERL_ARGS_ASSERT_SV_ONLY_TAINT_GMAGIC; > > ^ > > > > $ perl --version | head -2 > > > > This is perl 5, version 22, subversion 2 (v5.22.2) built for > > i586-linux-thread-multi > > > > /lcd > > Hi LCD and list, > > Please check this patch > https://framagit.org/Damien43/patches/raw/master/vim/perl-5.22.2.patch Thank you. It does solve the compilation problem, and it also passes some quick tests. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Can't compile with Perl v5.22.2
This seems to be a recent change in Perl rather than Vim: clang -c -I. -Iproto -DHAVE_CONFIG_H -pipe -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -I/usr/include/python3.5m -DPYTHON3_HOME='L"/usr"' -pthread -DDYNAMIC_PYTHON3_DLL=\"libpython3.5m.so.1.0\" -o objects/if_python3.o if_python3.c In file included from if_perl.xs:610: /usr/lib/perl5/CORE/inline.h:20:5: error: use of undeclared identifier 'PERL_ARGS_ASSERT_AV_TOP_INDEX' PERL_ARGS_ASSERT_AV_TOP_INDEX; ^ /usr/lib/perl5/CORE/inline.h:242:5: error: use of undeclared identifier 'PERL_ARGS_ASSERT_APPEND_UTF8_FROM_NATIVE_BYTE' PERL_ARGS_ASSERT_APPEND_UTF8_FROM_NATIVE_BYTE; ^ /usr/lib/perl5/CORE/inline.h:274:5: error: use of undeclared identifier 'PERL_ARGS_ASSERT__IS_UTF8_CHAR_SLOW' PERL_ARGS_ASSERT__IS_UTF8_CHAR_SLOW; ^ /usr/lib/perl5/CORE/inline.h:305:5: error: use of undeclared identifier 'PERL_ARGS_ASSERT_IS_SAFE_SYSCALL' PERL_ARGS_ASSERT_IS_SAFE_SYSCALL; ^ /usr/lib/perl5/CORE/inline.h:390:5: error: use of undeclared identifier 'PERL_ARGS_ASSERT_SV_ONLY_TAINT_GMAGIC' PERL_ARGS_ASSERT_SV_ONLY_TAINT_GMAGIC; ^ $ perl --version | head -2 This is perl 5, version 22, subversion 2 (v5.22.2) built for i586-linux-thread-multi /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to run a job asynchronously?
On 26 April 2016, Bram Moolenaar wrote:
>
> James McCoy wrote:
>
> > On Mon, Apr 25, 2016 at 11:06:43PM +0200, Bram Moolenaar wrote:
> > >
> > > Andrew Stewart wrote:
> > >
> > > > This handler gets called just about immediately, as expected, but
> > > > a:message is always 'DETACH', not the diff output. And then a few
> > > > seconds later the exit handler echoes its E906 error.
> > >
> > > This works. But the script should use "out_cb":
> > >
> > > func! OutHandler(channel, msg)
> > > echomsg a:msg
> > > endfunc
> > > let cmd = 'diff -u /tmp/a /tmp/b'
> > > let job = job_start(cmd, {'out_cb': 'OutHandler'})
> > >
> > > The echo statements overwrite each other, "DETACH" is the last one. Use
> > > ":messages" to see what happened before this.
> >
> > Why is Vim injecting "DETACH" into the output? The netbeans code uses
> > is because that's part of the established protocol, but why is that
> > being imposed on every other user of channels?
>
> Yeah, I was also wondering if we need it.
Some way to test for EOF would be more useful, IMO. Not quite the
same thing as a close callback.
/lcd
> At least when there is a close callback it doesn't make sense.
>
> I would think that normally the job will send some terminator.
> Otherwise, one can add a close callback if one needs to know the
> channel is done reading. Would there be any reason to add DETACH?
>
> Previously the close callback didn't work properly. I fixed that now.
>
> > Also, the help implies that this is only done for channels
> > representing a socket, not ones that are used for a simple
> > job_start() with a process:
> >
> > On read error or ch_close(), when using a socket with RAW or NL
> > mode, the string "DETACH\n" is sent, if still possible. The
> > channel will then be inactive.
>
> The documentation is wrong.
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Bug: read from free'd memory when jumping from a quickfix list
On 12 April 2016, Yegappan Lakshmanan wrote: > Hi, > > On Tue, Apr 12, 2016 at 9:59 AM, LCD 47 wrote: [...] > > Currently .ll when jumping to file "example.txt" line N goes > > roughly like this: > > > > (1) load "example.txt" > > (2) trigger autocmds for "example.txt" > > (3) go to line N. > > > > If the loclist changes between (2) and (3) there's trouble > > because you're reading from free()d memory. For this reason, your > > patch 1640 adds a safeguard between (2) and (3), making sure the > > loclist is still the same. > > > > The patch makes sure that the location list entry (not the entire > list) is still valid. Note that a autocmd can add entry to the current > location list and modify entries which will not impact the current > entry. But the autocmd cannot delete the current location list or load > a new location list. > > > > > This breaks autocmds for "example.txt" that override the current > > loclist. > > > > Do you have a real-world example of an existing plugin that breaks > because of this change? As I pointed out in my previous message: syntastic and vim-go break because of 1640. They need to set a new loclist from an autocmd, that's how they are supposed to work. [...] > > I suggest swapping (2) and (3), that is, delaying autocmds for > > "example.txt" until the jump is finished: > > > > (1') load "example.txt" > > (2') go to line N > > (3') trigger autocmds for "example.txt". > > > > As discussed in the earlier e-mails, triggering autocmd at this point > is too late. To load the buffer and jump to the line, you need to > trigger autocmds. We can keep running in circles if you like. Please look at quickfix.c lines 1857-1969 (in 1724), and point out which part would change anything related to autocmds if run earlier. > > With this approach there is no need to care whether autocmds > > change the current loclist or not, since the old loclist is no > > longer needed, and can be safely discarded at that point. > > > > The cursor also stand more chances to stay on the right line if > > the autocmds change the contents of the buffer, since Vim can keep > > track of it. > > > > When the contents of a buffer is modified, Vim automatically updates > the line numbers in the quickfix/location list entries (refer to the > qf_mark_adjust() function). qf_mark_adjust() adjusts the number of lines in the buffer. My scenario is different: (a) a loclist entry pointing to "example.txt" line 10 (b) an autocmd for "example.txt" that deletes lines 1-5. With your (existing) approach, "example.txt" is loaded and the cursor is set to line 10. With mine, "example.txt" is loaded, the cursor is set to linew 10, then lines 1-5 are deleted. The cursor still stays on the right logical line, because Vim keeps it there. > > > > And finally, setting the cursor before running the autocmds is > > highly unlikely to change the conditions that trigger said autocmds. > > Reference: quickfix.c lines 1857-1969 in 1724. > > > > Summary: 1640 was the wrong fix. It breaks existing plugins, > > such as syntastic and vim-go, which now have to find workarounds. > > > > Are you guessing that this change may break those plugins or do you > have a simplified example of how this change breaks those plugins? I do have a scenario that breaks syntastic. It isn't simple, because I already added a workaround that avoids the problem in most other cases: (1) set g:syntastic_always_populate_loc_list to 1 (2) set g:syntastic_auto_jump to 1 (3) set g:syntastic_cpp_check_header to 1 (4) set g:syntastic_check_on_open to 1 (5) set g:syntastic_cpp_checkers to ['gcc'] (6) set g:syntastic_cpp_compiler to 'clang++' (7) open a C++ file, run the checker, and .ll to a problem in a header. Result: E926. Alternatively, just downgrade syntastic to some older release, run any checker, and do a .ll . More real world evidence: https://github.com/scrooloose/syntastic/issues/1738 http://superuser.com/questions/1059194/vim-syntastic-not-jumping-to-the-error People elsewhere are discussing breaking cases for vim-go, but I'm not using vim-go, so I won't comment on those. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug: read from free'd memory when jumping from a quickfix list
On 12 April 2016, Yegappan Lakshmanan wrote: > LCD 47 wrote: [...] > > Can you please give an example when setting the cursor before an > > autocmd would "break functionality that depends on these events"? > > > > Consider for example, you have a BufReadPre autocommand that either > uncompresses a file or performs a network operation to load the > buffer. If these autocommands are delayed, then the buffer cannot be > loaded and the location list cannot position the cursor. > > Note that selecting an entry from the location can trigger various > autocommands depending on whether the buffer is already loaded in a > window or hidden or not in memory. > > Also, depending on the 'switchbuf' setting, selecting an entry from > the quickfix list can create a new window or a tab, jump to a tab or > window. This will trigger additional autocommand events. You cannot > delay autocommands in these cases (for example TabEnter/WinEnter). Right, this actually makes the case that patch 1640 is the wrong fix, and also that the problem I'm pointing to has nothing to do with patch 1592. Currently .ll when jumping to file "example.txt" line N goes roughly like this: (1) load "example.txt" (2) trigger autocmds for "example.txt" (3) go to line N. If the loclist changes between (2) and (3) there's trouble because you're reading from free()d memory. For this reason, your patch 1640 adds a safeguard between (2) and (3), making sure the loclist is still the same. This breaks autocmds for "example.txt" that override the current loclist. It also breaks autocmds for "example.txt" that modify the contents of "example.txt", because line N from .ll might no longer be the same after the autocmds. I suggest swapping (2) and (3), that is, delaying autocmds for "example.txt" until the jump is finished: (1') load "example.txt" (2') go to line N (3') trigger autocmds for "example.txt". With this approach there is no need to care whether autocmds change the current loclist or not, since the old loclist is no longer needed, and can be safely discarded at that point. The cursor also stand more chances to stay on the right line if the autocmds change the contents of the buffer, since Vim can keep track of it. And finally, setting the cursor before running the autocmds is highly unlikely to change the conditions that trigger said autocmds. Reference: quickfix.c lines 1857-1969 in 1724. Summary: 1640 was the wrong fix. It breaks existing plugins, such as syntastic and vim-go, which now have to find workarounds. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug: read from free'd memory when jumping from a quickfix list
On 12 April 2016, Dominique Pellé wrote: > LCD 47 wrote: > > > On 12 April 2016, Dominique Pellé wrote: > >> LCD 47 wrote: > >> > >> > Sorry, but no. The autocmd can mess things up beyond repair without > >> > touching touching the loclist. Example: > >> > > >> > (1) start jumping to line 500 in exmple.txt > >> > (2) example.txt has a BufEnter that deletes lines below 251 > >> > (3) segfault. > >> > >> Hi LCD, > >> > >> It's best if you can provide a completely automated way to > >> reproduce a crash: a command line using "vim -i NONE -c ... " or a > >> Vim script. It saves time when trying to reproduce bugs and it's > >> less ambiguous. > > > > We still seem to be seeing this at different abstaction levels. > > I'm talking about making sense. Making crashes reproducible and > > fixing them should come later. Getting the wrong result without > > crashes is somewhat pointless. :) > > > > /lcd > > In your description you were very specific, indicating line number 500 > and line 251, so I assumed (perhaps wrongly?) that you could reproduce > a crash, and that it was not theoretical. [...] No, that was just a mental experiment. I thought, perhaps wrongly, that putting that in concrete terms would make it easier to understand. I can write it in terms of formal specs if you prefer. I'm supposed to be a mathematician in real life not a programmer, so I can make it look as abstarct as you like. :) /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug: read from free'd memory when jumping from a quickfix list
On 12 April 2016, Christian Brabandt wrote: > Am 2016-04-12 08:40, schrieb LCD 47: > > On 11 April 2016, Yegappan Lakshmanan wrote: > >> Hi, > >> > >> On Mon, Apr 11, 2016 at 11:37 AM, LCD 47 wrote: > >> > On 11 April 2016, Christian Brabandt wrote: > >> >> Am 2016-04-11 08:20, schrieb LCD 47: > >> >> > On 19 March 2016, Dominique Pellé wrote: > >> >> >> Hi LCD, > >> >> >> > >> >> >> If you can still reproduce this bug, can you check > >> >> >> whether recent patch 7.4.1592 fixes it? > >> >> >> > >> >> >> patch 7.4.1592 > >> >> >> Problem:Quickfix code using memory after being freed. (Dominique > >> >> >> Pelle) > >> >> >> Solution: Detect that the window was closed. (Hirohito Higashi) > >> >> > > >> >> > (Context moved below the signature) > >> >> > > >> >> > Hi Dominique, > >> >> > > >> >> > I think I now have a better understanding of what was going > >> >> > on in my report. Your patch fixes the crash, but there might > >> >> > still be a deeper problem with jumping from quickfix lists. > >> >> > > >> >> > The crash scenario was something like this: > >> >> > > >> >> > (1) .ll from a loclist > >> >> > (2) the target file for .ll had a BufEnter autocmd > >> >> > (3) the BufEnter set a different loclist for the same window > >> >> > (4) .ll mixed data from the old and new loclists. > >> >> > > >> >> > Your patch adds a safeguard against the loclist going away > >> >> > from under .ll's feet, but the fact that an autocmd can happen in > >> >> > the middle of the operation is still a bug, I think. > >> >> > >> >> Is there an easy way to reproduce the issue? Perhaps, cloning as > >> >> github repository with mandatory setup files? > >> > > >> > You don't understand, there is nothing to reporduce (not yet > >> > anyway). The issue I reported way back was fixed by patch 1592, and > >> > by a patch to syntastic. However, I claim that the bigger picture > >> > of quickfix is _still_ wrong. > >> > > >> > Namely, autocmds can occur in the middle of quickfix commands. > >> > I don't have any use case to show what can break that way, but it's > >> > surely obvious that this is a bad idea? > >> > > >> > >> The above mentioned patch checks whether the current quickfix/location > >> list entry is still valid after opening a buffer (assuming this event > >> triggered an autocmd that changed the quickfix/location list). If the > >> entry is no longer valid, then the operation is aborted. > > > > Umm, this is what I said above. > > > >> This should gracefully handle this condition. > > > > Sorry, but no. The autocmd can mess things up beyond repair > > without > > touching touching the loclist. Example: > > > > (1) start jumping to line 500 in exmple.txt > > (2) example.txt has a BufEnter that deletes lines below 251 > > (3) segfault. > > does it? I think you'll get a bunch of ml_get errors, and if you've > finally hit-enter'ed away all messages, I think Vim will continue to > work fine. Depending on how many error messages you got, this can be > annoying however. The point is, an autocmd can mess things up by changing the context in a way the current command doesn't expect. > > You can add safeguards against jumping beyond EOF. I'll then > > come up with a slightly more complicated crash. :) > > > >> > Shouldn't autocmds be delayed until quickfix commands are > >> > finished? > >> > > >> > >> No. Jumping to an entry in the location/quickfix list may trigger > >> buffer, window and tab enter/leave autocmds. Delaying these autocmd > >> events will break functionality that depends on these events. > > > > Can you please give an example when setting the cursor before an > > autocmd would "break functionality that depends on these events"? > > As far as I can tell, delaying the autocmd until the current > > operation is finished would enable functionality (such as the >
Re: Bug: read from free'd memory when jumping from a quickfix list
On 12 April 2016, Dominique Pellé wrote: > LCD 47 wrote: > > > Sorry, but no. The autocmd can mess things up beyond repair without > > touching touching the loclist. Example: > > > > (1) start jumping to line 500 in exmple.txt > > (2) example.txt has a BufEnter that deletes lines below 251 > > (3) segfault. > > Hi LCD, > > It's best if you can provide a completely automated > way to reproduce a crash: a command line using > "vim -i NONE -c ... " or a Vim script. It saves time > when trying to reproduce bugs and it's less ambiguous. We still seem to be seeing this at different abstaction levels. I'm talking about making sense. Making crashes reproducible and fixing them should come later. Getting the wrong result without crashes is somewhat pointless. :) /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug: read from free'd memory when jumping from a quickfix list
On 11 April 2016, Yegappan Lakshmanan wrote: > Hi, > > On Mon, Apr 11, 2016 at 11:37 AM, LCD 47 wrote: > > On 11 April 2016, Christian Brabandt wrote: > >> Am 2016-04-11 08:20, schrieb LCD 47: > >> > On 19 March 2016, Dominique Pellé wrote: > >> >> Hi LCD, > >> >> > >> >> If you can still reproduce this bug, can you check > >> >> whether recent patch 7.4.1592 fixes it? > >> >> > >> >> patch 7.4.1592 > >> >> Problem:Quickfix code using memory after being freed. (Dominique > >> >> Pelle) > >> >> Solution: Detect that the window was closed. (Hirohito Higashi) > >> > > >> > (Context moved below the signature) > >> > > >> > Hi Dominique, > >> > > >> > I think I now have a better understanding of what was going > >> > on in my report. Your patch fixes the crash, but there might > >> > still be a deeper problem with jumping from quickfix lists. > >> > > >> > The crash scenario was something like this: > >> > > >> > (1) .ll from a loclist > >> > (2) the target file for .ll had a BufEnter autocmd > >> > (3) the BufEnter set a different loclist for the same window > >> > (4) .ll mixed data from the old and new loclists. > >> > > >> > Your patch adds a safeguard against the loclist going away > >> > from under .ll's feet, but the fact that an autocmd can happen in > >> > the middle of the operation is still a bug, I think. > >> > >> Is there an easy way to reproduce the issue? Perhaps, cloning as > >> github repository with mandatory setup files? > > > > You don't understand, there is nothing to reporduce (not yet > > anyway). The issue I reported way back was fixed by patch 1592, and > > by a patch to syntastic. However, I claim that the bigger picture > > of quickfix is _still_ wrong. > > > > Namely, autocmds can occur in the middle of quickfix commands. > > I don't have any use case to show what can break that way, but it's > > surely obvious that this is a bad idea? > > > > The above mentioned patch checks whether the current quickfix/location > list entry is still valid after opening a buffer (assuming this event > triggered an autocmd that changed the quickfix/location list). If the > entry is no longer valid, then the operation is aborted. Umm, this is what I said above. > This should gracefully handle this condition. Sorry, but no. The autocmd can mess things up beyond repair without touching touching the loclist. Example: (1) start jumping to line 500 in exmple.txt (2) example.txt has a BufEnter that deletes lines below 251 (3) segfault. You can add safeguards against jumping beyond EOF. I'll then come up with a slightly more complicated crash. :) > > Shouldn't autocmds be delayed until quickfix commands are finished? > > > > No. Jumping to an entry in the location/quickfix list may trigger > buffer, window and tab enter/leave autocmds. Delaying these autocmd > events will break functionality that depends on these events. Can you please give an example when setting the cursor before an autocmd would "break functionality that depends on these events"? As far as I can tell, delaying the autocmd until the current operation is finished would enable functionality (such as the scenario in my initial report), rather than break functionality. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug: read from free'd memory when jumping from a quickfix list
On 11 April 2016, Christian Brabandt wrote: > Am 2016-04-11 08:20, schrieb LCD 47: > > On 19 March 2016, Dominique Pellé wrote: > >> Hi LCD, > >> > >> If you can still reproduce this bug, can you check > >> whether recent patch 7.4.1592 fixes it? > >> > >> patch 7.4.1592 > >> Problem:Quickfix code using memory after being freed. (Dominique > >> Pelle) > >> Solution: Detect that the window was closed. (Hirohito Higashi) > > > > (Context moved below the signature) > > > > Hi Dominique, > > > > I think I now have a better understanding of what was going on > > in my report. Your patch fixes the crash, but there might still be > > a deeper problem with jumping from quickfix lists. > > > > The crash scenario was something like this: > > > > (1) .ll from a loclist > > (2) the target file for .ll had a BufEnter autocmd > > (3) the BufEnter set a different loclist for the same window > > (4) .ll mixed data from the old and new loclists. > > > > Your patch adds a safeguard against the loclist going away from > > under .ll's feet, but the fact that an autocmd can happen in the > > middle of the operation is still a bug, I think. > > Is there an easy way to reproduce the issue? Perhaps, cloning as > github repository with mandatory setup files? You don't understand, there is nothing to reporduce (not yet anyway). The issue I reported way back was fixed by patch 1592, and by a patch to syntastic. However, I claim that the bigger picture of quickfix is _still_ wrong. Namely, autocmds can occur in the middle of quickfix commands. I don't have any use case to show what can break that way, but it's surely obvious that this is a bad idea? Shouldn't autocmds be delayed until quickfix commands are finished? /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug: read from free'd memory when jumping from a quickfix list
On 19 March 2016, Dominique Pellé wrote: > Hi LCD, > > If you can still reproduce this bug, can you check > whether recent patch 7.4.1592 fixes it? > > patch 7.4.1592 > Problem:Quickfix code using memory after being freed. (Dominique Pelle) > Solution: Detect that the window was closed. (Hirohito Higashi) (Context moved below the signature) Hi Dominique, I think I now have a better understanding of what was going on in my report. Your patch fixes the crash, but there might still be a deeper problem with jumping from quickfix lists. The crash scenario was something like this: (1) .ll from a loclist (2) the target file for .ll had a BufEnter autocmd (3) the BufEnter set a different loclist for the same window (4) .ll mixed data from the old and new loclists. Your patch adds a safeguard against the loclist going away from under .ll's feet, but the fact that an autocmd can happen in the middle of the operation is still a bug, I think. /lcd On 19 March 2016, Dominique Pellé wrote: > LCD 47 wrote: > > > On 23 July 2014, Bram Moolenaar wrote: > >> > >> Lcd wrote: > >> > >> > > > Scenario: > >> > > > > >> > > > (1) set a loclist: > >> > > > > >> > > > call setloclist(0, list) > >> > > > > >> > > > (2) at some point later replace the list: > >> > > > > >> > > > call setloclist(0, other_list, 'r') > >> > > > > >> > > > (3) open the quickfix window > >> > > > > >> > > > lopen > >> > > > > >> > > > (4) switch to the quickfix window and press Enter to jump to an > >> > > > error: > >> > > > > >> > > > .ll > >> > > > > >> > > > The result is a read from free'd memory; valgrind trace > >> > > > included below. It's easy to make Vim crash from there, but the > >> > > > stack trace doesn't reveal any additional information. > >> > > > > >> > > > Sadly, this is not consistently reproducible. I can trigger > >> > > > it in syntastic, but I can't seem to get the same result in a > >> > > > simple test file. > >> > > > >> > > I have sent out patch 7.4.379. Can you check that this fixes the > >> > > problem? > >> > > >> > That was something I tried too, but it doesn't work; new > >> > valgrind trace included below. > >> > >> What exactly are the arguments to ex_cc when this happens? > > > > I added some rudimentary tracing, patch attached. The output is > > this: > > > > ex_cexpr(): arg = "err_lines", nextcmd = "NULL", *cmdlinep = "lgetexpr > > err_lines", cmdidx = 216, argt = 0x994, skip = 0, forceit = 0, addr_count = > > 0, line1 = 9, line2 = 9, flags = 0x0, do_ecmd_cmd = "NULL", do_ecmd_lnum = > > 0, append = 0, usefilter = 0, amount = 0, regname = 0, force_bin = 0, > > read_edit = 0, force_ff = 0, force_enc = 0, bad_char = 0, useridx = 0 > > get_errorlist() > > set_errorlist(): action ' ', title = "setloclist()" > > get_errorlist() > > get_errorlist() > > get_errorlist() > > ex_cc(): arg = "", nextcmd = "NULL", *cmdlinep = ".ll", cmdidx = 220, argt > > = 0x4503, skip = 0, forceit = 0, addr_count = 1, line1 = 1, line2 = 1, > > flags = 0x0, do_ecmd_cmd = "NULL", do_ecmd_lnum = 0, append = 0, usefilter > > = 0, amount = 0, regname = 0, force_bin = 0, read_edit = 0, force_ff = 0, > > force_enc = 0, bad_char = 0, useridx = 0 > > set_errorlist(): action 'r', title = "setloclist()" > > get_errorlist() > > get_errorlist() > > > > I'm also attaching the corresponding valgrind log. > > > > Perhaps also relevant: steps (1)-(3) happen from a BufWritePost > > autocmd, step (4) is done after the autocmd has finished. > > > >> Without knowing that the number of possibilities is too big. > > > > Oh, I do realise it's an useless report. I don't know how to make > > it more useful. Sorry about that. However the bug appears to be real, > > which is why I posted all this. > > > >> Can you reproduce it with a fixed location list? Otherwise I can't > >> reproduce the problem. > > [...] > > > > As I said, I can't reproduce the problem in a simpler setup. As any > > self-respecting Heisenbug, I can't even reproduce it in gdb. > > > > /lcd > > > -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1699
On 5 April 2016, Nikolay Aleksandrovich Pavlov wrote:
> 2016-04-05 13:52 GMT+03:00 LCD 47 :
> > On 4 April 2016, Bram Moolenaar wrote:
[...]
> >> Lcd wrote:
> > [...]
> >> > There is still the issue of finding scripts depth-first. This is
> >> > fine for glob(), and possibly also for runtimepath, but it doesn't make
> >> > sense for loading. Presumably the main script always has to be loaded
> >> > first.
> >>
> >> I haven't seen an example of this, and as mentioned, it already is the
> >> current behavior.
> >
> > Syntastic is an example I'm familiar with:
> >
> > https://github.com/scrooloose/syntastic
> >
> > It has this structure:
> >
> > syntastic
> > |-- CONTRIBUTING.md
> > |-- LICENCE
> > |-- README.markdown
> > |-- _assets
> > | `-- screenshot_1.png
> > |-- autoload
> > | `-- syntastic
> > | |-- c.vim
> > | |-- log.vim
> > | |-- postprocess.vim
> > | |-- preprocess.vim
> > | `-- util.vim
> > |-- doc
> > | `-- syntastic.txt
> > |-- plugin
> > | |-- syntastic
> > | | |-- autoloclist.vim
> > | | |-- balloons.vim
> > | | |-- checker.vim
> > | | |-- cursor.vim
> > | | |-- highlighting.vim
> > | | |-- loclist.vim
> > | | |-- modemap.vim
> > | | |-- notifiers.vim
> > | | |-- registry.vim
> > | | `-- signs.vim
> > | `-- syntastic.vim
> > `-- syntax_checkers
> > |-- actionscript
> > ...
> >
> > The main script is "plugin/syntastic.vim". This script loads
> > everything in "plugin/syntastic":
> >
> > runtime! plugin/syntastic/*.vim
> >
> > The scripts in "plugin/syntastic" make no sense on their own, and
> > they can't be run before "plugin/syntastic.vim" because they call
> > functions from the main script. For this reason, they have to make sure
> > overly eager package managers (and now Vim itself) don't try to load
> > them out of turn:
> >
> > if exists('g:loaded_syntastic_notifier_cursor') ||
> > !exists('g:loaded_syntastic_plugin')
> > finish
> > endif
> > let g:loaded_syntastic_notifier_cursor = 1
> >
> > Going through "plugin/**/*.vim" depth-first is harmless because
> > these scripts are prepared for it. But doing that is wasteful, and
> > having to be prepared for that is an unnecessary trap for script
> > writers. I can't imagine any situation when it would be _useful_ to
> > load scripts in (some other package's equivalent of) "plugin/syntastic"
> > before the main scripts, and I can easily imagine plenty of scenarios
> > when it's harmful. Why would anybody _expect_ such a thing, to begin
> > with?
>
> Because it is *explicitly* stated in documentation that all files in
> plugin/**/*.vim are sourced.
Yes. What I'm questioning here is why files in "plugin/syntastic"
are sourced _before_ those in "plugin". Can you give an example of
situation when this behaviour is actually useful?
> Syntastic has this code *not* because plugin managers do something
> like this. Both syntastic *and* plugin managers do what they do
> because *Vim* does source plugin/**/*.vim. And also note that with
> autoload feature script writers are expected to put problematic things
> in e.g. syntastic#init (autoload/syntastic.vim) which knows how to do
> something once only, better ask syntastic authors why they have chosen
> to use such a strange hack.
Err, because syntastic is old, and still maintains compatibility
with conventions designed back when everything fitted nicely in a single
file? Most of the time you get from a single file to ~250 files by
adding bits and ends one by one, rather than by adding 249 files in a
single move. :)
> Also plugin/*/*.vim do not have to be dependent files: e.g. in
> neocomplete plugin/neocomplete.vim and plugin/neocomplete/*.vim do not
> have such “main file / dependent files” relation.
I'd say that's the exception rather than the rule, by a wide margin.
Looking at the sources, there doesn't seem to be any good reason for
that choice, either. Perhaps an author who is young enough not have
ingrained the reflex that opening 4 scripts is slower than opening a
single one, but certainly nothing deeper than that. _shrug_
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Vim 7.5 or Vim 8?
On 4 April 2016, Bram Moolenaar wrote: > > I have been wondering if the next release should be called 7.5 or 8. > We have quite a few new features, but not that many as with the Vim 7 > release. Well, that was a big release. I think the most important > addition since then is persistent undo in 7.3. Now we have more new > features than in 7.3 or 7.4. 7.1 and 7.2 were mostly bug fixes. [...] +1 for 8.0, there have been a lot of major changes since 7.4. The asynch I/O feature is not something "normal" users will care for, since nothing uses it yet, but I'd fully expect it to become a superhit in the future. :) /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1699
On 4 April 2016, Bram Moolenaar wrote:
> tldr: Proposal: Change loading packages from pack/start (and
> :packloadall) to first add all directories to 'runtimepath' before
> sourcing the plugins.
After pondering about it for a while, I'm pretty sure this is the
right thing to do. It closes all sorts of race conditions, including
the problem of mutually recursive autoloads.
> Lcd wrote:
[...]
> > There is still the issue of finding scripts depth-first. This is
> > fine for glob(), and possibly also for runtimepath, but it doesn't make
> > sense for loading. Presumably the main script always has to be loaded
> > first.
>
> I haven't seen an example of this, and as mentioned, it already is the
> current behavior.
Syntastic is an example I'm familiar with:
https://github.com/scrooloose/syntastic
It has this structure:
syntastic
|-- CONTRIBUTING.md
|-- LICENCE
|-- README.markdown
|-- _assets
| `-- screenshot_1.png
|-- autoload
| `-- syntastic
| |-- c.vim
| |-- log.vim
| |-- postprocess.vim
| |-- preprocess.vim
| `-- util.vim
|-- doc
| `-- syntastic.txt
|-- plugin
| |-- syntastic
| | |-- autoloclist.vim
| | |-- balloons.vim
| | |-- checker.vim
| | |-- cursor.vim
| | |-- highlighting.vim
| | |-- loclist.vim
| | |-- modemap.vim
| | |-- notifiers.vim
| | |-- registry.vim
| | `-- signs.vim
| `-- syntastic.vim
`-- syntax_checkers
|-- actionscript
...
The main script is "plugin/syntastic.vim". This script loads
everything in "plugin/syntastic":
runtime! plugin/syntastic/*.vim
The scripts in "plugin/syntastic" make no sense on their own, and
they can't be run before "plugin/syntastic.vim" because they call
functions from the main script. For this reason, they have to make sure
overly eager package managers (and now Vim itself) don't try to load
them out of turn:
if exists('g:loaded_syntastic_notifier_cursor') ||
!exists('g:loaded_syntastic_plugin')
finish
endif
let g:loaded_syntastic_notifier_cursor = 1
Going through "plugin/**/*.vim" depth-first is harmless because
these scripts are prepared for it. But doing that is wasteful, and
having to be prepared for that is an unnecessary trap for script
writers. I can't imagine any situation when it would be _useful_ to
load scripts in (some other package's equivalent of) "plugin/syntastic"
before the main scripts, and I can easily imagine plenty of scenarios
when it's harmful. Why would anybody _expect_ such a thing, to begin
with?
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1699
On 3 April 2016, Bram Moolenaar wrote: > > Lcd wrote: > > > > > Error detected while processing > > > > /home/lcd047/Git/Vim/textobj-comment/plugin/textobj/comment.vim: > > > > line 27: > > > > E117: Unknown function: textobj#user#plugin > > > > Press ENTER or type command to continue [...] > If you want to use this in a package you need to have: > > :packadd vim-textobj-user [...] There is nothing special about "vim-textobj-comment", all other text object plugins for "vim-textobj-user" have the exact same problem. The way to make them work with Vim 7.4.1699 or later seems to be something like this: set runtimepath+=~/Git/Vim/textobj-user packloadall And the same is likely to be needed for every other packages that have a plugin architecture. Or wait for the authors of all these packages to provide the necessary safeguards for loading the main package when a plugin is sourced out of order. _shrug_ /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1699
On 3 April 2016, Bram Moolenaar wrote:
>
> Lcd wrote:
>
> > > > On 2 April 2016, Bram Moolenaar wrote:
> > > > >
> > > > > Patch 7.4.1699
> > > > > Problem::packadd does not work the same when used early or late.
> > > > > Solution: Always load plugins matching "plugin/**/*.vim".
> > > > > Files: src/ex_cmds2.c, src/testdir/test_packadd.vim
> > > > >
> > > > >
> > > > > *** ../vim-7.4.1698/src/ex_cmds2.c2016-03-19 14:16:34.611690741
> > > > > +0100
> > > > > --- src/ex_cmds2.c2016-04-02 22:29:44.513040078 +0200
> > > > > ***
> > > > > *** 3376,3382
> > > > >
> > > > > if (load_files)
> > > > > {
> > > > > ! static char *plugpat = "%s/plugin/*.vim";
> > > > > static char *ftpat = "%s/ftdetect/*.vim";
> > > > > int len;
> > > > > char_u *pat;
> > > > > --- 3376,3382
> > > > >
> > > > > if (load_files)
> > > > > {
> > > > > ! static char *plugpat = "%s/plugin/**/*.vim";
> > > > > static char *ftpat = "%s/ftdetect/*.vim";
> > > > > int len;
> > > > > char_u *pat;
> > > > [...]
> > > >
> > > > I'm afraid this is not a good idea. Wildcards are expanded depth
> > > > first, which means dependencies are now loaded before the main script.
> > > > This breaks scripts that are themselves designed to use plugins, e.g.:
> > > >
> > > > Error detected while processing
> > > > /home/lcd047/Git/Vim/textobj-comment/plugin/textobj/comment.vim:
> > > > line 27:
> > > > E117: Unknown function: textobj#user#plugin
> > > > Press ENTER or type command to continue
> > > >
> > > > I believe this seemingly unrelated report is likely to be another
> > > > symptom of the same problem:
> > > >
> > > > On 3 April 2016, Naruhiko Nishino wrote:
> > > > > Hi Bram,
> > > > >
> > > > > I found a case below when using `:packloadall` in .vimrc.
> > > > >
> > > > > A/plugin/a.vim -- call B's autoload functions.
> > > > > B/plugin/b.vim
> > > > >
> > > > > I think A can laod B's autoload functions.
> > > > > Do you think this?
> > > > [...]
> > >
> > > Hmm, plugins were always loaded this way. See main.c:
> > >
> > > source_runtime((char_u *)"plugin/**/*.vim", DIP_ALL);
> > >
> > > So, why did this work fine before but not now?
> >
> > "textobj-comment" in my example above is this package:
> >
> > https://github.com/glts/vim-textobj-comment
> >
> > It doesn't do anything by itself, it's just a plugin for
> > "textobj-user", which itself is a framework that can load specially
> > crafted plugins:
> >
> > https://github.com/kana/vim-textobj-user
> >
> > "textobj-comment" doesn't need, nor expects, to be run from anything
> > else than "textobj-user". Its structure looks like this:
> >
> > textobj-comment
> > |-- Makefile
> > |-- README.markdown
> > |-- VimFlavor
> > |-- addon-info.json
> > |-- autoload
> > | `-- textobj
> > | `-- comment.vim
> > |-- doc
> > | |-- tags
> > | `-- textobj-comment.txt
> > |-- plugin
> > | `-- textobj
> > | `-- comment.vim
> > `-- t
> > |-- fixtures
> > | |-- Inline.java
> > | |-- paired.c
> > | `-- simple.py
> > |-- inline.vim
> > |-- leaders.vim
> > |-- paired.vim
> > |-- plugin.vim
> > |-- simple.vim
> > `-- util
> > `-- helpers.vim
>
> Well, that is confusing. vim-textobj-user calls itself a plugin, but
> it doesn't have a plugin file.
It is indeed confusing. First, the word "plugin" is overloaded
above. For the purpose of this discussion, let's refer to Vim plugins
as "packages", and save "plugins" for the more general concept of
"modules loaded on-demand by something else".
> There is no mention of how to install it, I assume one has to trop
> the "autoload/textobj/user.vim into ~/.vim/autoload/textobj/user.vim.
> Thus it's to be invoked from other plugins, functions as a kind of
> library.
>
> So vim-textobj-comment is a plugin, and its plugin/textobj/comment.vim
> must be sourced for it to become active. It depends on
> vim-textobj-user to exist, but of course the user must make sure it
> can be found, thus it must be in 'runtimepath'.
No. "vim-textobj-user" is a framework for extending text objects.
It does nothing by itself, but it can load third-party plugins to create
new text objects. Various Vim packages are available, that provide
these plugins. "vim-textobj-comment" is such a package, that adds text
objects for comments.
"vim-textobj-user" can make sense without "vim-textobj-comment", if
other plugins are installed that provide text objects for it.
"vim-textobj-comment" needs "vim-textobj-user" to do anything
useful, and it doesn't make sense without it. You can think of
"vim-textobj-com
Re: Patch 7.4.1699
On 3 April 2016, Bram Moolenaar wrote:
>
> Lcd wrote:
>
> > On 2 April 2016, Bram Moolenaar wrote:
> > >
> > > Patch 7.4.1699
> > > Problem::packadd does not work the same when used early or late.
> > > Solution: Always load plugins matching "plugin/**/*.vim".
> > > Files: src/ex_cmds2.c, src/testdir/test_packadd.vim
> > >
> > >
> > > *** ../vim-7.4.1698/src/ex_cmds2.c2016-03-19 14:16:34.611690741
> > > +0100
> > > --- src/ex_cmds2.c2016-04-02 22:29:44.513040078 +0200
> > > ***
> > > *** 3376,3382
> > >
> > > if (load_files)
> > > {
> > > ! static char *plugpat = "%s/plugin/*.vim";
> > > static char *ftpat = "%s/ftdetect/*.vim";
> > > int len;
> > > char_u *pat;
> > > --- 3376,3382
> > >
> > > if (load_files)
> > > {
> > > ! static char *plugpat = "%s/plugin/**/*.vim";
> > > static char *ftpat = "%s/ftdetect/*.vim";
> > > int len;
> > > char_u *pat;
> > [...]
> >
> > I'm afraid this is not a good idea. Wildcards are expanded depth
> > first, which means dependencies are now loaded before the main script.
> > This breaks scripts that are themselves designed to use plugins, e.g.:
> >
> > Error detected while processing
> > /home/lcd047/Git/Vim/textobj-comment/plugin/textobj/comment.vim:
> > line 27:
> > E117: Unknown function: textobj#user#plugin
> > Press ENTER or type command to continue
> >
> > I believe this seemingly unrelated report is likely to be another
> > symptom of the same problem:
> >
> > On 3 April 2016, Naruhiko Nishino wrote:
> > > Hi Bram,
> > >
> > > I found a case below when using `:packloadall` in .vimrc.
> > >
> > > A/plugin/a.vim -- call B's autoload functions.
> > > B/plugin/b.vim
> > >
> > > I think A can laod B's autoload functions.
> > > Do you think this?
> > [...]
>
> Hmm, plugins were always loaded this way. See main.c:
>
> source_runtime((char_u *)"plugin/**/*.vim", DIP_ALL);
>
> So, why did this work fine before but not now?
"textobj-comment" in my example above is this package:
https://github.com/glts/vim-textobj-comment
It doesn't do anything by itself, it's just a plugin for
"textobj-user", which itself is a framework that can load specially
crafted plugins:
https://github.com/kana/vim-textobj-user
"textobj-comment" doesn't need, nor expects, to be run from anything
else than "textobj-user". Its structure looks like this:
textobj-comment
|-- Makefile
|-- README.markdown
|-- VimFlavor
|-- addon-info.json
|-- autoload
| `-- textobj
| `-- comment.vim
|-- doc
| |-- tags
| `-- textobj-comment.txt
|-- plugin
| `-- textobj
| `-- comment.vim
`-- t
|-- fixtures
| |-- Inline.java
| |-- paired.c
| `-- simple.py
|-- inline.vim
|-- leaders.vim
|-- paired.vim
|-- plugin.vim
|-- simple.vim
`-- util
`-- helpers.vim
> You mention dependencies, but there is no promise made about what
> order the files are loaded, so no dependencies can be handled.
"textobj-user" can handle all its dependencies, and can load
plugins such as "textobj-comment". The problem arises when Vim is
overly enthusiastic about finding something to initialise about
"textobj-comment".
This entire situation exists because for many years before the
package feature there was no official standard for what a Vim plugin
should be. There was only a de facto standard started by (I think)
Vundle and pathogen, but the writers of other plugin managers read
that their own way. So right now we have plugins that expect Vim to
look only in "plugin/", and plugins that expect it to look deeper.
These can't coexist in the new package scheme, so you'll have to make a
choice. Either way some of them will break, and will have to be fixed.
Now, in my experience most plugins expect Vim to source only
"plugin/*.vim", not "plugin/**.vim". But that's only my experience,
and I'm obviously only familiar to a tiny minority of plugins compared
to what exists out there. But I still think "plugin/*.vim" makes more
sense. *shrug*
> The error suggests an autoload file is used. But 'runtimepath' is
> update before the files are sourced, thus the autoload directory
> should already be found. I don't see how the change relates to that.
> Also, the path you mention is not under a package, and the change is
> for
> :packadd and :packloadall.
>
> We can change it to fist load plugin/*.vim and then plugin/*/**/*.vim,
> but I wonder why.
/lcd
--
--
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
Re: Patch 7.4.1699
On 2 April 2016, Bram Moolenaar wrote:
>
> Patch 7.4.1699
> Problem::packadd does not work the same when used early or late.
> Solution: Always load plugins matching "plugin/**/*.vim".
> Files: src/ex_cmds2.c, src/testdir/test_packadd.vim
>
>
> *** ../vim-7.4.1698/src/ex_cmds2.c2016-03-19 14:16:34.611690741 +0100
> --- src/ex_cmds2.c2016-04-02 22:29:44.513040078 +0200
> ***
> *** 3376,3382
>
> if (load_files)
> {
> ! static char *plugpat = "%s/plugin/*.vim";
> static char *ftpat = "%s/ftdetect/*.vim";
> int len;
> char_u *pat;
> --- 3376,3382
>
> if (load_files)
> {
> ! static char *plugpat = "%s/plugin/**/*.vim";
> static char *ftpat = "%s/ftdetect/*.vim";
> int len;
> char_u *pat;
[...]
I'm afraid this is not a good idea. Wildcards are expanded depth
first, which means dependencies are now loaded before the main script.
This breaks scripts that are themselves designed to use plugins, e.g.:
Error detected while processing
/home/lcd047/Git/Vim/textobj-comment/plugin/textobj/comment.vim:
line 27:
E117: Unknown function: textobj#user#plugin
Press ENTER or type command to continue
I believe this seemingly unrelated report is likely to be another
symptom of the same problem:
On 3 April 2016, Naruhiko Nishino wrote:
> Hi Bram,
>
> I found a case below when using `:packloadall` in .vimrc.
>
> A/plugin/a.vim -- call B's autoload functions.
> B/plugin/b.vim
>
> I think A can laod B's autoload functions.
> Do you think this?
[...]
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Comments on packages documentation
On 27 March 2016, Bram Moolenaar wrote: > > Tyru wrote: > [...] > > * In some places in repeat.txt, backtick(`) was used instead of bar(|) > > like `:packadd`. > > But almost quoted words seem to have its own helptag. > > If there is a helptag, it should be quoted by bar so a user can jump it. > > The backticks work like bars, but highlight the text as a command. I > started doing this a year ago, so there are still lots of commands in > bars. The idea is to use backticks where possible. Any idea what was the first version of Vim that supported backticks in help files? /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug: read from free'd memory when jumping from a quickfix list
On 19 March 2016, Dominique Pellé wrote: > LCD 47 wrote: [...] > > > > As I said, I can't reproduce the problem in a simpler setup. As > > any self-respecting Heisenbug, I can't even reproduce it in gdb. > > > > /lcd > > > > Hi LCD, > > If you can still reproduce this bug, can you check > whether recent patch 7.4.1592 fixes it? > > patch 7.4.1592 > Problem:Quickfix code using memory after being freed. (Dominique Pelle) > Solution: Detect that the window was closed. (Hirohito Higashi) It doesn't seem like the same scenario, f.i. my situation didn't involve closing any window. I'll try to reproduce the bug tomorrow. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1551
On 14 March 2016, Bram Moolenaar wrote: > > Lcd wrote: > > > On 12 March 2016, Bram Moolenaar wrote: > > > > > > Patch 7.4.1551 > > > Problem:Cannot generate help tags in all doc directories. > > > Solution: Make ":helptags ALL" work. > > > Files: src/ex_cmds2.c, src/proto/ex_cmds2.pro, src/ex_cmds.c, > > > src/vim.h, > > > src/testdir/test_packadd.vim > > [...] > > > > I get a segfault running ":helptags ALL": [...] > > Well, don't do that then! :-) > > Looks like a double free... Fixed by 7.4.1562, thank you! /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1551
On 12 March 2016, Bram Moolenaar wrote: > > Patch 7.4.1551 > Problem:Cannot generate help tags in all doc directories. > Solution: Make ":helptags ALL" work. > Files: src/ex_cmds2.c, src/proto/ex_cmds2.pro, src/ex_cmds.c, src/vim.h, > src/testdir/test_packadd.vim [...] I get a segfault running ":helptags ALL": (gdb) bt #0 0x in kill () at /lib/libc.so.6 #1 0x081c6969 in may_core_dump () at os_unix.c:3296 #2 0x081c6838 in mch_exit (r=1) at os_unix.c:3262 #3 0x082c4d1b in getout (exitval=1) at main.c:1532 #4 0x08173e8b in preserve_exit () at misc1.c:9488 #5 0x081ccbb8 in deathtrap (sigarg=6) at os_unix.c:1109 #6 0x in () #7 0x in raise () at /lib/libc.so.6 #8 0x in abort () at /lib/libc.so.6 #9 0x in __libc_message () at /lib/libc.so.6 #10 0x in _int_free () at /lib/libc.so.6 #11 0x in free () at /lib/libc.so.6 #12 0x0817922e in vim_free (x=0x9edde68) at misc2.c:1695 #13 0x081765d5 in FreeWild (count=0, files=0x9eddde8) at misc1.c:11181 #14 0x080e70eb in do_in_path (path=0x9eda750 "/home/lcd047/.vim,/usr/local/share/vim/vimfiles,/usr/local/share/vim,/usr/local/share/vim/vimfiles/after,/home/lcd047/.vim/after", name=0x82d4c35 "doc", flags=3, callback= 0x80ddeb0 , cookie=0xbfe019d8) at ex_cmds2.c:3049 #15 0x080c in ex_helptags (eap=0xbfe01cf0) at ex_cmds.c:6965 #16 0x080ee8ea in do_one_cmd (cmdlinep=0xbfe02210, sourcing=0, cstack=0xbfe01ef8, fgetline=0x810e390 , cookie=0x0) at ex_docmd.c:2921 #17 0x080ea916 in do_cmdline (cmdline=0x0, fgetline=0x810e390 , cookie=0x0, flags=0) at ex_docmd.c:1107 #18 0x0819764b in nv_colon (cap=0xbfe02380) at normal.c:5325 #19 0x0818da92 in normal_cmd (oap=0xbfe02450, toplevel=1) at normal.c:1149 #20 0x082c56ce in main_loop (cmdwin=0, noexmode=0) at main.c:1353 #21 0x082c164f in main (argc=1, argv=0xbfe02804) at main.c:1045 /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1553
On 13 March 2016, Bram Moolenaar wrote: > > I wrote: > > > Patch 7.4.1553 > > Problem:":runtime" does not use 'packpath'. > > Solution: Add "what" argument. > > Files: src/ex_cmds2.c, src/vim.h, runtime/doc/repeat.txt, > > src/testdir/test_packadd.vim > > This completes the todo items I had for package support. Please check > out the feature and let us know if something could be improved. The > help can be found with ":help packages". The result is _very_ nice, thank you. One more issue though: if :packloadall is used to load packages early and there is an error in one of the sourced plugins, the entire operation seem to be aborted instead of going on with the next plugins. As a result, this can break colorscheme again. :) Mostly unrelated: the directory structure of plugins should be documented explicitly. Right now there is a de facto standard, and most of the relevant bits and pieces are mentioned in the manual, but the information is scattered across different sections and files. It would be nice to have it all in a single place, for people that might consider writing their first plugin. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.1516
On 8 March 2016, Bram Moolenaar wrote:
>
> Patch 7.4.1516
> Problem:Cannot change file permissions.
> Solution: Add setfperm().
[...]
> + setfperm({fname}, {mode}) *setfperm()* *chmod*
> + Set the file permissions for {fname} to {mode}.
> + {mode} must be a string with 9 characters. It is of the form
> + "rwxrwxrwx",
[...]
This is a nice addition, but I think it would be pretty easy to also
support numeric permissions. Some of us really prefer to think of 0755
instead of rwxr-xr-x. :)
/lcd
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: More package semantics
On 7 March 2016, Bram Moolenaar wrote: > > Lcd wrote: > [...] > > The point is, the main problem packages are supposed to solve > > is to be able to distribute groups of plugins as packages. So one > > could have: > > > > pack/mypack1/opt/plugin1 > > pack/mypack1/opt/library1 > > pack/mypack1/opt/library2 > > > > pack/mypack2/opt/plugin2 > > pack/mypack2/opt/library3 > > > > and one would be able to enable / disable mypack1 and mypack2 > > independently to one another, with > > > > packadd mypack1 > > packadd mypack2 > > > > It seems to me this would make more sense than the current > > scheme: > > > > packadd plugin1 > > packadd library1 > > packadd library2 > > > > packadd plugin2 > > packadd library3 > > > > --- simply because there's no point in having enabled just plugin1 > > and library3. > > The mypack1 plugin would contain the packadd commands to load the > libraries it uses. And that can change over time. The user should > only do "packadd plugin1" and "packadd plugin2", the rest is loaded by > the plugins. Hmm, packadd can be nested. This is an interesting point, I don't think any of the popular plugin managers have an equivalent feature. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Colour schemes as packages
On 7 March 2016, Ben Fritz wrote: > On Monday, March 7, 2016 at 3:18:06 PM UTC-6, Bram Moolenaar wrote: > > Lcd wrote: > > > > > Placing a colour scheme like this should work, but it doesn't: > > > > > > $VIM/vimfiles/pack/my/ever/molokai/colors/molokai.vim > > > > > > The reason it doesn't work is that mandatory plugins are > > > sourced after vimrc, and thus the new scheme can't be set from > > > vimrc. > > > > > > To make it work, it can be made optional: > > > > > > $VIM/vimfiles/pack/my/opt/molokai/colors/molokai.vim > > > > > > and then it can be forced to load early with a packadd: > > > > > > packadd molokai > > > colorscheme molokai > > > > > > > The simplest solution (for the user) would be that :colorscheme also > > finds matches in the "ever" directory under 'packpath'. > > > > I like this idea. To me :colorscheme already means "find the > colors/schemename.vim file in my runtime and source it". I think > searching packages as well just makes sense for colorscheme. Possibly > :runtime! as well but that's more tricky and we can already :packadd > before using :runtime. As it is now, :packadd works only with optional packages. > > That's not a generic solution though. Perhaps we need > > ":packaddever". Or ":packadd EVER". > > > > Do we need a generic solution? We probably do. There are other similar situations to consider: autoload, after, ftplugin, syntax, indent, compilers, and probably others I don't remember rigt now. Not only we'd need a special case for each of those, but loading them before the "main" file can bomb out. > Normal plugins have never worked that way. Until recently "normal" plugins were always handled by plugin managers. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
More package semantics
With an optional package placed like this: pack/my/opt/mydebug/plugin/debugger.vim one can enable it with a packadd: packadd mydebug However, it seems to me it would make more sense to be able to do it by calling: packadd my The point is, the main problem packages are supposed to solve is to be able to distribute groups of plugins as packages. So one could have: pack/mypack1/opt/plugin1 pack/mypack1/opt/library1 pack/mypack1/opt/library2 pack/mypack2/opt/plugin2 pack/mypack2/opt/library3 and one would be able to enable / disable mypack1 and mypack2 independently to one another, with packadd mypack1 packadd mypack2 It seems to me this would make more sense than the current scheme: packadd plugin1 packadd library1 packadd library2 packadd plugin2 packadd library3 --- simply because there's no point in having enabled just plugin1 and library3. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Colour schemes as packages
Placing a colour scheme like this should work, but it doesn't: $VIM/vimfiles/pack/my/ever/molokai/colors/molokai.vim The reason it doesn't work is that mandatory plugins are sourced after vimrc, and thus the new scheme can't be set from vimrc. To make it work, it can be made optional: $VIM/vimfiles/pack/my/opt/molokai/colors/molokai.vim and then it can be forced to load early with a packadd: packadd molokai colorscheme molokai The only problem is, logically it isn't an optional package. There is no point in disabling a colour scheme. Pathogen doesn't have this problem because you're supposed to call pathogen#infect() near the top of vimrc, so all plugins are loaded early. It would be nice to have a command to force mandatory plugins to load at a given point. /lcd -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
