Re: minibuffer-exit when emacsclient executes Lisp code

[rentey <address@hidden>]

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

signature.asc
Description: OpenPGP digital signature