incremental search in lists

[mobi phil]

Hello,

 

I am a <search everywhere> obsessed with vim. However I miss a lot the feature to be able to (incremental) search in lists exactly as one searches in windows (buffers). Such lists are useful concepts in vim, mainly as they are similar to modal dialogs as you do not want to see them all the time, just when you need them.

 

:messages

:map

:ll

Usecase1... in my daily work it is always interesting to go back to old messages... I have a keyboard shortcut for the messages list (ctrl _lm)... but here the story ends. What I would love to do is to be able to search in this list.

Usecase2... MRU. I know there are lot of MRU implementations, but all of them they open a window and they destroy the layout of the windows... however what I think would be clever is to have a list with MRU shown, incremental search in it, enter, list is closed, and open file in the latest window as a new buffer... Similar way it would be powerfull to search in a loaded tags list, or why not, imagine a concatenated source file with all your source code. In such a buffer of concatenated files, you could incrementally search (I am using it often, but opened in a window), and once you identified the correct line, enter, and the file that represents that part of the concatenation would be opened on your last window.

Custom lists would be very interesting, and some commands to read a list from a file (elements of the list would be obviously the lines).

Another maybe exaggerated idea would be a feature to search inside completion lists... I press ctrlx f/i, thousands of files listed, or items listed, would be nice to have a shortcut

that would bring me into incremental search mode, and select faster the item I am interested in...

If you did not understand my description I am happy to give further details.

Thank you for your attention,

Mobi

http://www.mobiphil.com/?p=97

[Nazri Ramliy]

On Sat, Feb 21, 2009 at 11:55 PM, mobi phil <mo...@mobiphil.com> wrote:
> Usecase1... in my daily work it is always interesting to go back to old
> messages... I have a keyboard shortcut for the messages list (ctrl _lm)...
> but here the story ends. What I would love to do is to be able to search in
> this list.

You can extend your keyboard shortcut so that it redirects the output
of :messages to a register, then open a new window or tab, then paste
the content of that register.

:redir @a
:messages
:redir END
<open a new window or tab, then paste content of "a>

nazri

[Nazri Ramliy]

On Sun, Feb 22, 2009 at 2:27 AM, Nazri Ramliy <ayie...@gmail.com> wrote:
> You can extend your keyboard shortcut so that it redirects the output
> of :messages to a register, then open a new window or tab, then paste
> the content of that register.
>
> :redir @a
> :messages
> :redir END
> <open a new window or tab, then paste content of "a>

And then you can hit '/' and voila! Incremental search! Combine this
with a customized syntax highlight of your liking... ah the
possibilities are endless with vim!

nazri.

[mobi phil]

sorry that I posted my previous email twice.

thanks for the answer, but I knew that it was possible to achieve the same by redirecting, but that is not the same.
The main problem is that redirecting to a window, destroys the window layout. Ok, one could write more complicated
scripts to store the layout, but things would get much more complicated...

On the other side, if I reason like that I can say that lists do not have any role. Anything could be redirected,
so why to have the lists at all?

I was trying to mention that with some extra functionality in my opinion the lists would be more powerful.

I will look at the code and try find out, maybe it is trivial to implement...


mobi

[mobi phil]

hello... coming back to this question... I am insisting as it would be very usefull on vimo ( VI(m)Mo(bile).. I hope you like the new name). I am convinced you guys will use it one day when pdas will be cheaper than your threshold to buy it :)

Bram, would it be difficult to implement this? I am not asking to do so.. just some tips/tricks/bricks


rgrds
mobiphil.com
mobiphil.com/vimowiki to follow up vimo

--
rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com

[Ben Fritz]

You're worried about destroying window layout if you just redirect to
a new Window.

So why redirect to a new Window? Redirect to a new TAB PAGE instead,
then close the tab when done. Extremely simple, no additional
functionality needed, and your Window layout remains untouched.

[Ingo Karkat]

... or save the current window layout with winrestcmd() and restore it afterwards.

-- ingo

[mobi phil]

I am using vim for speed... I use this kind of lists very often. And I do not have a TAB-bed window. I tried to describe a use case, but it is difficult to convince by describing it... Completion would be one way, however that is also limited, as you cannot search in the completion lists.

