Several proposals, that I think will be helpful(or i dont know about).

Several proposals, that I think will be helpful(or i dont know about).

[Constantin Kulikov]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

The first one let you know if you are at the 'loading' stage while emacs is
starting. It could be useful in case when you start emacs --daemon from
startup script and your elisp code intended to ask yes-or-no -- then emacs
--daemon will stuck, but if you have some function like `loadingp' then you
can defer some questions on after-make-frame-functions for example.

Like:
(if (and (daemonp) (loadingp))
  (add-hook 'after-make-frame-functions ask-my-question)
 (ask-my-question))

This could be achieved by setting variable like `emacs-loading' to `t' in
the beginning of .emacs and setting it to `nil' in the end. But I think
there must be standard way for this.


Second I want some standard way to filter out emacs daemon's
'frame'(usually it's frame with ('name . "F1") parameter) from
`(frame-list)'.

[-- Attachment #2: Type: text/html, Size: 1024 bytes --]

Re: Several proposals, that I think will be helpful(or i dont know about).

[Michael Heerdegen]

Constantin Kulikov <zxnotdead@gmail.com> writes:

> The first one let you know if you are at the 'loading' stage while
> emacs is starting.

Isn't checking the value of `load-file-name' sufficient?

> Second I want some standard way to filter out emacs daemon's 'frame'
> (usually it's frame with ('name . "F1") parameter) from `(frame-list)

Sorry, can't help with that.

Michael.

Re: Several proposals, that I think will be helpful(or i dont know about).

[Stefan Monnier]

> Second I want some standard way to filter out emacs daemon's
> 'frame'(usually it's frame with ('name . "F1") parameter) from
> `(frame-list)'.

Does (eq frame-initial-frame (selected-frame)) work for you?
It could also replace your (loadingp) predicate, I think.


        Stefan

Re: Several proposals, that I think will be helpful(or i dont know about).

[Constantin Kulikov]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

> frame-initial-frame

hmm. The name of variable looked promising and I didn't know about it, but
it's value is `nil'.
emacs-version is "24.3.50.1"

Also, is it possible to somehow print text to stdout(into 'terminal') from
emacs and if not why?

[-- Attachment #2: Type: text/html, Size: 552 bytes --]

Re: Several proposals, that I think will be helpful(or i dont know about).

[Constantin Kulikov]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

> We're talking about determining the current state

Here what I have:

# cat ~/.emacs-experiments
-- (message "initial-frame: %s; frame: %s; eq: %s;" frame-initial-frame
(selected-frame) (eq frame-initial-frame (selected-frame)))

# emacs -q --daemon=exp --load ~/.emacs-experiments
-- ("emacs" "--load" "/home/constantin/.emacs-experiments")
-- Starting Emacs daemon.
-- initial-frame: nil; frame: #<frame F1 0x9a6a50>; eq: nil;



On 25 November 2013 22:26, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> >> frame-initial-frame
> > hmm. The name of variable looked promising and I didn't know about it,
> but
> > it's value is `nil'.
> > emacs-version is "24.3.50.1"
>
> We're talking about determining the current state, so the fact that it's
> nil at some point is not necessarily a problem.  Also, if that var work,
> try terminal-frame instead (which the one I was thinking of, really).
> It's also nil when you look at it interactively, but just like the
> other, it's not always nil (otherwise those vars would be useless).
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 1678 bytes --]

Re: Several proposals, that I think will be helpful(or i dont know about).

[Constantin Kulikov]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

Found that `frame-initial-frame' working when starting 'standalone' emacs:
# emacs -q --load ~/.emacs-experiments
then in *Message* buffer it prints:
> initial-frame: #<frame emacs@ZXnotdead 0xf502b0>; frame: #<frame
emacs@ZXnotdead 0xf502b0>; eq: t;

but in don't work for emacs --daemon



On 25 November 2013 22:42, Constantin Kulikov <zxnotdead@gmail.com> wrote:

> > We're talking about determining the current state
>
> Here what I have:
>
> # cat ~/.emacs-experiments
> -- (message "initial-frame: %s; frame: %s; eq: %s;" frame-initial-frame
> (selected-frame) (eq frame-initial-frame (selected-frame)))
>
> # emacs -q --daemon=exp --load ~/.emacs-experiments
> -- ("emacs" "--load" "/home/constantin/.emacs-experiments")
> -- Starting Emacs daemon.
> -- initial-frame: nil; frame: #<frame F1 0x9a6a50>; eq: nil;
>
>
>
> On 25 November 2013 22:26, Stefan Monnier <monnier@iro.umontreal.ca>wrote:
>
>> >> frame-initial-frame
>> > hmm. The name of variable looked promising and I didn't know about it,
>> but
>> > it's value is `nil'.
>> > emacs-version is "24.3.50.1"
>>
>> We're talking about determining the current state, so the fact that it's
>> nil at some point is not necessarily a problem.  Also, if that var work,
>> try terminal-frame instead (which the one I was thinking of, really).
>> It's also nil when you look at it interactively, but just like the
>> other, it's not always nil (otherwise those vars would be useless).
>>
>>
>>         Stefan
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2505 bytes --]

Re: Several proposals, that I think will be helpful(or i dont know about).

[Stefan Monnier]

> Found that `frame-initial-frame' working when starting 'standalone' emacs:
> # emacs -q --load ~/.emacs-experiments
> then in *Message* buffer it prints:
>> initial-frame: #<frame emacs@ZXnotdead 0xf502b0>; frame: #<frame
> emacs@ZXnotdead 0xf502b0>; eq: t;
> but in don't work for emacs --daemon

But have you tried with terminal-frame instead?


        Stefan


PS: As for sending text to stdout, you can do it (or maybe it
was to stderr), using a particular stream argument to `print', but
I can't remember now.

