From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.bugs Subject: bug#20921: 25.0.50; `tabulated-list-print' bad logic Date: Mon, 29 Jun 2015 01:18:18 +0100 Message-ID: References: <9afed6b3-9f3a-40d3-8569-d9d951bdb417@default> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c35152d9ac9505199d06cf X-Trace: ger.gmane.org 1435537159 20901 80.91.229.3 (29 Jun 2015 00:19:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Jun 2015 00:19:19 +0000 (UTC) Cc: 20921@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 29 02:19:10 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z9Mn0-0002wh-2D for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Jun 2015 02:19:10 +0200 Original-Received: from localhost ([::1]:40155 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9Mmz-0005C6-Ck for geb-bug-gnu-emacs@m.gmane.org; Sun, 28 Jun 2015 20:19:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43116) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9Mmv-0005C1-TQ for bug-gnu-emacs@gnu.org; Sun, 28 Jun 2015 20:19:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9Mms-0004Hl-MT for bug-gnu-emacs@gnu.org; Sun, 28 Jun 2015 20:19:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9Mms-0004H6-HH for bug-gnu-emacs@gnu.org; Sun, 28 Jun 2015 20:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z9Mms-0000BY-23 for bug-gnu-emacs@gnu.org; Sun, 28 Jun 2015 20:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Artur Malabarba Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Jun 2015 00:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20921 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20921-submit@debbugs.gnu.org id=B20921.1435537109644 (code B ref 20921); Mon, 29 Jun 2015 00:19:01 +0000 Original-Received: (at 20921) by debbugs.gnu.org; 29 Jun 2015 00:18:29 +0000 Original-Received: from localhost ([127.0.0.1]:60657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z9MmK-0000AJ-KJ for submit@debbugs.gnu.org; Sun, 28 Jun 2015 20:18:29 -0400 Original-Received: from mail-la0-f51.google.com ([209.85.215.51]:34261) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z9MmH-00009u-1G for 20921@debbugs.gnu.org; Sun, 28 Jun 2015 20:18:26 -0400 Original-Received: by lagx9 with SMTP id x9so106995604lag.1 for <20921@debbugs.gnu.org>; Sun, 28 Jun 2015 17:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EwyFSUpabnhNbOfrJDVryvBkSoJczlqk/KNfGqyNk8M=; b=ViDkZwXoo5nMaFKtY39f186ae1OwJLEoS0aW51jhKwLZIwuYbgKLfZjWDni3LZzzFU FbN5myZOj66/Xgc5O5cQbF+5LVV9jtL7Bgorc0i8UAeL0nmTUrAMZ6+iLTbBqZCb8xmj 0FbtvmcdbSF87AMTWg8gQXUWfMun2RdBw8En68+CKluKRMexgTvPKyW02bdz4eMX2knq ZQp9sxUKzdiYEqxCWaDScGuOEUpx1dwcW/JDGqX4MYocIAogu4Gf7ZuJOoOploOHkRRb E9UhVBDoQxlCMiBAMkcLC4woGEJ5tVQYzXAboY3KBld7RiO/tu1IEQ1p0O2acvnHq6GT u4+A== X-Received: by 10.152.43.110 with SMTP id v14mr11617710lal.4.1435537099040; Sun, 28 Jun 2015 17:18:19 -0700 (PDT) Original-Received: by 10.25.214.133 with HTTP; Sun, 28 Jun 2015 17:18:18 -0700 (PDT) Original-Received: by 10.25.214.133 with HTTP; Sun, 28 Jun 2015 17:18:18 -0700 (PDT) In-Reply-To: <9afed6b3-9f3a-40d3-8569-d9d951bdb417@default> X-Google-Sender-Auth: _wHvzn5kEp1bSTifNriS5wD90gA X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:104453 Archived-At: --001a11c35152d9ac9505199d06cf Content-Type: text/plain; charset=UTF-8 On Jun 28, 2015 9:46 PM, "Drew Adams" wrote: > > This new code seems quite wrong to me: > > (and remember-pos > (when (eq (window-buffer) (current-buffer)) > (setq window-line (count-screen-lines (window-start) (point)))) > (setq entry-id (tabulated-list-get-id)) > (setq saved-col (current-column))) > So that test fails, and none of the variables get assigned > values. This makes no sense to me. Yes, that's wrong. The window logic should come last, so as to not prevent the other variables. > When code calls `tabulated-list-print', the current buffer must pretty > much always be the buffer that will get the tabulated list. Why the > comparison with `window-buffer', which could be anything and which in > most cases will *not* be the tabulated-list buffer? > > This new code looks like it might be a misguided hack to try to deal > with the new parameter UPDATE. Not ready for prime time, I think. No. IIRC, it was necessary because of async refreshing in package.el. It makes no sense to store the screen line if current window is not displaying that buffer. As I said above, blocking the other two variables was unintentional. I can do that tomorrow if nobody beats me to it. --001a11c35152d9ac9505199d06cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 28, 2015 9:46 PM, "Drew Adams" <drew.adams@oracle.com> wrote:
>
> This new code seems quite wrong to me:
>
> (and remember-pos
> =C2=A0 =C2=A0 =C2=A0(when (eq (window-buffer) (current-buffer))
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(setq window-line (count-screen-lines (wind= ow-start) (point))))
> =C2=A0 =C2=A0 =C2=A0(setq entry-id (tabulated-list-get-id))
> =C2=A0 =C2=A0 =C2=A0(setq saved-col (current-column)))
> So that test fails, and none of the variables get assigned
> values.=C2=A0 This makes no sense to me.

Yes, that's wrong. The window logic should come last, so= as to not prevent the other variables.

> When code calls `tabulated-list-print', the current= buffer must pretty
> much always be the buffer that will get the tabulated list.=C2=A0 Why = the
> comparison with `window-buffer', which could be anything and which= in
> most cases will *not* be the tabulated-list buffer?
>
> This new code looks like it might be a misguided hack to try to deal > with the new parameter UPDATE.=C2=A0 Not ready for prime time, I think= .

No.
IIRC, it was necessary because of async refreshing in package.el. It makes = no sense to store the screen line if current window is not displaying that = buffer.
As I said above, blocking the other two variables was unintentional.

I can do that tomorrow if nobody beats me to it.

--001a11c35152d9ac9505199d06cf--