One-off history for read-string

One-off history for read-string

[Marcin Borkowski]

Hi all,

I need to call read-string with some history.  From the docs (and
experiments) I assume that the HISTORY parameter should be a symbol and
not e.g. a literal list.  However, I don't really need to /save/ the
input I get into the history, since each time I use read-string, the
history is regenerated anyway from external source (I'm working on
a client for certain web service, and the history is kept on the server,
so it really doesn't make sense to keep all those in my Emacs session.)

Is it fine to use a temporary, let-bound variable name as the HISTORY
parameter, or is there a better way for a "history" I only need to read
from, not to write to?

TIA,

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

Re: One-off history for read-string

[Stefan Monnier]

> Is it fine to use a temporary, let-bound variable name as the HISTORY
> parameter, or is there a better way for a "history" I only need to read
> from, not to write to?

It's probably OK, but do declare this variable with (defvar <myvar>)
since it shouldn't be lexically bound

Note also that if the user uses nested minibuffers, she may have two
such commands active at the same time, so you may need to generate the
symbol dynamically rather than always use the same symbol.


        Stefan

Re: One-off history for read-string

[Marcin Borkowski]

On 2015-09-24, at 17:47, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> Is it fine to use a temporary, let-bound variable name as the HISTORY
>> parameter, or is there a better way for a "history" I only need to read
>> from, not to write to?
>
> It's probably OK, but do declare this variable with (defvar <myvar>)
> since it shouldn't be lexically bound

Ah, I don't use lexical binding in my package.  I probably should;
thanks for this advice!

> Note also that if the user uses nested minibuffers, she may have two
> such commands active at the same time, so you may need to generate the
> symbol dynamically rather than always use the same symbol.

Rather not applicable to my situation.  But out of curiosity: what are
"nested minibuffers" and where can I read about them?  In my Emacs, when
I try to issue a command which needs minibuffer while I'm in
a minibuffer, I get the message "Command attempted to use minibuffer
while in minibuffer".

>         Stefan

Thanks,

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

RE: One-off history for read-string

[Drew Adams]

> what are
> "nested minibuffers" and where can I read about them?  In my Emacs, when
> I try to issue a command which needs minibuffer while I'm in
> a minibuffer, I get the message "Command attempted to use minibuffer
> while in minibuffer".

You can do (setq enable-recursive-minibuffers  t), to see the
effect.

More likely, it can be bound to non-nil by a command.  For example,
if a command that uses the minibuffer wants to let you use a key
that is bound to another command that uses the minibuffer, then
the first command can bind `enable-recursive-minibuffers' to `t'.

Re: One-off history for read-string

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> (I'm working on a client for certain web service,
> and the history is kept on the server, so it really
> doesn't make sense to keep all those in my
> Emacs session.)

Perhaps not (?), but why think of this at all?
What problem is it, that you experience, or what
behavior do you seek?

> Is it fine to use a temporary, let-bound variable
> name as the HISTORY parameter, or is there a better
> way for a "history" I only need to read from, not to
> write to?

If you consider the prototype

    (read-string PROMPT &optional INITIAL-INPUT HISTORY
    DEFAULT-VALUE INHERIT-INPUT-METHOD)

you see that the HISTORY argument is optional - you
don't need to have anything there, and if you want to
pass something to subsequent optional arguments, pass
nil as HISTORY.

You can see an example of using `read-string' like
this here:

    http://user.it.uu.se/~embe8573/conf/emacs-init/w3m/w3m-unisearch.el

on line 116.

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

Re: One-off history for read-string

[Marcin Borkowski]

On 2015-09-25, at 02:34, Emanuel Berg <embe8573@student.uu.se> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> (I'm working on a client for certain web service,
>> and the history is kept on the server, so it really
>> doesn't make sense to keep all those in my
>> Emacs session.)
>
> Perhaps not (?), but why think of this at all?
> What problem is it, that you experience, or what
> behavior do you seek?

Well, maybe I wasn't clear enough.

The history is on the server.  I download it from there, and I want the
user to be able to /access/ it using e.g. M-n and M-p while
entering/editing something.  However, I don't care about /writing/ it to
some variable in Emacs, since the new entry will be uploaded to the
server anyway, and taken from there the next time, together with the
rest of the history.  (This is actually an oversimplification due to
some caching, but never mind.)

>> Is it fine to use a temporary, let-bound variable
>> name as the HISTORY parameter, or is there a better
>> way for a "history" I only need to read from, not to
>> write to?
>
> If you consider the prototype
>
>     (read-string PROMPT &optional INITIAL-INPUT HISTORY
>     DEFAULT-VALUE INHERIT-INPUT-METHOD)
>
> you see that the HISTORY argument is optional - you
> don't need to have anything there, and if you want to
> pass something to subsequent optional arguments, pass
> nil as HISTORY.

I /do/ understand all this, of course.  But it is /not/ the behavior
I want.

Best,

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

Re: One-off history for read-string

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> However, I don't care about /writing/ it to some
> variable in Emacs, since the new entry will be
> uploaded to the server anyway, and taken from there
> the next time, together with the rest of
> the history.

So then, what does it matter?

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

Re: One-off history for read-string

[John Mastro]

Emanuel Berg <embe8573@student.uu.se> wrote:

> > However, I don't care about /writing/ it to some
> > variable in Emacs, since the new entry will be
> > uploaded to the server anyway, and taken from there
> > the next time, together with the rest of
> > the history.
>
> So then, what does it matter?

He wants history to be available to the user (e.g. `M-p'), but he wants
that history to come from a server rather than be accumulated in the
usual way. So the history on the server is likely changing over time,
but from the Lisp code's perspective it's conceptually a new list each
time.

Something like this, if I understand him correctly:

    (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)))

