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

Use short as key if no key specified #84

Closed
CasVisser opened this issue Dec 9, 2024 · 6 comments · Fixed by #87
Closed

Use short as key if no key specified #84

CasVisser opened this issue Dec 9, 2024 · 6 comments · Fixed by #87
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@CasVisser
Copy link

CasVisser commented Dec 9, 2024

Hi, this is my first ever issue on an OS project, so let me know if there is anything I should do differently!

My suggestion is as follows. Currently, for all my glossary entries, I simply use the short form as the key. This allows for a natural flow when writing, i.e. Thanks to @ABC, we can ... where ABC is some abbreviation. Specifying both key and short feels like unnecessary double work, as they are always the same anyway. If short is used as key when no key is specified, this would allow for cleaner Typst files.

@quachpas quachpas self-assigned this Dec 10, 2024
@quachpas quachpas added the enhancement New feature or request label Dec 10, 2024
@quachpas quachpas added this to the 0.5.2 milestone Dec 10, 2024
@quachpas
Copy link
Collaborator

Hello! Thanks for the issue. I have encountered the same feeling when writing my glossary, so I understand the issue here.

I can add an option to consider short as key in register-glossary. I would prefer that it is not the default behaviour for the reasons below:

  • if both key and short are considered the same, then if the user ever wants to change key but not short or vice-versa, it becomes a mess!
  • e.g., I want to change @abc's key to @abc, but it will also change every occurence of short.

Overall, I think it is bad practice to link the two, but I will add an option with a warning.

@CasVisser
Copy link
Author

An option would be a good solution, thanks! I am not sure I understand why using short as key would cause mess, but in any case an option would work.

Just to make sure we are understanding each other correctly, I would think that if we have e.g. a record (short: "abc", long: "all blue cows") and we want to change the key to abb:abc without changing short, we could update the record as follows: (key: "abb:abc", short: "abc", long: "all blue cows"). I don't think this is messy, but maybe I am missing something. In any case, thanks for your response!

@quachpas
Copy link
Collaborator

quachpas commented Dec 10, 2024 via email

@CasVisser
Copy link
Author

I see, but how is that different when using an option? Changing the key still would still require changing all the @abc as well. My suggestion is to only use short as key if no key is specified.

For example, suppose we have an entry (short: "ABC", long: "all blue cows"). No key is specified, so we can refer to this entry using @ABC. Suppose we want to change the short to AllBC. Then we change the entry to (key: "ABC", short: "AllBC", long: "all blue cows"). This way, the key does not change and we do not need to change any of the references @ABC. Suppose we want to change the key to abb:ABC, then we also need to also change all references @ABC to @abb:ABC. We update the entry to (key: "abb:ABC", short: "ABC", long: "all blue cows"). I hope this makes it more clear what I mean.

@quachpas
Copy link
Collaborator

I see it, thank you!

@quachpas
Copy link
Collaborator

I'll add it as "use key as short". From (key: "ABC"), if we want to change the key, then we add short instead of the other way around. It's essentially the same, it's just a matter of having the key first.

@quachpas quachpas linked a pull request Dec 20, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants