IMO the "forty hours per page" rule is not up to date, and more a consequence of lacking proof automation in 2005. From what I understand about Lean, this has been one of the things that they have put a lot of effort into improving, making proof mechanization more palatable to the mathematically inclined, as opposed to just logicians.
Lean went other way on automation that there is no automation. Isabelle users frequently point that decades old isabelle is better than Lean on this. In the end Lean approach proved to be better with LLM as the outer loop is automation.
What is your estimate for the number of hours to formalize one page of undergraduate mathematics? Maybe you are saying this is close to zero, if/when Mathlib eventually covers all of undergraduate math?
I'm using this for my mother's website (https://www.touchofglass.eu/), and my only complaint is that it assumes you version a website in a Git repository. You can work around it by uploading a tarball or something like that, but it is far less convenient than using sftp/rsync. But considering that we are far into the free 10GB a month and I only have to update it very infrequently, it seemed like the best solution.
"Research has shown that being creative through art projects can help promote stress relief, increase self-esteem, help connect with others, and boost intrinsic motivation. So, participating in mindful art projects can open one's mind to more positive thoughts and offer alternative solutions to life problems."
And wise. Well done publishing the Web site which works without fuss in a calm way.
Why should it be? In my experience it depends on the case, and in my case it seems like an absolute technological overkill to version the site and have statichost regularly pull from some repository, as I update it perhaps once a year.
I mean, versioning is basically free from a technical / storage / time spent standpoint, and my experience says that if you don’t do it you likely will lose your code at some point
Simpler. Or you work/collaborate on projects with people who really shouldn't have to learn Git, even via a GUI.
I'm a programmer by trade and do plenty of versioning via _v1 and so on when working on music with others, we basically send .zip files over Telegram and append some label at the end. Not gonna ask these people to learn something when basic "have many copies" does the trick sufficiently good.
Not really, I just use Emacs' versioned backup files that are automatically generated. As I said, I don't have to update the site that often, so it is entirely sufficient. An advantage for me, besides not having to write Git commit messages, is that I also don't have to version images in Git, which I don't like doing.
I was annoyed by some of the comments in the "Packages" section, because it is clear that the author didn't try anything out but just scattered a few comments though out the file.
Regarding :vc and :load-path, this was obsoleted transitively due to the obsoleting of package-vc-install-from-checkout, which has portability issues. Bug#80604 goes into the background for this. This is NOT an obsoletion of the :vc keyword for use-package.
Regarding package-autosuggest, this is disabled because it doesn't interest most users. It is targeted at new users who aren't familiar with the packages, and might be interested in new major modes. Experienced users are generally either familiar with the packages and use them or prefer to stay in fundamental mode. The minor mode is enabled as part of the newcomers theme!
No mention of package-review-policy, which especially in the "age of AI" is an important feature is you want to be careful about external code you are using on your system.
Oh and on the topic of the newercomers theme, the reason it is not mentioned "higher up" in the NEWS file, besides it being the wrong section, is that it is highlighted on the splash screen, where new users are going to find it, instead of a NEWS file.
The post mentioned so many things and went into lots of interesting discussions about the new stuff . I find it amusing you think it’s ok to criticize the author for not trying things out and not mentioning your favorite topics. Here’s an idea: write a better post yourself.
That is what https://www.emacswiki.org/emacs/EmacsThirtyOneHighlights is for. And it is not so much that the author doesn't mention the topics, but that he misconstrues them or just plain doesn't appear to understand what he is talking about.
But I do test things out, by virtue of often running the tip of master branch and submitting bug reports. But I cannot test every mention in the NEWS, so on that part you are right.
Deprecating :vc + :load-path without expressing why is a curious oversight. And "portability issues" is all fine and good, but why embed custom git clone + build grammar code in the treesit.el file if VC checkout portability is a concern? Surely VC is better at it than a bunch of brittle string concat code in treesit.el I do not understand why one part works and another supposedly does not.
The change is especially infuriating as for most of us it actually worked fine, and user-lisp directory does not solve the retrieval and setup problem, which `use-package` for all its flaws at least standardises.
Most users probably do care about discoverability of related packages, existing user or not. But that's in the eye of the beholder.
`package-review-policy` is security kabuki theatre. Someone who wants to harm an Emacs user can find many other ways of doing so with or without this flag.
The portability issues of `package-vc-install-from-checkout' are due to issues with symlinks not being portable, which is what that function relied on. None of this is related to tree-sitter. That is the function that the combination of :vc and :load-path would use, which just had to be transitively deprecated due to the mistake in `package-vc-install-from-checkout'. Critically `package-vc-install-from-checkout' _does not_ do any retrieval, the checkout of the package had to already exist beforehand, which use-package did not take care of. The function just made sure that package.el would activate the linked directory. User Lisp provides this same functionality. Do not confuse it with the :vc keyword that invokes `package-vc-install', which actually retrieves a checkout of some repository and prepares to do be loaded by package.el.
This is the kind of research that I would expect an article like yours to make. It is totally fair to contact the people who worked on this, instead of being smug about it and caricaturing the Emacs maintainers as conservative.
If you look at the definition of a macro like defcustom, you'll see that it just expands to a function call, where all the logic is implemented. This could also be implemented in the macro, but that is more complicated and brittle, due to the risk of double-evaluations and having to produce code that will (usually) later evaluate with the intended side effect.
Furthermore, macros and functions constitute a kind of function coloring. To use a macro in a function, like defcustom, you couldn't pass the name of the user option you are defining in as a symbol, as that is not evaluated. So instead you'd have to call eval on a runtime constructed expression, which is a cludge.
So I agree with the top comment, to avoid macros is a sign of Lisp maturity. It is easy and fun to admire them when you are coming from languages with arbitrary restrictions in their macro systems like C, but ones you get used to them you don't treat them with any more wonder than any other arbitrary restriction that a language may lack (bad ad hoc example: nobody praises C for the lack of a CALL keyword).
If you instantiate it with concrete types, does "(b IntBox) Map(f func(int) string) StringBox" make more sense? You have a collection (in this case Box) containing values of type T, a function that maps values of type T to type U, and if you apply that function to all elements in that collection you get a collection of type U.
A one item collection is admittedly a lame one, but it is a collection. Pointers are collections of zero or one items in a sense.
Now, the verb "map" is the traditional name for this operator, but I agree it sounds confusing when the noun "map" is also a collection type. C# and SQL call this Select, if that helps.
Is that really the confusing part? If you had a general collection interface, say Mapper, a Box (i.e. a singleton set) could implement it just as well as a List or a Tree.
I realize that mathematically speaking a singleton set is still a set, but as a programmer who is used to map operations in other mainstream languages, I was expecting some kind of loop in the implementation. It took a few page faults in my brain to realize what's going on.
Your understanding is quite incomplete. Wait till you think about the mapping operation for functions. Then there’s no loop, just function composition.
The more fundamental question for me is why the author didn't decide to make make code blocks non-breaking by default, or just add the class annotations when he writes the HTML?
I am familiar with the syntax, so I am biased ("*/3" and "12,14,20" makes sense if you are familiar with Unix tools), but it is still more intuitive to me than the systemd unit file syntax and usage. I know that I just have to edit /etc/cron or throw any executable file into /etc/cron.d/monthly and it will work on my system, but I cannot write a systemd timer file from scratch without looking it, and to do that I first have to find the directory where the other examples are located. /etc/systemd doesn't appear to be it.
This is generally my only real complaint about systemd. I don't care if it is too monolitic, written in C or whatever, I just want a straightforward syntax for straightforward operations. I'd like it if systemd could recognize if a .target file is a shell script and just do "the right thing". Perhaps it would make sense for a timer file to recognize cron syntax as well. Or at least allow for a kind of extensibility so that I can have it supported.
If systemd had a little more respect for existing conventions, I am pretty sure it wouldn't be so controversial. After all, system administrators like it because they use it all the time, but a regular, full-timer user like me, who only deals with it when something is broken or have to use it as a means-to-an-end to set something up, then all friction is annoying and bad UX. (And no, using Nix is not the solution)
Systemd lets you create templates that take an argument in from the scheduled service. It gets that from the value after the @. So you can write a unit file that schedules a task to run say every 3 days and in that unit file reference `jobs/%i`, then put your task in a file in jobs and say `systemctl start every-3-days@script1.sh` to run `script1.sh` on your schedule without needing to create a new unit file for each script. StepCA has a nice write up on their site about using these templates to schedule cert renewals for any arbitrary service
Yeah, it would be nice to have a folder like /etc/systemd-jobs/ where I could put them and where there are no files unrelated to job scheduling. There is /etc/systemd/user, but it does get a bit of pollution depending on the system.
Not sure if you're talking about cron or systemd, but cron definitely has that in /etc/cron.d where you can have arbitrary crontabs, or /etc/cron.{hourly|daily|weekly|monthly} where you can just place arbitrary scripts if you don't care exactly when they run, just the frequency.
reply