From: Marcin Borkowski <mbork@mbork.pl>
To: help-gnu-emacs@gnu.org
Subject: Re: One-off history for read-string
Date: Sun, 27 Sep 2015 08:02:43 +0200 [thread overview]
Message-ID: <87mvw8z9fg.fsf@mbork.pl> (raw)
In-Reply-To: <87612wr72k.fsf@debian.uxu>
On 2015-09-27, at 03:20, Emanuel Berg <embe8573@student.uu.se> wrote:
> Marcin Borkowski <mbork@mbork.pl> 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
next prev parent reply other threads:[~2015-09-27 6:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-24 12:10 One-off history for read-string Marcin Borkowski
2015-09-24 15:47 ` Stefan Monnier
2015-09-24 16:27 ` Marcin Borkowski
2015-09-24 17:04 ` Drew Adams
2015-09-25 0:34 ` Emanuel Berg
2015-09-25 7:16 ` Marcin Borkowski
2015-09-26 2:02 ` Emanuel Berg
2015-09-26 2:33 ` John Mastro
2015-09-26 2:47 ` Emanuel Berg
2015-09-26 7:46 ` Marcin Borkowski
2015-09-27 1:20 ` Emanuel Berg
2015-09-27 6:02 ` Marcin Borkowski [this message]
2015-09-27 23:14 ` Emanuel Berg
2015-09-28 0:50 ` Stefan Monnier
2015-09-26 7:46 ` Marcin Borkowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mvw8z9fg.fsf@mbork.pl \
--to=mbork@mbork.pl \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).