Persistence of variables

Persistence of variables

[Marcin Borkowski]

Hi all,

I want to make a variable persistent across Emacs sessions.  How do I do
it?

I know that I can write a form to init-file (or custom-file).  Are there
any facilities in Emacs which support that?  Or should I write them
myself?  A cursorty look at custom-save-all suggests that there are no
high-level functions to "save one particular thing to (custom-file)".
(I could make my variable customizable and use custom-save-variables,
but I do not want to do that - I feel this is too heavy-weight for just
one variable, and I don't even know whether my potential users
know/use/like the customization stuff messing around with their init
file.)

Any ideas?

-- 
Marcin Borkowski
http://mbork.pl

Re: Persistence of variables

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Wed, 21 Mar 2018 07:08:44 +0100
> 
> I want to make a variable persistent across Emacs sessions.  How do I do
> it?

Did you consider desktop.el?

Re: Persistence of variables

[Marcin Borkowski]

On 2018-03-21, at 07:55, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Date: Wed, 21 Mar 2018 07:08:44 +0100
>> 
>> I want to make a variable persistent across Emacs sessions.  How do I do
>> it?
>
> Did you consider desktop.el?

No, I did not remember about its existence.

But no, way too heavy.  I want _one variable_ to persist, and nothing
more.

Thanks anyway,

-- 
Marcin Borkowski
http://mbork.pl

Re: Persistence of variables

[Marcin Borkowski]

On 2018-03-21, at 08:25, Marcin Borkowski <mbork@mbork.pl> wrote:

> On 2018-03-21, at 07:55, Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Marcin Borkowski <mbork@mbork.pl>
>>> Date: Wed, 21 Mar 2018 07:08:44 +0100
>>> 
>>> I want to make a variable persistent across Emacs sessions.  How do I do
>>> it?
>>
>> Did you consider desktop.el?
>
> No, I did not remember about its existence.
>
> But no, way too heavy.  I want _one variable_ to persist, and nothing
> more.

OK, how about this?

--8<---------------cut here---------------start------------->8---
(defun make-variable-persistent (variable-name)
  "Save VARIABLE-NAME to `custom-file' or `init-file'."
  (when (y-or-n-p (format "I am going to save variable `%s' in %s.  Should I proceed? " variable-name user-init-file))
    (with-temp-file user-init-file
      (let ((sentinel-text (format "\n;; Persistent variable `%s'.  Do not edit manually!\n" variable-name)))
	(insert-file-contents user-init-file)
	(if (search-forward sentinel-text nil t)
	    (if (not (looking-at-p (format "^(setq %s" variable-name)))
		(error "Broken init file.")
	      (kill-sexp))
	  (goto-char (point-max))
	  (insert sentinel-text)))
      (insert (format "(setq %s %S)" variable-name (symbol-value variable-name))))))
--8<---------------cut here---------------end--------------->8---

Any thoughts/suggestions?

-- 
Marcin Borkowski
http://mbork.pl

Re: Persistence of variables

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Mar 21, 2018 at 10:13:11AM +0100, Marcin Borkowski wrote:
> 
> On 2018-03-21, at 08:25, Marcin Borkowski <mbork@mbork.pl> wrote:

[...]

> Any thoughts/suggestions?

Only one: I'd tend to stay clear from the init file and write to some
other specialized file which is included from there (a bit like what
customize does by separating its stuff into custom.el).

