Re: One-off history for read-string

[Marcin Borkowski <mbork@mbork.pl>]

On 2015-09-26, at 04:47, Emanuel Berg <embe8573@student.uu.se> wrote:

> John Mastro <john.b.mastro@gmail.com> writes:
>
>>     (defvar readonly-history)
>>
>>     (defun get-history-list-from-server ()
>>       ;; Imagine we fetch this list of HTTP
>>       (list "foo" "bar" "baz" "quux"))
>>
>>     (defun my-read-string (prompt)
>>       (let ((readonly-history (get-history-list-from-server)))
>>         (read-string prompt nil 'readonly-history)))
>
> And one would do that because...?

Please read John's email, he summed it up pretty well.

> Besides, isn't that "remote history" or "client-server
> history" or "distributed history" rather than
> "readonly history"?

From Emacs' point of view, it's kind of read-only; while read-string
does write to it, it _doesn't matter_ at all.  But you can call it what
you want.  I'm not very good at naming things, apparently.

> And how will the history be assembled if it is only
> clients that fetch it and then never add to it?

Who said about never adding?  Do you expect me to paste all 1400+ SLOC
here?  Of course it is sent to the server, by some _other_ piece of
code.

It works like this.  A datastructure, consisting of a series of
datapoints, is loaded into Emacs.  The user can view these series, and
optionally edit one of the datapoints.  Each datapoint has (among
others) a "comment" field, which might (or might not) be sometimes
repeated across datapoints.  So, when editing one datapoint, access to
comments of other datapoints is potentially useful.  A natural Emacs
concept for that is minibuffer history: when editing the 4th datapoint's
comment, M-n shows the 3rd's one, M-p the 5-th's one, and M-r and M-s do
"the right thing".  Then, this (maybe new) entry in history is
discarded, but the new datapoint is sent to the server.  Next time the
user downloads the data, surprise! it's available now!

And even though keeping that history in Emacs does make sense (since
downloading is triggered by the user and does not happen immediately;
I'll probably add support for updating the history in memory in the
future), Emacs' concept of history is of no use, since the history is
really the result of calling

(mapcar #'get-comment my-datastructure)

and there is _no point_ in keeping the history in two places:
my-datastructure and a list of comments alone (especially that there are
multiple my-datastructures at the same moment, completely unrelated to
each other!)

I hope it's clear now.

> And again, what is the purpose of all this?

To write an actual program which does something actually useful, not to
discuss endlessly about why anyone might want to write such a program.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University