minibuffer-exit when emacsclient executes Lisp code

minibuffer-exit when emacsclient executes Lisp code

[Klaus Zeitler]

Hi,
when I execute Lisp code via emacsclient, emacs exits automatically from the
current minibuffer. I'm not sure if this behavior is intended.
It took me quite a while to figure out why I got thrown out of the minibuffer
sometimes without apparent reason (or why C-s stopped inadvertently). The
reason was a script running in the background, that called emacsclient every
30 seconds. I don't think that this happened in older CVS versions (from a few
months ago, haven't used CVS emacs much lately), but maybe I just didn't notice.

Klaus

-- 
 --------------------------------------------------
|  Klaus Zeitler      Alcatel-Lucent               |
|  Email:             kzeitler@alcatel-lucent.com  |
 --------------------------------------------------
---
Join the march to save individuality!

Re: minibuffer-exit when emacsclient executes Lisp code

[Lennart Borgman (gmail)]

Klaus Zeitler wrote:
> Hi,
> when I execute Lisp code via emacsclient, emacs exits automatically from the
> current minibuffer. I'm not sure if this behavior is intended.
> It took me quite a while to figure out why I got thrown out of the minibuffer
> sometimes without apparent reason (or why C-s stopped inadvertently). The
> reason was a script running in the background, that called emacsclient every
> 30 seconds. I don't think that this happened in older CVS versions (from a few
> months ago, haven't used CVS emacs much lately), but maybe I just didn't notice.
> 
> Klaus

Yes, it is probably due to a change a while ago to avoid problems if the 
minibuffer was active. How are you calling emacsclient? Is it to open 
files or to eval some elisp code?

Re: minibuffer-exit when emacsclient executes Lisp code

[Klaus Zeitler]

>>>>> "Lennart" == Lennart Borgman (gmail) <lennart.borgman@gmail.com> writes:
    Lennart> 
    Lennart> Yes, it is probably due to a change a while ago to avoid problems
    Lennart> if the minibuffer was active. How are you calling emacsclient? Is
    Lennart> it to open files or to eval some elisp code?

My script calls emacsclient with --eval to evaluate lisp code.
Here's a simple example:
1. in your emacs do M-x to enter the minibuffer
2. in a shell type e.g.: emacsclient --eval cvs-emacs
=> emacs quits the minibuffer

Klaus

-- 
 --------------------------------------------------
|  Klaus Zeitler      Alcatel-Lucent               |
|  Email:             kzeitler@alcatel-lucent.com  |
 --------------------------------------------------
---
The difference between a fool and a wise man is not
the things they know, it's the questions they ask.

Re: minibuffer-exit when emacsclient executes Lisp code

[Lennart Borgman (gmail)]

Klaus Zeitler wrote:
>>>>>> "Lennart" == Lennart Borgman (gmail) <lennart.borgman@gmail.com> writes:
>     Lennart> 
>     Lennart> Yes, it is probably due to a change a while ago to avoid problems
>     Lennart> if the minibuffer was active. How are you calling emacsclient? Is
>     Lennart> it to open files or to eval some elisp code?
> 
> My script calls emacsclient with --eval to evaluate lisp code.
> Here's a simple example:
> 1. in your emacs do M-x to enter the minibuffer
> 2. in a shell type e.g.: emacsclient --eval cvs-emacs
> => emacs quits the minibuffer
> 
> Klaus

Unfortunately there is currently no way to distinguish your case from 
the more normal case where emacsclient is used to open a file. In the 
later case I think the change does what is needed, but for your (a bit 
more unusual) usage it breaks it.

One way to solve this problem would be to try to distinguish the two 
cases by the use of "-eval". If "-eval" is present in the command (as 
seen from the server) then your case is perhaps more common. Then 
something like the patch below could be used. I do believe however that 
a more explicit way to handle this would be better. Anyway here is a 
patch you might use for now:

