>> martin rudalics <rudalics@gmx.at>
  >> on Tue, 25 Dec 2012 19:09:38 +0100 wrote:

  >> Here is a patch of the comint-postoutput-scroll-to-bottom to circumvent
  >> resetting the point on select-window.

  > I'm too silly to understand what this is supposed to do.  But the
  > doc-string of `comint-adjust-point' says "Move point in the selected
  > window based on Comint settings." which, together with the fact that you
  > call this in a loop over all windows showing some buffer, indicates to
  > use `set-window-point' rather than `goto-char'.  

It is indeed tricky, I also was bothered by goto-char intricacy, but
decided not to intrude too much.

  > So why can't you write something like

  > (dolist (w (get-buffer-window-list current nil t))
  >   (when (and (< (window-point) (process-mark process))
  > 	     ...)
  >     (set-window-point w ...)))

  > here?

Because of the recentering in this piece: 

╭──────── #2132 ─ /home/vitoshka/TVC/emacs/lisp/comint.el ──
│ 		    (and comint-scroll-show-maximum-output
│ 			 (eobp)
│ 			 (recenter (- -1 scroll-margin))))
╰──────── #2134 ─


And this code:

╭──────── #2140 ─ /home/vitoshka/TVC/emacs/lisp/comint.el ──
│     (and (< (point) (process-mark process))
╰──────── #2140 ─

which implicitly relies on previous reseting of point by select-window.

And this:

╭──────── #2144 ─ /home/vitoshka/TVC/emacs/lisp/comint.el ──
│ 		 (if (eq (selected-window) selected) 'this 'others))
╰──────── #2144 ─

which compares current window with the original one. 


Because of this "implicitness" this piece of code is very tricky. I have
cleaned it up. Note that the internal function comint-adjust-point is no
longer used anywhere in emacs. I left it in the code for backward
compatibility. I think it is quite safe to remove it completely. It is
very unlikely that it has been used outside of this specific context.

    Vitalie