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: Emacs scrolling past the end of buffer Date: Sun, 12 Feb 2012 17:37:08 +0100 Message-ID: <4F37EAB4.7050809@dogan.se> References: <4F32E763.1060104@dogan.se> <877gzxufq3.fsf@gmail.com> <4F330620.7060201@dogan.se> <87wr7we2xp.fsf_-_@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1329064660 11726 80.91.229.3 (12 Feb 2012 16:37:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 12 Feb 2012 16:37:40 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 12 17:37:38 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 1RwcQk-0002pV-Ev for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2012 17:37:38 +0100 Original-Received: from localhost ([::1]:43282 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RwcQj-0004Qc-U1 for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2012 11:37:37 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:59914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RwcQf-0004QS-N6 for emacs-devel@gnu.org; Sun, 12 Feb 2012 11:37:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RwcQd-0004JG-OM for emacs-devel@gnu.org; Sun, 12 Feb 2012 11:37:33 -0500 Original-Received: from ch-smtp05.sth.basefarm.net ([80.76.153.6]:53062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RwcQd-0004Iw-FQ for emacs-devel@gnu.org; Sun, 12 Feb 2012 11:37:31 -0500 Original-Received: from c80-216-107-103.bredband.comhem.se ([80.216.107.103]:65380 helo=[192.168.0.10]) by ch-smtp05.sth.basefarm.net with esmtp (Exim 4.76) (envelope-from ) id 1RwcQL-0007gb-G8 for emacs-devel@gnu.org; Sun, 12 Feb 2012 17:37:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 In-Reply-To: <87wr7we2xp.fsf_-_@gmail.com> X-Originating-IP: 80.216.107.103 X-Scan-Result: No virus found in message 1RwcQL-0007gb-G8. X-Scan-Signature: ch-smtp05.sth.basefarm.net 1RwcQL-0007gb-G8 e3e8b6997fd8e417b8d249c782eb3732 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:148507 Archived-At: On 2012-02-09 11:06, Antoine Levitt wrote: > 09/02/12 00:32, Deniz Dogan >> 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. > > But then it sometimes happen that you see past the end of the buffer > when scrolling (the horror!). I'd rather have excessive CPU consumption. > What if we combine this with a function in `window-scroll-functions'? I haven't thought it through completely, but my gut feeling says it should be possible.