Re: Using file name with quickfix commands
Ramel Eshed wrote: > > > > Strange. Oh, perhaps it's because this "mybuf" is near the start of the > > > > buffer list? I reversed the search order, thinking that there is a > > > > higher chance of searching for a newer buffer. > > > > > > > > You can try changing buflist_findname_stat() from: > > > > > > > > for (buf = lastbuf; buf != NULL; buf = buf->b_prev) > > > > > > > > To: > > > > > > > > for (buf = firstbuf; buf != NULL; buf = buf->b_next) > > > > > > > > You can also try adding a new buffer after filling the quickfix list and > > > > calling setbufvar() on that one. > > > > > > > > Anyway, how relevant is calling setbufvar() 4 times? > > > > Can you use a buffer number instead of a name (would be more reliable > > > > anyway)? > > > > > > > When adding the buffer after filling the quickfix list it takes 3.7s > > > instead of 6.5. When using buffer number it takes 0.15s if the buffer > > > is the last one, but it's still slow (3.1s) if the buffer was created > > > before the list. > > > > > > I not sure if this specific use case is relevant (It was relevant to > > > me, before I made some optimizations to my script...), but I'm sure > > > that there are many other operations which involve searching in the > > > buffers list that can slow down Vim when there are many quickfix > > > items. > > > > Please try this again after patch 7.4.2036. The lookup of a buffer by > > number should be a lot faster. > > Yes. It is very fast now. Thanks for checking. Then we'll drop the idea to add an option not get a buffer for quickfix errors. -- FATHER:You only killed the bride's father - that's all - LAUNCELOT: Oh dear, I didn't really mean to... FATHER:Didn't mean to? You put your sword right through his head! LAUNCELOT: Gosh - Is he all right? "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Using file name with quickfix commands
On Thursday, July 14, 2016 at 11:34:36 PM UTC+3, Bram Moolenaar wrote: > Ramel Eshed wrote: > > > > Strange. Oh, perhaps it's because this "mybuf" is near the start of the > > > buffer list? I reversed the search order, thinking that there is a > > > higher chance of searching for a newer buffer. > > > > > > You can try changing buflist_findname_stat() from: > > > > > > for (buf = lastbuf; buf != NULL; buf = buf->b_prev) > > > > > > To: > > > > > > for (buf = firstbuf; buf != NULL; buf = buf->b_next) > > > > > > You can also try adding a new buffer after filling the quickfix list and > > > calling setbufvar() on that one. > > > > > > Anyway, how relevant is calling setbufvar() 4 times? > > > Can you use a buffer number instead of a name (would be more reliable > > > anyway)? > > > > > When adding the buffer after filling the quickfix list it takes 3.7s > > instead of 6.5. When using buffer number it takes 0.15s if the buffer > > is the last one, but it's still slow (3.1s) if the buffer was created > > before the list. > > > > I not sure if this specific use case is relevant (It was relevant to > > me, before I made some optimizations to my script...), but I'm sure > > that there are many other operations which involve searching in the > > buffers list that can slow down Vim when there are many quickfix > > items. > > Please try this again after patch 7.4.2036. The lookup of a buffer by > number should be a lot faster. Yes. It is very fast now. > > > Anyway, I don't think that saving all the buffers of the search > > results by default is a good idea. This way you can easily find > > yourself dealing with 4 digits buffer numbers while you have only few > > that you're actually working on. > > A user is not really expected to deal with buffer numbers, there are > many other ways to find the right buffer. > > In the other thread the discussion about the disadvantages of not > storing a file as a buffer were relevant. Also, adding an option to all > quickfix commands that add an entry is not nice. > > There are other ways to end up with lots of buffers, it is good to make > that fast anyway. > > > -- > GALAHAD: No, please. Please! I can defeat them! There's only a hundred. > GIRLS: He will beat us easily. We haven't a chance. > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ > ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org/// > \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Using file name with quickfix commands
Ramel Eshed wrote: > > Strange. Oh, perhaps it's because this "mybuf" is near the start of the > > buffer list? I reversed the search order, thinking that there is a > > higher chance of searching for a newer buffer. > > > > You can try changing buflist_findname_stat() from: > > > > for (buf = lastbuf; buf != NULL; buf = buf->b_prev) > > > > To: > > > > for (buf = firstbuf; buf != NULL; buf = buf->b_next) > > > > You can also try adding a new buffer after filling the quickfix list and > > calling setbufvar() on that one. > > > > Anyway, how relevant is calling setbufvar() 4 times? > > Can you use a buffer number instead of a name (would be more reliable > > anyway)? > > > When adding the buffer after filling the quickfix list it takes 3.7s > instead of 6.5. When using buffer number it takes 0.15s if the buffer > is the last one, but it's still slow (3.1s) if the buffer was created > before the list. > > I not sure if this specific use case is relevant (It was relevant to > me, before I made some optimizations to my script...), but I'm sure > that there are many other operations which involve searching in the > buffers list that can slow down Vim when there are many quickfix > items. Please try this again after patch 7.4.2036. The lookup of a buffer by number should be a lot faster. > Anyway, I don't think that saving all the buffers of the search > results by default is a good idea. This way you can easily find > yourself dealing with 4 digits buffer numbers while you have only few > that you're actually working on. A user is not really expected to deal with buffer numbers, there are many other ways to find the right buffer. In the other thread the discussion about the disadvantages of not storing a file as a buffer were relevant. Also, adding an option to all quickfix commands that add an entry is not nice. There are other ways to end up with lots of buffers, it is good to make that fast anyway. -- GALAHAD: No, please. Please! I can defeat them! There's only a hundred. GIRLS: He will beat us easily. We haven't a chance. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Using file name with quickfix commands
Ramel Eshed wrote:
[...]
> > > 2) The following script:
> > >
> > > func! Setbv()
> > > let rt = reltime()
> > > for i in range (1, 4)
> > > call setbufvar('mybuf', 'myvar', 2)
> > > endfor
> > > echo reltimestr(reltime(rt))
> > > endfunc
> > >
> > > Before setting any quickfix list it takes 0.22s. After setting a
> > > quickfix list with 8 entries it takes 6.5 seconds, which is
> > > actually worse than how it was before the last patches (it took then
> > > 3.56s).
> >
> > Strange. Oh, perhaps it's because this "mybuf" is near the start of the
> > buffer list? I reversed the search order, thinking that there is a
> > higher chance of searching for a newer buffer.
> >
> > You can try changing buflist_findname_stat() from:
> >
> > for (buf = lastbuf; buf != NULL; buf = buf->b_prev)
> >
> > To:
> >
> > for (buf = firstbuf; buf != NULL; buf = buf->b_next)
> >
> > You can also try adding a new buffer after filling the quickfix list and
> > calling setbufvar() on that one.
> >
> > Anyway, how relevant is calling setbufvar() 4 times?
> > Can you use a buffer number instead of a name (would be more reliable
> > anyway)?
> >
> When adding the buffer after filling the quickfix list it takes 3.7s
> instead of 6.5. When using buffer number it takes 0.15s if the buffer
> is the last one, but it's still slow (3.1s) if the buffer was created
> before the list.
>
> I not sure if this specific use case is relevant (It was relevant to
> me, before I made some optimizations to my script...), but I'm sure
> that there are many other operations which involve searching in the
> buffers list that can slow down Vim when there are many quickfix
> items.
> Anyway, I don't think that saving all the buffers of the search
> results by default is a good idea. This way you can easily find
> yourself dealing with 4 digits buffer numbers while you have only few
> that you're actually working on.
The option to store the file name as a string, not in a buffer, has been
discussed, but it has disadvantages. At least it adds another option,
with consequences for what data is stored in the error lists.
An alternative is to create an index for the buffers. Instead of going
through the list linearly it would use a dictionary to lookup by name or
by number. This means adding and removing a buffer becomes more
expensive. But lookups become much faster.
Actually, lookup by name using a hash table won't really work, at least
not for Unix, because the same file can have more than one name.
I would expect lookup by number to be more frequent anyway.
--
They now pass three KNIGHTS impaled to a tree. With their feet off the
ground, with one lance through the lot of them, they are skewered up
like a barbecue.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Using file name with quickfix commands
> > > > Before setting any quickfix list it takes 0.22s. After setting a > > quickfix list with 8 entries it takes 6.5 seconds, which is > > actually worse than how it was before the last patches (it took then > > 3.56s). > > Strange. Oh, perhaps it's because this "mybuf" is near the start of the > buffer list? I reversed the search order, thinking that there is a > higher chance of searching for a newer buffer. > > You can try changing buflist_findname_stat() from: > > for (buf = lastbuf; buf != NULL; buf = buf->b_prev) > > To: > > for (buf = firstbuf; buf != NULL; buf = buf->b_next) > Is it worth the effort to try using a data structure with faster lookup times than a linear search of a linked list? I imagine 80,000 buffers is not a very common case but just using a BST of some kind could probably improve that performance immensely, and probably won't hurt the more common cases noticeably. I assume there is a unique ID (like the buffer number?) we could use for the key. -- -- 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 Monday, July 11, 2016 at 12:33:28 PM UTC+3, Bram Moolenaar wrote:
> Ramel Eshed wrote:
>
> > On Sunday, July 10, 2016 at 8:23:15 PM UTC+3, 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.
> > >
> > > I have optimized the quickfix code with the last few patches. It's a
> > > lot faster now, especially when there are several matches in the same
> > > file. Let's see if Ramel thinks this is good enough, then we don't need
> > > to add the workaround.
> > >
> > I've checked 2 test cases:
> >
> > 1) Adding many (80,000+) entries to quickfix list: here I see huge
> > improvement -from 6.76 seconds to 0.38 (!!).
>
> Glad to hear my changes were effective.
>
> > 2) The following script:
> >
> > func! Setbv()
> > let rt = reltime()
> > for i in range (1, 4)
> > call setbufvar('mybuf', 'myvar', 2)
> > endfor
> > echo reltimestr(reltime(rt))
> > endfunc
> >
> > Before setting any quickfix list it takes 0.22s. After setting a
> > quickfix list with 8 entries it takes 6.5 seconds, which is
> > actually worse than how it was before the last patches (it took then
> > 3.56s).
>
> Strange. Oh, perhaps it's because this "mybuf" is near the start of the
> buffer list? I reversed the search order, thinking that there is a
> higher chance of searching for a newer buffer.
>
> You can try changing buflist_findname_stat() from:
>
> for (buf = lastbuf; buf != NULL; buf = buf->b_prev)
>
> To:
>
> for (buf = firstbuf; buf != NULL; buf = buf->b_next)
>
> You can also try adding a new buffer after filling the quickfix list and
> calling setbufvar() on that one.
>
> Anyway, how relevant is calling setbufvar() 4 times?
> Can you use a buffer number instead of a name (would be more reliable
> anyway)?
>
When adding the buffer after filling the quickfix list it takes 3.7s instead of
6.5. When using buffer number it takes 0.15s if the buffer is the last one, but
it's still slow (3.1s) if the buffer was created before the list.
I not sure if this specific use case is relevant (It was relevant to me, before
I made some optimizations to my script...), but I'm sure that there are many
other operations which involve searching in the buffers list that can slow down
Vim when there are many quickfix items.
Anyway, I don't think that saving all the buffers of the search results by
default is a good idea. This way you can easily find yourself dealing with 4
digits buffer numbers while you have only few that you're actually working on.
--
--
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 u
Re: Using file name with quickfix commands
Ramel Eshed wrote:
> On Sunday, July 10, 2016 at 8:23:15 PM UTC+3, 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.
> >
> > I have optimized the quickfix code with the last few patches. It's a
> > lot faster now, especially when there are several matches in the same
> > file. Let's see if Ramel thinks this is good enough, then we don't need
> > to add the workaround.
> >
> I've checked 2 test cases:
>
> 1) Adding many (80,000+) entries to quickfix list: here I see huge
> improvement -from 6.76 seconds to 0.38 (!!).
Glad to hear my changes were effective.
> 2) The following script:
>
> func! Setbv()
> let rt = reltime()
> for i in range (1, 4)
> call setbufvar('mybuf', 'myvar', 2)
> endfor
> echo reltimestr(reltime(rt))
> endfunc
>
> Before setting any quickfix list it takes 0.22s. After setting a
> quickfix list with 8 entries it takes 6.5 seconds, which is
> actually worse than how it was before the last patches (it took then
> 3.56s).
Strange. Oh, perhaps it's because this "mybuf" is near the start of the
buffer list? I reversed the search order, thinking that there is a
higher chance of searching for a newer buffer.
You can try changing buflist_findname_stat() from:
for (buf = lastbuf; buf != NULL; buf = buf->b_prev)
To:
for (buf = firstbuf; buf != NULL; buf = buf->b_next)
You can also try adding a new buffer after filling the quickfix list and
calling setbufvar() on that one.
Anyway, how relevant is calling setbufvar() 4 times?
Can you use a buffer number instead of a name (would be more reliable
anyway)?
--
Women are probably the main cause of free software starvation.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Using file name with quickfix commands
On Sunday, July 10, 2016 at 8:23:15 PM UTC+3, 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.
>
> I have optimized the quickfix code with the last few patches. It's a
> lot faster now, especially when there are several matches in the same
> file. Let's see if Ramel thinks this is good enough, then we don't need
> to add the workaround.
>
I've checked 2 test cases:
1) Adding many (80,000+) entries to quickfix list: here I see huge improvement
-from 6.76 seconds to 0.38 (!!).
2) The following script:
func! Setbv()
let rt = reltime()
for i in range (1, 4)
call setbufvar('mybuf', 'myvar', 2)
endfor
echo reltimestr(reltime(rt))
endfunc
Before setting any quickfix list it takes 0.22s. After setting a quickfix list
with 8 entries it takes 6.5 seconds, which is actually worse than how it
was before the last patches (it took then 3.56s).
--
--
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
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.
I have optimized the quickfix code with the last few patches. It's a
lot faster now, especially when there are several matches in the same
file. Let's see if Ramel thinks this is good enough, then we don't need
to add the workaround.
--
hundred-and-one symptoms of being an internet addict:
267. You get an extra phone line so you can get phone calls.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Using file name with quickfix commands
Since storing the file name instead of creating a buffer for entries in the quickfix list has disadvantages, I had a look at whether we can keep the current behavior and just make it faster. With a profiler I found the code where most time is spent. I did a few optimizations and it now works a lot faster. It depends on what you do, but it can easily be ten times faster. Please take the latest version and try it out with your script. Let us know whether it still seems slow. For what I tried it was grep that took most of the time, Vim adding the lines is quite fast now. Part of this is dealing with a long list of buffers. That's useful anyway. -- XML is a nice language for computers. Not for humans. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to 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
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?
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.
--
hundred-and-one symptoms of being an internet addict:
260. Co-workers have to E-mail you about the fire alarm to get
you out of the building.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to 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
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? -- Emacs is a nice OS - but it lacks a good text editor. That's why I am using Vim. --Anonymous /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to 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: Using file name with quickfix commands
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.
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.
--
hundred-and-one symptoms of being an internet addict:
247. You use www.switchboard.com instead of dialing 411 and 555-12-12
for directory assistance.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to 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: Using file name with quickfix commands
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?
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".
--
hundred-and-one symptoms of being an internet addict:
238. You think faxes are old-fashioned.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Using file name with quickfix commands
Christian Brabandt wrote: > On Do, 07 Jul 2016, Bram Moolenaar wrote: > > > > Is this only supported for quickfix commands, e.g. what happens > > > for :usefname :badd filename? > > > > No. Perhaps there could be some other commands that use ":usefname". > > Otherwise there might be a better name that makes it clearer what it > > does. > > So perhaps the command modifier should be called :qfadd which makes it > clear, it is for working with quickfix list and also meant for adding to > the list? The weird thing is that none of the quickfix commands start with :qf. They are :c and :l. ":cusefname" is not helping anyone. -- hundred-and-one symptoms of being an internet addict: 237. You tattoo your email address on your forehead. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to 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: Using file name with quickfix commands
Hi Bram! On Do, 07 Jul 2016, Bram Moolenaar wrote: > > Is this only supported for quickfix commands, e.g. what happens > > for :usefname :badd filename? > > No. Perhaps there could be some other commands that use ":usefname". > Otherwise there might be a better name that makes it clearer what it > does. So perhaps the command modifier should be called :qfadd which makes it clear, it is for working with quickfix list and also meant for adding to the list? Best, Christian -- Jede große Idee, die als ein Evangelium in die Welt tritt, wird dem stockenden pedantischen Volke ein Ärgernis und einem Viel-, aber Leichtgebildeten eine Torheit. -- Goethe, Maximen und Reflektionen, Nr. 535 -- -- 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
Ramel Eshed wrote:
> Hi Bram,
>
> On Thursday, July 7, 2016 at 10:24:49 PM UTC+3, 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?
> >
> Sounds good. Maybe we could also have an option only for search
> commands like :grep since this mode is most useful there? (Actually,
> this was one of the reasons which convinced me that quickfix is not
> the right tool to use for searches. See
> https://github.com/ramele/agrep).
What is called quickfix is what grew out of the actual quickfix feature
on the Amiga. Now it's everything related to a list of locations with
various extra bells and whistles. I would not want to duplicate code
and commands to have a separate list of search results.
> > Storing the file name instead of a buffer number has a few
> > disadvantages:
> > - When inserting or deleting lines in the file the position of the
> > quickfix items is not adjusted.
> > - Using more memory to store a copy of the file name.
> > - Changing directory can make the file name invalid. We could store the
> > full path, but creating that also adds overhead. Hmm, perhaps we
> > could store the full path the moment the directory is changed.
>
> Can't we just save the original working directory used when the
> quickfix list was created and use it when jumping to files stored with
> a relative path?
That's the same as turning the file name into a full name. Not sure how
much overhead this has. Anyway, doing it just before changing directory
is probably not too difficult.
--
hundred-and-one symptoms of being an internet addict:
227. You sleep next to your monitor. Or on top of it.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Using file name with quickfix commands
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.
> Is this only supported for quickfix commands, e.g. what happens
> for :usefname :badd filename?
No. Perhaps there could be some other commands that use ":usefname".
Otherwise there might be a better name that makes it clearer what it
does.
>
> > Storing the file name instead of a buffer number has a few
> > disadvantages:
> > - When inserting or deleting lines in the file the position of the
> > quickfix items is not adjusted.
> > - Using more memory to store a copy of the file name.
> > - Changing directory can make the file name invalid. We could store the
> > full path, but creating that also adds overhead. Hmm, perhaps we
> > could store the full path the moment the directory is changed.
>
> I think this might be a nice little feature.
--
hundred-and-one symptoms of being an internet addict:
226. You sit down at the computer right after dinner and your spouse
says "See you in the morning."
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Using file name with quickfix commands
Hi Bram,
On Thursday, July 7, 2016 at 10:24:49 PM UTC+3, 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?
>
Sounds good. Maybe we could also have an option only for search commands like
:grep since this mode is most useful there? (Actually, this was one of the
reasons which convinced me that quickfix is not the right tool to use for
searches. See https://github.com/ramele/agrep).
>
> Storing the file name instead of a buffer number has a few
> disadvantages:
> - When inserting or deleting lines in the file the position of the
> quickfix items is not adjusted.
> - Using more memory to store a copy of the file name.
> - Changing directory can make the file name invalid. We could store the
> full path, but creating that also adds overhead. Hmm, perhaps we
> could store the full path the moment the directory is changed.
Can't we just save the original working directory used when the quickfix list
was created and use it when jumping to files stored with a relative path?
--
--
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 Thursday, July 7, 2016 at 2:24:49 PM UTC-5, Bram Moolenaar wrote: > - Changing directory can make the file name invalid. We could store the > full path, but creating that also adds overhead. Hmm, perhaps we > could store the full path the moment the directory is changed. > Remember that autochdir can cause many frequent directory changes, especially for quickfix! So it will definitely need some sort of attention. -- -- 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
Hi Bram!
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? Is this only supported for quickfix commands, e.g. what happens
for :usefname :badd filename?
> Storing the file name instead of a buffer number has a few
> disadvantages:
> - When inserting or deleting lines in the file the position of the
> quickfix items is not adjusted.
> - Using more memory to store a copy of the file name.
> - Changing directory can make the file name invalid. We could store the
> full path, but creating that also adds overhead. Hmm, perhaps we
> could store the full path the moment the directory is changed.
I think this might be a nice little feature.
Best,
Christian
--
Es gibt keinen besseren Reiseführer als das Scheckbuch.
-- Heinz Drache
--
--
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.
Using file name with quickfix commands
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?
Storing the file name instead of a buffer number has a few
disadvantages:
- When inserting or deleting lines in the file the position of the
quickfix items is not adjusted.
- Using more memory to store a copy of the file name.
- Changing directory can make the file name invalid. We could store the
full path, but creating that also adds overhead. Hmm, perhaps we
could store the full path the moment the directory is changed.
--
hundred-and-one symptoms of being an internet addict:
222. You send more than 20 personal e-mails a day.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
