[vim/vim] help implement inc search in popup (Issue #16272)
qeatzy
Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
I want inc search inside popup, just like in normal window, but the task of implement it from scratch seems intimidating and duplicating many works what vim already doing.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Can vim abstract its internal code to add some api to support this, maybe mark the api as experimental until finalized or in case a better way found and implemented.
My attemp on the design
- create an inc search obj, return its id
- upon input of text changed, user call func to tell vim, vim act accordingly, return bool or first match.
- a func to goto next/prev match, similar to
<C-g>/<C-t>, probably add another to goto first match. a arg how to disguish next/prev/first. - a func to stop the inc search, second arg to tell vim move cursor to it or just cancel and restore. probably add some safe bet of auto closing in case bad user code.
I deliberately omit the process of get input text to make it simple and focused. Since different people have different preferences, some prefer getchar-echo-style as in ctrlp, some may prefer in a popup and stay at top, some may prefer a input box. Also get input is not inherently hard and many plugin writers have already done it.
some discussion and clarification.
- when inc search is active, if user call
getcurpos()/getpos(".")/line(".")should it return original postion or of active match? what's current behavior for normal window inc search. - until focus of popup implemented, user can fake cursor with
matchaddpos(), the pos arg of it comes from either inc search side effect of change cursor, or its update/move func return position of current match.
Describe alternatives you've considered
An alternative is support focusing of popup window. But it's a big topic and has many sub-features, some of which may interact in a subtle way.
A practical approach is divide into sub topics and progress individually, and divide into two part of back end and front end. The back end is low level (hard to implement in vimL and performance related), the front end is about user input and visual feedback.
Some front end task might be eventually implemented in vim, but let's refrain from it when we begin, leaving most of front end to plugin writer, and provide helper utility in case it's hard to do.
As for back end, it could start abstract code portion which works on normal mode, and extract common logic and call it in both normal window and popup window.
Otherwise, it will be a mess either
- long time of debate
- might cannot agree on a solution
- chosen solution only satisfy some people due to lack of flexibility/configuration
- one messed solution incorparating many thing can introduce many bugs, and make maintainance even harder. which in the worse case few one can work on vim codebase and make vim stagnant/fading.
One last consideration
- adding these developing apis, but mark it as experimental. And warn use not to use it, since it's mainly for plugin writers and not finalized yet.
I think focusing related features, like gd, yip, gf, inc search, etc is essential for a modern popup window inside a modern editor, otherwise it will be a half baked solution. Popup in vim should not be as limited as a tui chooser. Otherwise many useful thing cannot be done or require considerate effort, often lead to one plugin one workaround and the number of pluin writer/user will be both quite small and divided even further due to lack of common interface. Which will hurt community of vim greatly in the long run.
Additional context
Add any other context or screenshots about the feature request here.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
I don't understand what you are trying to achieve. If you want to implement incsearch inside a popup window, you can already use matchadd() family of functions to highlight matches.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.