On Mon, Aug 22, 2016 at 3:40 PM, Bram Moolenaar <b...@moolenaar.net> wrote:
>
> Justin M. Keyes wrote:
>
>> On Mon, Aug 22, 2016 at 2:29 PM, Bram Moolenaar <b...@moolenaar.net> wrote:
>> >
>> > David Fishburn wrote:
>> >
>> >> On Sat, Aug 20, 2016 at 12:37 PM, Bram Moolenaar <b...@moolenaar.net>
>> >> wrote:
>> >>
>> >> >
>> >> > Patch 7.4.2231
>> >> > Problem: ":oldfiles" output is a very long list.
>> >> > Solution: Add a pattern argument. (Coot, closes #575)
>> >> >
>> >> >
>> >> I was wondering if something similar to this could be added to the :let
>> >> command (though it has a lot of permutations).
>> >>
>> >> I can do the following:
>> >> :let g:
>> >>
>> >> I would love to do the following:
>> >> :let g:loaded_db\w\+
>> >>
>> >> And return only those matching variables.
>> >
>> > Are we going to get this request for any command with a long output
>> > list?
>> >
>> > Perhaps we better add a generic way to filter the output. Unfortunately
>> > we can't use "command | grep /pattern/". Not all commands accept
>> > another command following. We could put it in front:
>> >
>> > filter /pattern/ command
>> >
>> > It's like a command modifier then. But one with an argument.
>> > Note that the filtering would happen line-by-line, thus if there is an
>> > item that takes several lines only matching ones would show up.
>>
>> Why not use the conventions already built-in to Vim, i.e., ":global"?
>> If :read was enhanced to take a colon-prefixed Vim command:
>>
>> :read :let
>> :g!/foo/d
>>
>> all of these requests would be satisfied implicitly, as well as fix a
>> long-standing omission of :read. And it also re-uses existing Vim
>> concepts (":global" + buffer manipulation) instead of inventing new
>> workarounds like :filter.
>>
>> Enhancing :read to treat colon-prefixed commands as Vim commands is
>> analogous to the way read treats !-prefixed commands.
>
> That's an interesting idea. It's already possible indirectly using
> :redir. But having it in one command is more convenient. Well, with a
> little bit of typing you can have it on one command:
>
> :$put =execute('let')
>
> And you could also filter that:
>
> :$put =filter(split(execute('let'), '\n'), {i, v -> v =~ 'pat'})
>
> But that is not something you would like to type.
>
> However, we were discussing listing items, not changing the buffer.
> Just like "ps | grep pattern" can be used to find something in a long
> list.
Understood. But generally these problems always involve the
limitations of the Vim internal "pager". They could be elegantly
addressed by side-stepping the pager so that command output can be
treated in practice as an expression. execute() was a good step
towards that; its implementation could be re-used to implement `:read
:foo`.
An alternative is to make the pager more flexible. But to me that's
"six of one, half-dozen of another". A more-flexible pager IMO should
be implemented as a buffer.
The main value of the Vim internal pager is (1) to avoid breaking the
window layout, and (2) modal behavior. If window layout were exposed
so that it could be preserved, the pager is obviated: a buffer/window
can be used to page output (perhaps some sort of "modal flag"), and
the window layout restored after dismissal.
Related Neovim issue (for reference only, doesn't add much to this
discussion): https://github.com/neovim/neovim/issues/3933
---
Justin M. Keyes
--
--
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.
