Omniprompt broken if search is too long

[pirate486743186]

If the search is too long, the UI gets bugged up in various ways. This is apparent, when you are crammed and lack space. The underlying logic works, it's just the displaying of the text of the search that is bugged.

from terminal, do a very long search. It does the search, with the arrows, get the previous search, then if you try to move the cursor to the beginning, you can't go all the way.

In the UI, if you type too much, it comes back and overwrights the same line. If you try backspace the line is no longer visible or in part. Again, can't move the cursor all the way to the start.

I think the solution, is to simply support multiple lines in the UI. The bugs is just the one line overflowing and doing unexpected stuff. (probably the same issue in googler, didn't test that)

[jarun]

is to simply support multiple lines in the UI

Please raise the PR when you are ready with it.

[pirate486743186]

lol, i don't know how to fix it, i was just speculating.

[jarun]

Please refer to this comment of mine.

[jarun]

Refer to this link: https://stackoverflow.com/questions/30239092/how-to-get-multiline-input-from-user

and if you can fix it, raise the PR.

[jarun]

Or you can also use a wider terminal.

[pirate486743186]

O_o

I think there's some cultural misunderstanding here. You have the wrong expectations/attitude. I think you see this too much as a job. It's meant to be a hobby.

Leave the issues open, only close the ones that really need closing. You'll get duplicates and other contributors get a harder time seeing what's going on.

Just slow down development. And get some helpers.

(for the issue here, it's not about multiline input, the line doesn't wrap around properly, it should be like the python prompt)

[jarun]

Few people care about open defects in open source projects. Check out the contribution graph. So now I see it as - if you need it, fix it yourself or use the available workaround.

[jarun]

The api that I know of is input() and input() has this limitation. That needs to be addressed in python core/an alternative has to be provided instead of trying hacks in the caller's side.

[jarun]

I see the problem is using color codes in input() prompt. I see it happening even with hard-coded values:

diff --git a/ddgr b/ddgr
index f098cc5..1ffa036 100755
--- a/ddgr
+++ b/ddgr
@@ -1376,7 +1376,8 @@ class DdgCmd:

         colors = self.colors
         message = 'ddgr (? for help)'
-        self.prompt = ((colors.prompt + message + colors.reset + ' ')
+        #self.prompt = ((colors.prompt + message + colors.reset + ' ')
+        self.prompt = (('\x1b[40m' + message + '\x1b[0m' + ' ')
                        if (colors and os.getenv('DISABLE_PROMPT_COLOR') is None) else (message + ': '))

     @property

You can export DISABLE_PROMPT_COLOR=1 to disable printing the prompt in color. You can also follow up with the python package on this.

[pirate486743186]

This workaround is fine.

I have the impression, you should be using this library instead. https://github.com/prompt-toolkit/python-prompt-toolkit

You should let relevant issues open. You make it harder for people that care to contribute. You can also add a "help wanted" tag Yes, interest will still be low. You can leave issues open for years. There's zero reason to close them all. issues are documenting various stuff.

[jarun]

I don't link to libraries for a single function call. As I have explained the issue is not in ddgr, in should be fixed upstream.