I tried to describe this with the MRU files list. I use such lists intensively, and I am sure most of you do so. I have other lists like lists of links, lists of files in a projects. And the usage pattern is to find quickly a file in this list, and either insert it at the cursors position, or do a command on it. Another usage is translation. If I could open a file with translation of words in a certain language, I could search fast in the list (and more than 50% of the cases I search nor for from the beginning nor at the end of the word, I search for the pattern in the word that would bring me the result the fastest). Once the word found, enter, the result would be inserted at cursor position.


Well... I will have a look at the code and investigate myself.. I hoped smbdy would share my idea..
 

[Ingo Karkat]

Your use case sounds like "scratch buffers", which are temporarily opened by a
mapping, you navigate in it, then often select an entry by hitting <Return>,
which then closes the scratch buffer and returns to the original window. Many
plugins (project.vim, taglist.vim) use this approach to emulate an IDE's
sidebar, task list, etc. Vim's built-in command-line window (q:) and quickfix
window (:copen) are like that, too.

To implement such a thing in Vimscript, save the current window layout via
let save_layout = winrestcmd()
then :split open the scratch buffer. Inside that special buffer, you often set
up mappings to acknowledge and close that buffer, e.g.
nmap <CR> :let selected_line = getline('.')<Bar>close<Bar>silent! execute
save_layout<CR>
but you could also setup an :autocmd on closing / leaving the scratch buffer to
restore the layout. With the autocmd, you are able to close the scratch buffer
with any built-in Vim command like CTRL-W_c.

Unless I misunderstood your use case, winrestcmd() (and maybe also
winsaveview()) is all you need to implement temporary windows that restore the
window layout.

-- regards, ingo

[mobi phil]

Your use case sounds like "scratch buffers", which are temporarily opened by a
mapping, you navigate in it, then often select an entry by hitting <Return>,
which then closes the scratch buffer and returns to the original window. Many
plugins (project.vim, taglist.vim) use this approach to emulate an IDE's
sidebar, task list, etc. Vim's built-in command-line window (q:) and quickfix
window (:copen) are like that, too.

Thanks for your quick answer.
Indeed there is always a workaround. However if you look at the help of the winrestcmd function it says ... "only works properly if..."

Please do not take it as an offense, but if I would follow your reasoning practically the functionality of the lists (:map, :clist, :command, :tags etc.) they all could be implemented by the scratch buffers/windows, given that a function provides their content. The existence of the lists, and the way they are displayed tell me that they had to have a reason to be implemented as they are. And they are unbelievable useful. Just a simple example, when I have several files/buffers open, just doing :ls, and then execute :b or other commands on the buffers, I need the list of the buffers just for the short moment I take a decision/fork my workflow. If now I had to write a script to open the scratch buffer, then close it etc. etc. hm... much less people would use such feature/pattern. The pluggins you mentioned like tags.vim, projects.vim, could alse benefit be much more usefull, if they could be opened for the short period of the need (to select sthg.), etc...


anyway... I do not want to give the impression that I am blowing against the wind... I will look at the code, if somebody wants to help, that is welcome... Once implemented, I will list 100 use cases, where it will improve everyday life experience with vim :)



 

[Ingo Karkat]

On 11-Jul-09 19:07, mobi phil wrote:
> Your use case sounds like "scratch buffers", which are temporarily
> opened by a
> mapping, you navigate in it, then often select an entry by hitting
> <Return>,
> which then closes the scratch buffer and returns to the original
> window. Many
> plugins (project.vim, taglist.vim) use this approach to emulate an IDE's
> sidebar, task list, etc. Vim's built-in command-line window (q:) and
> quickfix
> window (:copen) are like that, too.
>
>
> Thanks for your quick answer.
> Indeed there is always a workaround. However if you look at the help of
> the winrestcmd function it says ... "only works properly if..."

Well, you also have to properly quote the caveat:
Only works properly when no windows are opened or closed and the current
window and tab page is unchanged.
That's why in my example, I first :close'd the scratch buffer (restoring the
previous number of windows and jumping back to the previous window, thus meeting
the preconditions), and only then restored the window sizes. Trust me, if you
stick to the rules, it all works fine.

