From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: E Sabof Newsgroups: gmane.emacs.bugs Subject: bug#13887: 24.3; doc-view will render blurry images when image-magick is available Date: Fri, 15 Mar 2013 01:11:42 +0000 Message-ID: References: <87sj46493q.fsf@thinkpad.tsdh.de> <877gle1etb.fsf@thinkpad.tsdh.de> <838v5tx4av.fsf@gnu.org> <87txohx0g0.fsf@thinkpad.tsdh.de> <831ubllqr0.fsf@gnu.org> <87zjy9vg0r.fsf@thinkpad.tsdh.de> <83y5dtk606.fsf@gnu.org> <83li9sk1bh.fsf@gnu.org> <83hakgjpbi.fsf@gnu.org> <87ip4ue95q.fsf@thinkpad.tsdh.de> <8738vydj1b.fsf@thinkpad.tsdh.de> <87620t64ko.fsf@thinkpad.tsdh.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bdc093474711204d7ec5294 X-Trace: ger.gmane.org 1363309987 1055 80.91.229.3 (15 Mar 2013 01:13:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Mar 2013 01:13:07 +0000 (UTC) Cc: 13887@debbugs.gnu.org To: Tassilo Horn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 15 02:13:27 2013 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 1UGJD2-0001fH-SQ for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Mar 2013 02:13:25 +0100 Original-Received: from localhost ([::1]:60410 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGJCg-0007N3-7W for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 Mar 2013 21:13:02 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGJCX-0007Mj-Aq for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2013 21:13:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UGJCT-0004bn-Bw for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2013 21:12:53 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50910) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGJCT-0004bi-7J for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2013 21:12:49 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UGJDe-0003Ud-ML for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2013 21:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: E Sabof Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Mar 2013 01:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13887 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13887-submit@debbugs.gnu.org id=B13887.136330998513349 (code B ref 13887); Fri, 15 Mar 2013 01:14:02 +0000 Original-Received: (at 13887) by debbugs.gnu.org; 15 Mar 2013 01:13:05 +0000 Original-Received: from localhost ([127.0.0.1]:55018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGJCj-0003TF-Ab for submit@debbugs.gnu.org; Thu, 14 Mar 2013 21:13:05 -0400 Original-Received: from mail-qe0-f50.google.com ([209.85.128.50]:43692) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGJCg-0003Sl-5B for 13887@debbugs.gnu.org; Thu, 14 Mar 2013 21:13:03 -0400 Original-Received: by mail-qe0-f50.google.com with SMTP id k5so1621884qej.37 for <13887@debbugs.gnu.org>; Thu, 14 Mar 2013 18:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iKeL9QwjWW4PTac/6U7PfySIZYkwxP7DDFo2CuMEXj8=; b=K4BxnVNsZwbABCYczSAvCXDFnXqASyJi9A1XDM3SF7XHVN/nGiSdIPDBuoaU04a61H l0EHWtkZSjtp65eJNNtVT7MBOdc12po9lw1XVhT6jgC/u56A2VEEh8vsP6+AFonYvKNu aNsvJ4AACKbWCl4lk65xW0M+Jb6NLTqP8uG9OtRe7ipBaaW2m/yE5NtLJEnOM4bD5hSE r04nqqvFSpo6UjbiKGYPDLrIPclLUtsHD3DVVRZhXBjkXGx/Q5MID2SEgd5YPWUBbLdk DyVw7dXaKdixDWR3HKjtySUdR/kgGatNU+nA9AHaA5Fj95MzImowS6sKGGxWYp1rKW+f drzw== X-Received: by 10.49.84.6 with SMTP id u6mr3828203qey.35.1363309902457; Thu, 14 Mar 2013 18:11:42 -0700 (PDT) Original-Received: by 10.49.70.233 with HTTP; Thu, 14 Mar 2013 18:11:42 -0700 (PDT) In-Reply-To: <87620t64ko.fsf@thinkpad.tsdh.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.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:72514 Archived-At: --047d7bdc093474711204d7ec5294 Content-Type: text/plain; charset=ISO-8859-1 Now it works in "emacs -Q", but not with my configuration. To be honest I don't think it's worth coding something final on top of current image-mode's API - it looks under-developed at several points. a) Is all the "window t" stuff necessary? Does anyone really care what is "shown" in a buffer unless it's displayed in a window? b) If yes, should "window t" be passed to a public hook? c) Does (image-get-display-property) have any business asking what buffer is currently selected in the window? d) Why data is sometimes retrieved from the the buffer (as in ( image-get-display-property)), and sometimes from image-mode-winprops-alist (as in (image-mode-winprops))? Is the complexity justified, or is one of the methods "legacy"? I use image viewers, so I could try re-factoring it, adding H/V centering, improving zooming options, and extending the API. Evgeni On Thu, Mar 14, 2013 at 9:42 PM, Tassilo Horn wrote: > Tassilo Horn writes: > > Hi again, > > >> With this patch I don't get an overlay in the initial window, and > >> sometimes after splitting. > > > > Gosh, indeed! I'll look into that later. > > Ok, now I really think I've fixed it (revno 112045), although I had to > add some obscure code in `doc-view-new-window-function' which adds > functions doing a display refresh to a timer. If I execute the code of > these functions directly in `doc-view-new-window-function', I get Lisp > nesting exceeds `max-lisp-eval-depth' errors. > > Bye, > Tassilo > --047d7bdc093474711204d7ec5294 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Now it works in "emacs -Q", but not with my conf= iguration. To be honest I don't think it's worth coding something f= inal on top of current image-mode's=A0API - it looks under-developed=A0= at several points.

a) Is all the "window t" stuff necessary? Do= es anyone really care what is "shown" in a buffer unless it's= displayed in a window?
b) If yes, should "window t&qu= ot; be passed to a public hook?
c) Does (image-get-display-prop= erty) have any=A0business=A0asking what buffer is currently selected in the= window?
d) Why dat= a is sometimes retrieved from the the buffer (as in (image-get-display-property)), and sometimes from=A0image-mode-winpro= ps-alist (as in (image-mode-winprop= s))? Is the complexity = justified, or is one of the methods "legacy"?

I use image viewers, so I could t= ry=A0re-factoring=A0it,=A0adding H/V centering, improving zooming options, and extending the API.<= /span>

Evgeni



On Thu, Mar 14, 2013 at 9:42 PM, Tassilo= Horn <tsdh@gnu.org> wrote:
Tassilo Horn <tsdh@gnu.org> write= s:

Hi again,

>> With this patch I don't get an overlay in the initial window, = and
>> sometimes after splitting.
>
> Gosh, indeed! =A0I'll look into that later.

Ok, now I really think I've fixed it (revno 112045), although I h= ad to
add some obscure code in `doc-view-new-window-function' which adds
functions doing a display refresh to a timer. =A0If I execute the code of these functions directly in `doc-view-new-window-function', I get Lisp<= br> nesting exceeds `max-lisp-eval-depth' errors.

Bye,
Tassilo

--047d7bdc093474711204d7ec5294--