*** c:/DOCUME~1/LENNAR~1/LOCALS~1/Temp/ediff972Kmu	2007-05-16 
13:22:50.109375000 +0200
--- c:/emacs/p/070515/emacs/lisp/server.el	2007-05-16 13:22:19.750000000 
+0200
***************
*** 1,3 ****
   ;;; server.el --- Lisp code for GNU Emacs running as server process

   ;; Copyright (C) 1986, 1987, 1992, 1994, 1995, 1996, 1997, 1998, 
1999, 2000,
--- 1,3 ----
***************
*** 405,411 ****
       (when prev
         (setq string (concat prev string))
         (process-put proc :previous-string nil)))
!   (when (> (recursion-depth) 0)
       ;; We're inside a minibuffer already, so if the emacs-client is 
trying
       ;; to open a frame on a new display, we might end up with an unusable
       ;; frame because input from that display will be blocked (until 
exiting
--- 404,424 ----
       (when prev
         (setq string (concat prev string))
         (process-put proc :previous-string nil)))
!   (when (and (> (recursion-depth) 0)
!              (not
!               (catch 'eval-found
!                 (let ((str string)
!                       arg)
!                   (save-match-data
!                     (while (string-match
!                             (rx line-start
!                                 (0+ (not (any space)))
!                                 (1+ space))
!                             str)
!                       (setq arg (substring str (match-beginning 0) (1- 
(match-end 0))))
!                       (when (string= arg "-eval")
!                         (throw 'eval-found t))
!                       (setq str (substring str (match-end 0)))))))))
       ;; We're inside a minibuffer already, so if the emacs-client is 
trying
       ;; to open a frame on a new display, we might end up with an unusable
       ;; frame because input from that display will be blocked (until 
exiting

Re: minibuffer-exit when emacsclient executes Lisp code

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Klaus Zeitler wrote:
>>>>>>> "Lennart" == Lennart Borgman (gmail) <lennart.borgman@gmail.com> writes:
>>     Lennart>     Lennart> Yes, it is probably due to a change a
>> while ago to avoid problems
>>     Lennart> if the minibuffer was active. How are you calling emacsclient? Is
>>     Lennart> it to open files or to eval some elisp code?
>>
>> My script calls emacsclient with --eval to evaluate lisp code.
>> Here's a simple example:
>> 1. in your emacs do M-x to enter the minibuffer
>> 2. in a shell type e.g.: emacsclient --eval cvs-emacs
>> => emacs quits the minibuffer
>>
>> Klaus
>
> Unfortunately there is currently no way to distinguish your case
> from the more normal case where emacsclient is used to open a
> file. In the later case I think the change does what is needed, but
> for your (a bit more unusual) usage it breaks it.

--eval '(find-file "xxxx")

I think we should probably try to address this in connection with
another issue: a suitable way for opening a tty: open a frame only
once it is "needed".  One problem we currently have is that it is not
really pleasing to specify Emacs frame geometries, colors, toolbar or
menubar presence by using .emacs and/or customize: that way, the
initial frame will first get mapped wrongly, then flicker into
shape/position.

So one would want to have a delayed mapping, basically happening when
sit-for is called.

If this point is never reached, we don't need a mapping at all.  In a
similar vein, if emacsclient never reaches a point where it would be
interested in looking at tty input, maybe it is not worth mapping a
frame (and stealing the minibuffer).  Of course, the question when to
call "top-level" remains.

-- 
David Kastrup

Re: minibuffer-exit when emacsclient executes Lisp code

[Lennart Borgman (gmail)]

David Kastrup wrote:

> --eval '(find-file "xxxx")

Yes, but I thought this could just be referred to the --eval case. But 
in the long run I agree that it is a problem and that a solution along 
the lines you describe below should be better.

I just wanted to give a quick and non-dangerous solution for now.

> I think we should probably try to address this in connection with
> another issue: a suitable way for opening a tty: open a frame only
> once it is "needed".  One problem we currently have is that it is not
> really pleasing to specify Emacs frame geometries, colors, toolbar or
> menubar presence by using .emacs and/or customize: that way, the
> initial frame will first get mapped wrongly, then flicker into
> shape/position.
> 
> So one would want to have a delayed mapping, basically happening when
> sit-for is called.
> 
> If this point is never reached, we don't need a mapping at all.  In a
> similar vein, if emacsclient never reaches a point where it would be
> interested in looking at tty input, maybe it is not worth mapping a
> frame (and stealing the minibuffer).  Of course, the question when to
> call "top-level" remains.
> 

Re: minibuffer-exit when emacsclient executes Lisp code

[Károly Lo"rentey]

[-- Attachment #1.1: Type: text/plain, Size: 2782 bytes --]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Klaus Zeitler wrote:
>>> My script calls emacsclient with --eval to evaluate lisp code.
>>> Here's a simple example:
>>> 1. in your emacs do M-x to enter the minibuffer
>>> 2. in a shell type e.g.: emacsclient --eval cvs-emacs
>>> => emacs quits the minibuffer
>>>
>> Unfortunately there is currently no way to distinguish your case
>> from the more normal case where emacsclient is used to open a
>> file. In the later case I think the change does what is needed, but
>> for your (a bit more unusual) usage it breaks it.
> 
> --eval '(find-file "xxxx")

Well said.  It is not clear to me if this bug report is for the
multi-tty branch or the trunk, but with the multi-tty emacsclient, a
more useful heuristic would be whether or not the client requested the
creation of a new frame.  (Incidentally, the freeze issue was to be
resolved by better user feedback and an elaborate C-g-based protocol to
let the user manually return to top-level from frozen frames. I like
this simple approach even better.)

To reduce conflicts and parallel effort, I think people should look at
the multi-tty emacsclient, and (if possible) stop enhancing the trunk
version.  The two versions are considerably different.

> I think we should probably try to address this in connection with
> another issue: a suitable way for opening a tty: open a frame only
> once it is "needed".  One problem we currently have is that it is not
> really pleasing to specify Emacs frame geometries, colors, toolbar or
> menubar presence by using .emacs and/or customize: that way, the
> initial frame will first get mapped wrongly, then flicker into
> shape/position.
> So one would want to have a delayed mapping, basically happening when
> sit-for is called.  If this point is never reached, we don't need a
> mapping at all.

The flickering issue may not be strictly relevant for the emacsclient
case, since the parameters that apply on the new frame are (or at least
should be) already known at the time the frame is created.

(Multi-tty) Emacs is dumped with a dummy (no-op) terminal, and creates
the first real terminal only on the second run.  One way to reduce
flickering would be to delay terminal initialization until after .emacs
is loaded.  Is this what you mean?  Wouldn't that make it harder to
debug .emacs errors?

> In a
> similar vein, if emacsclient never reaches a point where it would be
> interested in looking at tty input, maybe it is not worth mapping a
> frame (and stealing the minibuffer).  Of course, the question when to
> call "top-level" remains.

I think something like (run-at-time 0 nil 'top-level) would work fine.

-- 
Karoly



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: minibuffer-exit when emacsclient executes Lisp code

[Juanma Barranquero]

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

On 5/16/07, Károly Lo"rentey <karoly@lorentey.hu> wrote:

> To reduce conflicts and parallel effort, I think people should look at
> the multi-tty emacsclient, and (if possible) stop enhancing the trunk
> version.

Are you proposing throwing the trunk version and just replacing it
with the multi-tty one?

             Juanma

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: minibuffer-exit when emacsclient executes Lisp code

[David Kastrup]

"Károly Lőrentey" <karoly@lorentey.hu> writes:

> David Kastrup wrote:
>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>> 
>>> Klaus Zeitler wrote:
>>>> My script calls emacsclient with --eval to evaluate lisp code.
>>>> Here's a simple example:
>>>> 1. in your emacs do M-x to enter the minibuffer
>>>> 2. in a shell type e.g.: emacsclient --eval cvs-emacs
>>>> => emacs quits the minibuffer
>>>>
>>> Unfortunately there is currently no way to distinguish your case
>>> from the more normal case where emacsclient is used to open a
>>> file. In the later case I think the change does what is needed, but
>>> for your (a bit more unusual) usage it breaks it.
>> 
>> --eval '(find-file "xxxx")
>
> Well said.  It is not clear to me if this bug report is for the
> multi-tty branch or the trunk, but with the multi-tty emacsclient, a
> more useful heuristic would be whether or not the client requested
> the creation of a new frame.  (Incidentally, the freeze issue was to
> be resolved by better user feedback and an elaborate C-g-based
> protocol to let the user manually return to top-level from frozen
> frames. I like this simple approach even better.)

It may be too simple (which is the common problem with simple
solutions).  And if one falls in love with the simplicity, one tends
to build complex workarounds around it in order to be able to keep
it...  More at the bottom.

> To reduce conflicts and parallel effort, I think people should look
> at the multi-tty emacsclient, and (if possible) stop enhancing the
> trunk version.  The two versions are considerably different.

To a degree that instead "conflicts" and "parallel effort", "wasted
effort" would probably be more accurate.

The multi-tty emacsclient is actually quite more similar in
functionality to "gnuclient".

>> I think we should probably try to address this in connection with
>> another issue: a suitable way for opening a tty: open a frame only
>> once it is "needed".  One problem we currently have is that it is
>> not really pleasing to specify Emacs frame geometries, colors,
>> toolbar or menubar presence by using .emacs and/or customize: that
>> way, the initial frame will first get mapped wrongly, then flicker
>> into shape/position.  So one would want to have a delayed mapping,
>> basically happening when sit-for is called.  If this point is never
>> reached, we don't need a mapping at all.
>
> The flickering issue may not be strictly relevant for the
> emacsclient case, since the parameters that apply on the new frame
> are (or at least should be) already known at the time the frame is
> created.

Sure, that's why I wrote "in connection with another issue": maybe one
problem can be solved in a way that gives an obvious solution for the
other problem.

> (Multi-tty) Emacs is dumped with a dummy (no-op) terminal, and
> creates the first real terminal only on the second run.  One way to
> reduce flickering would be to delay terminal initialization until
> after .emacs is loaded.  Is this what you mean?  Wouldn't that make
> it harder to debug .emacs errors?

Not really.  There is -debug-init (which could well cause an immediate
mapping to facilitate debugging), there is the *Message* buffer, and
there might also be stderr for messages (if the process is started
from some window manager or similar, stderr might still possible be
available in some internal log or window or console from the window
manager) while we are not yet mapped.

And even if we have the equivalent of (while t) in our .emacs, having
a mapped frame will probably not help significantly.  Probably less
than using stdin/stdout/stderr (basically, the -batch environment)
would before top-level is entered the first time.  Of course, this has
the disadvantage that communication will have to occur keeping in mind
output and keyboard locales.  Maybe Emacs should retain some minimal
knowledge about its controlling tty for that purpose?

>> In a similar vein, if emacsclient never reaches a point where it
>> would be interested in looking at tty input, maybe it is not worth
>> mapping a frame (and stealing the minibuffer).  Of course, the
>> question when to call "top-level" remains.
>
> I think something like (run-at-time 0 nil 'top-level) would work fine.

This is asking for trouble, since quite a lot of not-top-level code
may call sit-for and consequently timers.

-- 
David Kastrup

Re: minibuffer-exit when emacsclient executes Lisp code

[Klaus Zeitler]

>>>>> "Karoly" == Karoly Lorentey <karoly@lorentey.hu> writes:
    Karoly> 
    Karoly> Well said.  It is not clear to me if this bug report is for the
    Karoly> multi-tty branch or the trunk, but with the multi-tty emacsclient.

It was meant for the "normal" trunk, I haven't tried the multi-tty branch yet.

Klaus

-- 
 --------------------------------------------------
|  Klaus Zeitler      Alcatel-Lucent               |
|  Email:             kzeitler@alcatel-lucent.com  |
 --------------------------------------------------
---
There are two ways of constructing a software design: One way is to make it so
simple that there are obviously no deficiencies, and the other way is to make
it so complicated that there are no obvious deficiencies.    -- C. A. R. Hoare

Re: minibuffer-exit when emacsclient executes Lisp code

[Stefan Monnier]

> the first real terminal only on the second run.  One way to reduce
> flickering would be to delay terminal initialization until after .emacs
> is loaded.  Is this what you mean?

I've been using a local hack which does just that.  Funnily enough it
doesn't remove all frame-resizing.  Maybe it's a bug in my hack, of course.

> Wouldn't that make it harder to debug .emacs errors?

Not really, no.  But it did break part of my .emacs which called
`frame-parameter' or something like that.

In any case, w.r.t calling `toplevel' I agree that we should probably not do
that when processing a "-eval" (after all, the user can explicitly add
a call to (toplevel) in the Elisp code passed to the Emacs session).
The only reason why it does do it currently, is because it seemed too much
trouble to try and distinguish this case.  Maybe the recursion-depth check
should be moved elsewhere where it's easier to determine whether -eval was
used or not.


        Stefan

Re: minibuffer-exit when emacsclient executes Lisp code

[Klaus Zeitler]

>>>>> "Lennart" == Lennart Borgman (gmail) <lennart.borgman@gmail.com> writes:
    Lennart> 
    Lennart> One way to solve this problem would be to try to distinguish the
    Lennart> two cases by the use of "-eval". If "-eval" is present in the
    Lennart> command (as seen from the server) then your case is perhaps more
    Lennart> common. Then something like the patch below could be used.

Thanks, I'll try your patch next Monday. Maybe checking if a frame needs to be
created might be a better idea.

Klaus

-- 
 --------------------------------------------------
|  Klaus Zeitler      Alcatel-Lucent               |
|  Email:             kzeitler@alcatel-lucent.com  |
 --------------------------------------------------
---
Law of Probable Dispersal:
 Whatever it is that hits the fan will not be evenly distributed.

Re: minibuffer-exit when emacsclient executes Lisp code

[Lennart Borgman (gmail)]

Klaus Zeitler wrote:
>>>>>> "Lennart" == Lennart Borgman (gmail) <lennart.borgman@gmail.com> writes:
>     Lennart> 
>     Lennart> One way to solve this problem would be to try to distinguish the
>     Lennart> two cases by the use of "-eval". If "-eval" is present in the
>     Lennart> command (as seen from the server) then your case is perhaps more
>     Lennart> common. Then something like the patch below could be used.
> 
> Thanks, I'll try your patch next Monday. Maybe checking if a frame needs to be
> created might be a better idea.

Sure something better is needed in the future. This is just a quick way 
to get back the functionality you had before without breaking too much.

Re: minibuffer-exit when emacsclient executes Lisp code

[Klaus Zeitler]

Hello Lennart,
>>>>> "Lennart" == Lennart Borgman (gmail) <lennart.borgman@gmail.com> writes:
    Lennart> 
    Lennart> Anyway here is a patch you might use for now:
    Lennart> 
    Lennart> *** c:/DOCUME~1/LENNAR~1/LOCALS~1/Temp/ediff972Kmu	2007-05-16 13:22:50.109375000 +0200
    Lennart> --- c:/emacs/p/070515/emacs/lisp/server.el	2007-05-16 13:22:19.750000000 +0200

your patch works great. Thanks a lot. I'm afraid this patch will not make it
into the upcoming emacs 22 nor into trunk?

Klaus

-- 
 --------------------------------------------------
|  Klaus Zeitler      Alcatel-Lucent               |
|  Email:             kzeitler@alcatel-lucent.com  |
 --------------------------------------------------
---
Military intelligence is a contradiction in terms. -- Groucho Marx

Re: minibuffer-exit when emacsclient executes Lisp code

[Lennart Borgman (gmail)]

Klaus Zeitler wrote:
> Hello Lennart,
>>>>>> "Lennart" == Lennart Borgman (gmail) <lennart.borgman@gmail.com> writes:
>     Lennart> 
>     Lennart> Anyway here is a patch you might use for now:
>     Lennart> 
>     Lennart> *** c:/DOCUME~1/LENNAR~1/LOCALS~1/Temp/ediff972Kmu	2007-05-16 13:22:50.109375000 +0200
>     Lennart> --- c:/emacs/p/070515/emacs/lisp/server.el	2007-05-16 13:22:19.750000000 +0200
> 
> your patch works great. Thanks a lot. I'm afraid this patch will not make it
> into the upcoming emacs 22 nor into trunk?

No, I would not expect that. The best one can hope for is that the 
question is not forgotten. Maybe there is somewhere to put a note about 
this, but I am not sure.

Re: minibuffer-exit when emacsclient executes Lisp code

[Stefan Monnier]

> No, I would not expect that. The best one can hope for is that the question
> is not forgotten. Maybe there is somewhere to put a note about this, but
> I am not sure.

That's what etc/TODO is for.


        Stefan

Re: minibuffer-exit when emacsclient executes Lisp code

[Richard Stallman]

    > your patch works great. Thanks a lot. I'm afraid this patch will not make it
    > into the upcoming emacs 22 nor into trunk?

    No, I would not expect that.

Should we install the fix in the trunk?

Re: minibuffer-exit when emacsclient executes Lisp code

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     > your patch works great. Thanks a lot. I'm afraid this patch will not make it
>     > into the upcoming emacs 22 nor into trunk?
> 
>     No, I would not expect that.
> 
> Should we install the fix in the trunk?

The fix is not done in the best possible way. I wanted to show what 
could be done and also make something useful now.

But maybe it does not matter that it is not done in the best possible 
way since I think this will be rewritten later in the multi-tty job. The 
patch is reasonable and useful now IMO.

Re: minibuffer-exit when emacsclient executes Lisp code

[Stefan Monnier]

>> your patch works great. Thanks a lot. I'm afraid this patch will not make it
>> into the upcoming emacs 22 nor into trunk?

>     No, I would not expect that.

> Should we install the fix in the trunk?

I think the right solution will look different, and also the right solution
will depend on what the multi-tty's server.el does, so it's probably better
to fix it in the multi-tty branch than in the trunk, or else to wait until
the multi-tty branch is merged into the trunk.


        Stefan

Re: minibuffer-exit when emacsclient executes Lisp code

[Richard Stallman]

    I think the right solution will look different, and also the right solution
    will depend on what the multi-tty's server.el does, so it's probably better
    to fix it in the multi-tty branch than in the trunk, or else to wait until
    the multi-tty branch is merged into the trunk.

Would someone please fix it in the multi-tty branch?

Re: minibuffer-exit when emacsclient executes Lisp code

[karoly]

Juanma Barranquero wrote:
> Are you proposing throwing the trunk version and just replacing it
with the multi-tty one?

No, not at all.  I mean that if there is indeed a consensus that multi-tty will be merged soon, then perhaps emacsclient improvements should concentrate on the version on the branch.  The two versions are much different and conflicts are sometimes hard to resolve correctly, leading to lost fixes and new regressions.

If we're not yet sure multi-tty is acceptable, then please ignore my suggestion.  This is unclear to me.

-- 
Károly

Re: minibuffer-exit when emacsclient executes Lisp code

[Juanma Barranquero]

On 5/16/07, karoly@lorentey.hu <karoly@lorentey.hu> wrote:

> No, not at all.  I mean that if there is indeed a consensus that multi-tty will be merged soon

I thought there was sort of an agreement that the unicode-2 branch
would be merged and stabilized before multi-tty. Though the branch is,
AFAIK, in a really good shape, I wouldn't expect the process to be a
matter of days or even weeks (though, truth to be told, perhaps I'm
being a bit pessimistic).

> then perhaps emacsclient improvements should concentrate on the > version on the branch.

I don't agree. The burden of being mergeable without loss of
features/bugfixes should be on the multi-tty branch, not on the trunk.
Not that that means it's OK to make live difficult to the multi-tty
developers, of course.

             Juanma

Re: minibuffer-exit when emacsclient executes Lisp code

[Károly Lőrentey]

[-- Attachment #1.1: Type: text/plain, Size: 668 bytes --]

Juanma Barranquero wrote:
> I don't agree. The burden of being mergeable without loss of
> features/bugfixes should be on the multi-tty branch, not on the trunk.
> Not that that means it's OK to make live difficult to the multi-tty
> developers, of course.

That's exactly my point.  I want to make my burden a little lighter.
emacsclient.c and server.el was relatively stable on the trunk for
years, then a few months ago a number of new features have suddenly
started to appear.  That gave me a few headaches, and if possible I
would like to prevent a similar situation now that the branch is easily
accessible for all Emacs developers.

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: minibuffer-exit when emacsclient executes Lisp code

[Juanma Barranquero]

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

On 5/16/07, Károly Lőrentey <karoly@lorentey.hu> wrote:

> emacsclient.c and server.el was relatively stable on the trunk for
> years, then a few months ago a number of new features have suddenly
> started to appear.

You make it sound like that was bad :)

The truth is that emacsclient didn't grok TCP sockets, so it wouldn't
work on Windows, or from a remote machine. Eventually we got feed up
with having to recomend (one of several different and sometimes
conflicting implementations of) gnuclient/gnuserv.

> That gave me a few headaches, and if possible I
> would like to prevent a similar situation now that the branch is easily
> accessible for all Emacs developers.

It is not, for those of us working on Windows.

             Juanma

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: minibuffer-exit when emacsclient executes Lisp code

[Dan Nicolaescu]

"Juanma Barranquero" <lekktu@gmail.com> writes:

  > On 5/16/07, Károly Lőrentey <karoly@lorentey.hu> wrote:
  > 
  > > That gave me a few headaches, and if possible I
  > > would like to prevent a similar situation now that the branch is easily
  > > accessible for all Emacs developers.
  > 
  > It is not, for those of us working on Windows.

After the last checkin on the multi-tty branch emacs starts, and
emacsclient can connect to it. I haven't tested it too much, but it
seems to work OK (at least when compiled with mingw). Please check it
out and find any missing functionality.

emacsclient -t does not work, but that is not a regression. (It
probably needs a significant amount of new code to be made work).

emacs -nw seems to go into an infinite loop, help fixing that would be
appreciated. 

Re: minibuffer-exit when emacsclient executes Lisp code

[David Kastrup]

<karoly@lorentey.hu> writes:

> Juanma Barranquero wrote:
>> Are you proposing throwing the trunk version and just replacing it
>> with the multi-tty one?
>
> No, not at all.  I mean that if there is indeed a consensus that
> multi-tty will be merged soon,

Maybe my pushing for getting multi-tty into the Emacs repository
(which others have agreed to be a good idea) has left a wrong
impression.  This was not as much a consensus, I guess, that
"multi-tty will be merged soon" but that we _really_ should get a
handle on it.  This is happening right now.

Part of an evaluation is actually getting the stuff to compile (and
then work) again on other platforms (by the way, multi-tty HEAD
emacsclient does no longer compile at the moment on GNU/Linux/GTK
because of some seemingly half-finished changes in connection with
sockets).

In parallel with the basic work on other platforms, some people might
or might not be tempted to discuss the design and implications.  While
I am probably one of the more vocal people in that area, it does not
mean that others don't form an opinion.

> then perhaps emacsclient improvements should concentrate on the
> version on the branch.  The two versions are much different and
> conflicts are sometimes hard to resolve correctly, leading to lost
> fixes and new regressions.
>
> If we're not yet sure multi-tty is acceptable, then please ignore my
> suggestion.  This is unclear to me.

multi-tty capability will be in Emacs 23 if we can get it to form an
acceptable and stable part of Emacs.  The point where a merge into
trunk becomes feasible is when we have no major usability regression
on _all_ platforms _and_ people agree that the basic design is sound.
If there are still fundamental instead of incremental changes to be
expected, a branch is a better place than the trunk.

Since multi-tty is planned for Emacs 23, polishing the uni-tty
emacsclient appears like a waste of effort.  That does not mean that
polishing the multi-tty emacsclient would be much better as long as
the design is not cast into stone.

At the current point of time, I should be very much surprised if we
could arrive at the decision to merge multi-tty or even whether to aim
for a merge before something like a month is over.

Up to now, multi-tty has largely been a single-person project, with a
restricted number of testers on a restricted number of platforms and
uses.

So you have to expect some growth pains, and it would be audacious to
expect that this can happen without some fairly significant changes in
the branch.  And it is likely that once that I run out of yelling at
the design (I am working intermittently on another detailed mail) that
others will take up the buck.

At the current point of time, I don't see that we are going to see
this process finish at a point of time before unicode-2.  I have not
yet taken a look at unicode-2, however, and I seem to remember it also
has some Windows-specific issues remaining (somebody correct me if I
am wrong).

The metric for unicode-2 would be the same: a merge into trunk seems
reasonable as soon as no major functional regression can be expected
to occur on all supported platforms.

-- 
David Kastrup

Re: minibuffer-exit when emacsclient executes Lisp code

[Juanma Barranquero]

On 5/16/07, David Kastrup <dak@gnu.org> wrote:

> Since multi-tty is planned for Emacs 23, polishing the uni-tty
> emacsclient appears like a waste of effort.

Before believing that I'd like to know how the multi-tty features are
going to affect the current functionality. For example, does
implementing some variant of Lennart's much-wanted Emacs auto-start
make sense, or is that functionality subsumed somehow for the
multi-tty feature set?

             Juanma

Re: minibuffer-exit when emacsclient executes Lisp code

[Károly Lo"rentey]

[-- Attachment #1.1: Type: text/plain, Size: 2566 bytes --]

David Kastrup wrote:
> Maybe my pushing for getting multi-tty into the Emacs repository
> (which others have agreed to be a good idea) has left a wrong
> impression.  This was not as much a consensus, I guess, that
> "multi-tty will be merged soon" but that we _really_ should get a
> handle on it.  This is happening right now.

OK, so I misunderstood the posts about merge ordering and about whether
or not the trunk is open for them now.  No wonder I was surprised at the
speed of things.

This is excellent news.  I don't see a reason to hurry anything now.
However, my post about emacsclient changes still stands.  Simple
bugfixes are fine, but please at least let's try to keep new trunk
features at a minimum.

> In parallel with the basic work on other platforms, some people might
> or might not be tempted to discuss the design and implications.  While
> I am probably one of the more vocal people in that area, it does not
> mean that others don't form an opinion.

I am very much open and eager to discuss design issues with you and
everyone else.

> At the current point of time, I should be very much surprised if we
> could arrive at the decision to merge multi-tty or even whether to aim
> for a merge before something like a month is over.

That's welcome news for me.

> Up to now, multi-tty has largely been a single-person project, with a
> restricted number of testers on a restricted number of platforms and
> uses.
> 
> So you have to expect some growth pains, and it would be audacious to
> expect that this can happen without some fairly significant changes in
> the branch.

If at least the basic infrastructure of multi-tty (the introduction of
struct terminal on the C-level) gets onto the trunk at some future merge
without an extensive reimplementation, then I'll be already satisfied.

So, uhm, can we also concentrate a little on the core changes in
src/*.[ch]?  I got very little feedback for those since Richard reviewed
an early revision a few years ago.  If the core of the cake is rotten,
then we should stop eating it -- there is little point wasting time
scraping off the tasteless parts of the icing first.

Of course, I'm also looking forward to defend every single line of Lisp
code (except perhaps the indefensibly disgusting parts) :-), but those
are easier to replace or rip out than the C groundwork.

> At the current point of time, I don't see that we are going to see
> this process finish at a point of time before unicode-2.

That is fine.

-- 
Karoly



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: minibuffer-exit when emacsclient executes Lisp code

[Kenichi Handa]

In article <86d510rfuj.fsf@lola.quinscape.zz>, David Kastrup <dak@gnu.org> writes:

> The metric for unicode-2 would be the same: a merge into trunk seems
> reasonable as soon as no major functional regression can be expected
> to occur on all supported platforms.

I don't know any such regression.  I know that the new
font-backend feature is not yet available on Windows and
Mac, but that is not a problem for merging.  And, for Mac, I
remeber someone was working on font-backend.  How is the
state of that?

---
Kenichi Handa
handa@m17n.org