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: Sun, 27 Sep 2015 08:02:43 +0200 Message-ID: <87mvw8z9fg.fsf@mbork.pl> References: <87y4fwt3vq.fsf@mbork.pl> <87twqjpc9h.fsf@debian.uxu> <87oagrt1d0.fsf@mbork.pl> <87zj0arl88.fsf@debian.uxu> <87pp15sxqf.fsf@debian.uxu> <87h9mhbp26.fsf@mbork.pl> <87612wr72k.fsf@debian.uxu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1443333808 23751 80.91.229.3 (27 Sep 2015 06:03:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Sep 2015 06:03:28 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Sep 27 08:03:16 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 1Zg53L-00026q-UR for geh-help-gnu-emacs@m.gmane.org; Sun, 27 Sep 2015 08:03:16 +0200 Original-Received: from localhost ([::1]:56237 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zg53L-0003iy-Br for geh-help-gnu-emacs@m.gmane.org; Sun, 27 Sep 2015 02:03:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zg53B-0003in-9b for help-gnu-emacs@gnu.org; Sun, 27 Sep 2015 02:03:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zg538-0001Ou-1Q for help-gnu-emacs@gnu.org; Sun, 27 Sep 2015 02:03:05 -0400 Original-Received: from mail.mojserwer.eu ([2a01:5e00:2:52::8]:42035) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zg537-0001Ob-Lx for help-gnu-emacs@gnu.org; Sun, 27 Sep 2015 02:03:01 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.mojserwer.eu (Postfix) with ESMTP id DB8C96F2005 for ; Sun, 27 Sep 2015 08:03:00 +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 w0kfh1CKjAuz for ; Sun, 27 Sep 2015 08:02:53 +0200 (CEST) Original-Received: from localhost (103-115.echostar.pl [213.156.103.115]) by mail.mojserwer.eu (Postfix) with ESMTPSA id B90D96F2003 for ; Sun, 27 Sep 2015 08:02:53 +0200 (CEST) In-reply-to: <87612wr72k.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:107371 Archived-At: On 2015-09-27, at 03:20, Emanuel Berg wrote: > Marcin Borkowski writes: > >> 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. > > It is not a good policy to name things after > properties that doesn't matter. I didn't _name_ it that way. I only used that unfortunate wording in the email, as an explanation. Seemingly, I failed with that;-). Also, I didn't say that this property _didn't matter_. I only said that it doesn't matter that read-string writes to that variable. So, while technically it's of course both read from and written to, its _purpose/usefulness_ lies in the fact that only the reading-from part matters. > Also, most often it is not a good idea to name things > in terms of technology but rather their > purpose/usefulness, but there are more and more > exceptions to that rule the deeper you delve into > technology and this might be one of them. > > This is client-server/remote/distributed history. In my code, it is just (let ((comment-history ...)) ...) I'd be thankful if you could come up with a better, non-generic name. But I don't see the point in doing that: the scope of the name is limited to one let-form, whose body is one read-string invocation. It's pretty much self-explanatory. >>> 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? ... Of course it is >> sent to the server, by some _other_ piece of code. > > Then it is even more confusing to call it "read only" > as both writing and reading is done. Maybe, but from the standpoint of read-string, which was ALL MY ORIGINAL POST WAS ABOUT, writing is IRRELEVANT. I was not asking whether my code design was sane or proper or anything. If I had asked that, I would include all other info within my first post. I asked a technical question of how to handle a one-off history for read-string. It was you who assumed that what I'm doing doesn't make sense, based on very incomplete information about my use-case. >> and there is _no point_ in keeping the history in >> two places > > Still, there is no gain removing it unless it does > any harm. Yes, there is. The DRY principle. Also, it does some harm: the (server-side) history _can (and frequently is) be changed by other tools_, and then the (Emacs-side) one would be _wrong_. >>> 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. > > I don't ask in general, I specifically ask why you > want a server to handle the history? It's not that I want it or not; it just works that way. (But I want it, too, btw.) It is a service I'm not an author of, nor do I control it. And there are at least two other clients besides my Emacs one (and I personally use at least one of them also regularly!), and they all have a "history" feature. And it's a good thing they do, because, it is sometimes needed. Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University