`apy list` does not list `cid` like README says

[camoz]

Hi,

the README says under Usage:

# List leech cards (will show cid values for each card). Note that the query
# should be similar to a search query in the Anki browser.
apy list -v tag:leech

However the cid values are not shown for me. I've looked at the code and I think either the comment or the code is incorrect?

Is there another way that I missed to print the cid values?

[lervag]

the README says under Usage: …

Yes, sorry, I think this is a form of regression. I decided relatively recently that the cid values where not so interesting. I found I never really used them for anything. Thus I ended up removing them. The nid values are still displayed, though.

Is there another way that I missed to print the cid values?

No, not currently. I'm curios, what's the use case for that?

Also, feel free to comment on the apy list output. I'm not really happy with it, to be honest. I never really figured out a nice way to print it. It's ok, I guess; I do use it once in a while. But I believe it could be better.

[camoz]

Ah I see.

The nid values are still displayed, though.

Hm, in my case they are not displayed, even with apy list -v (but they are in the apy review output). Are you sure they are displayed for you?

No, not currently. I'm curios, what's the use case for that?

Actually I don't care about whether it's the cid or nid value in the output of apy list. As I seem to be missing the nid values in its output for some reason, I just asked for the cid value, because it seemed more natural, since apy list lists cards and not notes. The reason I don't care about cid vs nid is that apy review QUERY seems to accept both cid and nid (which is nice).

My idea was: If I have that one note I want to change, but I don't have it in front of me, just an idea, then I could use apy list to find it and then modify it using apy review cid/nid:.... If my apy list query returns a bunch of cards, then using the same query for apy review and pressing c until the card I'm looking for is a bit cumbersome, esp. since right now you can't go backwards, only forward (c).

Actually I want to do it with fzf. So if the output of apy list is something like:

cid:01293 Q: What is the answer to life?
cid:12934 Q: Why is apy so great?
...

Then I could do something like:

apy review "$(apy list | fzf | cut -d' ' -f 1)"

I tested it by modifying the list_cards() function to print cid:... before the question and it seems to work!

If the cid:... would be printed at the end of the line instead of the beginning it would maybe be a bit more aesthetic, but for me I don't really care.

Also, feel free to comment on the apy list output. I'm not really happy with it, to be honest. I never really figured out a nice way to print it. It's ok, I guess; I do use it once in a while. But I believe it could be better.

Hm good question. The Anki card browser is quite nice, but I think it's also because it's a GUI and more flexible. I guess one could mimic Anki's card browser in an interactive screen like apy review but I don't think it's worth the effort. I think for that one should use Anki.

What would be helpful maybe is being able to manually change the output of apy list using some kind of format string, similar to how printf works. E.g. apy list -f "%deck %due %field1". But I'm sure it's not trivial to implement and there will be corner cases... because cards have different fields etc. I'm not sure it's worth the effort.

Even simpler would be to just have a few flags to include the deckname, duedate, etc. in the output, which would be displayed in a fixed order. So apy list --deckname --duedate would print:

Deckname |    Due    | Sort Field
---------------------------------
Biology   2024-06-07  Q: How many arms does a human have?
Biology   2024-06-07  Q: How many heads does a human have?
Personal  2024-09-07  Q: What's the name of my husband?

AFAICS the output functions currently are somewhat line-based, I'm not sure how much effort it would be to achieve an output like the above with different attributes in the same line.

[lervag]

Ah I see.

The nid values are still displayed, though.

Hm, in my case they are not displayed, even with apy list -v (but they are in the apy review output). Are you sure they are displayed for you?

Sorry, my mistake. They are displayed with apy review, but not with apy list.

No, not currently. I'm curios, what's the use case for that?

Actually I don't care about whether it's the cid or nid value in the output of apy list.

If anything, apy list should include cids, since it will list the cards.

The reason I don't care about cid vs nid is that apy review QUERY seems to accept both cid and nid (which is nice).

Yes, that's true; apy review will go through your notes and you can match a note on a card ID.

My idea was: If I have that one note I want to change, but I don't have it in front of me, just an idea, then I could use apy list to find it and then modify it using apy review cid/nid:.... If my apy list query returns a bunch of cards, then using the same query for apy review and pressing c until the card I'm looking for is a bit cumbersome, esp. since right now you can't go backwards, only forward (c).

Hmm, yes; I guess allowing more details in the apy list output can be useful for refining a search.

