Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding descriptions for each option #114

Merged
merged 23 commits into from
Apr 11, 2024
Merged

Adding descriptions for each option #114

merged 23 commits into from
Apr 11, 2024

Conversation

iamalisalehi
Copy link
Contributor

Hi,

This patch provides a feature to show descriptions for each options. The description for each option shows on the right side of the screen as the cursor moves on to it.
A function was also added that divides long description into multiple lines based on the terminal size.
An example was also provided.

Hope it is useful.

P.S. I couldn't think of a way to write a test for it so I didn't.

Added the option to show description messages for each option by moving the cursor on to them.
Fixed some screen size math
@iamalisalehi
Copy link
Contributor Author

Here's a gif of the example:
descriptions

@SnowzNZ
Copy link

SnowzNZ commented Mar 27, 2024

I feel like it would be better to have descriptions and options stored as a dictionary rather than two lists.

@gustavo-mag
Copy link

gustavo-mag commented Mar 27, 2024 via email

@iamalisalehi
Copy link
Contributor Author

I feel like it would be better to have descriptions and options stored as a dictionary rather than two lists.

That's a nice idea. I'll try it.

…scriptions.

2) changed the example to work with the new way of using the code.
3) wrote a new test for descriptions
@iamalisalehi
Copy link
Contributor Author

So I just added a new commit which incorporates @SnowzNZ's idea with minimal changes to the way the code is written to still be backwards compatible (Although the descriptions will only work properly with python3.7+ because the dictionaries weren't ordered before that).

please read the commit notes too.

Copy link

@SnowzNZ SnowzNZ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove .idea folder

@wong2
Copy link
Collaborator

wong2 commented Mar 31, 2024

In case you don't know, the item passed to options could be an Option instance, so I think it's better to add description as an attribute of Option.

https://github.com/wong2/pick/blob/master/src/pick/__init__.py#L22
https://github.com/wong2/pick/blob/master/example/option.py

example/description.py Outdated Show resolved Hide resolved
@aisk
Copy link
Owner

aisk commented Apr 1, 2024

Hi @iamalisalehi, if you want to continue the work, please merge the latest code from the master branch, which has fixed the CI, and we should ensure that it passes before merging.

@iamalisalehi
Copy link
Contributor Author

Hi @wong2 , thanks for the review.
Sorry I am not still very skilled in git and messed up commit messages a little bit so I'll explain what I did here:

  1. Added an optional attribute description to the Option class.
  2. Changed parse_options function to turn dictionaries in instances of Option. Now we don't need self.descriptions anymore.
  3. Added a new example.
  4. Updated test_option to include the new possibilities.
  5. Changed the test for parsing dictionaries.

P.S. I didn't change value attribute, only gave it a default None value. Is this okay?

Copy link
Owner

@aisk aisk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some comments for the PR, and the CI should be passed, I see it failed mainly because the type checker, you can run mypy on your local machine to check and then fix them.

example/description_option.py Outdated Show resolved Hide resolved
src/pick/__init__.py Outdated Show resolved Hide resolved
example/description_dict.py Outdated Show resolved Hide resolved
src/pick/__init__.py Outdated Show resolved Hide resolved
tests/test_pick.py Show resolved Hide resolved
@iamalisalehi
Copy link
Contributor Author

hi @aisk , so I'm seeing that type checks failed for python<3.10. The thing is that I used mypy cheatsheet to rewrite the type hints for python>=3.10: For example: typing.List to list and so on.
Should I revert it back?

@aisk
Copy link
Owner

aisk commented Apr 2, 2024

Yes, since we support old version of Python, we have to use some old grammars for type hints.

@SnowzNZ

This comment was marked as off-topic.

src/pick/__init__.py Outdated Show resolved Hide resolved
src/pick/__init__.py Outdated Show resolved Hide resolved
@aisk
Copy link
Owner

aisk commented Apr 3, 2024

Actually, the current codes don't have the expected behavior on my machine. I guess it's been broken during the updated commits. This is the result of running python example/description_dict.py:

image

@aisk
Copy link
Owner

aisk commented Apr 3, 2024

When picking a dict, the pick result is an Option. But in the current main branch, you pass a list of str of Option, and the pick result will be the original type.

So I think the pick result of a dict should be a two-element tuple, like when iterating over a dict.

@iamalisalehi
Copy link
Contributor Author

Actually, the current codes don't have the expected behavior on my machine. I guess it's been broken during the updated commits. This is the result of running python example/description_dict.py:

image

Hi @aisk , I fixed the issues you raised, and checked the example again. It worked well on my computer (I am running python3.11.8). Can you please check it again?

@iamalisalehi
Copy link
Contributor Author

When picking a dict, the pick result is an Option. But in the current main branch, you pass a list of str of Option, and the pick result will be the original type.

So I think the pick result of a dict should be a two-element tuple, like when iterating over a dict.

