Mattias Engdegård <mattias.engdeg...@gmail.com> writes: > 25 aug. 2025 kl. 22.31 skrev Daniel Mendler <m...@daniel-mendler.de>: > >> When using Unicode glyphs, org-habit-build-graph breaks due to a recent >> change in Emacs master. Emacs master disallows resizing unibyte strings >> to multibyte strings. >> >> (setq org-habit-overdue-glyph ?• >> org-habit-alert-glyph ?• >> org-habit-today-glyph ?• >> org-habit-completed-glyph ?◦) > > Interesting, thank you for reporting it! I've seen this kind of code only once > before, in ruler-mode.el, and a simple fix is to work on a vector instead and > convert it to a string at the end. String properties can be gathered and > applied > afterwards.
Mattias, thanks for looking into this so quickly! Vectors are indeed a good substitute for such code. > The attached patch (untested!) shows how this might be done. No doubt > it can be improved. If you are happy with it, I'll push it to Emacs > master. Yes, org-habit with Unicode characters works well again with your patch. > (By the way, did the old code work if you used the glyph `·`?) If by old code you mean the code before your patch, but without the aset string resizing - it works somewhat. The strings are modified successfully, but the end result in the agenda buffer looks broken, with some \257 characters. >> Instead of mutating strings, a better approach in org-habit-build-graph >> could be to concatenate a new string? > > A vector can be a straightforward one-to-one replacement in cases like this. > Building a string from smaller pieces is generally a good solution, and lends > itself to a mutation-free coding style that makes code easy to read and reason > about. Another way is to use a temporary buffer. Agree. Buffers are a bit expensive though. I would only use them if more complex transformations are needed. >> It seems the goal of upstream Emacs is to move away from string mutations? > > Only very slowly. Almost all modern languages have immutable strings and for > good reasons, but the goal right now is to do away with the rare kinds of > mutation that cause the most harm, in this case a feature whose mere existence > imposes extra costs on code that does not use it. Yes, it is a good direction. I am all for making Elisp strings immutable given that we have vectors and buffers. Emacs even crashes when using aset on symbol-names, which I had reported a while ago. Thanks again! Daniel
