The First Field is Empty Problem

Anki Suggestions
1

People are constantly asking for “empty first field” for various reasons receiving different niche answers, but again and again question appears anew, so why not implement?

So, my story. I learn languages, so I have a few note types filled with different functions that depend on information I provided or it’s absence. The problem currently is only with my chinese deck. The first field is Sentence (because the main information is the audio-sentence pairs), because I don’t learn words, most words fields throughout the deck are empty. But sometimes I add more information, like words, so some fields/sibling cards appear. And today I decided to create some cards with transliterated names, and again, to avoid Sentence-related siblings, I left it empty. Because it doesn’t allow saving this way, I: input some letter here, save, then open the card, remove it, save (without the error), and when I finish the import session, I go to check —> empty cards (sentence cards that shouldn’t appear in the first place) → remove empty. Too much to do, is it not? I got tired through a first bunch and finally came here.

So, you may say that I’d be better making other note type. But firstly, it will be extra difficult to make identical changes if needed. Through the years I was constantly modificating and unifying all my decks visuals and functions (although a little bit different for different subjects), and it will be boring to do exact steps for much more different types. Secondly, sometimes I add information when it is hard to remember, not to make more instances of the same information I just fill a certain field and the additional sibling cards appear automatically. Thirdly, I also use AnkiDroid and sometimes import from phone too, so the workarounds of addons like ID field or batch edit of the first field will solve only a half of the problem, being an unnecessary extra step. Yeah, it is possible to make this sticky useless field (to spawn later on a megaton of duplicates) to avoid this inconvenience, but is this really a solution? It is almost convenient already, but this single artificial softlock message just prolongs time I spend on card creation, which is already a slow and laborious process in itself. Cards already have unique ID-s (although not for users to use), there is already a function to search through duplicates (which really helps with shared decks’ import in more than one field), so why should we have this status quo of not having duplicates or empty first fields too? Anki is flexible enough to go far beyond basic reverse cards, I can’t see why the first field must be special. People were asking for it for quite a while with different depth of knowledge and for different purposes. So again, why not implement? Also, imagine having less posts on this topic :slightly_smiling_face:

2 Likes
2

Might be related to the fact that the first field is used as the sort field in the browser. If it’s empty, how will ankis card browser sort the cards accordingly? Maybe changing this behavior is possible but it might be a lot of work or cause problems regarding performance.

3

Well, I imply that it is already working, already here for some reason. Currently I have 432 cards without the first field in that note type and nothing is broken. Also, the filtering stuff you mentioned, it has no problems even there:

image
image695×583 29.3 KB

(First 4 fields are empty)

Having or editing the field to empty is absolutely okay according to Anki. It is not okay only in the process of creating. I would even thought that it’s just a bug, but then saw all those posts through years with no changes made. Really strange.

1 Like
4

Where the rubber meets the road for your example might be exporting/importing. I think what you’ve got there would be impossible to export/import as text/CSV – and not without challenges as APKG. Hopefully you’re not considering sharing these decks, but even in your own collection you’ll want to be careful so as to not lose data.

There are obvious advantages to a complex note type that covers all of your possible uses, but you might want to consider adding a keyword in that first field to avoid any disadvantages sneaking up on you!

1 Like
5

Well, that’s another layer of weirdness. Why are there no warnings when changing the notetype (e.g. putting the later field, which might be empty, to the first place) and then in case of manual deletion, maybe an additional check, but for this problem only? But I guess it will be not the most optimal way to handle the problem. Yes, I don’t plan to export anything and can imagine the difficulties with the text format, but why should there be any with APKG? I believe notes and cards already have their own IDs, so why should they depend heavily on the first field instead? Because now it is funny that it is necessary for advanced cards to have gibberish, anything useless at the top of the card edit window (and not accidentally duplicated!) in each card of a such note type. Yes, unfortunately we also don’t have support for hidden ID fields like all those addons try to do. This is the first major problem I’ve encountered in maybe 4 years of using Anki that doesn’t have any quick workarounds, so I’m asking you: Is it possible that something could be changed in the future?

6

I think this is because the card, note, revlog and note type ID doubles as the creation date. It is in fact the current time in milliseconds when the db inserted the object: Database Structure · ankidroid/Anki-Android Wiki · GitHub

