XDG Base Directory Specification

[jsuntheimer72]

Hi, So we've chatted on twitter a bit, and gwlester is the guy that contacted me about the repl/shell environment thing. While I was on twitter asking you if you were interested, gwlester was busy opening issues. So here we are, ready or not :)

I'm digging into the code now, and the first thing I want to do, in a branch, is to refactor to use the XDG standard, and my preferred method is

http://techtinkering.com/2013/02/27/xdgbasedir-a-tcl-module-to-access-the-xdg-base-directory-specification/

This would create a package dependency, but I don't believe this should be greatly feared. i think it would be great if tcl people worked together, and used each others stuff. Like tclsh-wrapper, for instance :)

The issues involved only grow when considering features like alternative keybinding defaults (though I personally love the current defaults, they are bashy/emacs-y and familiar to my muscle memory to a large degree), help systems, snippets, configurable completion options, and the like.

[jsuntheimer72]

$env(HOME) is good, not worth the dependency, or a sub spec kludge.

[gwlester]

Actually, ~/ is safer than $env(HOME) since Tcl explicitly state that it will be the user home directory -- no matter how future OS decide to represent/hide it.

On 02/15/2018 04:38 PM, Jeremy Suntheimer wrote:

$env(HOME) is good, not worth the dependency, or a sub spec kludge.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/suewonjp/tclsh-wrapper/issues/6#issuecomment-366085613, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUFGImsvc3jajANIzAt_xNiDoR7kk9Zks5tVLHtgaJpZM4SCnef.

-- +------------------------------------------------------------------------+ | Gerald W. Lester | |"The man who fights for his ideals is the man who is alive." - Cervantes| +------------------------------------------------------------------------+

[jsuntheimer72]

Good to learn. So just a quick report. Pure tcl can't trap Unix signals. I didn't at all know any of that. I've been using tcl as my shell and loving it, but the one problem is, say, I tclsh % Ctrl-c. This will not only kill tclsh, but also tclsh-wrapper. I'm not saying this is a fatal flaw, but it can't be fixed by tcl alone.

There is also a set of functionality that can't be obtained by any version of readline, and that is stuff like key-down and other finer grained X events. The characters come one at a time with their modifiers attached and such. "ptty" limitations, I think. Running Tk headless gives access to a convenient structered streams.

The biggest reason I wanted tcloo is that for a system like readline, something like js EventEmitters would be ideal, and the api is simple and i implemented it and it's just how I think now. So for instance keybindings could just be "register a listener for a key combo, fire this method (or proc, or applied anon function) when it shows up. Very simple, very easy, very dslable for configuration files. Alternate completion schemes could register distinctly to both completion information and keybinding.

Conclusion. I think I need a separate project. Since a full shell will require a binary extension, and some awesome tricks for a shell/repl can't be done in readline at all, I need to just start at a lower level (plenty of tcl bindings to existing c readline like things, but to change them requires changes to the c, and I don't want that either,was there almost a year ago to the day.). Not that low. Tk has its own EventEmitterish system, so I am using that, and tclib has uevent, which is the same system but generic, and will use that at the readline level.

I think it would be great to get the tclsh-wrapper code organized in sub namespaces that relate to functionality, as it would ease onramping of contributors. Since TclX is in the kitcreator, it would be easy to fix the signal handling, that's in the original wiki code, but I think it's great to have a pure tcl option in the ecosystem. I'm going with Expect, because it's a great excuse to have it. I love the [ESC] command, a set of commands for codez would be great for prompts and tuis of all sorts.

On February 15, 2018, at 7:43 PM, Gerald Leter notifications@github.com wrote:

Actually, ~/ is safer than $env(HOME) since Tcl explicitly state that it will be the user home directory -- no matter how future OS decide to represent/hide it.

On 02/15/2018 04:38 PM, Jeremy Suntheimer wrote:

$env(HOME) is good, not worth the dependency, or a sub spec kludge.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/suewonjp/tclsh-wrapper/issues/6#issuecomment-366085613;, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUFGImsvc3jajANIzAt_xNiDoR7kk9Zks5tVLHtgaJpZM4SCnef;.

-- +------------------------------------------------------------------------+ | Gerald W. Lester | |"The man who fights for his ideals is the man who is alive." - Cervantes| +------------------------------------------------------------------------+

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/suewonjp/tclsh-wrapper","title":"suewonjp/tclsh-wrapper","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/suewonjp/tclsh-wrapper"}},"updates":{"snippets":[{"icon":"PERSON","message":"@gwlester in #6: Actually, ~/ is safer than $env(HOME) since Tcl explicitly state that it \nwill be the user home directory -- no matter how future OS decide to \nrepresent/hide it.\n\n\nOn 02/15/2018 04:38 PM, Jeremy Suntheimer wrote:\n\u003e\n\u003e $env(HOME) is good, not worth the dependency, or a sub spec kludge.\n\u003e\n\u003e —\n\u003e You are receiving this because you are subscribed to this thread.\n\u003e Reply to this email directly, view it on GitHub \n\u003e \u003chttps://github.com/suewonjp/tclsh-wrapper/issues/6#issuecomment-366085613\u003e, \n\u003e or mute the thread \n\u003e \u003chttps://github.com/notifications/unsubscribe-auth/ABUFGImsvc3jajANIzAt_xNiDoR7kk9Zks5tVLHtgaJpZM4SCnef\u003e.\n\u003e\n\n-- \n+------------------------------------------------------------------------+\n| Gerald W. Lester |\n|\"The man who fights for his ideals is the man who is alive.\" - Cervantes|\n+------------------------------------------------------------------------+\n\n"}],"action":{"name":"View Issue","url":"https://github.com/suewonjp/tclsh-wrapper/issues/6#issuecomment-366111015"}}}

