Re: incremental search in lists

[StarWing]

On 7月13日, 上午1时39分, mobi phil  wrote:
> 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:)
>
> --
> rgrds,
> mobi phil
>
> being mobile, but including technologyhttp://mobiphil.com

expect you patch :-) I found it's a little diffcult to implement
this...
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[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:)




-- 
rgrds,
mobi phil

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

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[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 

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[StarWing]

On 7月13日, 上午12时19分, mobi phil  wrote:
> 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
>
> --
> rgrds,
> mobi phil
>
> being mobile, but including technologyhttp://mobiphil.com

you can make a tab in terminal vim... try :tab sp $MYVIMRC in terminal
vim :-)
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[StarWing]

On 7月13日, 上午12时17分, mobi phil  wrote:
> 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
>
>
>
> On Sun, Jul 12, 2009 at 9:15 AM, StarWing  wrote:
>
> > 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?
>
> --
> rgrds,
> mobi phil
>
> being mobile, but including technologyhttp://mobiphil.com

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" :-)
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in 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





-- 
rgrds,
mobi phil

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

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[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



On Sun, Jul 12, 2009 at 9:15 AM, StarWing  wrote:

>
> 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?
> >
>


-- 
rgrds,
mobi phil

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

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[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?
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[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.

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[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
> ,
> 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


--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[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
> ,
> 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 :)









-- 
rgrds,
mobi phil

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

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[Ingo Karkat]

On 11-Jul-09 17:36, mobi phil wrote:
> On Sat, Jul 11, 2009 at 4:55 PM, Ingo Karkat  > wrote:
> On 11-Jul-09 16:52, Ben Fritz wrote:
>  > 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.
> 
> ... or save the current window layout with winrestcmd() and restore
> it afterwards.
> 
> -- ingo
> 
> 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..

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 , 
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  :let selected_line = getline('.')closesilent! execute 
save_layout
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


--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[mobi phil]

On Sat, Jul 11, 2009 at 4:55 PM, Ingo Karkat  wrote:

>
> On 11-Jul-09 16:52, Ben Fritz wrote:
> > 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.
>
> ... or save the current window layout with winrestcmd() and restore it
> afterwards.
>
> -- ingo
>
>
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..



-- 
rgrds,
mobi phil

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

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[Ingo Karkat]

On 11-Jul-09 16:52, Ben Fritz wrote:
> 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.

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

-- ingo


--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[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.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[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





On Sun, Feb 22, 2009 at 5:40 PM, mobi phil  wrote:

> 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
>
>
>
>
> On Sat, Feb 21, 2009 at 7:27 PM, Nazri Ramliy  wrote:
>
>>
>> On Sat, Feb 21, 2009 at 11:55 PM, mobi phil  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
>> 
>>
>> nazri
>>
>> >>
>>
>


-- 
rgrds,
mobi phil

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

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[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



On Sat, Feb 21, 2009 at 7:27 PM, Nazri Ramliy  wrote:

>
> On Sat, Feb 21, 2009 at 11:55 PM, mobi phil  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
> 
>
> nazri
>
> >
>

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[Nazri Ramliy]

On Sun, Feb 22, 2009 at 2:27 AM, Nazri Ramliy  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
> 

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.

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: incremental search in lists

[Nazri Ramliy]

On Sat, Feb 21, 2009 at 11:55 PM, mobi phil  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


nazri

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

incremental search in lists

[mobi phil]

Hello,
I am a  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

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---