> Please do not take it as an offense, but if I would follow your
> reasoning practically the functionality of the lists (:map, :clist,
> :command, :tags etc.) they all could be implemented by the scratch
> buffers/windows, given that a function provides their content. The
> existence of the lists, and the way they are displayed tell me that they
> had to have a reason to be implemented as they are. And they are
> unbelievable useful. Just a simple example, when I have several
> files/buffers open, just doing :ls, and then execute :b or other
> commands on the buffers, I need the list of the buffers just for the
> short moment I take a decision/fork my workflow. If now I had to write a
> script to open the scratch buffer, then close it etc. etc. hm... much
> less people would use such feature/pattern. The pluggins you mentioned
> like tags.vim, projects.vim, could alse benefit be much more usefull, if
> they could be opened for the short period of the need (to select sthg.),
> etc...
> anyway... I do not want to give the impression that I am blowing against
> the wind... I will look at the code, if somebody wants to help, that is
> welcome... Once implemented, I will list 100 use cases, where it will
> improve everyday life experience with vim :)

So you seem intent on implementing generic functionality for lists / temporary
windows. Fine, I'm looking forward to it. I actually remember one occasion when
I wanted to "tune" the output of the :tags command, but would have to emulate a
lot of built-in functionality.
By explaining what can be done today (with scratch buffers), I simply want to
avoid frustration on your side in case your enhancement is later rejected
because it can already be done with Vimscript. (Cp. :help design-goals)
On the other hand, if your enhancement really improves usability and offers
totally new ways to customize and use Vim, I'm sure I'll love that new feature.
I sincerely wish you good luck and success in improving Vim!

-- ingo

[Tony Mechelynck]

On 11/07/09 17:36, mobi phil wrote:
> I am using vim for speed... I use this kind of lists very often. And I

> do not have a TAB-bed window. [...]

What do you mean, "you don't have a tab-bed window?" If you have Vim
version 7, compiled with +windows (i.e., with the split-windows
capability), then it also has the capability to handle several "tab
pages", i.e., several "layouts" of one of more split-windows each, in a
single instance of the executable. See ":help tabpage.txt" for details.
For the use case discussed on this thread, you can open a window on a
different tabpage with ":tabnew", do anything you want there, then close
it with ":tabclose!" and you're back to wherever you were before, with
your window layout undisturbed. Depending how your script works (see
also ":help :silent" and ":help :redir"), it could even be possible to
open and close that auxiliary tab page without anyone the wiser, but I
confess I haven't tried it.

Best regards,
Tony.
--
Experience is what causes a person to make new mistakes instead of old
ones.

[StarWing]

I have a idea. a short list needn't inc-search. so you expect to
search in a long list.

you can see :h more-prompt. maybe you can make your work here. add a
key (maybe '/') here to search in list, it should be like:

-- More --
-- More -- SPACE/d/j: screen/page/line down, b/u/k up, /: search
q:quit

and when you press /, you can make inc-search, and list jump to the
position fit your pattern.

is that difficult to implement?

[mobi phil]

YES!!! you got the point... :) I can add the string... that is easy.. but implementing probably is not so straighforward, as I understand the code for list is a bit "multiplied" across the different lists....

[mobi phil]

I use vim on terminal mainly... why? just my work flows better like that...

so there are no tabs....

And I am planning to use intensively VIM no windows mobile, mainly to write and to read/use large texts

[StarWing]

or you needn't change the text, just implement your char in
do_more_prompt() function. add a "case '/':" block, and change the
document. because i notice that several command in do_more_prompt are
not in notice text (just like 'g' and 'G').

but it seems a little "hard" :-)

[StarWing]

you can make a tab in terminal vim... try :tab sp $MYVIMRC in terminal
vim :-)

[James Vega]

On Sun, Jul 12, 2009 at 06:19:11PM +0200, mobi phil wrote:
> I use vim on terminal mainly... why? just my work flows better like that...
>
> so there are no tabs....

Yes, there are tabs. Vim's tabpages work both in the console and gui
builds of Vim.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jame...@jamessan.com>

[mobi phil]

Yes, there are tabs.  Vim's tabpages work both in the console and gui

builds of Vim.

yes yes... indeed... always ignored that they are also available also on console...  I will add to my shortcats moving between tabs... as I basically need that functionality more and more...
however I am insisting on search on lists:)
 

[StarWing]

expect you patch :-) I found it's a little diffcult to implement
this...