I think https://git.sr.ht/~leon_plickat/lswt may work.

Some applications can't display some Unicode strings like s̵t̵r̵o̵k̵e̵, so replacing Markdown element like ~strike~ with Unicode equivalent (s̵t̵r̵o̵k̵e̵ ) may not be a good idea if you want portability. I opened your post in text editors and noticed that neovim-qt drops s̵t̵r̵o̵k̵e̵'s combining characters (issue on Github) and just displays stroke instead of s̵t̵r̵o̵k̵e̵; GUI Emacs with my font settings (Noto) doesn't combine the characters and displays s-t-r-o-k-e- (as I said, this may depends on font settings).

Can you get the stack trace with (setq debug-on-error t)? The error means rx got wrong regex form like (rx (** 3 2 "a")) or (rx (** 3 nil "a")).

I don't know why the motion didn't work in Evil mode, but if the goal is deleting all invisible Unicode characters, I'd write a command like this:

(defun my/delete-invisibles-in-region (start end)
  "Delete invisible characters in the region specified with START and END."
  (interactive "r")
  (save-excursion
    (replace-regexp "\u200B\\|\u200C" "" nil start end))
    ;; (query-replace-regexp "\u200B\\|\u200C" "" nil start end))
  (deactivate-mark))

Try glyphless-display-mode:

https://emacs.stackexchange.com/questions/65108/zero-width-space-shows-as-underscore

Cheese Day

Thank you for trying the package! I completely forgot to mention require in README, and didn't know package-vc-install. I'll add it to README later.

I’m using emacs’ built-in completion–it works fine.

I hope it works on other packages like helm or ivy too.

Fixed wrong link - now the post title correctly link to the repository ;)

One of the reasons is it makes moderation (including soft moderation by users like downvotes or reports) harder. Users not familiar with Japanese can't decide whether the post follows the rule and is on topic.

I encountered a bug while posting another comment. If a user "Submit" text from the "Preview" view, empty text will be sent.

Thanks for the hard work. It's already quite usable for me. Here are the issues I noticed on Firefox/Linux:

• Each comment area seems to have overflow (caused by the text buttons?), so hovering a mouse cursor on the comment reveals hidden scroll bar on the right.
• Titles are too bold and look somewhat intimidating.
• Rendered inline code (`...`) leaves the backquotes like this.

I stick with C-s (similar to vim's /) because of the exact reason you said, and I'm happy with C-s.

Please note that C-s <some characters> RET moves the cursor at the end of the target (/ moves it at the beginning). If you don't like the behavior, see this post (I use C-s ... C-r RET in that case).

How about incremental search (C-s) or some external packages like avy?

Thanks for the clarification. I switched from Xfce4 to GNOME many years ago because the former doesn't support Wayland at that time, but I still miss the manual quarter tiling with the shortcut keys.

IIRC Xfce4 supports quad manual tiling like that.

Strong focus on privacy and security (all authentication with the Lemmy API is done through secure httpOnly cookies, user IP addresses are not leaked to external image hosts, etc)

Awesome. The current lemmy-ui sends a lot of traffic to other Lemmy instances to get pictrs-cached images, so this is huge improvement. On the other hand, on next.lemm.ee those requests seems to be gone. As feedback, I noticed this page still seems to send a request to imgur, and the text is difficult to read because of the low-contrast theme. (edit: fixed and now completely readable. thank you @[email protected] )

If I understood correctly, the first match expression doesn't take the ownership of the prev_data.kind because the prev_data.kind is a place expression:

https://doc.rust-lang.org/stable/reference/expressions.html#place-expressions-and-value-expressions

A place expression is an expression that represents a memory location.

https://doc.rust-lang.org/stable/reference/expressions/match-expr.html#match-expressions

When the scrutinee expression is a place expression, the match does not allocate a temporary location; however, a by-value binding may copy or move from the memory location.

I'm not sure what "a by-value binding may copy or move from the memory location" does mean, but I beleive no allocation means no move.

For the second match, move happens. The tuple (prev_data.kind, new_data.kind) tries to take an ownership of the prev_data.kind, but the prev_data is &Data (borrowed from the vec data), so the tuple can't take the ownership.

I prefer high-contrast themes these days and modus-themes work great. Note that Emacs 29 doesn't contain newer themes like modus-vivendi-tinted.

Lemmyでのアナウンス

Lemmyのニッチなコミュニティ向けの連携してくれるといいなーとか思ってます
Redditにもあったんですけどあれはあまり作りこむ気がなかったみたいで…

Oh I didn't know the book is freely available under the CC license; I bought the Japanese translated version just a week ago. The book is quite difficult for me but the first chapter was very good read.