From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Deniz Dogan Newsgroups: gmane.emacs.devel Subject: Re: New hook for ERC Date: Thu, 09 Feb 2012 00:32:48 +0100 Message-ID: <4F330620.7060201@dogan.se> References: <4F32E763.1060104@dogan.se> <877gzxufq3.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1328743997 11484 80.91.229.3 (8 Feb 2012 23:33:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Feb 2012 23:33:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 09 00:33:16 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RvH0k-0006AQ-44 for ged-emacs-devel@m.gmane.org; Thu, 09 Feb 2012 00:33:14 +0100 Original-Received: from localhost ([::1]:39723 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvH0j-0007zB-JI for ged-emacs-devel@m.gmane.org; Wed, 08 Feb 2012 18:33:13 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:53846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvH0f-0007z3-PQ for emacs-devel@gnu.org; Wed, 08 Feb 2012 18:33:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvH0e-000303-Cz for emacs-devel@gnu.org; Wed, 08 Feb 2012 18:33:09 -0500 Original-Received: from ch-smtp05.sth.basefarm.net ([80.76.153.6]:47683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvH0e-0002zQ-3z for emacs-devel@gnu.org; Wed, 08 Feb 2012 18:33:08 -0500 Original-Received: from c80-216-107-103.bredband.comhem.se ([80.216.107.103]:51550 helo=[192.168.0.10]) by ch-smtp05.sth.basefarm.net with esmtp (Exim 4.76) (envelope-from ) id 1RvH0R-0004nK-GY for emacs-devel@gnu.org; Thu, 09 Feb 2012 00:32:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 In-Reply-To: <877gzxufq3.fsf@gmail.com> X-Originating-IP: 80.216.107.103 X-Scan-Result: No virus found in message 1RvH0R-0004nK-GY. X-Scan-Signature: ch-smtp05.sth.basefarm.net 1RvH0R-0004nK-GY ad9824fccc009b8dca57eb27730a67e2 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.76.153.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:148382 Archived-At: On 2012-02-08 23:23, Antoine Levitt wrote: > 08/02/12 22:21, Deniz Dogan >> Hi, >> >> I've been trying to "fix" the behavior of ERC's scroll-to-bottom >> module by hooking into erc-insert-post-hook. I thought that the state >> when that hook is executed would be that point is back in the input >> area, but it does not seem like it. > > Hi, > > What's your plan for scroll-to-bottom in ERC? Why do you need this hook > in addition to the existing one? scroll-to-bottom in its current state > is clearly suboptimal, and it has a pretty excessive CPU consumption > when repeating characters. > I don't really have a fully thought-out plan yet, but I believe the new hook is necessary, because the other hooks are run when the point has moved away from its original position. At least I couldn't figure out how to write code that worked with those hooks. Having looked at the code for scroll-to-bottom just now, I see that it uses post-command-hook, which is obviously not an acceptable solution for the reason that you mention. A good compromise, in my opinion, would be to basically _not_ "scroll to bottom" on every single character insertion. With the addition of the post-display hook, when the user hits RET, the message will be sent, ERC will display that message, the new hook will run, and it will be recentered to the bottom again. This method is something I've personally used in rcirc for quite some time and I'm very happy with it. > (I've also been looking for an emacs-wide replacement, without much > success. This would be something that says : emacs is not allowed to > display anything past the end of a buffer, period - except when the > buffer is not long enough. Just like every other software does. This is > one of the things that bother me the most about emacs.) > I agree with you very much on this point!