Re: Several proposals, that I think will be helpful(or i dont know about).

[Constantin Kulikov]

[-- Attachment #1: Type: text/plain, Size: 182 bytes --]

> have you tried with terminal-frame instead?
initial-frame: nil; frame: #<frame F1 0x9a6a50>; eq: nil;

same as with --daemon. So how can I use it? Maybe misunderstand something...

[-- Attachment #2: Type: text/html, Size: 353 bytes --]

Re: Several proposals, that I think will be helpful(or i dont know about).

[Constantin Kulikov]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

oh, wait. `terminal-frame' is variable name(i thought that you want me to
run my test code in emacs -nw) -- going to try it.


On 26 November 2013 17:35, Constantin Kulikov <zxnotdead@gmail.com> wrote:

> > have you tried with terminal-frame instead?
> initial-frame: nil; frame: #<frame F1 0x9a6a50>; eq: nil;
>
> same as with --daemon. So how can I use it? Maybe misunderstand
> something...
>
>

[-- Attachment #2: Type: text/html, Size: 880 bytes --]

Re: Several proposals, that I think will be helpful(or i dont know about).

[Constantin Kulikov]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

OK.

Then when asking question:

(if (and (daemonp) (eq terminal-frame (selected-frame)))
    try searching for another frame to focus or defer ask-my-question
  ask-my-question)

For frame-list:

(defun my-frame-list ()
  (if (daemonp)
      (filtered-frame-list #'(lambda (f) (not (eq f terminal-frame))))
    (frame-list)))

Right ?

[-- Attachment #2: Type: text/html, Size: 542 bytes --]

Re: Several proposals, that I think will be helpful(or i dont know about).

[Stefan Monnier]

> Then when asking question:

> (if (and (daemonp) (eq terminal-frame (selected-frame)))
>     try searching for another frame to focus or defer ask-my-question
>   ask-my-question)

I think so, yes (and you can skip the (daemonp) test).


        Stefan

Re: Several proposals, that I think will be helpful(or i dont know about).

[Stefan Monnier]

> (if (and (daemonp) (eq terminal-frame (selected-frame)))
>     try searching for another frame to focus or defer ask-my-question
>   ask-my-question)

Another option would be to check (framep (selected-frame)), tho I'm
afraid that it would return the same for a tty as for the daemon case.


        Stefan

Re: Several proposals, that I think will be helpful(or i dont know about).

[Glenn Morris]

Constantin Kulikov wrote:

> It could be useful in case when you start emacs --daemon from startup
> script and your elisp code intended to ask yes-or-no -- then emacs
> --daemon will stuck,

I'm not sure what you are saying/proposing, but it sounds somewhat like
http://debbugs.gnu.org/13697

Re: Several proposals, that I think will be helpful(or i dont know about).

[Johan Bockgård]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> PS: As for sending text to stdout, you can do it (or maybe it was to
> stderr), using a particular stream argument to `print', but I can't
> remember now.

`external-debugging-output'

Re: Several proposals, that I think will be helpful(or i dont know about).

[Constantin Kulikov]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

Interesting, thanks. Yes it's the same issue.

(or noninteractive
    (and (daemonp)
         (null (cdr (frame-list)))
         (eq (selected-frame) terminal-frame)))

On 26 November 2013 23:33, Glenn Morris <rgm@gnu.org> wrote:

> Constantin Kulikov wrote:
>
> > It could be useful in case when you start emacs --daemon from startup
> > script and your elisp code intended to ask yes-or-no -- then emacs
> > --daemon will stuck,
>
> I'm not sure what you are saying/proposing, but it sounds somewhat like
> http://debbugs.gnu.org/13697
>

[-- Attachment #2: Type: text/html, Size: 1031 bytes --]

Re: Several proposals, that I think will be helpful(or i dont know about).

[Glenn Morris]

Constantin Kulikov wrote:

> Interesting, thanks. Yes it's the same issue.

As I said there, IMO there should be a standard function for this
("can I interact with the user").

Re: Several proposals, that I think will be helpful(or i dont know about).

[Constantin Kulikov]

[-- Attachment #1: Type: text/plain, Size: 164 bytes --]

> there should be a standard function for this
Agree.
// And then maybe standard packages from emacs distro should be updated to
not hang emacs daemon. Eventually.

[-- Attachment #2: Type: text/html, Size: 265 bytes --]

Re: Several proposals, that I think will be helpful(or i dont know about).

[Glenn Morris]

Constantin Kulikov wrote:

> // And then maybe standard packages from emacs distro should be updated to
> not hang emacs daemon. Eventually.

Sounds like my other suggestion in that report ("maybe yes-or-no-p etc
should abort in such cases rather than waiting for ever").

Re: Several proposals, that I think will be helpful(or i dont know about).

[Constantin Kulikov]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

> maybe yes-or-no-p etc should abort
Just aborting is not so good in my apinion.
I think it could be replaced with something like: yes-or-no-or-defer-p that
takes a function as argument, and if it cannot interact with user it
executes this function or add this function to after-make-frame-functions
hook.


On 27 November 2013 00:07, Glenn Morris <rgm@gnu.org> wrote:

> Constantin Kulikov wrote:
>
> > // And then maybe standard packages from emacs distro should be updated
> to
> > not hang emacs daemon. Eventually.
>
> Sounds like my other suggestion in that report ("maybe yes-or-no-p etc
> should abort in such cases rather than waiting for ever").
>

[-- Attachment #2: Type: text/html, Size: 1054 bytes --]