[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6535: 24.0.50; grep seems not to work

From: Jan Djärv
Subject: bug#6535: 24.0.50; grep seems not to work
Date: Wed, 30 Jun 2010 13:47:03 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv: Gecko/20100608 Thunderbird/3.1

Štěpán Němec skrev 2010-06-29 20.27:
Jan Djärv<address@hidden>  writes:

Štěpán Němec skrev 2010-06-29 13.14:

Nothing suggests anyone is working on fixing the problem. If you have a
fix, why don't you commit it?

I don't have a recepie for repeating the problem turning off ICANON would
solve.  It isn't a high priority for me.

I wonder what makes you assume somebody is working on it then.

I did some tests when this come up. Basically I adopted xterm:s approach with buffering. But this makes send_process asynchronous when the subprocess isn't reading. It may be a too big of a change. Besides, with the current send_process implementation, it does seem to do the right thing, so asynchronous send is perhaps not needed. As I said, I haven't been able to trigger any problem with it, RAW or ICANON. The only problem is if the subprocess doesn't read, Emacs hangs forever.

The code and the documentation is not in sync w.r.t. EOF either.

If you don't have a fix *now*, why is the
breakage not reverted for the time being? I didn't even get any reaction
on this question.

That you must ask the person who made that checkin.

...which I did. I posted the URL in this thread already.

He may not read this thread.

I don't expect the trunk to be perfectly usable all the time, but I fail
to see any value in leaving a known and repeatedly reported breakage in
for an extended period of time.

The breakage must have fixed some other problem.  If breakage one is better
than breakage two is a matter of opinion, depending which one you see the
most.  AFAIK, I haven't seen either.

I can't make much sense of Stefan's commit message. It also doesn't
mention any related bug it would be supposed to fix.

The code mentions the same problem to the current one (EOF showing up as ^D) because the terminal is in raw mode. The scenario is that Emacs puts the terminal in icanon mode and then the subprocess puts it in raw, ^D will be seen by the subprocess because Emacs sends EOF as a means to flush output.

But AFAIK, Emacs doesn't send EOF to flush output anymore.

So I wont put in my stuff until Stefan has commented on his. I don't think this is a pressing matter, this is the trunk after all, and people have other things to do. It must be resolved before next release though.

        Jan D.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]