Ideally, like customize, the user could choose her ways by setting
a variable (in the customize-example, it's custom-file).

More modularity, less risk.

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlqyJZIACgkQBcgs9XrR2kaICACfUi5oO9WzZDo2jb7M4dsMwCiN
9SQAnj1EOu5UizmNmlY8nBs2grMC9uu/
=YEix
-----END PGP SIGNATURE-----

Re: Persistence of variables

[Marcin Borkowski]

On 2018-03-21, at 10:27, tomas@tuxteam.de wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, Mar 21, 2018 at 10:13:11AM +0100, Marcin Borkowski wrote:
>>
>> On 2018-03-21, at 08:25, Marcin Borkowski <mbork@mbork.pl> wrote:
>
> [...]
>
>> Any thoughts/suggestions?
>
> Only one: I'd tend to stay clear from the init file and write to some
> other specialized file which is included from there (a bit like what
> customize does by separating its stuff into custom.el).
>
> Ideally, like customize, the user could choose her ways by setting
> a variable (in the customize-example, it's custom-file).
>
> More modularity, less risk.

In general, this is a good point.

But in my use-case, I will have one user besides me (it's a tool for our
in-house workflow), and I wouldn't care about it too much.

If I turn this into a Melpa package (or even a blog post), I would of
course follow your suggestion.  (The drawback is that the user would
have to (once) insert something manually into init.el.)

BTW, is there any demand for such a micro-package?

Thanks,

--
Marcin Borkowski
http://mbork.pl

Re: Persistence of variables

[Eric Abrahamsen]

Marcin Borkowski <mbork@mbork.pl> writes:

> On 2018-03-21, at 07:55, Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Marcin Borkowski <mbork@mbork.pl>
>>> Date: Wed, 21 Mar 2018 07:08:44 +0100
>>> 
>>> I want to make a variable persistent across Emacs sessions.  How do I do
>>> it?
>>
>> Did you consider desktop.el?
>
> No, I did not remember about its existence.
>
> But no, way too heavy.  I want _one variable_ to persist, and nothing
> more.

If you already use savehist-mode, you can add your variable to
savehist-additional-variables.

Re: Persistence of variables

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Mar 21, 2018 at 10:51:23AM +0100, Marcin Borkowski wrote:
> 
> On 2018-03-21, at 10:27, tomas@tuxteam.de wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Wed, Mar 21, 2018 at 10:13:11AM +0100, Marcin Borkowski wrote:
> >>
> >> On 2018-03-21, at 08:25, Marcin Borkowski <mbork@mbork.pl> wrote:
> >
> > [...]
> >
> >> Any thoughts/suggestions?

[...]

> In general, this is a good point.
> 
> But in my use-case, I will have one user besides me (it's a tool for our
> in-house workflow), and I wouldn't care about it too much.

Makes sense.

> If I turn this into a Melpa package (or even a blog post), I would of
> course follow your suggestion.  (The drawback is that the user would
> have to (once) insert something manually into init.el.)

Note that it's not either-or: in the Customize case, the package writes
into init.el if the variable is unset, and into the file specified by
that variable otherwise.

> BTW, is there any demand for such a micro-package?

Tough to say: it is so small that it would make more sense as
"basic infrastructure", to be used by "clients" like Customize.

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlqyMpIACgkQBcgs9XrR2kZElACfbydlPtqIYtt8mLFu0Di0pBMh
QLsAnjMOE18OZnYLkWrrXyz6hsKxjF1y
=uYm1
-----END PGP SIGNATURE-----

Re: Persistence of variables

[Marcin Borkowski]

On 2018-03-21, at 10:53, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> On 2018-03-21, at 07:55, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>>> From: Marcin Borkowski <mbork@mbork.pl>
>>>> Date: Wed, 21 Mar 2018 07:08:44 +0100
>>>> 
>>>> I want to make a variable persistent across Emacs sessions.  How do I do
>>>> it?
>>>
>>> Did you consider desktop.el?
>>
>> No, I did not remember about its existence.
>>
>> But no, way too heavy.  I want _one variable_ to persist, and nothing
>> more.
>
> If you already use savehist-mode, you can add your variable to
> savehist-additional-variables.

Interestringly, I have this mode turned on, but I can see no traces of
turning it on in my init.el

Thanks!

-- 
Marcin Borkowski
http://mbork.pl

Re: Persistence of variables

[Emanuel Berg]

Marcin Borkowski wrote:

> Any thoughts/suggestions?

It is better to just dump it to a dedicated
file in your .emacs.d dir (or someplace else),
easier, less error prone, and more secure, as
if something goes haywire it won't interfere
with the regular setup.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Persistence of variables

[Emanuel Berg]

> It is better to just dump it to a dedicated
> file in your .emacs.d dir (or someplace
> else), easier, less error prone, and more
> secure, as if something goes haywire it won't
> interfere with the regular setup.

And remember this is what files are for so it
isn't hackish or disencouraged in any way.
The init files for Emacs, the shell, X, or
whatever, do exactly the same.

-- 
underground experts united
http://user.it.uu.se/~embe8573

RE: Persistence of variables

[Drew Adams]

> > But no, way too heavy.  I want _one variable_ to persist, and nothing
> > more.
> 
> If you already use savehist-mode, you can add your variable to
> savehist-additional-variables.

There are several possibilities, including these:

1. `savehist.el' (what Eric said)
2. Customize (option value)
3. Bookmark (e.g., Bookmark+ variable-list bookmark)
4. Desktop

If you only want to save one variable, just use an option.

Re: Persistence of variables

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Mar 21, 2018 at 08:12:40AM -0700, Drew Adams wrote:
> > > But no, way too heavy.  I want _one variable_ to persist, and nothing
> > > more.
> > 
> > If you already use savehist-mode, you can add your variable to
> > savehist-additional-variables.
> 
> There are several possibilities, including these:
> 
> 1. `savehist.el' (what Eric said)
> 2. Customize (option value)
> 3. Bookmark (e.g., Bookmark+ variable-list bookmark)
> 4. Desktop
> 
> If you only want to save one variable, just use an option.

Of course!

What Drew said. The whole thing was in front of us all, we
just had to squint the right way.

Thanks, Drew :-)

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlqyd/4ACgkQBcgs9XrR2kZGKACfU4ufdESxZLM00Rn787cOA0cU
mnYAnRpfig07JLzITobvvfOGeLb/rHsg
=WmP8
-----END PGP SIGNATURE-----

Re: Persistence of variables

[Emanuel Berg]

Drew Adams wrote:

> There are several possibilities, including these:
>
> 1. `savehist.el' (what Eric said)
> 2. Customize (option value)
> 3. Bookmark (e.g., Bookmark+ variable-list bookmark)
> 4. Desktop

5.

(defun write-string-to-file (string file)
  "Write STRING to FILE.
Create nonexistent FILE otherwise overwrite."
  (interactive "sstring: \nFfile: ")
  (with-temp-file file
    (insert string "\n") ))
    
;; (write-string-to-file "Leeloo Dallas Multipass" "~/5ifth.txt")

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Persistence of variables

[Eli Zaretskii]

> From: Emanuel Berg <moasen@zoho.com>
> Date: Wed, 21 Mar 2018 19:00:52 +0100
> 
> (defun write-string-to-file (string file)
>   "Write STRING to FILE.
> Create nonexistent FILE otherwise overwrite."
>   (interactive "sstring: \nFfile: ")
>   (with-temp-file file
>     (insert string "\n") ))

We have append-to-file, which can do this out of the box.

Re: Persistence of variables

[Emanuel Berg]

Eli Zaretskii wrote:

>> (defun write-string-to-file (string file)
>>   "Write STRING to FILE.
>> Create nonexistent FILE otherwise overwrite."
>>   (interactive "sstring: \nFfile: ")
>>   (with-temp-file file
>>     (insert string "\n") ))
>
> We have append-to-file, which can do this out
> of the box.

6. Use `append-to-file'.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Persistence of variables

[Emanuel Berg]

(defun write-string-to-file (string file)
  "Write STRING to FILE.
Create nonexistent FILE otherwise overwrite."
  (interactive "sstring: \nFfile: ")
  (with-temp-file file
    (insert string "\n") ))
;; (write-string-to-file "Leeloo Dallas Multipass" "~/5ifth.txt")

(require 'subr-x)
(defun file-to-string (file)
  "Put the contents of FILE into a string and return it."
  (interactive "Ffile: ")
  (with-temp-buffer
    (insert-file-contents file)
    (string-trim
     (buffer-substring-no-properties (point-min) (point-max)))
    ))
;; (file-to-string "~/5ifth.txt")

(defmacro read-from-file (var file)
  `(setq ,var ,(file-to-string file)) )

(defvar string-value)
(setq string-value "")

;; (read-from-file string-value "~/5ifth.txt")
;; string-value

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Persistence of variables

[Joost Kremers]

On Wed, Mar 21 2018, tomas@tuxteam.de wrote:
> On Wed, Mar 21, 2018 at 08:12:40AM -0700, Drew Adams wrote:
>> If you only want to save one variable, just use an option.
>
> Of course!
>
> What Drew said. The whole thing was in front of us all, we
> just had to squint the right way.

Well, that depends on the variable. Options (i.e., those defined 
with defcustom) are really meant for user customisation: meant to 
be set explicitly by the user, and meant to be forgotten once set. 
If you want to save a variable that changes regularly and that the 
user doesn't set explicitly, then a user option is a bad fit. IMHO 
the best way to deal with that is indeed to use a separate file 
and to provide a user option to set the file path & name. That 
way, users can decide for themselves if they want to keep the file 
under version control, sync it across machines, or not.



-- 
Joost Kremers
Life has its moments

Re: Persistence of variables

[Rolf Ade]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Emanuel Berg <moasen@zoho.com>
>> Date: Wed, 21 Mar 2018 19:00:52 +0100
>> 
>> (defun write-string-to-file (string file)
>>   "Write STRING to FILE.
>> Create nonexistent FILE otherwise overwrite."
>>   (interactive "sstring: \nFfile: ")
>>   (with-temp-file file
>>     (insert string "\n") ))
>
> We have append-to-file, which can do this out of the box.

I'm sorry to nit, but Emanuels write-string-to-file differs from
append-to-file in that it ensures the file includes (only) string while
append-to-file, well, appends string to the file at the end, if it
exists.

That makes write-string-to-file are more useful building block in the
context of the question of the OP, IMHO. But it's musing anyway.

Re: Persistence of variables

[Eli Zaretskii]

> From: Rolf Ade <rolf@pointsman.de>
> Date: Thu, 22 Mar 2018 02:36:56 +0100
> 
> >> (defun write-string-to-file (string file)
> >>   "Write STRING to FILE.
> >> Create nonexistent FILE otherwise overwrite."
> >>   (interactive "sstring: \nFfile: ")
> >>   (with-temp-file file
> >>     (insert string "\n") ))
> >
> > We have append-to-file, which can do this out of the box.
> 
> I'm sorry to nit, but Emanuels write-string-to-file differs from
> append-to-file in that it ensures the file includes (only) string while
> append-to-file, well, appends string to the file at the end, if it
> exists.

And I'm sorry to nit back, but creating an empty file is trivial, in
which case append-to-file will do the same job.

More to the point, I think this feature of append-to-file is largely
unknown, which is why I made a point of mentioning it.  (Btw,
write-region supports a very similar feature.)

Re: Persistence of variables

[Emanuel Berg]

Eli Zaretskii wrote:

>> From: Rolf Ade <rolf@pointsman.de>
>> Date: Thu, 22 Mar 2018 02:36:56 +0100
>> 
>> >> (defun write-string-to-file (string file)
>> >>   "Write STRING to FILE.
>> >> Create nonexistent FILE otherwise overwrite."
>> >>   (interactive "sstring: \nFfile: ")
>> >>   (with-temp-file file
>> >>     (insert string "\n") ))
>> >
>> > We have append-to-file, which can do this out of the box.
>> 
>> I'm sorry to nit, but Emanuels
>> write-string-to-file differs from
>> append-to-file in that it ensures the file
>> includes (only) string while append-to-file,
>> well, appends string to the file at the end,
>> if it exists.
>
> And I'm sorry to nit back, but creating an
> empty file is trivial, in which case
> append-to-file will do the same job.
>
> More to the point, I think this feature of
> append-to-file is largely unknown, which is
> why I made a point of mentioning it. (Btw,
> write-region supports a very
> similar feature.)

1) topic drift isn't OT unless its OT

2) one would even suspect - if Manny wasn't
   such a skilled programmer - he would have
   written that function because he didn't
   *know* of the append-to-file-use! But of
   course that seems completely unthinkable


    You can fire your arrows from the tower of
    Babylon. But you can NEVER strike God!


-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Persistence of variables

[Robert L.]

On 3/21/2018, <tomas@tuxteam.de> wrote:

> What Drew said. The whole thing was in front of us all, we
> just had to squint the right way.

What Drew said. The whole thing was in front of us all; we
just had to squint the right way.

-- 
The conscious and intelligent manipulation of the organized habits and opinions
of the masses is an important element in democratic society.  Those who
manipulate this unseen mechanism of society constitute an invisible government
which is the true ruling power of our country.
http://archive.org/details/nolies

Re: Persistence of variables

[Marcin Borkowski]

On 2018-03-21, at 11:23, tomas@tuxteam.de wrote:

>> If I turn this into a Melpa package (or even a blog post), I would of
>> course follow your suggestion.  (The drawback is that the user would
>> have to (once) insert something manually into init.el.)
>
> Note that it's not either-or: in the Customize case, the package writes
> into init.el if the variable is unset, and into the file specified by
> that variable otherwise.

I know that.  But thanks anyway!

-- 
Marcin Borkowski
http://mbork.pl

Re: Persistence of variables

[Marcin Borkowski]

On 2018-03-21, at 16:12, Drew Adams <drew.adams@oracle.com> wrote:

>> > But no, way too heavy.  I want _one variable_ to persist, and nothing
>> > more.
>> 
>> If you already use savehist-mode, you can add your variable to
>> savehist-additional-variables.
>
> There are several possibilities, including these:
>
> 1. `savehist.el' (what Eric said)
> 2. Customize (option value)
> 3. Bookmark (e.g., Bookmark+ variable-list bookmark)
> 4. Desktop
>
> If you only want to save one variable, just use an option.

One variable, but I don't like Customize.  Also, even though I set the
type as "directory", autocompletion somehow didn't work for me (in the
Customize interface).

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Persistence of variables

[Marcin Borkowski]

On 2018-03-21, at 23:16, Joost Kremers <joostkremers@fastmail.fm> wrote:

> On Wed, Mar 21 2018, tomas@tuxteam.de wrote:
>> On Wed, Mar 21, 2018 at 08:12:40AM -0700, Drew Adams wrote:
>>> If you only want to save one variable, just use an option.
>>
>> Of course!
>>
>> What Drew said. The whole thing was in front of us all, we
>> just had to squint the right way.
>
> Well, that depends on the variable. Options (i.e., those defined with
> defcustom) are really meant for user customisation: meant to be set
> explicitly by the user, and meant to be forgotten once set. If you
> want to save a variable that changes regularly and that the user
> doesn't set explicitly, then a user option is a bad fit. IMHO the best
> way to deal with that is indeed to use a separate file and to provide
> a user option to set the file path & name. That way, users can decide
> for themselves if they want to keep the file under version control,
> sync it across machines, or not.

And this is exactly my use-case: a variable whose value will be
periodically changed.  And I don't like the hassle of having an option
to a separate file with just this one variable...  Of course, if the
only user beside me won't like Emacs messing around with his init.el,
I'll do it that way.

Thanks!

-- 
Marcin Borkowski
http://mbork.pl

RE: Persistence of variables

[Drew Adams]

> >>> If you only want to save one variable, just use an option.
> >> Of course!
> >> What Drew said. The whole thing was in front of us all, we
> >> just had to squint the right way.
> >
> > Well, that depends on the variable. Options (i.e., those defined with
> > defcustom) are really meant for user customisation: meant to be set
> > explicitly by the user, and meant to be forgotten once set.

Yes - although it is not necessarily meant to be forgotten
once set.  It is sometimes useful for a user to change an
option during the same session, sometimes even multiple times.

And it can be useful for a user to have a command that changes
some option.  The rule that code should not trample on user
options does not apply to a command that a user invokes
explicitly, voluntarily, to make such a change.

> > If you want to save a variable that changes regularly and
> > that the user doesn't set explicitly, then a user option is
> > a bad fit.

Yes (although "changes regularly" is not relevant here, IMO).

In that case, the persistence is not to provide a user with
a persistent cache as much as it is to provide the code with
a persistent cache.

But is it really the case that the persistence is intended
across Emacs sessions for all users?  If not, it is, in
effect, something personal for the user, regardless of how
"regular" the updating might be, and regardless of which
file the value is persisted in.

> > IMHO the best
> > way to deal with that is indeed to use a separate file and to provide
> > a user option to set the file path & name. That way, users can decide
> > for themselves if they want to keep the file under version control,
> > sync it across machines, or not.

If the user specifies the file then this is, in effect,
user-specific.  Whether you make the variable itself a user
option, or you put its value in a file whose name is a user
option, does not change the fact that the variable value is
essentially user-specific.  All you're talking about in that
case is which file to save the value in: (1) `custom-file'
or init file versus (2) some other file.

> And this is exactly my use-case: a variable whose value will be
> periodically changed.

When and how often a variable gets changed doesn't enter
into it.  What's important wrt user options is whether the
variable is user-specific.

> And I don't like the hassle of having an option
> to a separate file with just this one variable...  Of course, if the
> only user beside me won't like Emacs messing around with his init.el,
> I'll do it that way.

If you don't want to save the value in your init file or your
`custom-file', and you don't want to save it in some other
file whose name you have to specify as an option value, then
consider using your bookmark file (which you presumably have
already).  If you want to do that, just create a variable-list
bookmark (using Bookmark+) - it persists and restores any
number of variables, including just one.

"Jumping" to the bookmark restores the saved variable value.
Use command `bmkp-set-variable-list-bookmark' to create and
update the value.  When you save your bookmark list (or when
it is saved automatically), the variable is persisted.

Re: Persistence of variables

[Eric Abrahamsen]

Drew Adams <drew.adams@oracle.com> writes:

>> > But no, way too heavy.  I want _one variable_ to persist, and nothing
>> > more.
>> 
>> If you already use savehist-mode, you can add your variable to
>> savehist-additional-variables.
>
> There are several possibilities, including these:
>
> 1. `savehist.el' (what Eric said)
> 2. Customize (option value)
> 3. Bookmark (e.g., Bookmark+ variable-list bookmark)
> 4. Desktop
>
> If you only want to save one variable, just use an option.

To muddy the waters further, there's also eieio-persistent:

(require 'eieio-base)
(defclass my-var-persister (eieio-persistent)
  ((directory
    :initarg :directory
    :initform ""
    :type string)))

(setq persister (make-instance 'my-var-persister
			       :directory "~/dir"
			       :file "~/.emacs.d/persist"))

(eieio-persistent-save persister)

;; Restart Emacs

(setq persister (eieio-persistent-read "~/.emacs.d/persist"))

(slot-value persister 'directory) ; "~/.dir"


Probably too heavy-weight for what you're describing, but it's another
option. If you ever want to save more complex data than just a single
value, it's not a bad choice.

Eric

Re: Persistence of variables

[Emanuel Berg]

Marcin Borkowski wrote:

> And I don't like the hassle of having an
> option to a separate file with just this
> one variable.

You realize this is the weirdest feeling, even
tho I believe you its genuine. Because storing
data in a file is the most natural thing anyone
could ever do with a computer, just like
a mathematician would write (0, 0) at origo or
a manufacturer of sledge hammers would inscribe
the weight in kg and oz on its head.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Persistence of variables

[Marcin Borkowski]

On 2018-03-28, at 02:21, Emanuel Berg <moasen@zoho.com> wrote:

> Marcin Borkowski wrote:
>
>> And I don't like the hassle of having an
>> option to a separate file with just this
>> one variable.
>
> You realize this is the weirdest feeling, even
> tho I believe you its genuine. Because storing
> data in a file is the most natural thing anyone
> could ever do with a computer, just like
> a mathematician would write (0, 0) at origo or
> a manufacturer of sledge hammers would inscribe
> the weight in kg and oz on its head.

I think you misunderstood me.  Storing data in a file is natural.
Having a separate file for just one variable looks like an overkill.

Best,

--
Marcin Borkowski
http://mbork.pl

Re: Persistence of variables

[Emanuel Berg]

Marcin Borkowski wrote:

> I think you misunderstood me. Storing data in
> a file is natural. Having a separate file for
> just one variable looks like an overkill.

Then create a file in your home dir called
.pervert - the persistent variable register.

It can be an XML file or just a text file like
this


    caliber     5.56
    insulation  none
    tire        650B
    LSD         ALD-52


("just a text file" doesn't make it any less of
a database than an XML ditto by the way)

Now write a parser that will search the file
for e.g. the key "tire" and return the data
item "650B".

Because you said you at this point only have
a single variable, you don't need to worry
about sorting (at least not for the sake of an
algorithm parsing it being too slow), but it
can be nice to have it sorted anyway - and easy
to do like any Emacs buffer, even automatically
on insert - nice because you might come to
realize this file is handy also for
manual [1] use, e.g. when writing to the math
faculty and having to look up pi (3.1415..) and
so on :) No, seriously!

I'm pretty sure someone already did an Emacs
framework/interface to populate, change, and
retrieve data from such a text DB file?


[1] Remember the words (mantra/motto) of the UK
    intelligence service: Knowledge gives
    strength to the hands.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Persistence of variables

[Marcin Borkowski]

On 2018-03-26, at 03:48, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:

> Drew Adams <drew.adams@oracle.com> writes:
>
>>> > But no, way too heavy.  I want _one variable_ to persist, and nothing
>>> > more.
>>> 
>>> If you already use savehist-mode, you can add your variable to
>>> savehist-additional-variables.
>>
>> There are several possibilities, including these:
>>
>> 1. `savehist.el' (what Eric said)
>> 2. Customize (option value)
>> 3. Bookmark (e.g., Bookmark+ variable-list bookmark)
>> 4. Desktop
>>
>> If you only want to save one variable, just use an option.
>
> To muddy the waters further, there's also eieio-persistent:
>
> (require 'eieio-base)
> (defclass my-var-persister (eieio-persistent)
>   ((directory
>     :initarg :directory
>     :initform ""
>     :type string)))
>
> (setq persister (make-instance 'my-var-persister
> 			       :directory "~/dir"
> 			       :file "~/.emacs.d/persist"))
>
> (eieio-persistent-save persister)
>
> ;; Restart Emacs
>
> (setq persister (eieio-persistent-read "~/.emacs.d/persist"))
>
> (slot-value persister 'directory) ; "~/.dir"
>
>
> Probably too heavy-weight for what you're describing, but it's another
> option. If you ever want to save more complex data than just a single
> value, it's not a bad choice.

Interesting.  Not for one string-valued variable, but worth keeping in
mind.  Thanks!

-- 
Marcin Borkowski
http://mbork.pl