∀ X, X is right for those who share the same opinion.
If you think a simple tautology disproves someone's claim, there's a good chance you're missing the point.
1,197 karma · joined December 5, 2018
If you think a simple tautology disproves someone's claim, there's a good chance you're missing the point.
One can endlessly discuss pros and cons of using C++ in the Kernel, but in the end it's about either making a bet on C++ or not; it's not that one can or has to formally prove that the bet is right to avoid being called religious. Linus listed cons that he finds important (which are real) and decided not to bet on C++.
Linus has a long history of successfully managing Kernel, I think this makes his bets worth something. So yes, passing Linus filter is a great success for Rust, and even greater given that C++ didn't pass.
Also, the fact that C++ succeeded somewhere doesn't disprove this claim.
I remember someone being enthusiastic that "our young are exploring their sexuality". What will happen if they don't? Nothing. They will explore something else and be fine.
UPD: rafale is right, I misunderstood the parent. It's not about any change, it's about allowing more freedoms.
Some might argue this doesn't qualify as "C++ trying", but I think it does.
And more importantly, a place where C++ has failed.
I'm very impressed with what asciidoc-hs plans to do! Especially looking forward to LSP support and stuff like incomplete/incremental parsing.
My favourites are Rust and Haskell. Neither of them had a parcer until recently (even though the original implementation has been around for a few years now). Both are at early development stages at the moment.
[1]: https://github.com/bytesparadise/libasciidoc/blob/master/LIM...
This must be contributing a lot to the adoption difficulty (at least for resource-limited open-source projects). There's a good chance you will not find an AsciiDoc parser library for your favourite programming language.
www.youtube.com##ytd-watch-next-secondary-results-renderer.style-scope.ytd-watch-flexy
www.youtube.com###comments.ytd-watch-flexy.style-scope
www.youtube.com##ytd-browse.ytd-page-manager.style-scope[page-subtype="home"]
www.youtube.com##ytd-guide-renderer
www.youtube.com##ytd-vertical-channel-section-renderer
But know that these filters break some functionality (which I, personally, do not use) like uploading videos or showing your subscriptions page.
Other things that are being brought up here are at least as important and interesting to discuss.
The links to LibreSignal (already mentioned here) and Wire stories summarize most of what I was pointing at: https://github.com/LibreSignal/LibreSignal/issues/37#issueco... https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7
But I support the devs who work on alternative clients. The official Electron app is just bad, especially on Wayland. Hope signal-cli will keep working.
[1]: https://www.reddit.com/r/linux/comments/mp2j0j/starting_a_na...
How does this client bypass it? Can I use it to text a friend who uses the official servers?
Truth is not like that. It's must be absolute, and it should not be defined arbitrarily based on what improves people's well-being. (Or maybe it should, but that's going to be a different kind of truth.)
Suppose you did this and encrypted + signed your values with FHE and FHS as Sign(Encrypt(x)) and Sign(Encrypt(y)). Now you want to add x and y. For that, you will have to run the homomorphic addition of Encrypt(·) values using homomorphic operations of Sign(·), i.e. you do Encrypt(x) + Encrypt(y) inside Sign(·), not just x + y.
This means that the overheads introduced by FHE and FHE do not just add up, they get composed (as in composition of functions). This will be a terrible blow-up in performance. I guess, for this reason people try to build authenticated FHE that will have the properties of FHE + FHS but as a one, more efficient block.
If you send your server two encryped numbers and ask to multiply them for you, the server may send you their addition instead, or just encrypt some constant it chooses and send you that. And you can't check that your data was processed the way you want.
If you want authenticated FHE, that will be even slower.
For anyone who wanted a database to query privately, you can look at dishonest majority generic MPC protocols. Here, you will need N servers instead of just one. You will secret-share your inputs between them, and let them do computations on the shares. As long as at least one of the N servers is acting in your interest, you are safe. But if all servers unite their shares, they can recover your values.
But. Kakoune is still something bigger for me. It does take text editing to a new level and it does make it more efficient. It is similar to Emacs in the sense that both follow the sequence “select and apply an action”. But Kakoune has richer selection primitives and has actions that work on multiple selections at the same time; this can be done with macros, but it's by far less convenient.
In your example, you can record a macro and apply it to all the lines of a table. Will you have to do it for each line one by one? Can you say, “run the macro on each line of this paragraph”?
> You have instant feedback while recording a macro too?
Sure, but not on all the places where you're going to apply it at the same time. And your macro may not work correctly on some of the lines, you will not see it while recording it. With multiple selections you see it immediately and can undo the last action and try again.
Multiple selections stay there after you apply actions on them. After you apply something, you can see the result and slowly think of the thing to do next with them. With a macro, you will have to type in the whole sequence when you record the macro.
Macros can achieve the same things, but they require more mental effort and are harder to get used to. And when you're focused on your code, the mental effort it takes to used your editor matters.
In the same way, multiple selections are an improvement over Vim's tradition of shooting regexes at your text; for the same reasons: interactiveness and instant feedback.
I have no doubt that what I've shows can be done in Emacs. How natural is it to express? How much scripting and packaging does it require? How much extra memorizing does it require?
> What I think is the mistake is that vim/kak are all just interfaces, while Emacs is software
Yes, I am talking about interfaces, not software. I was talking about the interface that Emacs offers by default. Of course, you can script anything in it, but it's a meaningless argument; Linux kernel allows you to implement any program you want, but it doesn't make Linux a good text editor.
And in particular, I was talking about interfaces that are efficient, take little time to setup and save you a lot of time when you use them. My claim is that Emacs is not one of them. (Which doesn't make Emacs bad in the ultimate sense. It can be good for other things.)
> Multiple cursors are just visualized macros, after all.
Yes and no. Any text editing operation can expressed in ex commands, but it doesn't make ex a good editor, and definitely doesn't make it an efficient one.
Multiple cursors give instant feedback, this is a big advantage over blindly shooting macros at your text.
Useful, yes, but ad-hoc.
> What do you mean by ad-hoc?
I mean that in Emacs you have one ready to use action for everything you might want to do. One shortcut covers exactly one use case; if you want more use cases covered, install plugins or write scripts. M-q is an example, it formats the current paragraph. What if I want to format something other that a paragraph? In Emacs, you will need a new shortcut and a new keybinding for that.
In Vim-like editors you have some small atomic terms that you can combine to build the actions. You can have a small number of atomic terms, which can be combined in a multitude of ways and therefore cover a multitude of use cases. In Vim the gqap is not a single take it or leave it action, it's a sentence with verb gq and noun ap. If you want the verb to act on something different, you replace the ap part with something else.
Think of keybindings as a language you speak to your editor. In Vim the language has a number of words that you can combine to build sentences. In Emacs you have only a given number of ready to use sentences, and you have to memorize each one. This is a big distinction if we're talking about a text editor for efficiency, because it defines the ratio “time spent customizing” / “time saved editing”.
> Could you point me to some example?
You can cut and paste columns in Markdown tables using Kakoune's multiple selections. Like this:
- <a-i>p -- select the paragraph
- <a-s><a-;>; -- this creates a cursor at the beginning of each line
- <a-f>| -- move cursor to the next pipe symbol (selecting everything as it moves)
- <a-.> -- repeat the last move command (do this to select the column you want)
- d -- delete the selected (by each of the selection)
- <a-f>| (or <a-b>|) -- again to move cursors where you want to paste things
- p -- paste the deleted column
In this example, I haven't used a single command that I don't normally use while editing, say, Rust or Haskell. And you can manipulate Org, Latex tables with similar commands. In Emacs, you'd need a separate plugin for each of these, wouldn't you?
Kakoune.org has more videos where they show what it can do (without plugins).
Shortcuts can improve your experience, yes, but not in such a fundamental way as a new model of editing.
UPD.
For example, the Emacs way of dealing with tables in markdown/latex is to have a custom plugin which will have a separate shortcut for each action one might want. As a consequence, you need to remember the keys for each of them.
Kakoune, on the other hand, gives you a language that can express most of those operations naturally. And the language is no different than the one you use for other everyday tasks, no need to memorize new shortcuts.
Try a text editor that does something for text editing, not scripting. Vim is an option. I personally used Kakoune with (almost) default config for some 3 years and I'm sure it saved me a lot of time. I never redefined default keys, they were good enough, I only added a few user mode bindings. (Although I felt a lack of some features over that time; Kakoune with no plugins is a bit too minimalistic.)
Recently I spent a few days setting up LSP and some useful plugins, now I'm going to forget about customization for few more months again.
What you say reminds me of synchronous-asynchronous analogy I just made in another branch of this thread.