From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Marcin Borkowski Newsgroups: gmane.emacs.help Subject: Re: One-off history for read-string Date: Sat, 26 Sep 2015 09:46:41 +0200 Message-ID: <87h9mhbp26.fsf@mbork.pl> References: <87y4fwt3vq.fsf@mbork.pl> <87twqjpc9h.fsf@debian.uxu> <87oagrt1d0.fsf@mbork.pl> <87zj0arl88.fsf@debian.uxu> <87pp15sxqf.fsf@debian.uxu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1443253656 2194 80.91.229.3 (26 Sep 2015 07:47:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Sep 2015 07:47:36 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Sep 26 09:47:26 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZfkCX-0002Sh-HT for geh-help-gnu-emacs@m.gmane.org; Sat, 26 Sep 2015 09:47:21 +0200 Original-Received: from localhost ([::1]:52301 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZfkCX-0000rs-4Y for geh-help-gnu-emacs@m.gmane.org; Sat, 26 Sep 2015 03:47:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZfkC1-0000NO-19 for help-gnu-emacs@gnu.org; Sat, 26 Sep 2015 03:46:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZfkBz-0001Hu-7T for help-gnu-emacs@gnu.org; Sat, 26 Sep 2015 03:46:48 -0400 Original-Received: from mail.mojserwer.eu ([2a01:5e00:2:52::8]:34035) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZfkBz-0001Hl-0L for help-gnu-emacs@gnu.org; Sat, 26 Sep 2015 03:46:47 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.mojserwer.eu (Postfix) with ESMTP id DB2E96F2009 for ; Sat, 26 Sep 2015 09:46:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.mojserwer.eu Original-Received: from mail.mojserwer.eu ([127.0.0.1]) by localhost (mail.mojserwer.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSFr4CUrRZzw for ; Sat, 26 Sep 2015 09:46:42 +0200 (CEST) Original-Received: from localhost (103-115.echostar.pl [213.156.103.115]) by mail.mojserwer.eu (Postfix) with ESMTPSA id 589046F2008 for ; Sat, 26 Sep 2015 09:46:42 +0200 (CEST) In-reply-to: <87pp15sxqf.fsf@debian.uxu> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a01:5e00:2:52::8 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:107366 Archived-At: On 2015-09-26, at 04:47, Emanuel Berg wrote: > John Mastro 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