Re: [bug-gtypist] Potential for a few updates

[Daniel Long Sockwell]

Thanks for sending this along.  On a first look, it is very interesting 
(although, as an aside, I note that I needed to rename the makefile to 
`Makefile` to make the code on a GNU/Linux computer).  I definitely look 
forward to digging into the code in more depth.

I agree that the JSON formatting is a big change and may not be worth 
reimplementing.  On the other hand, having that as (at least) an option would 
make it far easier for gtypist to work with other typing programs (to the 
extent that's necessary).  

I'm still wrapping my head around the gtypist code, but plan to be more active 
in the project later this year, and would be happy to work on incorporating 
some of your improvements. 

Thanks again for passing the source along. 

Best,
Daniel 
On 05/23, Simon Baldwin wrote:
>  FYI, you can now find a source drop of the code I recently wrote relating to 
> gtypist here:https://github.com/OnePointSixOneEight/typist
> 
> Please feel free to extract anything from it that you think might be useful 
> to you.
> 
>     On Wednesday, 16 May 2018, 17:37:46 BST, Simon Baldwin <address@hidden> 
> wrote:  
>  
>  As the original author of gtypist way back, I have spent the past two 
> decades in some embarrassment at the quality of the code I wrote back then. 
> This finally got the better of me, to the point where I sat down recently and 
> rewrote large pieces of it to be more maintainable and modular.
> I only have to hand an old Mac PowerBook that does not build gtypist cleanly, 
> so my starting point was the initial drop of typist to gtypist. Because of 
> this, much of the work that has gone in to gtypist since then is either 
> absent from my newer version -- for example, wide character support; I have 
> not tackled this yet -- or I have re-implemented as a decent facsimile of the 
> feature -- proper menus, on-failure labels, etc. That means my re-work cannot 
> be a drop-in replacement for the current gtypist code. More of a 'fork', I 
> guess.
> However... there may be a few features in my work that you can reasonably (or 
> perhaps, very) easily port forwards into the current gtypist and which might 
> be useful, and if you are interested then you are more than welcome to do so. 
> Just let me know, and I will send the sources through for you.
> To pique your interest, the new code includes: a fully re-entrant interpreter 
> so that scripts can run other scripts; JSON format lessons, for better data 
> portability; a purely declarative lesson format (no more goto's!); the 
> ability to emulate other keyboard layouts directly and without having to set 
> them in the OS; infinite loop detection; better string hashing; improved 
> debugging (eg tracing interpreter actions); an attempt at C namespaces; and 
> recovery on script or input errors. And of course, improved readability and 
> modularity, and close to full backwards and sideways compatibility.
> Of these, it will be tricky to add re-entrancy to gtypist, and JSON would be 
> a sizeable project that might not be worth the effort (I used this 
> re-implementation to try out a few ideas I had bubbling around in my head, 
> some more successfully than others!).
> Emulating other keyboard layouts, on the other hand, should be fairly easy. 
> The new version uses JSON to hold layouts, but it would be fairly easy to 
> 'bake in' the parsed JSON layouts into gtypist, and so offer a decent 
> selection of hard-coded layouts without too much effort -- ultimately, all 
> this emulation boils down to is: for each keypress, find the key position on 
> the keyboard you have, and then look up the character associated with that 
> position on the one being emulated and use that instead.
> Tracing the interpreter should also be easy to add. Infinite loop detection 
> is trivial. The C 'namespaces' are fiddly to retro-fit to anything, but 
> perhaps moving the curses stuff out to a separate module might be worth 
> considering, to keep all the curses macro definition and other curses 'noise' 
> out of the main code.
> And please update the string hash in gtypist :-). I had no good idea of how 
> to hash strings well when I wrote the first version, but I do now. Moving to 
> a prime number of hash buckets would also be worthwhile, I guess.
>   

> _______________________________________________
> bug-gtypist mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-gtypist