abbreviate descriptions supports custom suffix

[KaiyoungYu]

Problem

There is two options now. The default is '120 words', and abbreviated '120w' I personally use novel-word-count in a total Chinese vault. aesthetically, showing '120 words' or '120w' is not very pleasing.

Idea

Is there any possibility that the post-fix part be customizable? like '[words_cnt][postfix]', and I can customize the [postfix] part.

[isaaclyman]

Aesthetic appeal isn't a specific goal of this plugin. However, this has been requested before (#23), so I'm going to give it more thought. There are a few possible problems:

• The plugin has 14 different data types that can be chosen. A format string would need to handle all of these, which is a testing and maintenance burden.
• Overcomplicating the Settings screen is something I'm serious about avoiding. This is already a much more complex plugin than it set out to be. All the complexity so far has been reasonable and valuable, but this seems like less of a functional improvement than anything else so far.
• A custom format string is something most non-programmers would struggle with; the average person has trouble understanding matched pairs, case sensitivity, and different bracket types.
• If people are raising issues because they made a typo in their format string, not because there's any actual bug in the plugin, that's going to waste my time a lot more than just saying "no" to requests like this.

Like I said, I'm considering it, but it seems like a lot of work for something that isn't very important.

[Sp3ctre18]

Definitely appreciate as beyond expectations to have the number of options you already chose to include, so thank you for that, but I'll chime in and say that even in alphabet languages, some further reduction can definitely be nice, especially considering the small and non-colored text we have to deal with there, potentially long note-names + multiple stats one could add on with this plugin, etc. I personally am using note counts on folders and word counts on notes, so I'd rather have the note counts as pure numbers (like the previous note count plugin I was using), to more clearly distinguish from the word counts, which have units.

So this is supporting a 3rd option for no units, combined with splitting the abbreviation option to be unique for folders - in fact, I think all options should be different for notes and folders, which currently means including the alignment option too. Right-aligning causes a vertical column that is desirable for scanning, but too far away from folder indications, so I think I'd ideally set up unit-less note counts inline for folders, and unit-including word counts & goal percentages right-aligned for notes, as I do now.

But none of this is of any priority and it's a great plugin at is, so consider at your leisure. Thanks. :)

[dushanwegner]

Hi, yet another chime in: I “hacked” line 1100 in main.js by simply removing the “ch” from ${characterCount.toLocaleString()}ch. (Would prefer not having to do that on updates etc.)

The reason is that the cognitive load feels considerably different whether I can simply “see a number” or have to “read and decipher an expression made of number and unit”. As the number of characters is my only concern, the unit is useless info to me.

(Also, while I was at it, I added my own locale to toLocaleString, as I am used to a dot and not a comma as thousands-separator. Now it is perfect for me.)

But let me point out what a super useful and well crafted plugin this is, thank you! 🙏🤗

[isaaclyman]

I appreciate everyone's input. Clearly there's a demand for this.

I've had some ideas about how to add more formatting options without increasing the complexity of the Settings pane. Stay tuned.

[isaaclyman]

Fixed in v3.0.0. Please update the plugin and check out the new "Use advanced formatting" toggle at the top of the plugin settings.

This was a big feature to implement and makes the plugin more difficult to maintain. If you find it useful, please consider leaving me a tip.

[isaaclyman]

@dushanwegner As for your locale issues, toLocaleString() uses the default locale for the runtime, which is determined by Electron, and in turn (I would expect) by your OS. If your OS is set to the correct locale and you're still seeing the wrong digit separator, it's likely a bug in Electron.

Still, supporting a custom locale identifier in the plugin settings isn't out of the question. Feel free to file another issue if you want to discuss further.