Update physica.typ

[ruben-hude]

Makes i and j dotless when under a vector arrow.

[Leedehai]

Thanks! But I prefer creating minimum surprises for the users. I've seen math expressions where the accented i and j still have their dots, so I'd like to allow users to write just that. If a user want to have dotless i and j when an accent is present like , they can do so explicitly, e.g.

$ va(dotless.i), vu(dotless.i) $

or if they want dotless i and j throughout the paper:

#show "i": sym.dotless.i
...
$ va(i), vu(i) $

[ruben-hude]

Thanks! But I prefer creating minimum surprises for the users. I've seen math expressions where the accented i and j still have their dots, so I'd like to allow users to write just that. If a user want to have dotless i and j when an accent is present like , they can do so explicitly, e.g.

$ va(dotless.i), vu(dotless.i) $

or if they want dotless i and j throughout the paper:

#show "i": sym.dotless.i
...
$ va(i), vu(i) $

I understand that! It just seemed obvious to me that accentuated i and j should be dotless, since all of my teachers have been doing that.
I added a commit that add a dotless option set to false by default. Users can do let va(a) = vectorarrow(a, dotless: true) to make their writing more convenient instead of having to use dotless.i every time.
Tell if I should update the manual too.

[Leedehai]

Hi, I find it kind of clumsy, imho.. 😢 Typst currently doesn't support set rules for custom functions, so it seems you will have to specify the dotless arg every time. Moreover, this argument just takes effect on i and j, and it seems too "specialized" from an API design perspective, and it is doing something that should've been done at the symbol level.

Yeah I get that in many contexts accented vectors of i and j are dotless, as I've ran into them myself, but I still don't feel the the weight is heavy enough to tip the balance.

Maybe you could define a variables with va(dotless.i) etc. and use these variables whenever you want such vectors?

[Sinthoras7]

Typst currently doesn't support set rules for custom functions
Is there already an issue on the Typst compiler repo? This seems to me like a very useful feature for packages.

I definitely think that an option to get the behavior of the dotless letters would improbe this package, but I am not sure what the best implementation would be.

To circumvent the non-existence of set rules for custom functions, you could create a boolean variable, which the user can switch and then in the package code an if-expression which defines the function either in the old way or in the new way of the original commit. But to be honest I don't really like this solution, as this is really clumsy.

I am not sure, if the let va(a) = vectorarrow(a, dotless: true) solution of OPs comment works, but if it does and one doesn't need to specify it every time I would be in favor of adding this to the package, as I think a way to get this behavior with just setting one global variable would improve the package. (But it should be wrapped into a boolean variable, which does this.)

Edit: I don't think the boolean variable way would work unfortunately.

[Sinthoras7]

After further thinking, I'd probably wait until there is some easier way for setting global package options supported. Right now it feels quite hacky for such a small feature.

(FYI: This is what 🔥PgSuper🔥 on Discord said regarding package options:
egarding global package options , the most idiomatic equivalent thing nowadays would be using state with a global show rule, like

#show: package.with(option1: true, option2: false)

// becomes
#state("package", (:)).update((option1: true, option2: false))

// then, when you use a function...
#something-from-package()

// ...it retrieves the data
#let something-from-package() = context {
  let (option1, option2) = state("package", (:)).get()
  [Yay: #option1 #option2]
}

however , the problem is that it makes package functions contextual, so they all return opaque content

removing the context keyword will help with that (they wont return opaque content anymore), but then you will always need to be inside a context to use something from the package, i.e. you'd write #context something-from-package()
which is a minor annoyance but maybe not that bad depending on the package
but the true equivalent to global, immutable options (The previous approach is the only possibility when you want to be able to change options mid-document) would be to make a single function returning functions

i.e. your package is defined as

#let init(option1: true, option2: true) = {
  let something-from-package() = [Yay: #option1 #option2]

  (something-from-package: something-from-package)
}

then, in your document

#import "package": init
#let (something-from-package,) = init(option1: true, option2: false)

// Works, no `context` needed
#something-from-package()

right now these are the two approaches for global options (state and function returning functions), in the future it's possible we will have more ergonomic approaches though
previous discussions:
here typst/typst#2403 and here typst/typst#2636 )

[Leedehai]

Thanks! I'll close this for now.