omtose

Is Netflix even using H265?

Is this a joke? There are about a thousand projects / things I would rather donate to before a trivial color visualizer.

This website sucks, it takes forever to load challenge pages because they're flooded with irrelevant entries which you can't even see if you don't submit your own. You can't even visualize the solutions directly in the browser.

How's the performance of the resulting games? With unity I've found that it's a mixed bag, but it's hard to know if that's the fault of developers or the engine.

>execute AIs on clients, and send their inputs along with players' inputs

That seems strange, you'd be sending multiple times the same AI's actions to the server, in which case you better be certain that it's deterministic, not to mention the security concerns. It seems far easier to execute the AI on the server and send its actions to each player, especially if it's a trivial AI.

It's funny how you see these articles about fancy text editor buffer representation (gap buffer, ropes) but meanwhile, the editor with the best feature/performance ratio (including multiple cursors) I've found[1] "simply" represents a buffer as a vector of strings.

[1]: https://github.com/mawww/kakoune

I somewhat doubt that a hollow plastic tank is significantly more expensive than a concrete block. Factor in the added cost of shipping the much heavier concrete block, and it seems like the manufacturer would also save money in the process.

>because of sore fingers

Maybe in the beginning, but after having developed calluses you can basically practice for an undefinite period of time.

Maybe in the short term you'll change distro or stick to X11, but when you decide to change GPU you'll likely try to get one with more compatibility.

I never understood why people argue that operator overload is a bad thing. In a language that doesn't support it, you're going to have a function "T add(T, T)" which is pretty much the same, and can do anything. Overloading "T operator+(T, T)" is mostly syntactic sugar.

But then you get different behavior depending on the platform, which doesn't seem any more portable to me.

I've also gutted a lot of stuff from termite in my own fork (overaly, vi mode, clickable urls) and it definitely makes for a lovely minimalistic terminal. I'm thankful for termite being so simple (granted the lifting is done by a lib) that this is possible without much effort.

I just wish I could log the scrollback buffer so that I could open an actual editor on it, but I don't think libvte exposes anything to do this.

Are you talking about Xi as a frontend for kakoune? If it's the UI part that you're interested in, there is also kakoune-qml[1] made by one of the regular uses.

[1] https://github.com/doppioandante/kakoune-qml

Kakoune[1] has been posted recently here on HN to great reception. As a C++ developer, I think it has a very high quality codebase, especially considering how non-trivial it is. As a user, it's been my main text editor for over a year. It also has a vibrant community, jump in on IRC if you have questions or ideas.

[1] https://github.com/mawww/kakoune

>I just wish you guys can learn more of vi, so you can truly deliver something better. So far, these surface scratching alterations only build on irritations of those vi first-timers

Mind expanding on that, or are you just going to whine? It's not like vi is the ultimate tool.

Yes it's in no way a dealbreaker, but it starts rearing its head when you want to use keys outside of the alphanumeric cluster.

I also absolutely agree that this is the correct way for an editor to be implemented.

Mmh right, but that's not going to dispel my feeling that mawww is actually a weeaboo.

Oh that makes a lot of sense, that's probably the origin of the name. The project is quite a bit older than that though (>4 years).

I don't understand what you mean. It's destructive in the sense that the raw input is not even being passed to the application in the terminal.

No applications running in the terminal will be able to tell the difference between these two different key presses.

For example the fact that the terminal does not make any difference between <c-m> and <ret>. Or <c-i> and <tab>.

> What would a GUI bring to this that isn't possible in the console?

Not being destructive of user input, for starters.

For what it's worth, it works properly on cygwin (and certainly the linux subsystem too). I know that the author uses it on cygwin too so there is at least some guarantee.

>How would that work if the motion comes first? Would I go "wwwwd"? Would that delete one word, or four?

'w' will move the current selection to the next word so only one word. To extend the selection you need to press 'W' so "wWWWd" will delete four words. For most motions (if not all), the uppercase variant will extend the current selection.

This also makes searching slightly different:

  / search forwards 
  ? extend selection forward
  <a-/> search backwards
  <a-?> extend selection backwards

They are just command that you could execute manually (using ':' like in vim). The difference is that all the commands in this file are executed at startup.

As I said, all the heavy lifting is done in scopes like %sh{ ... }. This way you can actually use any language you want, and it's only the piping you have to do through kakoune commands.

Most common languages (like go) already have plugins to do some basic tasks like formatting.

If you're interested in the editor, I would rather recommend reading the readme of the project[1]. There is a lot to read, and you can start making plugins once you understand it.

[1] https://github.com/mawww/kakoune

As a user, I think this is the main reason why I like kakoune:

> Another often overlooked property of using a text editing language is that it’s fun.

Some other things that I like about it that are not mentioned:

The author is responsive to feature requests and bugs on github.

The codebase is very well-made, if you have any interest in C++ I recommend taking a look at it.

You can also use a cat or nothing as "helper".

Some answers as a user:

No scripting language, most of the heavy lifting done in plugin is through shell calls (asynchronously or not). Example here [1]. I personally think that it's kinda hard to grok to be honest.

Thanks to the client server architecture, it is possible to make an external UI[2].

There is no line wrapping currently. Don't know about long documents, but the editor in general is very efficient.

[1] https://github.com/mawww/kakoune/blob/master/rc/core/grep.ka...

[2] https://github.com/mawww/kakoune/blob/master/doc/json_ui.asc...

I was sort of in your situation a while ago and wanted to learn vim, but was a bit put off by all the legacy that it carries (also spoiled by sublime's multiple cursors).

I then discovered kakoune[1] and liked its design. I started getting familiar with it and using it more and more, and I think its core is much more solid than vim/emacs. It definitely doesn't have the same community support and plugins but it's already quite feature rich.

[1] https://github.com/mawww/kakoune

How so? If the entire directory structure is also encrypted then no program can easily know which sites or services I have passwords for.

This is all a lot of effort, if I went down that road I might as well skip "pass" and handle the passwords myself. What I like about pass is that there isn't much setup.

Full disk encryption also doesn't prevent a running application from seeing the directory structure. But I guess this is not a very realistic attack vector.