nmtake

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 @sunaurus@lemm.ee )

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.