From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Sean McAfee Newsgroups: gmane.emacs.bugs Subject: bug#35334: 26.2; Changes to position of point are undone during with-current-buffer if window is visible but not current Date: Sun, 21 Apr 2019 16:32:48 -0700 Message-ID: References: <8736mduxjh.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b5ee9c058712c5bb" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="189118"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35334@debbugs.gnu.org To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 22 01:34:17 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hILyT-000n4R-Ci for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Apr 2019 01:34:17 +0200 Original-Received: from localhost ([127.0.0.1]:58212 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hILyS-0005EL-AX for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Apr 2019 19:34:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hILyG-0005E4-6A for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2019 19:34:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hILyE-00078u-SA for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2019 19:34:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35791) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hILyE-00078h-ON for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2019 19:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hILyE-0002Ud-F8 for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2019 19:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Sean McAfee Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Apr 2019 23:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35334 X-GNU-PR-Package: emacs Original-Received: via spool by 35334-submit@debbugs.gnu.org id=B35334.15558895889524 (code B ref 35334); Sun, 21 Apr 2019 23:34:02 +0000 Original-Received: (at 35334) by debbugs.gnu.org; 21 Apr 2019 23:33:08 +0000 Original-Received: from localhost ([127.0.0.1]:49335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hILxL-0002TX-NV for submit@debbugs.gnu.org; Sun, 21 Apr 2019 19:33:08 -0400 Original-Received: from mail-wr1-f53.google.com ([209.85.221.53]:37378) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hILxJ-0002T3-Ln for 35334@debbugs.gnu.org; Sun, 21 Apr 2019 19:33:06 -0400 Original-Received: by mail-wr1-f53.google.com with SMTP id t17so2219838wrr.4 for <35334@debbugs.gnu.org>; Sun, 21 Apr 2019 16:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y/D6tOJWW90Zl5QbHY6ea/x76dmFdpR4YNYrAotVhNI=; b=Gqek4h5M3dgrT4P5mRp0HaTkCde/Bq/1kzUMCizvRj9UCrAIjgsMJC7f13XHf4UCDF kLvheoJdqEp/areyvFd9dsn4QGbzNhF1eB4qJnZ53u6oD3N8o/2YKjuZXjnZa+5yQJQE Yl8bki0rWCme7NFWVyODj2igEl+L/hv3Ywot0rWp4YGyTHhP3VpI7jBrGAzhG85gWUar NBe+NL0Sg8HP3TFvtlM6IH/ko5GH4AoZ+QXxIdoaPenAojidzVjYTqmtdGYW1ih1jwrj F4feLQhIHecp+5Jr397D4NSxyH24O/shm9a0B3uo2/YcTZmNsbBweUl5Yk1HhVYt6AP6 ceUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y/D6tOJWW90Zl5QbHY6ea/x76dmFdpR4YNYrAotVhNI=; b=ooMQBOGJWcbKTaA9VXEjfwO34+KrQuCFo1xGzvJ38uVoy/UH/L2c1TcRwL8oIB6DYO ifQ9c8PeQ0KPumPH2ogb89kWKs8NKoYp1sGUpq/9aBxFP849TtLo/C4o2UAKIq2YRmjv upzZjKeE5pdvQDRqYtvPLqxg1YjQQXqDJhuhi93TVVNkz4a+wEXlUD/Vb6V2b+pBPggV FGRwS0mc7weMMWTbwg6hgtrwLWzyKQmo4nKkvq2+Z0uY6+rngxwMuZb0tenUSOEgtbej z4vECL6h0UgolvxKBUFRuu1kGDjL2nbiPPgF0v+vtUQW5t8KE8HNWzi0WwERp/vPBMjy vCFQ== X-Gm-Message-State: APjAAAX1FBqg64RlCUePprmDlptvQJNnLnVgCGaQ8LYottNFWAqDY5lY zng1dSyaOnqmTD9kp++NAbTeE8RJ9Nd+ws59/QY= X-Google-Smtp-Source: APXvYqxqD7ZjByDtaEb8/Zcz1UjArzb4dsKrDabal0bAQkRNLJEvQ2P0BUBIwx0zSvjde8mZjGQBcPpSQoFfN8ShEZI= X-Received: by 2002:a5d:488d:: with SMTP id g13mr11041485wrq.119.1555889579747; Sun, 21 Apr 2019 16:32:59 -0700 (PDT) In-Reply-To: <8736mduxjh.fsf@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:157974 Archived-At: --000000000000b5ee9c058712c5bb Content-Type: text/plain; charset="UTF-8" On Fri, Apr 19, 2019 at 9:10 PM Noam Postavsky wrote: > Sean McAfee writes: > > I would expect point to move to position 8 in both cases, and I don't > > see anything in the documentation for with-current-buffer or goto-char > > to suggest that it ever wouldn't. > > How about in (elisp) Window Point? > > * Selecting a window sets the value of point in its buffer from the > window's value of point. Conversely, deselecting a window sets the > window's value of point from that of the buffer. > Okay, I wasn't fully aware of these window-point semantics. I'll take a step back and describe my actual problem, of which the bug I thought I was reporting was the simplest case I could reduce it to. Starting with two windows visible, the scratch buffer and a window showing empty buffer "a", I evaluate this expression in the scratch buffer: (start-process "count" "a" "bash" "-c" "for i in {1..10}; echo $i; sleep 1; done") I see the numbers 1-10 inserted into buffer "a", one second apart, as expected. The position of point in buffer "a" follows the new lines as they're inserted. Now I define the function ordinary-insertion-filter, as found on this page: https://www.gnu.org/software/emacs/manual/html_node/elisp/Filter-Functions.html That function is described as "mimicking the actions of the default filter." However, if I erase buffer "a" and evaluate this expression in the scratch buffer: (let ((proc (start-process "count" "a" "bash" "-c" "for i in {1..10}; echo $i; sleep 1; done"))) (set-process-filter proc #'ordinary-insertion-filter)) ...then I see the numbers inserted as before, but now the position of point in buffer "a" doesn't move; it stays at the beginning of the buffer. If I select the window showing buffer "a" as the numbers are still being inserted and move point to the end of the buffer, then point starts following the new numbers. But if I select the scratch buffer again, point in buffer "a" stops following the new numbers. Is this the expected behavior? --000000000000b5ee9c058712c5bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Apr 19, 2019 at 9:10 PM Noam Post= avsky <npostavs@gmail.com> = wrote:
Sean McAfee <eefacm@gmail.com> writes:
> I would expect point to move to position 8 in both cases, and I don= 9;t
> see anything in the documentation for with-current-buffer or goto-char=
> to suggest that it ever wouldn't.

