From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chad Brown Newsgroups: gmane.emacs.devel Subject: Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch Date: Tue, 24 May 2016 18:22:33 -0700 Message-ID: References: <83oa7x5wpc.fsf@gnu.org> <83k2ik68h2.fsf@gnu.org> <83bn3w675o.fsf@gnu.org> <834m9o659c.fsf@gnu.org> <83fut74fbu.fsf@gnu.org> <83bn3v4bcj.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_189C7E3A-A013-40A4-BCC9-8C2DF3CAB705" X-Trace: ger.gmane.org 1464140052 31631 80.91.229.3 (25 May 2016 01:34:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 May 2016 01:34:12 +0000 (UTC) Cc: emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 25 03:34:05 2016 Return-path: Envelope-to: ged-emacs-devel@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 1b5Ni0-0006W5-Py for ged-emacs-devel@m.gmane.org; Wed, 25 May 2016 03:34:05 +0200 Original-Received: from localhost ([::1]:56625 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5Ni0-0001Hv-24 for ged-emacs-devel@m.gmane.org; Tue, 24 May 2016 21:34:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5NX4-0000ng-3N for emacs-devel@gnu.org; Tue, 24 May 2016 21:22:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b5NX1-0001JY-Qc for emacs-devel@gnu.org; Tue, 24 May 2016 21:22:45 -0400 Original-Received: from mail-pa0-x229.google.com ([2607:f8b0:400e:c03::229]:34629) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5NWv-0001Ho-QD; Tue, 24 May 2016 21:22:38 -0400 Original-Received: by mail-pa0-x229.google.com with SMTP id qo8so12029927pab.1; Tue, 24 May 2016 18:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=rAdn7GX9lzny4IinHO05FqI5g8PToRI8v5qiqgFXDSo=; b=QBuH+rAYtuuk/nDC82GgwIH7RO+K1k2hx3+thPXL6H+lRBUzqI5E1WmaBXiXYjgOOz CF019d6Qpg4VSyucWSqKEmANte6NV5M+ob1WGXti4GLlJJc976rVTbnC6JdIQ4rw6Jqm J5fVyXT3nX3WAwGN35As/SW0uLFefvChPoHVlNv19+QTqQIe1RlRrZpHb3i9xQnl3srO XOPvWiqi+0XrmiHbIcD9dikv4d+xoZsmL+1zkZksylfuNzWsAwt9HkFcz4IfaP2PIJJm ckvUbKLv9bSPiDOe1NxkqhcA4f8zXDxvYXBInjmh0jeA58O7e3EMpuv1Csoy8gEbzWYT SB8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=rAdn7GX9lzny4IinHO05FqI5g8PToRI8v5qiqgFXDSo=; b=jOQV054NuubKgGVmq783pZo8js7JjkCmrMkKo62+M+vl53wBFuPv9AtHj+BsgXBTdt z2U/mku3yCBsIuYziY8W97E8HbqBDccyX5nDXcl4RwQttVUfCwATLwB/QeLic34hkoNZ oFfnZHWP3YH3/TgC2yH59QGsA4PENvPF8FBtJ0IiMWKc1ymqLtOgnwTNSwRzAV+jw1sJ 7gakgjzMnXf60Knj74TDTJyyedoIIHveudlT4l5biCHnE9FSY1Wrs7VsHRlPzj0B5bTJ KxKDHtSwx1NsAtrQzwvmEo+JSRKCgDMpcybUYIL6szJF+3KowO8XTjFdTegNWfaEA2bS xbLg== X-Gm-Message-State: ALyK8tKKekYoQ9mxI3CtyNT26GK6ZAI5QelG8Ue5dktnmlKisPMiTOyHYMS+5DKnp1VIYw== X-Received: by 10.66.148.42 with SMTP id tp10mr1714084pab.159.1464139356488; Tue, 24 May 2016 18:22:36 -0700 (PDT) Original-Received: from [192.168.1.18] (c-73-97-209-57.hsd1.wa.comcast.net. [73.97.209.57]) by smtp.gmail.com with ESMTPSA id k69sm22169910pfc.41.2016.05.24.18.22.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 May 2016 18:22:34 -0700 (PDT) In-Reply-To: <83bn3v4bcj.fsf@gnu.org> X-Mailer: Apple Mail (2.3124) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400e:c03::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:203991 Archived-At: --Apple-Mail=_189C7E3A-A013-40A4-BCC9-8C2DF3CAB705 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 24 May 2016, at 10:25, Eli Zaretskii wrote: >=20 >> From: Paul Eggert >> Date: Tue, 24 May 2016 09:47:35 -0700 >> Cc: rgm@gnu.org, emacs-devel@gnu.org >>=20 >> On 05/24/2016 08:59 AM, Eli Zaretskii wrote: >>> I have hard time believing this is a browser issue >>=20 >> I don't. There are different kinds of refreshes, and it's possible = that=20 >> a partial refresh won't give you a new page at the same time that a = full=20 >> refresh would. >=20 > That makes no sense at all. It's the same browser and the same Web > page. How can the browser know to refresh it in one case, but not in > the other? Because the refresh button doesn=E2=80=99t ask the web server for a new = copy of the page; it instead asks the local cache to check and see if it = thinks a new copy of the web page is needed. There are many = circumstances where the local cache controller can ask the web server = and get back what is effectively the wrong answer. C-F5 is a standard = command that tells the web browser to have the local cache get a new = copy of the page, without asking the web server if it can use the cached = copy instead. In practice, this sort of thing happens in certain corners = often enough that many people have developed the habit of always using = the reload-dammit command when they=E2=80=99re sure they want a fresh = page (see Kaushal Modi=E2=80=99s message, for example). Debbugs could be changed to always give out a new copy of the page, with = the concomitant increase in load you might expect from always bypassing = the cache. It could presumably be changed to never give out the wrong = answer, but (if this is what is happening in this case =E2=80=94 it=E2=80=99= s hard to tell without someone trying) that depends on specific effort = being put into debbugs. I hope that helps. ~Chad --Apple-Mail=_189C7E3A-A013-40A4-BCC9-8C2DF3CAB705 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 24 May 2016, at 10:25, Eli Zaretskii <eliz@gnu.org> = wrote:

