Does it even work on Wayland? I always thought this was a feature of X. I really like it too but the inconsistent support seems to catch me more and more often these days.
Yeah, it's an X thing. But on X, the highlight/middle-click clipboard is separate from the ctrl-c/ctrl-v clipboard, so you can hold two things at once when moving text around. IIRC this was just a historical quirk rather than any intentional design, and I think in Wayland they duplicated the controls but also combined them into a single clipboard.
You don't have to just "stare" at the source; you can interact with it! Emacs is incredibly well documented and you can learn a ton with just C-h f (i.e. M-x describe-function) and C-h v (i.e. M-x describe-variable). In an Elisp source file, use those commands whenever you don't know exactly what a function or variable does. Read the description, and click on the hyperlinks to see the source. This is IMHO the best way to learn how to actually get things done. If you don't know what function or variable you're looking for, M-x apropos and its variants will be helpful.
I don't have a good reference (other than the Elisp manual) for high-level design patterns, but in general, Elisp is very flexible and already has what you'd need to implement any patterns you know from elsewhere. Decide on your data structures first. Probably the most important lesson you might not know yet is to use buffers, not strings, to do most text manipulation.
I started using fossil recently and have been quite pleased with this aspect of it. I miss a few things from the git world (mostly magit and its magical ability to stage individual hunks of a diff) and there are a few rough edges, but I totally agree that having a wiki and issue tracking inside the repository makes so much sense. fossil‘s simplicity is a breath of fresh air for anyone who has to use git from a CLI. Well worth a try for anyone on the fence.
I love Fossil, I have been using it for all of my projects for the last couple years. Things that I love include:
1. batteries included single-file functionality (fossil binary + sqlite file and I have everything!)
2. Hosting them is super easy, I have a lighttpd server configured to do cgi-bin, and i just pop the project.fossil file onto the server and I have a project.
The biggest friction is managing users across repos. Each repo is its own RBAC, the "zhynn" user in one repo is not the same as the "zhynn" user in another repo. It would be cool to be able to sync users across repos, which should be possible with sql, but I think that it could get weird with repo-specific permissions. Currently I just add my user to each new repo, granting that user setup permissions, and removing the admin before I scp the .fossil file up to the webserver.
In the end though, I intend to use it for all of my personal projects from here out.
I have a pipe dream of turning a fossil repo into a portable distributed more-async-friendly slack clone, where the "chat", "wiki" and "forum" functionalities are all used as the back-end for a responsive UI that basically does the same thing that slack does, but lives in a single sqlite file + binary. It could run mostly offline in a kind of scuttlebutt/limited connectivity pattern (when online push/pull messages, get latest chats/files/etc, go back offline. As you go through the content, make your responses locally, then go back online, push/pull again, repeat.)
I have another pipe dream of making a RedBean APE fossil UI. I think it would be cool to have a single file universal executable that is my project repo.
Those two pipe dreams sound really cool! Do you have a website or something to lurk you via if you eventuality get around to those? I find it difficult to keep up, as it were, using form histories and other social media platforms.
The workflow is paradigmically different, and that may throw many people off.
There's no rebase, on principle. Branch names are permanent attributes of commits. Even abandoned branches remain visible forever. Code review is post-hoc.
People who are extremely accustomed to Git workflows may find the paradigm alienating.
Yep, it’s not for everyone, and their docs are pretty clear about that. OTOH those same docs contain a variety of arguments that git isn’t really designed for everyone either and that fossil might be a better fit for projects that have just one or a handful of developers, which AFAIK is the vast majority of projects on Github. My experience is that it is certainly an adjustment but the docs are good at explaining (and justifying) the differences, and the built-in features are very useful, especially for anyone looking to reduce their dependence on a centralized host that’s become unreliable.
Citations. Until we can cite specific passages in HTML as quickly, easily and readably as we can cite pages in paged media, HTML will remain a second class citizen for serious scholarship.
Yes, I'm aware. The problem with anchors is that the author has to take care to make them both unique and human-readable across the whole document. The problem with URL text fragments is that they generally become too long to be a citation. Both need quality-of-life improvements in the tooling before academics will consider using them.
For example, it's pretty easy to use CSS counters to create as many automatically incrementing counters as you need. Page number, section number, theorem number, etc. But (a) you can't do this in raw HTML, which means you can't rely on this working in any user agent that has poor support for CSS; and (b) you can't refer to the values of those counters outside of CSS. Thus, there's no way for you, as an author, to write the write the equivalent of LaTeX's "See Theorem~\ref{thm:foo}" in HTML and rely on having it auto-numbered and rendered correctly wherever your readers are. So the number has to already be there as text in the HTML, and you need a separate, document-unique id attribute coordinated with the number to use for linking. This means you need a separate compilation step to produce the HTML, so you've lost pretty much the only advantage that HTML had over LaTeX.
But fundamentally, the problem is that citation practices assume that the reading format is controlled by the author/publisher, so that all readers are looking at a common view of the document, whereas the Web assumes that the reading format is controlled by the user agent, and user agents vary widely. Thus, on the Web, you need formatting-independent citation practices, which have not yet evolved, or at least not become widely used, because it's too hard compared to page-based media, which have been working for centuries.
Sure, the world is a better place with fewer serfs in it, but what exactly is of "higher value" than being a research mathematician? It's already a profession that consists essentially of exercising our highest and most distinctly human capacities: creativity, abstract reasoning, and passing the results of those on through a distinctive language and culture. I don't think the comparison with serfs is useful.
I'm sure most research mathematicians would like more freedom from some of the drudgery of their work (grading, admin, etc.), just like the rest of us. But we should be aiming for a world that allows more people to become mathematicians, not fewer.
I love the idea and wish I could get something like this in Europe. The main reason I "need" a smartphone over here is that EU banking regulations make it nearly impossible to do online banking without one. Anyone know of similar projects over here that would satisfy that need?
"Europe" may be a bit broad there. In Denmark, I can get by without a smartphone; I have to carry what they call a "MitID code display" to gain access to online public services (though the device is entirely free of charge), but I also carry keys, so it's not a big hassle.
A lot of banks in Germany still offer photoTAN generators. Effectively, a physical device that generates 2FA codes for your login. You can then use the website as usual and use the codes from this instead of phone confirmation. This is one example from ING.[0]
That way you can effectively use most feature phones as your daily drivers. HMD (Nokia) still manufacturers some of them that even come with GPS, etc. There are some feature phones that even run Android but I don't know what app support for things like Spotify is like.
There was a comment a couple of days ago that mentioned using MDM to lock down their iPhone. So essentially, dumbing down a normal smartphone to whatever your essentials are and removing the web browser. That may be an expensive way of going about this, but I find it an interesting approach. Android probably has similar solutions, anything outside that duopoly will get tricky again w.r.t. banking.
I gotta ask. What does everybody do with their banking app, that they need it with them all the time? It's always the excuse why people can't switch to some other phone.
I don’t need it with me all the time; I‘d prefer to just log in to a website on a real computer! But you can’t do this in the EU in practice without a banking app on a phone, or some other piece of hardware that you have to pay extra for and is certainly not more convenient.
Right, I suppose this is theoretically possible here too (I'm in Austria), though I haven't looked into it that carefully, because all the options here seem to cost more than my current bank account and as far as I can tell still require a smartphone.
I wouldn't necessarily mind a dedicated piece of hardware, but if it's dedicated hardware, I feel like the bank ought to provide it, not make me pay for it. And I'd much rather it be a generic piece of hardware that can also be used as a second authentication factor for other things, like a Yubikey. I've looked around but have not found any banks that offer this. The only one I had heard of no longer offers it.
Presumably the 40mb of data is not from Wikipedia, but the Javascript tracking code bundle needed to turn it into a doomscrollable social media feed. ;) By those standards, I think it’s pretty lightweight! For comparison, the Instagram iOS app is 468.9mb, more than ten times the size…
This app IS made in under 1mb. The entire app, including all the assets minus all the actual Wikipedia data, is 21kB (no minification or compression). And all of it is in a single html file with human-readable code.
I have been working on implementing iCalendar/RFC5545 in Emacs Lisp. I recently submitted a large patch and hope it will be merged in the next couple of months:
This will add an iCalendar library to GNU Emacs, allowing packages in core and third-party packages to work with the format. More on the decisions I made and what I learned here:
This isn't really comparable. A newspaper is a single source. New York Times is a newspaper, CNN (a part of it) is a newspaper. Services like Kagi News, whether AI or human-curated, try to do aggregation and meta-analysis of many newspaper.
reply