I don’t agree. The issue linked in the post and also this one have shown the new maintainer to be antagonistic and evasive.

Yes. The relevant points are that Catfriend’s repo was fully reset, no git history, multiple times this year, supposedly because of sensitive data that was mistakenly checked in. If that’s the case, it might explain why shortly before Catfriend deleted his repo, he created an issue saying something along the lines of ‘stop messing with my desktop’, which could be read as a plea to hackers. The repo went dark, and someone else published it, with Catfriend’s private signing key, which triggered automatic updates for some users, without them knowing the maintainer changed. They also claim to have Catfriend’s github credentials. After staying quiet for a month, Catfriend recently posted on the syncthing forum saying that everything is dandy with the new maintainer, without addressing major concerns. Meanwhile, the new maintainer has made large changes to the codebase without public comments. The last two updates from the new maintainer have been reviewed independently, and reproducible builds are enabled to ensure the apk matches the sources. However, that is assuming that Catfriend’s repo was safe to begin with. In the case of ongoing blackmail, malicious code could have been added during one of the repository resets, or in a large refactor commit.

The sad part is that Catfriend picked up this repo after Syncthing deprecated it, just for his friends and family. I don’t think he is a professional developer, and he very obviously was overwhelmed by the project. Syncthing is a very juicy target for malicious state actors, and trust is crucial. I feel awful to say that I no longer trust Catfriend or his replacement, but the circumstances don’t inspire confidence.

I said this in another thread, but apparently it’s not widely known: syncthing works fine on termux, there is no need to install any third party code. You do need to run termux-setup-storage to get access to the shared storage that other apps can access, and I found it worth it to set up the termux:boot app to run syncthing on phone boot. This way only uses the official syncthing repo.

I have no idea what you mean. I just had to set this up once on my parents’ phones and now it works all the time, even when they change networks, no port forwarding or any interaction required on their part. Rsync is a cli that requires an existing network connection between two devices, both online, and doesn’t watch files or create a file version history. It is an entirely different tool.

Yeah, it’s odd to me that the syncthing repo makes a point of not officially supporting android, and not making any promises about its continued maintenance. It’s a large part of their user base, but it seems, for some reason, this developer that went dark never spent time to coordinate with or join the core team.

Not as much as the syncthing apps.

The android development always just seemed… off, idk, I just got weird feelings about it and the fork. So I switched my family to use termux and termux:boot to run syncthing instead, it works fine.

One more note on this is that while some searching did lead to webservers that can decode uris into utf before handling them, I believe this is very unsafe for a public server, and, in the worst case, could allow public access to your entire drive. There are vulnerabilities because different systems, and even different services on a single system, can treat specific unicode characters differently. My advice above to url-encode the filenames before serving or while building them would avoid the need for any decoding of requests as they come in.

URIs can only contain ASCII characters, so the web server is receiving requests in ‘percent encoded’ form for urls, not in utf8, and so there is no way for the server to know which file to respond with. You’ll have to urlencode the filenames yourself unfortunately, so that they will match the incoming requests. The tool jq can urlencode cyrillic characters:

echo "људиа" | jq -rR @uri

You could probably do this as part of the build process if you are clever enough.

This is only for the file name itself; the exported document should share the source document’s encoding unless overridden by the org-export-coding-system option.

I was wrong, just remembered incorrectly.

Signal is not open source.

As other comments have pointed out, and you already mentioned this as a possibility, this is how I would write it:

(defun eat-more ()
  "Open a new terminal."
  (interactive)
  (eat nil t))

However, given your goal of understanding commands and the buffer list better, I’ll try to explain a little better.

The first parameter, the shell, when left nil, will use your default eat-shell, so the funcall in your current implementation is redundant. The eat-shell can be customized separately if necessary.

The <3> or <5> or whatever suffix in the eat buffer name is actually not generated by eat itself, eat is using generate-new-buffer, which is an Emacs built-in function that relies on the C function generate-new-buffer-name.

So what you are attempting to do is not just re-implement a feature eat already has, but a core function within Emacs itself. If you don’t rely on built-in functionality, I would argue that you are not familiarizing yourself with elisp development, you are really creating your own language.

However, re-implementing what eat does can maybe be a good exercise, so to use the built-in function to help us, I would probably write it like something like this:

(defun eat-more ()
  "Open a new terminal."
  (interactive)
  (require 'eat)
  (eat
   nil
   (let ((name (generate-new-buffer-name eat-buffer-name)))
     (when (string-match "<\\([[:digit:]]+\\)>" name)
       (string-to-number (match-string 1 name))))))

One thing I’d like to draw attention to is the use of the variable eat-buffer-name, which is defined by eat and is customizable, so even though most people are using the default name "*eat*", this could be different for some users. However, using this variable means we need to ‘require’ the eat package first. In the simpler answer, we were relying on the fact that the (eat ...) command is autoloaded, and can be called without requiring the package first. But that isn’t true for the eat-buffer-name variable.