From: Kenjiro NAKAYAMA <nakayamakenjiro@gmail.com>
To: Ivan Shmakov <ivan@siamics.net>
Cc: 16204@debbugs.gnu.org
Subject: bug#16204: eww does not respect shr-width customization
Date: Sat, 21 Dec 2013 23:49:40 +0900 [thread overview]
Message-ID: <87zjnucl8b.fsf@dhcp-193-97.nrt.redhat.com> (raw)
In-Reply-To: <87k3eywjfb.fsf@violet.siamics.net>
Thank you for your review. But I have some comments. I'm sorry if I
misunderstood.
> I’d also ask for a separate “do not override” value. That is:
>
> (shr-width (if (DO-NOT-SET-P eww-rendering-width)
> shr-width
> eww-rendering-width))
I'm not sure how to work well with this logic.
I think shr-width should be overridden by nil or new rendering-width
every time, since previous windows-width will be set to shr-width next rendering.
When users change their window-width, the shr-width should be current
window-width, not previous width.
> > +(defvar eww-rendering-width nil)
>
> Shouldn’t it rather be defcustom?
For the above reason, I think defvar is ok.
> Shouldn’t this rather be ‘error’?
Yes, it is my mistake. Sorry.
Kenjiro Nakayama
ivan@siamics.net writes:
>>>>>> Kenjiro NAKAYAMA <nakayamakenjiro@gmail.com> writes:
>>>>>> ivan@siamics.net writes:
>
> >> Package: emacs Severity: wishlist
>
> >> As currently implemented, eww-display-html simply resets shr-width
> >> to nil, disrespecting any user’s customization thereof, and
> >> providing no easy way to specify the HTML rendering width to use in
> >> EWW buffers.
>
> > Yes, I think so too. I wrote the patch to cusomize rendering-width
> > (shr-width) easily by users.
>
> ACK, thanks!
>
> […]
>
> > --- a/lisp/net/eww.el
> > +++ b/lisp/net/eww.el
> > @@ -129,6 +129,7 @@ See also `eww-form-checkbox-selected-symbol'."
> > (defvar eww-home-url nil)
> > (defvar eww-start-url nil)
> > (defvar eww-contents-url nil)
> > +(defvar eww-rendering-width nil)
>
> Shouldn’t it rather be defcustom?
>
> > (defvar eww-local-regex "localhost"
> > "When this regex is found in the URL, it's not a keyword but an address.")
> > @@ -255,7 +256,7 @@ word(s) will be searched for via `eww-search-prefix'."
> > (setq eww-current-dom document)
> > (let ((inhibit-read-only t)
> > (after-change-functions nil)
> > - (shr-width nil)
> > + (shr-width eww-rendering-width)
>
> I’d also ask for a separate “do not override” value. That is:
>
> (shr-width (if (DO-NOT-SET-P eww-rendering-width)
> shr-width
> eww-rendering-width))
>
> (And, similarly, defcustom’s :type above being a ‘choice’.)
>
> > (shr-target-id (url-target (url-generic-parse-url url)))
> > (shr-external-rendering-functions
> > '((title . eww-tag-title)
>
> […]
>
> > @@ -543,6 +546,15 @@ appears in a <link> or <a> tag."
> > (url-retrieve eww-current-url 'eww-render
> > (list eww-current-url (point))))
>
> > +(defun eww-set-rendering-width (width)
> > + "Set the redering width."
> > + (interactive "nSet new redering width (0: window-width) :")
> > + (if (zerop width)
> > + (setq eww-rendering-width nil)
> > + (if (wholenump width)
> > + (setq eww-rendering-width width)
> > + (message "Set Number to rendering width"))))
>
> Shouldn’t this rather be ‘error’?
>
> > +
> > ;; Form support.
>
> > (defvar eww-form nil)
next prev parent reply other threads:[~2013-12-21 14:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-20 17:01 bug#16204: eww does not respect shr-width customization Ivan Shmakov
2013-12-21 10:48 ` Kenjiro NAKAYAMA
2013-12-21 11:08 ` Ivan Shmakov
2013-12-21 14:49 ` Kenjiro NAKAYAMA [this message]
2013-12-21 16:59 ` Ivan Shmakov
2013-12-21 20:24 ` bug#16204: eww does not respect shr-width customization, " Ted Zlatanov
2013-12-24 8:01 ` Lars Ingebrigtsen
2014-07-25 9:58 ` bug#16204: proposed patch for 24.4 Ivan Kanis
2014-08-05 17:31 ` Lars Magne Ingebrigtsen
2014-08-06 17:34 ` Ivan Kanis
2014-08-07 14:21 ` Ivan Kanis
2014-09-18 19:19 ` Lars Magne Ingebrigtsen
2014-09-18 23:48 ` Ivan Kanis
2014-09-21 12:27 ` Lars Magne Ingebrigtsen
2014-09-22 0:31 ` Ivan Kanis
2014-10-19 22:36 ` Lars Magne Ingebrigtsen
2014-10-20 17:40 ` Ivan Kanis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zjnucl8b.fsf@dhcp-193-97.nrt.redhat.com \
--to=nakayamakenjiro@gmail.com \
--cc=16204@debbugs.gnu.org \
--cc=ivan@siamics.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.