Have anybody cooked together high-level bindings on top of the C-bindings for libreadline here

http://code.dlang.org/packages/readline

?

On Thursday, 7 September 2017 at 13:37:16 UTC, Nordlöw wrote:
> Have anybody cooked together high-level bindings on top of the C-bindings for libreadline here

Have you ever used readline?

The basic C api is already very high level:


char* from_user = readline("Prompt> ");


I don't think there's a lot to gain by wrapping that...

On Thursday, 7 September 2017 at 13:44:52 UTC, Adam D. Ruppe wrote:
> On Thursday, 7 September 2017 at 13:37:16 UTC, Nordlöw wrote:
>> Have anybody cooked together high-level bindings on top of the C-bindings for libreadline here
>
> Have you ever used readline?
>
> The basic C api is already very high level:
>
>
> char* from_user = readline("Prompt> ");
>
>
> I don't think there's a lot to gain by wrapping that...

There's always room for usability improvements when wrapping C APIs...

Here's what I hacked together:

version = readline;
extern(C) void add_history(const char*); // missing from gnu.readline
/**
   High-level wrapper around GNU libreadline.
 */
const(char)[] readLine(in string prompt,
                       bool useHistory = true)
{
    version(readline)
    {
        import gnu.readline : readline;
        import std.string : toStringz, fromStringz;
        const lineStringz = readline(prompt.toStringz);
        if (useHistory)
        {
            add_history(lineStringz);
        }
        return lineStringz.fromStringz;
    }
    else
    {
        write(prompt); stdout.flush;
        return readln.strip;
    }
}

On Thursday, 7 September 2017 at 14:00:36 UTC, Nordlöw wrote:
> On Thursday, 7 September 2017 at 13:44:52 UTC, Adam D. Ruppe wrote:
>> [...]
>
> There's always room for usability improvements when wrapping C APIs...
>
> [...]

Minor point: you should add_history only if `lineStringz && lineStringz[0] != '\0'`

On Thursday, 7 September 2017 at 14:00:36 UTC, Nordlöw wrote:
> On Thursday, 7 September 2017 at 13:44:52 UTC, Adam D. Ruppe wrote:
>> [...]
>
> There's always room for usability improvements when wrapping C APIs...
>
> [...]

Isn't it pointless to make "prompt" in?

On Thursday, 7 September 2017 at 16:18:09 UTC, bauss wrote:
> Isn't it pointless to make "prompt" in?

No, it promises the function isn't doing anything weird to it (modify, which immutable covers, but also scope.. .unless dmd changed that), which means a copy of the pointer won't be stored either. Important to realize with C cuz then you know it is ok to use a temporary to it.

On Thursday, 7 September 2017 at 16:23:46 UTC, Adam D. Ruppe wrote:
> On Thursday, 7 September 2017 at 16:18:09 UTC, bauss wrote:
>> Isn't it pointless to make "prompt" in?
>
> No, it promises the function isn't doing anything weird to it (modify, which immutable covers, but also scope.. .unless dmd changed that), which means a copy of the pointer won't be stored either. Important to realize with C cuz then you know it is ok to use a temporary to it.

But I believe it's ok to relax it from `string` to `const(char)[]`, right?

On Thursday, 7 September 2017 at 19:38:38 UTC, Nordlöw wrote:
> But I believe it's ok to relax it from `string` to `const(char)[]`, right?

Yeah, it should be const(char)[] or even `in char[]`

On Thursday, 7 September 2017 at 15:31:13 UTC, Nemanja Boric wrote:
> Minor point: you should add_history only if `lineStringz && lineStringz[0] != '\0'`

Wonderful. That prevented a crashs when writing history. Thanks!

On Thursday, 7 September 2017 at 19:45:06 UTC, Adam D. Ruppe wrote:
> On Thursday, 7 September 2017 at 19:38:38 UTC, Nordlöw wrote:
>> But I believe it's ok to relax it from `string` to `const(char)[]`, right?
>
> Yeah, it should be const(char)[] or even `in char[]`

Ahh, correct.