I'll see about using the top-level command things, and I'll also see about adding support for secondary command storage, apart from the regular history file, and I'll make it so that it isn't enabled by default so that regular users aren't burdened by it. I can't promise that it'll use sqlite, though.

On 01/25/2015 04:02 PM, Matt Welland wrote:


On Sun, Jan 25, 2015 at 2:55 PM, Alexej Magura <agm2...@gmail.com <mailto:agm2...@gmail.com>> wrote:


    Forgot to send my reply to the Chicken users mailing list too.

    -------- Forwarded Message --------
    Subject:    Re: [Chicken-users] readline egg v2.0 feedback
    Date:       Sun, 25 Jan 2015 14:54:09 -0700
    From:       Alexej Magura <agm2...@gmail.com> <mailto:agm2...@gmail.com>
    To:         Matt Welland <mattrwell...@gmail.com>
    <mailto:mattrwell...@gmail.com>



    Actually, after reviewing the source a little, it seems that #4 is
    already supported, although it probably isn't very well
    documented.  This next release may need to be /3.0/ instead of
    /2.5/ if I decide to change the interface again--I hate doing
    that--which may prove necessary with some of the changes I already
    want to make to the /history-list/ function for example: presently
    the underly C code uses a statically allocated buffer, which
    should be more than big enough for most cases, but I feel like
    it's awfully wasteful, and would be better served by dynamic
    memory allocation instead.

    I'm not familiar with the ,X interface idiom or whatever it is,
    but it sounds like something worth looking into and using.


From http://wiki.call-cc.org/man/4/Using%20the%20interpreter the ,commands are called "toplevel commands" and you can define them with:

(toplevel-command SYMBOL PROC [HELPSTRING])


    As for using sqlite, I'd be worried that it would add unnecessary
    overhead and read/write times to readline; moreover, readline
    provides no hooks, AFAICT; I'd have to write my own, and I don't
    see much to gain from using sqlite, sorry.  I guess you were
    hoping that it would make it easier to implement more advanced
    history features like, super easy history grepping, running the
    last command over again, and that sort of thing, or something like
    that?


Yes, I use csi almost as a Unix shell and I do a lot of almost-but-not-quite scripts at the command line, for me the ability to store commands for the long term would be very handy however I certainly would not want to impinge the overhead of sqlite on anyone else. You can forget the suggestion. Note that my hs command line store has over 15k commands stored in it and searching doesn't seem too slow. For example if I forget how to start/stop symformnode this search reminds me:

matt@xena:~/data/stml/doc$ time hs %symform%stop%
sudo ./SymformNode.sh stop contrib
sudo /opt/symform/SymformNode.sh stop
sudo ./SymformNode.sh stop web

real    0m0.186s
user    0m0.128s
sys    0m0.020s

2/10's of a second doesn't seem too bad and this machine is mediocre by today's standards.

    One problem with Readline, which I admittedly have been avoiding,
    is that the documentation, is lacking, and, I think, this may
    contribute to the  number/degree of users unaware or unsure of how
    to achieve a desired effect using Readline.

On 01/25/2015 02:29 PM, Matt Welland wrote:
#1 - yes, appreciated
#2 - nice, csi commands using the ,X interface would be nice. ,er - enable recording, ,dr - to disable recording or something similar.
#3 - very nice indeed.
#4 - even nicer :)

Aside: I think it'd be handy to store my csi history using my sqlite3 based "hs" command line history store tool (http://www.kiatoa.com/cgi-bin/fossils/opensrc/wiki?name=histstore). If your readline library allowed writing hooks that could update/query via other calls it would be easy to bolt on hs or other such tools. Perhaps this is already easy - I haven't actually looked yet.

On Sun, Jan 25, 2015 at 1:50 PM, Alexej Magura <agm2...@gmail.com <mailto:agm2...@gmail.com>> wrote:

    I think that a reasonable solution would be to (1) create the
    history file if it does not already exist, (2) allow users to
    explicitly disable/enable history keeping at any time, (3)
    simplify history file installation to include only about a line
    of code, (4) add an option to either wipe the history file
    completely, truncat it to X many lines or history transactions.

    How does all that sound?

    Also, it's worth noting that we're currently on version 2.4 with
    2.5 on the way.

    On 01/25/2015 10:21 AM, John Cowan wrote:

        m...@kiatoa.com <mailto:m...@kiatoa.com> scripsit:

            As a daily user of csi with readline I look forward to
            using your
            enhancements.  If it makes sense to do I would like to
            see the
            behavior change for a new install, currently the user has
            to touch
            the ~/.csi-history (?) file before history will be kept.
            I'd like it
            if that became unnecessary.

        That amounts to saying that every instance of csi logs
        everything you do.
        For both space and security reasons, I think it's better if
        the user has
        to take an affirmative action before that happens.



    _______________________________________________
    Chicken-users mailing list
    Chicken-users@nongnu.org <mailto:Chicken-users@nongnu.org>
    https://lists.nongnu.org/mailman/listinfo/chicken-users






    _______________________________________________
    Chicken-users mailing list
    Chicken-users@nongnu.org <mailto:Chicken-users@nongnu.org>
    https://lists.nongnu.org/mailman/listinfo/chicken-users



_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Reply via email to