Hmm, I thought about this but I am not so sure that it would be the best way to do it. As I understood from the code before I worked on it, there is a simple way and a more complex way to use it. In the first versions that I wrote, adding descriptions was considered a part of the simple way of doing things but then at the suggestion of @wong2 , I changed it to be a part of the complex way of doing it (this also makes more sense to me).
But I feel like that returning a tuple, introduces a third way of doing things and needs another datatype to be considered and might introduce unnecessary complexity. But as you have probably seen, I don't have a lot of coding experience so I am not sure..

@aisk
Copy link
Owner

aisk commented Apr 3, 2024

Hi @aisk , I fixed the issues you raised, and checked the example again. It worked well on my computer (I am running python3.11.8). Can you please check it again?

It's the same result, but I'm using Linux with Tilix as terminal emulator. Maybe this is OS dependent issue, I'll check the result in other OS tomorrow.


Update: Kitty on Linux have no issue:

image

@iamalisalehi
Copy link
Contributor Author

Hi @aisk , I fixed the issues you raised, and checked the example again. It worked well on my computer (I am running python3.11.8). Can you please check it again?

It's the same result, but I'm using Linux with Tilix as terminal emulator. Maybe this is OS dependent issue, I'll check the result in other OS tomorrow.

Update: Kitty on Linux have no issue:

Does the option.py example work on Tilix or is it just the dict example?

P.S. I tested them on Konsole, Terminator and Pycharm's terminal and they work

Copy link
Owner

@aisk aisk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I resolved the problem; it's not caused by Tilix, but by a wider screen. With a wider screen, the last value passed to addstr in draw method will be larger than 256, which will draw the description text with the same color as the background, leading to invisibility.

Kitty works fine on my machine because the default font is larger than Tilix's, so the screen is not wide enoght to triger the bug.

I guess you want to use addnstr instead of addstr to specify the maximum line width, but you missed an n, which caused the bug.

src/pick/__init__.py Outdated Show resolved Hide resolved
Co-authored-by: AN Long <aisk@users.noreply.github.com>
@aisk
Copy link
Owner

aisk commented Apr 6, 2024

When picking a dict, the pick result is an Option. But in the current main branch, you pass a list of str of Option, and the pick result will be the original type.
So I think the pick result of a dict should be a two-element tuple, like when iterating over a dict.

Hmm, I thought about this but I am not so sure that it would be the best way to do it. As I understood from the code before I worked on it, there is a simple way and a more complex way to use it. In the first versions that I wrote, adding descriptions was considered a part of the simple way of doing things but then at the suggestion of @wong2 , I changed it to be a part of the complex way of doing it (this also makes more sense to me). But I feel like that returning a tuple, introduces a third way of doing things and needs another datatype to be considered and might introduce unnecessary complexity. But as you have probably seen, I don't have a lot of coding experience so I am not sure..

I have some slight concerns about the complexity too, so I think for now, maybe we should only support using list[pick.Option] as the input type for items with descriptions.

In this way, we can ensure that the pick's result type matches the input type exactly. If you put a list of str, you'll get a str; if you put a list of Option, you'll get an Option.

@iamalisalehi
Copy link
Contributor Author

I have some slight concerns about the complexity too, so I think for now, maybe we should only support using list[pick.Option] as the input type for items with descriptions.

So I should get rid of the parse_options function completely?

In this way, we can ensure that the pick's result type matches the input type exactly. If you put a list of str, you'll get a str; if you put a list of Option, you'll get an Option.

Question: In the option example now we see both str and Option inputs. Should this be acceptable? It outputs exactly the same thing and yet the input is not uniform.

@aisk
Copy link
Owner

aisk commented Apr 7, 2024

So I should get rid of the parse_options function completely?

Yes, and thus we can revert specify the self.options to Any.

Question: In the option example now we see both str and Option inputs. Should this be acceptable? It outputs exactly the same thing and yet the input is not uniform.

You reminded me, I think it's not accepted, because I guess mypy or pyright will complain about this, I'm not using my development machine so I don't try it, but you can have a try. I think we should add a type checker to the examples on the GHA.

@iamalisalehi
Copy link
Contributor Author

So I should get rid of the parse_options function completely?

Yes, and thus we can revert specify the self.options to Any.

I did that, and also updated the tests.

I think it's not accepted, because I guess mypy or pyright will complain about this.

mypy did complain so I had to only feed it Options or strs at a time. Fixed the option.py example and removed dict example.

I think we should add a type checker to the examples on the GHA.

I am a bit confused, is it something different than what mypy checks already do?

src/pick/__init__.py Outdated Show resolved Hide resolved
src/pick/__init__.py Outdated Show resolved Hide resolved
iamalisalehi and others added 2 commits April 8, 2024 12:36
Co-authored-by: AN Long <aisk@users.noreply.github.com>
@aisk
Copy link
Owner

aisk commented Apr 8, 2024

LGTM. I'll wait a few days before merge to give @wong2 a chance to take a look if he has time. Thanks for your contribution! @iamalisalehi

@iamalisalehi
Copy link
Contributor Author

iamalisalehi commented Apr 8, 2024

Thank you for the great reviews @aisk . I learned a lot from you ;-)

@aisk aisk merged commit d1a8e6b into aisk:master Apr 11, 2024
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants