Just tested, at first it appears to work without issues. I think the problem can arise if some encoded unicode char looks like an escape char or other key combination, don't know if this is actually possible or not.
It doesn't work without issues at all. It's going to calculate the width of the string wrong, so the pointer movement is all broken: enter some utf-8 characters, move a "character" backwards - boom, your pointer is in a funny place. Once you move past the excess "space" (which is there because the code assumes 1 character=1 byte), you're going to tap multiple times to see the cursor go past a single character. Delete a character (byte) and watch it turn into something else.
There's no unicode support at all.
I also miss a lot of features most would take for granted in a line editor. Deleting and jumping between entire words, simple (or not-so-simple) history search are just a couple common and useful features.
Right, this is not compatible with readline, so people can't use it as a fallback. Now who's going to depend on a 400sloc library only to get a prompt and forward/backward & line-wise history movement with hardcoded non-personalizable bindings? Surely one can do that in seventy lines? ;)
You've got a lot of code to write; the line editing capabilities of the common libraries aren't as minimal as some may think. Of course you can just ignore all of it and say that other people don't need these features because you never used them.
Having said all that, I don't have anything against the idea of seeing another BSD-licensed line editing library prosper. If you want to do it, go for it! If the basic features get there, I'll embrace the project. In the meanwhile, I'll sit back and promote libedit.
Comments
MRI is looking for a replacement for readline because of its GPL license. How does Linenoise work with Unicode?
Just tested, at first it appears to work without issues. I think the problem can arise if some encoded unicode char looks like an escape char or other key combination, don't know if this is actually possible or not.
It doesn't work without issues at all. It's going to calculate the width of the string wrong, so the pointer movement is all broken: enter some utf-8 characters, move a "character" backwards - boom, your pointer is in a funny place. Once you move past the excess "space" (which is there because the code assumes 1 character=1 byte), you're going to tap multiple times to see the cursor go past a single character. Delete a character (byte) and watch it turn into something else.
There's no unicode support at all.
I also miss a lot of features most would take for granted in a line editor. Deleting and jumping between entire words, simple (or not-so-simple) history search are just a couple common and useful features.
Right, this is not compatible with readline, so people can't use it as a fallback. Now who's going to depend on a 400sloc library only to get a prompt and forward/backward & line-wise history movement with hardcoded non-personalizable bindings? Surely one can do that in seventy lines? ;)
You've got a lot of code to write; the line editing capabilities of the common libraries aren't as minimal as some may think. Of course you can just ignore all of it and say that other people don't need these features because you never used them.
Having said all that, I don't have anything against the idea of seeing another BSD-licensed line editing library prosper. If you want to do it, go for it! If the basic features get there, I'll embrace the project. In the meanwhile, I'll sit back and promote libedit.
I think you would use 'editline' for that, no? This is more a minimalist/default/configure can't find anything else solution.