emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sqlite3


From: Byung-Hee HWANG
Subject: Re: sqlite3
Date: Mon, 06 Dec 2021 20:46:19 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Arthur Miller <arthur.miller@live.com> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> I think many user experience things in Emacs would be better if Emacs
>> remembered more.
>>
>> The bigger systems don't have this problem -- Gnus needs a large
>> .newsrc.eld file, and it maintains that.
>>
>> The tiny things don't really have this problem, either: You save options
>> with `customize-save-variable', and that fine.
>>
>> It's the many things that fall between these two extremes that have the
>> problem: Where you want to store some state, but figuring it's just too
>> much work to figure out Yet Another Storage Format, but the data is too
>> messy to stash in somebody's .emacs file via Customize (like lists of
>> stuff).
>>
>> So there's a bunch of stuff that Emacs just forgets when you shut down,
>> where it perhaps shouldn't.
>
> I would definitely like to see sqlite in core and avialable by default. I 
> really
> love it and think it is a great as application/desktop database. I think it
> would open for some nice applications people could write.
>
>> I've brought this up before, but I didn't really have a solution then,
>> but I think I do now: sqlite3.
>>
>> sqlite3 is supported on more platforms than Emacs is, the interface is
>> small and stable, and (best of all) somebody has already created
>> interface functions for Emacs (via a module):
>>
>>   https://github.com/syohex/emacs-sqlite3
>>
>> I think it'd be good to bring that into core, and then write a small
>> wrapper library (well, a trivial ORM) for the rest of Emacs to use, so
>> that we don't have to write SQL all over the place.  That is:
>>
>> (setf (persistent-data :namespace "emoji" :key "favorites") emoji--favorites)
>>
>> I.e., what Emacs needs is a persistent key/value store, and this would
>> give us that.
>
>> In addition, if somebody really wants to write SQL stuff (it can be very
>> handy for some things), having sqlite3 in there gives us that in
>> addition for free.
>>
>> This comes with questions about how the users are supposed be able to
>> clear out the data, for instance, but we could have a `M-x
>> list-persistent-data' where the users could blow out whatever they want
>> to.
>
> My only remark is that sqlite is usually used for exactly same purpose as what
> Emacs already has: customize. Your example:
>
>> (setf (persistent-data :namespace "emoji" :key "favorites") emoji--favorites)
>
> looks to me like something one would use customize for.
>
> Also in general since we can read/write lisp objects easily in elisp it is not
> hard to serialize/deserialize a hashmap or an assoc list as an application
> key-value db. I don't know how many application does this, but I have used it
> myself, and it felt trivial to use in my app. Objects that are not 
> serializable
> will not be serializable to sql either, without some extra work, so there is 
> not
> much win to use sqllite db instead of hashmap. 
>
> Anyway I still think sqlite in core would be nice; I have thought of it 
> several
> times myself.
>
> Back to your example, I also wonder if api, as suggested in your example could
> be done so it in addition also can automatically take applications prefix as
> namespace and variable name as key, so your example could look like: 
>
> (defgroup my-app nil
> "My cool app."
> :prefix 'my-app-
> :group 'applications)
>
> (defcustom my-app-emoji-favorites nil
> "List of most used emojis."
> :persist t
> :type 'list
> :group 'my-app)
>
> (setf (persistent-data 'my-app-emoji-favorites) my-app-emoji--favorites)
>
> And if we could also have more declarative api for defvars:
>
> (defvar my-app-foo 'bar
> "Foo property of my-app."
> :persist t)
>
> Just thoughts.

+1, very much!!!

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//



reply via email to

[Prev in Thread] Current Thread [Next in Thread]