[gwlester]

TclX handles trapping the signals -- it may even be broken out as a small piece.

Go ahead for a separate project if it makes senses -- we can just pull it into the meta project/package.

On 02/15/2018 08:55 PM, Jeremy Suntheimer wrote:

Good to learn. So just a quick report. Pure tcl can't trap Unix signals. I didn't at all know any of that. I've been using tcl as my shell and loving it, but the one problem is, say, I tclsh % Ctrl-c. This will not only kill tclsh, but also tclsh-wrapper. I'm not saying this is a fatal flaw, but it can't be fixed by tcl alone.

There is also a set of functionality that can't be obtained by any version of readline, and that is stuff like key-down and other finer grained X events. The characters come one at a time with their modifiers attached and such. "ptty" limitations, I think. Running Tk headless gives access to a convenient structered streams.

The biggest reason I wanted tcloo is that for a system like readline, something like js EventEmitters would be ideal, and the api is simple and i implemented it and it's just how I think now. So for instance keybindings could just be "register a listener for a key combo, fire this method (or proc, or applied anon function) when it shows up. Very simple, very easy, very dslable for configuration files. Alternate completion schemes could register distinctly to both completion information and keybinding.

Conclusion. I think I need a separate project. Since a full shell will require a binary extension, and some awesome tricks for a shell/repl can't be done in readline at all, I need to just start at a lower level (plenty of tcl bindings to existing c readline like things, but to change them requires changes to the c, and I don't want that either,was there almost a year ago to the day.). Not that low. Tk has its own EventEmitterish system, so I am using that, and tclib has uevent, which is the same system but generic, and will use that at the readline level.

I think it would be great to get the tclsh-wrapper code organized in sub namespaces that relate to functionality, as it would ease onramping of contributors. Since TclX is in the kitcreator, it would be easy to fix the signal handling, that's in the original wiki code, but I think it's great to have a pure tcl option in the ecosystem. I'm going with Expect, because it's a great excuse to have it. I love the [ESC] command, a set of commands for codez would be great for prompts and tuis of all sorts.

On February 15, 2018, at 7:43 PM, Gerald Leter notifications@github.com wrote:

Actually, ~/ is safer than $env(HOME) since Tcl explicitly state that it will be the user home directory -- no matter how future OS decide to represent/hide it.

On 02/15/2018 04:38 PM, Jeremy Suntheimer wrote:

$env(HOME) is good, not worth the dependency, or a sub spec kludge.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub

https://github.com/suewonjp/tclsh-wrapper/issues/6#issuecomment-366085613;,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ABUFGImsvc3jajANIzAt_xNiDoR7kk9Zks5tVLHtgaJpZM4SCnef;.

-- +------------------------------------------------------------------------+ | Gerald W. Lester | |"The man who fights for his ideals is the man who is alive." - Cervantes| +------------------------------------------------------------------------+

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/suewonjp/tclsh-wrapper","title":"suewonjp/tclsh-wrapper","subtitle":"GitHub repository","main_image_url":"<a href="https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png">https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"<a href="https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png">https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"<a href="https://github.com/suewonjp/tclsh-wrapper">https://github.com/suewonjp/tclsh-wrapper"}},"updates":{"snippets":[{"icon":"PERSON","message":"@gwlester in #6: Actually, ~/ is safer than $env(HOME) since Tcl explicitly state that it \nwill be the user home directory -- no matter how future OS decide to \nrepresent/hide it.\n\n\nOn 02/15/2018 04:38 PM, Jeremy Suntheimer wrote:\n\u003e\n\u003e $env(HOME) is good, not worth the dependency, or a sub spec kludge.\n\u003e\n\u003e —\n\u003e You are receiving this because you are subscribed to this thread.\n\u003e Reply to this email directly, view it on GitHub \n\u003e \u003c<a href="https://github.com/suewonjp/tclsh-wrapper/issues/6#issuecomment-366085613">https://github.com/suewonjp/tclsh-wrapper/issues/6#issuecomment-366085613\u003e, \n\u003e or mute the thread \n\u003e \u003c<a href="https://github.com/notifications/unsubscribe-auth/ABUFGImsvc3jajANIzAt_xNiDoR7kk9Zks5tVLHtgaJpZM4SCnef">https://github.com/notifications/unsubscribe-auth/ABUFGImsvc3jajANIzAt_xNiDoR7kk9Zks5tVLHtgaJpZM4SCnef\u003e.\n\u003e\n\n-- \n+------------------------------------------------------------------------+\n| Gerald W. Lester |\n|\"The man who fights for his ideals is the man who is alive.\" - Cervantes|\n+------------------------------------------------------------------------+\n\n"}],"action":{"name":"View Issue","url":"<a href="https://github.com/suewonjp/tclsh-wrapper/issues/6#issuecomment-366111015">https://github.com/suewonjp/tclsh-wrapper/issues/6#issuecomment-366111015"}}}

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/suewonjp/tclsh-wrapper/issues/6#issuecomment-366131504, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUFGHG4gP-SYDQKMixDZ4bDBvQUnsI4ks5tVO4jgaJpZM4SCnef.

-- +------------------------------------------------------------------------+ | Gerald W. Lester | |"The man who fights for his ideals is the man who is alive." - Cervantes| +------------------------------------------------------------------------+