How about in (elisp) Window Point?

=C2=A0 =C2=A0* Selecting a window sets the value of point in its buffer fro= m the
=C2=A0 =C2=A0 =C2=A0window's value of point.=C2=A0 Conversely, deselect= ing a window sets the
=C2=A0 =C2=A0 =C2=A0window's value of point from that of the buffer.

Okay, I wasn't fully aware of these w= indow-point semantics.=C2=A0 I'll take a step back and describe my actu= al problem, of which the bug I thought I was reporting was the simplest cas= e I could reduce it to.

Starting with two windows = visible, the scratch buffer and a window showing empty buffer "a"= , I evaluate this expression in the scratch buffer:

(start-process "count" "a" "bash" "-c&= quot; "for i in {1..10}; echo $i; sleep 1; done")

<= /div>
I see the numbers 1-10 inserted into buffer "a", one se= cond apart, as expected.=C2=A0 The position of point in buffer "a"= ; follows the new lines as they're inserted.

N= ow I define the function ordinary-insertion-filter, as found on this page:<= /div>


That function is described as "mimicking the actions of the default f= ilter."=C2=A0 However, if I erase buffer "a" and evaluate th= is expression in the scratch buffer:

(let ((proc (= start-process "count" "a" "bash" "-c&quo= t; "for i in {1..10}; echo $i; sleep 1; done")))
=C2=A0= (set-process-filter proc #'ordinary-insertion-filter))

<= /div>
...then I see the numbers inserted as before, but now the positio= n of point in buffer "a" doesn't move; it stays at the beginn= ing of the buffer.=C2=A0 If I select the window showing buffer "a"= ; as the numbers are still being inserted and move point to the end of the = buffer, then point starts following the new numbers.=C2=A0 But if I select = the scratch buffer again, point in buffer "a" stops following the= new numbers.

Is this the expected behavior?
=

--000000000000b5ee9c058712c5bb--