AnkiMorphs V3

[mortii]

Discuss anything related to the v3 update here

[mortii]

Also, if you're planning to break backwards compatibility anyway, you may want to consider changing the field name "field" in the ankimorphs_profile_settings.json to something more meaningful and distinctive.

Originally posted by @xofm31 in #221 (reply in thread)

Sure! What would you want it to be instead?

[xofm31]

I think it refers to the AnkiCardData slot "expression" so it could be the same as that.

[mortii]

oh, I want to do the complete opposite and replace "expression" everywhere with something more fitting. The only reason it is used is because morphman used it in the base morphemizer class, which is the only thing that hasn't been completely rebuilt at this point.

I was thinking the config name could be "parse_field" or something in that vein.

[xofm31]

parse_field is descriptive. A user will never see that, it's just for the code

Thinking about the other field names, I think these all will be populated
am-unknowns:the morphs that have not been seen, and becomes empty when all of the morphs have been seen
am-unknowns-count: count of am_unknowns
am-all-morphs: all the morphs in parse_field
am-all-morphs-count: count of am_all_morphs
am-highlighted: colors the morphs by their learning status
am-score: shows the card's score for determining it's due value

For the "focus morph" equivalent field, personally, I don't have a problem with the name "focus morph" because it's the "morph" I'm "focusing" on with that card. I do like the term "morph" better than "unknown", because it's going to be kept long after it's no longer unknown. What about something like am-study-morph?

[mortii]

parse_field is descriptive. A user will never see that, it's just for the code

Well, it wouldn't be a bad idea to rename the column header in the note filter settings as well. "read field" might actually be better than "parse field" now that I think about it... not sure.

As for the extra fields, i think renaming am-unknowns -> am-unknown-morphs might be a good idea to make it more consistent with the new am-all-morphs, it would also provide the extra benefit of not deleting the "focus morph" people already have on their current cards since that field wouldn't be overwritten any more.

I do like the term "morph" better than "unknown", because it's going to be kept long after it's no longer unknown. What about something like am-study-morph?

Good point, and I like am-study-morph. Technically people could study cards that have multiple unknown morphs at the same time, so naming it am-study-morphs might be more accurate, although It could also be more confusing since it's usually only one morph. What do you think?

[xofm31]

"read field" is good. "input field" would also work.
"am-unknown-morphs" sounds better than "am-unknowns".
Either "am-study-morph" or "am-study-morphs" sound good to me.

[aleksejrs]

I found that moving files (meta.json, ankimorphs.db and ankimorphs_profile_settings.json) around is easier than doing anything about #176 (since updates are frequent).
I hadn't seen much use in specifying different frequency files for different notes when you first implemented it. I guess it is useful if you use different morphemizers.
But it is also useful to have different databases for different languages, because they often share homographs, so knowing a word in one language does not mean knowing a similar-looking word in another language. That's not what I want this for, but I hope it makes sense to you this way.
If not, a possible workaround might be to make a morphemizer that adds an unusual prefix to each word. It could also exclude words in different scripts from prefixing.

[aleksejrs]

you basically want to use different databases for different note types/note filters to give the same morphs different learning statuses depending on the context of the note type.

Right.

to use different anki profiles at that point.

I don't like that idea.
I run recalc, Reschedule all cards, Recalculate today's new limit for all decks.
I have review statistics for everything in one place.
Review history for the specific deleted cards cannot be moved to another profile, only copied as a whole (replacing everything).
I would have to remember to switch between profiles. I usually use Anki profiles for testing and can delete anything but the main one. The only other reason I used profiles was to generate a list of all morphs, including known ones, with MorphMan.

[mortii]

I don't like that idea.

Understandable, but it's the only alternative I can think of. Storing and retrieving morphs based on note type would add too much complexity, sorry.

[aleksejrs]

I made scripts like this:

#!/bin/bash
ln -is ~/.local/share/Anki2/customizedaddons2404/ankimorphs-m2a/472573498/meta.json  ~/.local/share/Anki2/addons21-24.04/472573498/meta.json
ln -is ~/.local/share/Anki2/customizedaddons2404/ankimorphs-m2a/user/ankimorphs_profile_settings.json ~/.local/share/Anki2/user/ankimorphs_profile_settings.json
ln -is ~/.local/share/Anki2/customizedaddons2404/ankimorphs-m2a/user/ankimorphs.db ~/.local/share/Anki2/user/ankimorphs.db

That script does not remove the links in advance yet, hence the -i.

Hope an update does not confuse anything.

[mortii]

Preserving anything downstream will not be taken into consideration for any future updates, so no promises.

[aleksejrs]

I meant an update changing meta.json and then being unable to update the other one.
Or replacing the meta.json symlink with a new version of meta.json, which it did, but I noticed.

[xofm31]

I saw in #222 that you want to address avoiding short parse_fields (#195).

Are you interested in tackling an alternate score algorithm in V3, since my score incorporates the parse_fields length?

[mortii]

I consider the am-unknowns-count problem discussed in #221 to be a semi-bug, so I was hoping to push out the v3 update asap. That being said, v3 is shaping up to be a really hard break from v2, so we might as well make the most of it and accept that it will take 3-4 months to release. So yes, we could work on incorporating the alternative algorithm in v3. I'll add it to the list.

[mortii]

changing extra fields is super annoying to work with because it causes problem when switching between the prod and the dev version, so we should leave that for last and work on the algorithm first.

[xofm31]

I consider the am-unknowns-count problem discussed in #221 to be a semi-bug

Fixing am-unknowns-count (keeping the same field name) can be done now, and then fixing the am-unknown-morphs / am-study-morphs can be done later.

[mortii]

Fixing am-unknowns-count (keeping the same field name) can be done now

I disagree, changing the behavior of an existing feature counts as breaking backwards compatibility, so they should be released at the same time.