Will the abbr package support Content?

I am currently trying if usage of the package “abbr” Version 0.3.0 makes sense for my project and I like the simple use in the text in the form of @ABBR. This does not break the text flow.

Now I noticed it does not support [Content] in the abbreviations dictionary.

Is there any reason for this? Generally, for dictionaries, I believe this works in typst.
Will this be supported at some time or is this supported in another abbreviations manager?

Hi there, welcome to the forum!

You should check and ask @slowjo the package author for that, and maybe suggest some changes to the package?

In a nutshell, content is not intended to be manipulated.

There are other similar packages and some may well be supporting content.

Edit: I just found i-am-acro – Typst Universe and they seem to be supporting content. But this limits some functionalities, such as:

NOTE: It is not possible to sort by content. If you want to sort the arconyms by their short definition, they all need to be strings.

Could you share your particular use-case so we can provide advice?

Thanks vmartel08, for the additional hints. I will take a look at the other alternative packages…

The reason for my request is I want to use formatting in the returned text, such as…

    #abbr.add("ECM", [#underline("E")lectronically #underline("C")ommutated #underline("M")otor])

In that case, unless you request a change to abbr (or change it locally to fit your needs), probably best to switch package then and use:

#import "@preview/i-am-acro:0.1.3": * // import everything
#let acronyms = (
  ECM: ( // key
    en: ( // language key
      short: [ECM], //requiered
      short-pl: [ECMs], //optional
      long: [#underline("E")lectronically #underline("C")ommutated #underline("M")otor], // requiered
    ),
  ),
)
#init-acronyms(acronyms, "en", always-link: false)
#ac("ECM")

Hey, author of abbr here, thanks @vmartel08 for tagging me!

@Matze to quickly answer your question: the only reason this usecase is not supported is that nobody needed it until now, but I’m always open to suggestions!

If you’re willing to look into it, I’ll gladly take patches :)

1 Like

I didn’t think this would be answered so quickly!

@slowjo: Thanks for the open answer!

Despite my so far little knowledge on typst code, I think about looking into this. Maybe in my free time. But I have no idea on how to commit something like this. Is there a starting point on package structure and local storage and how I can checkout, make local changes and so on?

2 Likes

The level of necessary instructions really depends on your background, but in a nutshell, the most straight-forward way would be to grab a copy of the code using git

git clone https://git.sr.ht/~slowjo/typst-abbr

and work on your changes directly in that folder, and checking everything works using the testing.typ file that uses a local import (i.e. import "abbr.typ" instead of import "@local/abbr:0.3.0" which would have to be set up first).

Your changes would go into the typst-impl.typ file where most of the implementation lives. Once you’re happy with the changes and everything works as you want it, you commit your changes, checking that you only add what’s actually needed

git add -p abbr-impl.typ
git commit -m "meaningful commit message"

after which you send the patch off to be reviewed

git send-email --to="~slowjo/public-inbox@lists.sr.ht" HEAD^

I’ll then check your patch, potentially reply with suggestions I have, until we’re both happy with the changes.

If you’re new to git, or sending patches by email, check out the nice tutorial over on https://git-send-email.io

1 Like

Thanks, I will enventually try this…

@Matze otherwise I could also look into it if you convince me that you’re unable to patch it yourself, but really need it anyways.
I’m busy with real life for now tho, so it’ll have to wait a few weeks at least

That’s also my problem. I don’t believe I will be able to look into this by this week…

Yeah no worries, the package will be waiting :)

I were too curious. So, I checked out the code and played around with it.

The Problem can be fixed in line 61 in abbr-impl.typ if I shorten the line.

If the long part of the abbreviation is not added to the label, it works like charm.

It makes some sense that formatted content may not be used as label. But I wonder what this label formatting “short + sym.hyph.point + long” is used at all.
If am not completely wrong, I am using only the short label, if I write @ECM in my normal content context. I would never dare to use @ECM#sym.hyph.pointElectronicallyCommutatedMotor

So I assume, this is for some completely different use that is broken like this or I didn’t understand the label here?

I also found a behaviour I still didn’t understand. I don’t want to call it strange, because it could in fact be useful!

  1. if I include my formatted abbreviation “ICE” and use the @ICE label in the test document, it is also displayed in the #abbr.list() call.

  2. However, if I don’t use the @ICE label in the test document, it is not displayed in the #abbr.list() call.

Is this intended behaviour?

In fact, this could be helpful!
We have a relatively complex document which can be parametrized to need. So, depending on the parametrization, abbreviations make sense or they don’t.

If this is intended functionality, I could just add all Abbreviations and only the used ones are listed. This would make total sense.

Please don’t ping random usernames in your messages. Read about posting and formatting in How to post in the Questions category, How to post in the Questions category - #7 by Andrew.

Sorry, I didn’t mean to ping random usernames. I suppose my mistake was to use my code without the quotes?

Without backticks, yes.

so the label is only put into the document in the list function, so that every time you use an abbreviation it links to the point in the list where its long form is shown. the form short+'-'+long was only used as an attempt to make sure this will be unique in a document. it doesn’t actually matter what the string is, as long as it’s unique.

you do bring up a good point tho, it would make much more sense to have the label point to something akin to "abbr:" + short.
I’ll try to remember this next time I touch the code

yes, this is intended behaviour.

The way I prefer to use the package is to have a textfile of all my abbreviations

#abbrevs.csv
BC, Boundary Condition
DOF, Degree of Freedom, Degrees of Freedom
...

and then just include that with abbr.load("abbrevs.csv") and not have to think about what I defined or didn’t define. If it’s used, it’ll show up, otherwise it won’t. Basically just like all your bibliography entries.

2 Likes

Super. That is a good idea.
You should mention that in your doc and I will use it just like that. :-)

I have committed the change to the repo and tried to send the mail via git, but I get the error message “Unable to initialize SMTP properly.” I believe this, as git in my company is probably configured to work internally primarily. I am unsure which SMTP server is used to send this mail and I don’t believe I have access to external mail servers.

Anyway: You shall be notified that I committed the change.