-- 
john

Re: One-off history for read-string

[Emanuel Berg]

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...?

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

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

And again, what is the purpose of all this?

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

Re: One-off history for read-string

[Marcin Borkowski]

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

Re: One-off history for read-string

[Emanuel Berg]

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.

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.

>> 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.

> and there is _no point_ in keeping the history in
> two places

Still, there is no gain removing it unless it does
any harm.

>> 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?

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

Re: One-off history for read-string

[Marcin Borkowski]

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

Re: One-off history for read-string

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> 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.

On that level it is nothing to argue about. Modules,
and functions, and variables that are made public by
means of the documentation and help system, there is
where it matters and one should think twice.

Nothing to say you can't start practice at the `let'
level, and that attitude will bottom-up eventually
lead to better and more editable code, for sure, but
it is nothing to argue about.

>> 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_.

DRY (don't repeat yourself) is "aimed at reducing
repetition of information" [1] but there is also the
principle of redundancy as a good thing (e.g., RAID,
memory hierarchy, even larger systems as once Usenet).

But here, neither DRY nor redundancy-yes-please
apply what I can see because the client history
shouldn't be used, so it doesn't matter what it is.

If something doesn't help, but doesn't harm either, it
shouldn't be removed/disabled as the only outcomes of
that are neutral (OK, still no help/harm) or negative
(ouch! a bug introduced in removing/disabling it,
unsuspected consequences for some other component,
unsuspected loss of usefulness in some not-thought-of
future use case, etc.).

> 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.

So you have several computers and you want the history
to be shared between them?

[1] https://en.wikipedia.org/wiki/Don't_repeat_yourself

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

Re: One-off history for read-string

[Stefan Monnier]

> 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.

BTW, I think another option here might be to use a normal global
variable, and to simply `setq' it (instead of let-bind) to the proper
value just before you use it.


        Stefan

Re: One-off history for read-string

[Marcin Borkowski]

On 2015-09-26, at 04:33, John Mastro <john.b.mastro@gmail.com> wrote:

> Emanuel Berg <embe8573@student.uu.se> wrote:
>
>> > However, I don't care about /writing/ it to some
>> > variable in Emacs, since the new entry will be
>> > uploaded to the server anyway, and taken from there
>> > the next time, together with the rest of
>> > the history.
>>
>> So then, what does it matter?
>
> He wants history to be available to the user (e.g. `M-p'), but he wants
> that history to come from a server rather than be accumulated in the
> usual way. So the history on the server is likely changing over time,
> but from the Lisp code's perspective it's conceptually a new list each
> time.

Yes.

> Something like this, if I understand him correctly:

Yes, you do.

>     (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 this is exactly what I'm doing now, modulo variable names (and
get-history-list-from-server, which is really

(mapcar #'get-piece-of-history a-big-datastructure-got-from-the-server)

or really

(mapcar #'get-piece-of-history
        (cdr
          (assoc 'datastructure-key
                 an-even-bigger-alist-of-similar-but-unrelated-datastructures-got-from-the-server)

Best,

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