CREATE TABLE notes (
    id              integer primary key,
      -- epoch milliseconds of when the note was created

And so, if I understand correctly (correct me if I’m wrong here @dae), to ensure no ID collision happens a new ID must be created when importing anything from .apkg. Because, while unlikely, there is a chance that your current db has an object you created at the exact same millisecond as an object coming in as an import.

1 Like
7

Yes for text, .apkg is totally fine though.

No, the id is the created at time and acts as the id in the card browser. When importing, there’s been a guid for a long time already that is the globally unique identifier.

Actually read the code

I ended up doing some reading on the importer code and found that when importing .apkg files it’s the guid that is used to match notes to each other. The original id is imported to the database and only changed if the id isn’t unique. Because it’s still used when referring to notes in the browser, it needs to be unique. But it’s not the note’s unique identifier in .apkg imports, the guid is.

Importing text files with no ids

The problem is indeed non-apkg importing. You have to have some method of identifying notes that are supposed to be updated by the import. Since there’s no ids in the text file some other content needs to be used as a replacement “id” and using the first field seems to have been decided to be that replacement.

So, basically the first field in a note acts as a surrogate id for importing purposes and thus needs to conform to restrictions on what an id is supposed to be: unique.

If importing non-apkg files could only be used to add notes, not update them, then this first field restriction wouldn’t be needed.

Actually tried importing empty first field notes with text vs .apkg

.apkg

Importing as .apkg works fine, you can get new notes or update existing notes even, if the first field is empty because the guid is what matters then.

Text

Currently it seems to be impossible to import any notes with empty first fields due this being explicitly not allowed in the text importer:

I don’t think I fully understand why this is done. Naturally, every single empty first field note would be found to be a duplicate and could not be matched uniquely to any existing empty first field. But it ought to still be possible to add it as a new note, if that was specified in the import options?

How to allow empty first field

After reading the code more, I’m also thinking if it wouldn’t be ok to not be so obnoxious about this? It really is only a problem in text file imports. Sorting is fine, all the empty first fields just get put together first or last when sorting by that field.

I guess it’s not entirely simple as the text import code needs to handle empty first fields as a special case. The import UI would then need a new option to specifically say how you want to handle those with the options being basically “Do nothing” or “Import as new note” as there’s nothing else that could be done.

2 Likes
8

There should be few if any remaining technical reasons preventing blank first fields, but it’s still recommended that you pick something unique and always present for the first field, as it’s not very useful to be notified of duplicates as you’re typing the last field in.

9

So, nothing will be done? That’s a pity. An artificial problem it is, an artificial problem it will remain. It not even requires code changes apart from some code removal, it affects text export alone (which is niche), basically a user-friendly (in case you might export text!) rigidity.

10

Why not have a redundant field as the first field (that doesn’t appear anywhere in the cards)? You can just fill them with a number. A lot of people create INDEX fields that serve a similar purpose.

1 Like
11

Source-code-aware folks already said that empty first field doesn’t break anything except text export, it already works (as I said above a few times), and people create exact same suggestion time and time again for various other reasons. Yeah, I can do this or that about the problem, but the problem still exists and requires an extra step nevertheless, where it should require none. That is the point.

12

To me, that sounds like a reason not to allow empty first-fields. It the user had an empty first field and now their export is broken, that would be horrible user experience.

1 Like
13

Again, Anki allows empty first fields. It just doesn’t allow creating one when you “Add” a card. When you modify it, there is no problem. So, I propose either ban them whatsoever, or remove the soft lock in card creation. Again, export to .apkg works, everything else works besides text export. Personally, I never once needed or heard about anyone using text export. I’d prefer error there “You cannot export while having some cards with empty first field” or smth.

14

Which might be an oversight and thus a bug that needs fixing. But extending the bug by breaking the export functionality cannot be the goal.

Skimming the above messages, Danika actually said that it might still cause data loss; which is why she warned that you shouldn’t do that (and especially not share your cards without a non-empty first field).

Edit: jhhr actually found it would work.
Edit 2: Apparently it breaks importing as well (including import as csv):

I argue a better design would be to not allow empty fields from the get go, or properly support empty first fields (which might not happen based on dae’s message).

Otherwise the user would have to solve something in their cards that anki never told them about, but they are forced to solve it in order to get basic functionality (export and import) working properly; which would be bad user experience.

1 Like
15

I disagree with you there. If we speak about plain Front-to-Back notes without as much as a thought, then yeah, why there should be empty first fields. But if we can make 10 fields with cards that appear or disappear (or information on them) automatically based on fields filled, then why should we stick to some status quo or placeholders?

UPD. CSV? Why not having something else as a first field, say, ID, if a whitespace is a no go? In CSV we are already loosing data, showing media names (and not storing it), so the only real use is importing it back after some scripting work. So why not ID? I think it is better to show some surplus data than a placeholder keyboard mash of all things.

Here is my generic Chinese note. All of them are mainly sentences, but I can omit anything, which will change what I’ll see at the end. No word will hide the word card, “mute” if present hides all sentence cards, etc. And you basically telling: “Nah, this and all your decks better have a placeholder with junk, at the very top so that you would notice it for sure. Note, that we will also cry with warnings if you’d accidentally put the same junk to 2 different notes, so be vigilant!” — a horrible solution to the problem that should not even exist!

1000001518
10000015181298×4096 290 KB

Well, my point is that I’ll try to keep this problem afloat until it solved (until the soft lock is gone). I am not in the state to contribute to open source yet, but I plan to lean this way after my current projects are at least satisfactory (I am bad at OOP). And I hope the solution will come a little sooner than that.

1 Like
16

Not yunk. There would be no point, then. Actual useful data like an id (which you even suggested).

As an aside, that’s how my cards work as well, since I always import with csv files after updating my file.

Not true, but not the point here.

It doesn’t really matter if the user creates the id (or random string or whatever) that makes import and export work properly or if anki does it. In fact, export already allows you to include a unique identifier.

What I understood you were saying is basically this: “An empty first field is not allowed in general, but there is this one instance where you can actually cause the first field to be empty. Thus, anki should break import and export for text based files, instead of solving the bug or finding a way to solve the issue”.

But aside all that, you actually stopped quoting at the crucial bit. I specifically said:

(made it bold in the quote for highlighting purposes)

So, honestly, not sure what you are arguing against. All I said is: Breaking existing import and export functionality (like you suggested) and causing bad user experience doesn’t solve the issue, thus we should not do that. My quote says what I think should be done instead.

17

The code/addon below works in two ways:

Anki Hook: Intercepts the validation before adding the card. If it detects the error “first field” (first field empty), it returns an empty string indicating that there is no error.

Invisible space: When you click “Add” and the first field is empty, the addon automatically inserts the character \u200B (zero-width space) in the first field.

This character \u200B is completely invisible - you can’t see it even when viewing the card. It technically exists, so Anki accepts the card, but visually the field appears empty.

It’s as if you typed “nothing” which is technically “something” to Anki, but it still appears empty to you. This way you can create cards without text in front if needed (for example, for cards with only images, audio, or other specific situations).

#__init__.py

from aqt import gui_hooks
from aqt.editor import Editor
from anki.notes import Note

def on_add_note_will_be_added(problem: str, note: Note) -> str:
    if problem and "first field" in problem.lower():
        return ""
    return problem

gui_hooks.add_cards_will_add_note.append(on_add_note_will_be_added)

original_add_current_note = None

try:
    from aqt.addcards import AddCards
    original_add_current_note = AddCards.add_current_note
    
    def patched_add_current_note(self):
        note = self.editor.note
        if note and not note.fields[0]:
            note.fields[0] = "\u200B"
        return original_add_current_note(self)
    
    AddCards.add_current_note = patched_add_current_note
except:
    pass

######################################

Step-by-step to install the addon:

Open Anki
Click on “Tools” in the top menu
Click on “Add-ons”
Click on the “View Files” button

This will open a folder on your computer
Create a new folder inside this folder that opened
Give it any name, for example: allow_empty_field

Enter this folder you created
Create a new file called exactly: __init__.py

You can use Notepad to create it
IMPORTANT: it has to be __init__.py (with two underscores before and two after) “init”)

Open the __init__.py file with Notepad.
Paste the addon code into this file.
Save the file.
Close Anki completely.
Open Anki again.

Done! The addon is now working. Now you can create cards even with the first field empty.

18

Well, it does partially solve the problem. First of all it will insert info, and as I explained earlier if there will be any info in {{Sentence}} field, it will create both listening and reading cards for sentence in my case. But really, instead of opening each card to fix junk for now I can just ignore that and edit the note in time it will appear, thus instead of “\u200B” other text might be entered, like “remove me”. A little less hustle — no need to enter manually, I’ll use that, thank you — but hustle nevertheless: editing and removing empty are required.