Actually I want to do it with fzf. So if the output of apy list is something like:

cid:01293 Q: What is the answer to life?
cid:12934 Q: Why is apy so great?
...

I can agree to something like that. I think I'll try to find a better way to output the apy list e.g. with rich Tables. I believe we could allow some options to include columns in the table.

Also, feel free to comment on the apy list output. I'm not really happy with it, to be honest. I never really figured out a nice way to print it. It's ok, I guess; I do use it once in a while. But I believe it could be better.

Hm good question. The Anki card browser is quite nice, but I think it's also because it's a GUI and more flexible. I guess one could mimic Anki's card browser in an interactive screen like apy review but I don't think it's worth the effort. I think for that one should use Anki.

Agreed. apy should be adapted for some specific work flows. In many cases, the full Anki desktop will be better suited.

What would be helpful maybe is being able to manually change the output of apy list using some kind of format string, similar to how printf works. E.g. apy list -f "%deck %due %field1". But I'm sure it's not trivial to implement and there will be corner cases... because cards have different fields etc. I'm not sure it's worth the effort.

Even simpler would be to just have a few flags to include the deckname, duedate, etc. in the output, which would be displayed in a fixed order. So apy list --deckname --duedate would print: …

Yes, this aligns with my above mentioned thought of using rich tables. The allowed options should be general ones that are not note type dependant.

[lervag]

I've made an attempt at improving this now. It would be very nice if you could try it. It's in a branch called feat/improve-list. You should be able to test it by cloning the repo, checking out the branch, creating a virtualenv and installing things there, then running apy list within the virtualenv.

[camoz]

Nice, thank you! Yes of course I will test it -- but I will probably only get to it next weekend (or maybe a bit before that). I've never worked with virtual environments. Although it's probably quite easy, I want to set aside some time for that...

[camoz]

I have tried it now! Overall very nice. Here are a few things I noticed, esp. in combination with long questions, so that the added columns get pushed to the right (I think this is not a super uncommon case):

• When using the -m flag alone, the names of the models don't get truncated, they get wrapped and cause a weird formatting of the result:

  

• When using the -t flag alone, the type names get truncated to 4 or 5 characters. It may be worth increasing the minimum column width to the length of learning, otoh this is the "longest" type of a card.

  

• When combining many options with -m, e.g. -dmctel, then the model column gets only two characters width. (And the wrapping issue mentioned above is still somehow present.)

  

• "Ease" is always displayed with a decimal point, like 250.0. It might be worth rounding this to whole integers and removing the decimal point to save some space.

• I was wondering if it makes more sense to add the small columns, except for the answer column, to the left side by default. Idea: If one adds the colums, I assume one would also actually look at them. And one would almost always also want to look at the question column to identify the card. Right now, the eyes have to jump from the very left (beginning of question column) to the very right (where the smaller columns are added). Edit: I don't really have an opinion on this one, it just came to my mind and I wanted to mention it.

Note that I don't know how easy it is to address some of those issues, if it makes the code too complicated I think this is already useful! Thank you so far.

[lervag]

• When using the -m flag alone, the names of the models don't get truncated, they get wrapped and cause a weird formatting of the result:

Ah, yes; it's actually surprisingly hard to get this particular thing right. I think perhaps the best option is to truncate the question (and answer) columns manually.

• When using the -t flag alone, the type names get truncated to 4 or 5 characters. It may be worth increasing the minimum column width to the length of learning, otoh this is the "longest" type of a card.

Yes, good catch.

• When combining many options with -m, e.g. -dmctel, then the model column gets only two characters width. (And the wrapping issue mentioned above is still somehow present.)

I've made a change to fix the first mentioned problem - let me know if this particular thing still happens after that change.

• "Ease" is always displayed with a decimal point, like 250.0. It might be worth rounding this to whole integers and removing the decimal point to save some space.

Agreed!

• I was wondering if it makes more sense to add the small columns, except for the answer column, to the left side by default. Idea: If one adds the colums, I assume one would also actually look at them. And one would almost always also want to look at the question column to identify the card. Right now, the eyes have to jump from the very left (beginning of question column) to the very right (where the smaller columns are added). Edit: I don't really have an opinion on this one, it just came to my mind and I wanted to mention it.