From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 24 May = 2016 09:47:35 -0700
Cc: rgm@gnu.org, emacs-devel@gnu.org

On = 05/24/2016 08:59 AM, Eli Zaretskii wrote:
I have hard time believing this is a browser = issue

I don't. There are = different kinds of refreshes, and it's possible that 
a partial = refresh won't give you a new page at the same time that a full 
refresh = would.

That makes no sense at all.  It's = the same browser and the same Web
page.  How can the browser know to = refresh it in one case, but not in
the = other?

Because = the refresh button doesn=E2=80=99t ask the web server for a new copy of = the page; it instead asks the local cache to check and see if it thinks = a new copy of the web page is needed. There are many circumstances where = the local cache controller can ask the web server and get back what is = effectively the wrong answer. C-F5 is a standard command that tells the = web browser to have the local cache get a new copy of the page, without = asking the web server if it can use the cached copy instead. In = practice, this sort of thing happens in certain corners often enough = that many people have developed the habit of always using the = reload-dammit command when they=E2=80=99re sure they want a fresh page = (see Kaushal Modi=E2=80=99s message, for example).

Debbugs could be changed to always give out a new = copy of the page, with the concomitant increase in load you might expect = from always bypassing the cache. It could presumably be changed to never = give out the wrong answer, but (if this is what is happening in this = case =E2=80=94 it=E2=80=99s hard to tell without someone trying) that = depends on specific effort being put into debbugs.

I hope that helps.
~Chad

= --Apple-Mail=_189C7E3A-A013-40A4-BCC9-8C2DF3CAB705--