News for hackers. Stuff that matters.

omtose

Re:AV1: A new general-purpose video codec on Tuesday April 10, 2018 @04:17AM (#16799862)
Is Netflix even using H265?
Re:About the goodwill of people: 4,500 users and 0 donations on Monday February 12, 2018 @06:32AM (#16357993)
Is this a joke? There are about a thousand projects / things I would rather donate to before a trivial color visualizer.
Re:Interactive Vim tutorial on Wednesday October 04, 2017 @11:24AM (#15401115)
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.
Re:Godot Engine – Free and open-source 2D and 3D game engine on Friday September 22, 2017 @05:20AM (#15310477)
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.
Re:Ask HN: How does an online game with AIs manage so many AIs? on Wednesday September 13, 2017 @03:55AM (#15236333)
>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.

Re:Gap Buffers Are Not Optimized for Multiple Cursors on Friday September 08, 2017 @09:28AM (#15199974)
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.
Re:It's Never Too Late to Learn Guitar on Monday August 14, 2017 @10:33AM (#15008817)
>because of sore fingers

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

Re:“We currently have no plans to support Xwayland” on Friday July 21, 2017 @05:19AM (#14819132)
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.
Re:C++ on Embedded Systems on Tuesday February 21, 2017 @04:16AM (#13694363)
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.
Re:Stop using 'short' for line and allocation sizes (2013) on Thursday February 16, 2017 @09:47AM (#13660193)
But then you get different behavior depending on the platform, which doesn't seem any more portable to me.
Re:St – A simple terminal implementation for X on Thursday February 02, 2017 @09:41AM (#13550788)
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.

Re:The Craft of Text Editing (1999) on Monday January 30, 2017 @11:42AM (#13522655)
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

Re:The Craft of Text Editing (1999) on Monday January 30, 2017 @06:07AM (#13520108)
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

Re:Why Kakoune – The quest for a better code editor on Tuesday December 13, 2016 @02:29PM (#13169960)
>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.

Re:Why Kakoune – The quest for a better code editor on Tuesday December 13, 2016 @11:56AM (#13168281)
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.

Re:Why Kakoune – The quest for a better code editor on Tuesday December 13, 2016 @11:43AM (#13168143)
Mmh right, but that's not going to dispel my feeling that mawww is actually a weeaboo.
Re:Why Kakoune – The quest for a better code editor on Tuesday December 13, 2016 @11:34AM (#13168080)
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).
Re:Why Kakoune – The quest for a better code editor on Tuesday December 13, 2016 @10:37AM (#13167530)
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.

Re:Why Kakoune – The quest for a better code editor on Tuesday December 13, 2016 @10:24AM (#13167422)
For example the fact that the terminal does not make any difference between <c-m> and <ret>. Or <c-i> and <tab>.
Re:Why Kakoune – The quest for a better code editor on Tuesday December 13, 2016 @09:50AM (#13167138)
> What would a GUI bring to this that isn't possible in the console?

Not being destructive of user input, for starters.

Re:Why Kakoune – The quest for a better code editor on Tuesday December 13, 2016 @09:43AM (#13167079)
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.
Re:Why Kakoune – The quest for a better code editor on Tuesday December 13, 2016 @09:31AM (#13166990)
>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
Re:Why Kakoune – The quest for a better code editor on Tuesday December 13, 2016 @09:24AM (#13166948)
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

Re:Why Kakoune – The quest for a better code editor on Tuesday December 13, 2016 @09:18AM (#13166895)
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.

Re:Why Kakoune – The quest for a better code editor on Tuesday December 13, 2016 @09:15AM (#13166872)
You can also use a cat or nothing as "helper".
Re:Why Kakoune – The quest for a better code editor on Tuesday December 13, 2016 @09:09AM (#13166831)
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...

Re:VimWiki – A personal wiki for Vim on Monday December 12, 2016 @10:54AM (#13158913)
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

Re:LessPass: sync-less open source password manager on Monday November 07, 2016 @09:54AM (#12891435)
How so? If the entire directory structure is also encrypted then no program can easily know which sites or services I have passwords for.
Re:LessPass: sync-less open source password manager on Monday November 07, 2016 @08:47AM (#12890935)
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.

Older »