@PauloCereda so I have fedora 40 installed, but I cannot figure out how to get it to boot 40 without just overriding fedora, which would mean I had to do it every time I update the system. what is happening is that the automatic processes are writing EFI inits to the ESP, while /boot still holds traditional initrd (.img etc.) for 38. that would be fine, except the boot menu only gives me 38. the EFI boot menu just includes fedora's shim. I don't know exactly how this goes, but ...
... I'm assuming the menu I'm seeing at boot is grub's. (it certainly looks like it). that menu appears to be derived from the contents of /boot rather than the ESP. I've tried regenerating initrds with dracut, regenerating grub's config and reinstalling grub (not the package - I mean reinstalling it as the bootloader). I need to fix this in the OS because I don't know the firmware password. (more specifically, I've forgotten it and doubt our newly centralised IT will be forthcoming.)
@PauloCereda I would be very grateful for any pointers e.g. a description of fedora's current boot process all in one place would be great. do you know where I might find one? I don't like grub much, but it has always 'just worked' on fedora. did something change between 38 and 40? I can't figure out why it has decided to install images into the ISP or to generate EFI executables rather than .imgs. Or why regenerating grub config doesn't update the menu?
[looking at the length of that, you will never admit using any software whatsoever to me again :(.]
[I will try to compose something more coherent in a bit ...]
@PauloCereda just ignore the above for now. I don't think it is intelligible.
Can anyone here who a) uses emacs, and b) uses LaTeX3 please try out my emacs mode for LaTeX3? I have recently updated it, and am now happy with the cls/sty mode (dtx mode hasn't yet been done, and doc-mode is very incomplete): github.com/enkorvaks/emacslatex to get it. I would appreciate any feedback (either here, or as an issue on github) if you like or dislike certain parts (other than colour scheme opinions :-)
The expl3 manual says that it can be reasonable to use a linked prop for props that store a large number of items. What kind of large is meant here? > 100? > 10000? Is there some kind of rule of thumb? And would it make sense to change a prop to a linked one when it is about to store more than a certain number of items during compilation?
I understand that this depends on the use case. Here, user data would be stored in a prop. When the prop is created, \prop_put:Nn is used to store the data entry by entry. So, I would assume that it could be beneficial to use a linked prop in such a case.
@JasperHabicht Correct - the flat ones are all stored in one macro - good for csname usage (was the original driver - in the 1990s), good if you need to copy the prop, reasonable performance for short lists
@JosephWright I will further investigate … and then propbably go for a linked prop :) … I think, in my case, it would make sense even if in some cases the stored data might not be > 100 entries. Thanks!
@JasperHabicht for the bible tagging example (which was the use case that pushed us into moving linked props from development code to more mainstream) the run time went from over an hour to 5 minutes just by changing the prop implementation
The \prop_ command should all work with flat and linked props, right? So, in theory, I would only need to change \prop_new to \prop_new_listed and everything should work? But I saw on GitHub a recent bug for \prop_item …
I resolved it by declaring unknown .code:n = { \PassOptionsToClass { \CurrentOption } { book } } within the \keys_define:nn. Was that the correct approach?
@EmanueleNardi I am not sure if that will pass on everything. I still don't have a good sense of how to do this ....
@EmanueleNardi no. the complications arise if you want to pass on only those which aren't declared by your class and/or you want to not have spurious warnings about unknown options.
By "complicated," I was referring to >this question<. @cfr mentioned that this approach is appropriate when "you want to pass along only the options not declared by your class and/or avoid spurious warnings about unknown options."
@DavidCarlisle The solution provided here is exactly what I needed
@EmanueleNardi note that you shouldn't do this anyway unless you are sure that none of the keys you define are keys or options used by any package the user might load, including packages which haven't been written yet. or you limit filtering to your class's namespace or something. e.g. if you do something language-specific, you don't want to filter out the language option before packages see it ....
@cfr Would you be willing to review my class and offer feedback on areas for improvement? I have a feeling I may have taken some shortcuts and could have written the code more efficiently.
