New hook for ERC

New hook for ERC

[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.

I need point to be in the input area (after erc-input-marker) when the 
hook is executed to properly recenter the window.  I can't seem to find 
a hook for when that happens, so I made a new one and run that hook as 
the last thing that happens in the buffer in erc-display-line-1:

...snip...
	(erc-update-undo-list (- (or (marker-position erc-insert-marker)
				     (point-max))
				 insert-position)))
       (run-hooks 'erc-display-post-hook)))) ;; as such!

Then I add my own function to erc-display-post-hook as such:

(defun damd-erc-display-post-hook ()
   (let ((windows (get-buffer-window-list (current-buffer) nil 'visible)))
     (dolist (w windows)
       (when (>= (point) erc-input-marker)
         (with-selected-window w
           (recenter -1))))))
(add-hook 'erc-display-post-hook 'damd-erc-display-post-hook)

Is there any way to do this without introducing yet another hook like I 
just did?  If not, can I add the hook to trunk?

Deniz

Re: New hook for ERC

[Antoine Levitt]

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'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.)

Re: New hook for ERC

[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.

> (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!

Re: New hook for ERC

[Johan Bockgård]

Deniz Dogan <deniz@dogan.se> writes:

> 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.
>
> I need point to be in the input area (after erc-input-marker) when the
> hook is executed to properly recenter the window.  I can't seem to
> find a hook for when that happens, so I made a new one and run that
> hook as the last thing that happens in the buffer in
> erc-display-line-1:

I use a hook in exactly this place in my copy of ERC, though I named it
`erc-insert-completed-hook' (cf. erc-send-{post,completed}-hook).

Re: New hook for ERC

[Deniz Dogan]

On 2012-02-09 00:53, Johan Bockgård wrote:
> Deniz Dogan<deniz@dogan.se>  writes:
>
>> 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.
>>
>> I need point to be in the input area (after erc-input-marker) when the
>> hook is executed to properly recenter the window.  I can't seem to
>> find a hook for when that happens, so I made a new one and run that
>> hook as the last thing that happens in the buffer in
>> erc-display-line-1:
>
> I use a hook in exactly this place in my copy of ERC, though I named it
> `erc-insert-completed-hook' (cf. erc-send-{post,completed}-hook).
>

Do you use it for the same thing or is your use-case different?

Emacs scrolling past the end of buffer (was: New hook for ERC)

[Antoine Levitt]

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.

>
>> (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!

What do the emacs experts think about this? Is it doable?

Re: Emacs scrolling past the end of buffer

[Deniz Dogan]

Antoine Levitt skrev 2012-02-09 11:06:
> 09/02/12 00:32, Deniz Dogan
>> 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.
>

Fair enough!  This makes me wonder, though, whether there is any other 
useful hook we can use in combination with my suggestion, to properly 
recenter whenever point goes outside of the currently viewed part of the 
buffer.

Re: New hook for ERC

[Lars Ingebrigtsen]

Deniz Dogan <deniz@dogan.se> writes:

>> (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!

The horror.  You both want `C-v' (and friends) to make no guarantee
where the next line you're supposed to read is?  That's as broken as
Firefox is.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New hook for ERC

[Antoine Levitt]

09/02/12 22:29, Lars Ingebrigtsen
> Deniz Dogan <deniz@dogan.se> writes:
>
>>> (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!
>
> The horror.  You both want `C-v' (and friends) to make no guarantee
> where the next line you're supposed to read is?  That's as broken as
> Firefox is.

Yes. It definitely makes more sense in several modes (erc, everything
comint), and I'd rather have it as well in the editing modes.

Re: Emacs scrolling past the end of buffer

[Deniz Dogan]

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.

Re: Emacs scrolling past the end of buffer

[Eli Zaretskii]

> Date: Sun, 12 Feb 2012 17:37:08 +0100
> From: Deniz Dogan <deniz@dogan.se>
> 
> > 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'?

Please make sure that no code that runs off `window-scroll-functions'
tries to affect the display.  Functions run by that hook should treat
the display as "read-only".

Re: Emacs scrolling past the end of buffer

[Deniz Dogan]

On 2012-02-12 17:45, Eli Zaretskii wrote:
>> Date: Sun, 12 Feb 2012 17:37:08 +0100
>> From: Deniz Dogan<deniz@dogan.se>
>>
>>> 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'?
>
> Please make sure that no code that runs off `window-scroll-functions'
> tries to affect the display.  Functions run by that hook should treat
> the display as "read-only".

Yeah, I noticed the warning in the manual and function docstring, but 
there was no explanation as to why.  Is this to avoid recursive 
execution of the hooks?

Re: Emacs scrolling past the end of buffer

[Eli Zaretskii]

> Date: Sun, 12 Feb 2012 20:52:41 +0100
> From: Deniz Dogan <deniz@dogan.se>
> CC: emacs-devel@gnu.org
> 
> > Please make sure that no code that runs off `window-scroll-functions'
> > tries to affect the display.  Functions run by that hook should treat
> > the display as "read-only".
> 
> Yeah, I noticed the warning in the manual and function docstring, but 
> there was no explanation as to why.  Is this to avoid recursive 
> execution of the hooks?

Mostly to uphold the assumptions which the code that runs
`window-scroll-functions' relies on: that the visible portion of the
window does not change across this call.