I was thinking about this. I tried both, but I didn't really decide which I liked the best. I think my reasoning for keeping the question at the left was because I found it to be the "most essential" part. Let's keep it like it is for now and reconsider it after we merge this to the master branch.

Note that I don't know how easy it is to address some of those issues, if it makes the code too complicated I think this is already useful! Thank you so far.

Thanks! The main problem is that the table functionality of Rich is not as straightforward as I hoped with regard to the automatic widths. But I've tried to improve based on your comments, so I hope it may work better now. Please let me know as soon as you have a chance to update and test.

[camoz]

Sorry it took me so long to test. I will have more time from mid-August on and will hopfully also send some PRs then! Also sorry for the gibberish cards in my screenshots, it makes it a bit harder to read...

I have not done extensive testing but played around for half an hour, and most of the mentioned issues seem to be gone now! The only issue that remains is the wrapping issue in some cases. E.g. -ac seems fine, but -ad or -am are not:

Another thing I noticed is something weird, which is probably related to another issue: Some of the question part is highlighted in pink:

Some of these have markdown code blocks with type html in them, But one of them has not; the content after apy review -> e is:

# Note
model: Basic
tags: 
deck: Default::New testdeck

## Front
$ a=34 $

## Back
owijef

## Extra

That is weird.

Also, when I decrease the terminal width sufficiently, some questions wrap again instead of being truncated. This seems to happen only with those cards where I have the pink highlighting phenomenon. But! When listing some of them alone, I don't get the wrapping issue:

[camoz]

(If you don't want to work on it further, since AIUI you don't even use this feature, you could just merge it as is and assign an issue about this to me, then I'll have a look late August.)

[lervag]

If you don't want to work on it further, since AIUI you don't even use this feature, you could just merge it as is and assign an issue about this to me, then I'll have a look late August.

I'll attempt to improve the things that are simplest, then merge this as I think it is already an improvement. Then you could open new issues for the remaining things that you think should be improved and you could possibly help improve things through PR's when you get the time?

[lervag]

I have not done extensive testing but played around for half an hour, and most of the mentioned issues seem to be gone now!

Glad to hear that!

The only issue that remains is the wrapping issue in some cases. E.g. -ac seems fine, but -ad or -am are not: …

Yes; it was unfortunately really hard to make this work properly with the rich mechanism. I could look into it further, but I think it is better to do it in a follow-up thread. If you think it is worth the effort, please open a new issue for it after I've merged the branch.

Another thing I noticed is something weird, which is probably related to another issue: Some of the question part is highlighted in pink: …

This is also from the rich library, which will highlight parts of the text when it recognizes some form of structure. It can be disabled. I've not really fully decided if I like it or not yet.

Some of these have markdown code blocks with type html in them, But one of them has not; the content after apy review -> e is: …

Ah, I notice that the ### Current HTML ... thing shows up in the listing. This is there to detect if there may have been a change to the card. E.g., if you were to update a card on your phone, then the card HTML will be different than the embedded base64 encoded raw content. This mechanism allows to detect that and update the card if necessary. But it is only relevant when you actually edit the card, not when listing it.

Also, when I decrease the terminal width sufficiently, some questions wrap again instead of being truncated. This seems to happen only with those cards where I have the pink highlighting phenomenon. But! When listing some of them alone, I don't get the wrapping issue: …

This is similar to the above -ac vs -ad and -am, or at least partly. I think we could continue looking in to it as part of the same followup issue.

[lervag]

Ok, I've merged #95 now. Feel free to open follow up issues as separate threads that we can discuss separately. I'll consider this particular thread as closed with the merge, I hope that's OK.

[camoz]

Thank you very much for your effort!

Then you could open new issues for the remaining things that you think should be improved and you could possibly help improve things through PR's when you get the time?

Yes I will! I have a list of some ideas already, but will open issues/PRs when I have more time, probably mid-August.

Ah, I notice that the ### Current HTML ... thing shows up in the listing.

I see you have fixed this, nice!

[lervag]

Thank you very much for your effort!

My pleasure; it's nice to have someone else interested in the project also, so thanks for that!

Then you could open new issues for the remaining things that you think should be improved and you could possibly help improve things through PR's when you get the time?

Yes I will! I have a list of some ideas already, but will open issues/PRs when I have more time, probably mid-August.

Looking forward to it!

Ah, I notice that the ### Current HTML ... thing shows up in the listing.

I see you have fixed this, nice!

Yup!