eww

eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Before the first release that contains eww, I think we should set up
natural aliases for the commands, perhaps using the name "browse" or
"www" or "web" instead of "eww".  With natural names, users won't have
to wonder, "What in the world did they call that?"  We can avoid
adding one more difficulty to learning to use Emacs.

I think epa also needs a set of natural aliases, with "crypt" instead
of "epa".

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Juanma Barranquero]

On Sun, Jan 12, 2014 at 2:46 PM, Richard Stallman <rms@gnu.org> wrote:

> Before the first release that contains eww, I think we should set up
> natural aliases for the commands, perhaps using the name "browse" or
> "www" or "web" instead of "eww".  With natural names, users won't have
> to wonder, "What in the world did they call that?"  We can avoid
> adding one more difficulty to learning to use Emacs.
>
> I think epa also needs a set of natural aliases, with "crypt" instead
> of "epa".

We introduced define-alternatives for exactly that case. It's just
that nobody has used it yet.

     j

Re: eww

[Bastien]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sun, Jan 12, 2014 at 2:46 PM, Richard Stallman <rms@gnu.org> wrote:
>
>> Before the first release that contains eww, I think we should set up
>> natural aliases for the commands, perhaps using the name "browse" or
>> "www" or "web" instead of "eww".  With natural names, users won't have
>> to wonder, "What in the world did they call that?"  We can avoid
>> adding one more difficulty to learning to use Emacs.
>>
>> I think epa also needs a set of natural aliases, with "crypt" instead
>> of "epa".
>
> We introduced define-alternatives for exactly that case. It's just
> that nobody has used it yet.

Try this:

  (define-alternatives web)
  (setq web-alternatives '(("eww" . eww)))
  M-x web RET TAB RET

Does not work without the attached patch.

I think it's safe to recommend `define-alternatives' for commands
only, not for function, and the docstring suggests this too.  If so,
I'll apply the patch.

Two other problems:

1) when there is only one "alternative", the user is asked which
   one he wants.  I think COMMAND should use the alternative without
   asking, and tell the user how to add other alternatives through
   COMMAND-alternatives for 2 secs the first time the alternative is
   chosen.

2) Once an alternative is chosen, setting COMMAND-alternatives will
   not take any effect, and I don't see a way to cancel the first
   choice.

What do you think?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: simple.el.patch --]
[-- Type: text/x-diff, Size: 857 bytes --]

=== modified file 'lisp/simple.el'
*** lisp/simple.el	2014-01-12 04:00:03 +0000
--- lisp/simple.el	2014-01-13 11:10:41 +0000
***************
*** 7694,7700 ****
                 (customize-save-variable ',varimp-sym
                                          (cdr (assoc-string val ,varalt-sym))))))
           (if ,varimp-sym
!              (funcall ,varimp-sym)
             (message ,(format "No implementation selected for command `%s'"
                               command-name)))))))
  
--- 7694,7700 ----
                 (customize-save-variable ',varimp-sym
                                          (cdr (assoc-string val ,varalt-sym))))))
           (if ,varimp-sym
!              (call-interactively ,varimp-sym)
             (message ,(format "No implementation selected for command `%s'"
                               command-name)))))))
  


[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


-- 
 Bastien

Re: eww

[Davis Herring]

> 2) Once an alternative is chosen, setting COMMAND-alternatives will
>    not take any effect, and I don't see a way to cancel the first
>    choice.

So introduce a function `add-alternative' that extends the appropriate
list and also cancels the user's choice (or rather, makes it the default
for the next prompt).  Of course, there's an issue of timing: you want
the behavior I just described when installing a new package, but not
when loading it in a new Emacs after the choice has been made (again).

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: eww

[Bastien]

Davis Herring <herring@lanl.gov> writes:

> So introduce a function `add-alternative' that extends the appropriate
> list and also cancels the user's choice (or rather, makes it the default
> for the next prompt).

Yes, but let's go back to this after the release (and when
`define-alternatives' is used at least once!)

-- 
 Bastien

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

      (define-alternatives web)
      (setq web-alternatives '(("eww" . eww)))
      M-x web RET TAB RET

If the only user-level entry point for eww is `eww',
this would do the right thing.

Is that the case?

For epa, there are several such entry points, including
epa-mail-encrypt and epa-insert-keys.  We could do

(define-alternatives crypt-mail-encrypt)
(define-alternatives crypt-insert-keys)
with the suitable variable values, but that won't give
the right result.  The user would be asked to choose an
alternative for crypt-mail-encrypt, and independently
to choose an alternative for crypt-insert-keys.

What we really want is for the two commands to be synced
so that a single choice of alternative applies to both.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> For epa, there are several such entry points, including
> epa-mail-encrypt and epa-insert-keys.  We could do
>
> (define-alternatives crypt-mail-encrypt)
> (define-alternatives crypt-insert-keys)
> with the suitable variable values, but that won't give
> the right result.  The user would be asked to choose an
> alternative for crypt-mail-encrypt, and independently
> to choose an alternative for crypt-insert-keys.
>
> What we really want is for the two commands to be synced
> so that a single choice of alternative applies to both.

I guess for epa-* what is really needed is a better prefix,
not a UI level for the users to chose alternatives--but maybe
that's just because I don't know alternatives to epa-*.

-- 
 Bastien

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    I guess for epa-* what is really needed is a better prefix,
    not a UI level for the users to chose alternatives--but maybe
    that's just because I don't know alternatives to epa-*.

Are there any alternatives to epa
that we ought to support?
If not, aliases would do fine.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     I guess for epa-* what is really needed is a better prefix,
>     not a UI level for the users to chose alternatives--but maybe
>     that's just because I don't know alternatives to epa-*.
>
> Are there any alternatives to epa
> that we ought to support?

I don't think there is one, but I just browse this page:
http://www.emacswiki.org/emacs/CategoryCryptography

From what I saw, mailcrypt and pgg used to be widely used,
but mailcrypt is not active since 2002 and pgg is marked as
`obsolete' in Emacs.

> If not, aliases would do fine.

The problem is: what is the set of epa-* command for which
an alias is useful?

PS: I'm not using epa-* enough to decide myself.

-- 
 Bastien

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    The problem is: what is the set of epa-* command for which
    an alias is useful?

I propose to make the alias for all the autoloaded functions in epa.el
and epa-mail.el.

Any counterproposals?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Creating aliases for epa-* comands => crypt-* commands? (was: eww)

[Bastien]

(Moving this to a dedicated thread.)

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     The problem is: what is the set of epa-* command for which
>     an alias is useful?
>
> I propose to make the alias for all the autoloaded functions in epa.el
> and epa-mail.el.
>
> Any counterproposals?

If there is no counterproposals soon, let me know and I will create
the aliases for epa-* autoloaded functions.

-- 
 Bastien

Re: Creating aliases for epa-* comands => crypt-* commands?

[Stefan Monnier]

> If there is no counterproposals soon, let me know and I will create
> the aliases for epa-* autoloaded functions.

I think that as long as there is no existing alternative, it makes no
sense to provide aliases.  And we're talking about 30 autoloaded functions.


        Stefan

Re: Creating aliases for epa-* comands => crypt-* commands?

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> If there is no counterproposals soon, let me know and I will create
>> the aliases for epa-* autoloaded functions.
>
> I think that as long as there is no existing alternative, it makes no
> sense to provide aliases.  And we're talking about 30 autoloaded
> functions.

The idea was to make epa-* easier to discover by providing a better
prefix.  But I agree 30 aliases sounds too much.

-- 
 Bastien

Re: Creating aliases for epa-* comands => crypt-* commands?

[Stefan Monnier]

>>> If there is no counterproposals soon, let me know and I will create
>>> the aliases for epa-* autoloaded functions.
>> I think that as long as there is no existing alternative, it makes no
>> sense to provide aliases.  And we're talking about 30 autoloaded
>> functions.
> The idea was to make epa-* easier to discover by providing a better
> prefix.  But I agree 30 aliases sounds too much.

I use EPA but have never needed to call something that has "epa" it
its name.  I just open a foo.gpg file and things "just work".
There's an "Encryption/Decryption" submenu which seems "discoverable".
In what sense does it need to be more "discoverable"?


        Stefan

Re: Creating aliases for epa-* comands => crypt-* commands?

[Vibhav Pant]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

>I use EPA but have never needed to call something that has "epa" it
>its name.  I just open a foo.gpg file and things "just work".
>There's an "Encryption/Decryption" submenu which seems "discoverable".
>In what sense does it need to be more "discoverable"?
>
>
>        Stefan

I guess an alias for mail-mode commands would help, as Epa is also used to sign emails.
- --
Vibhav Pant
vibhavp@gmail.com

Sent from my Android device with K-9 Mail. Please excuse my brevity.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.9

iQI9BAEBCAAnBQJS2UmzIBxWaWJoYXYgUGFudCA8dmliaGF2cEBnbWFpbC5jb20+
AAoJEO86onTybWtcbWoQANbeG6hkfHCovww3qYkrE78jkitqWLhqVCvsPRA2Ab8Y
IAwQuPMg13zjRZ4hk7O0uOXkb2tpvrpB3BwwxePOva7aMo+UZguripk/9x/lGh8k
xio6HD71z/ouTS/MnyxAyRGCbm192RKqVc4BMW6VoLED0UixcgePlI1FODCsnMMO
MbTx7vX46gLg73jsyLGDEr3O2BJkH9lNjHWqWZENRvQ2U4yu/paH/a7sAoZh1Rma
Cx/rSyoheE3ikunwtB3/I0lXnGr/aRV/aTkx5d1xroY5pZRCU6Sgxl/imXYeioj9
WnEndfHOj55VAEJQL0RI69fJosYrSr7d6J6xn0mWYE7P5qOWo5rI4Gk5qh3zD1t4
yWpE4qq8pM13bt+67lPsdw2XbEn87xrS6uYQL+s71SFniC93evlP8GHacOYSlGRW
5xuvIRAmoEbemiwAwzeYjppmEDQr6Q6YVzBSmRg4HPTKyowjgpxgE9HmGgtma5FB
ybMdUWIBPZBReXLAbMkvNxyqXePxlNDKKev2gEx4bnQxJU6kJ3R0iANOJsE11lAH
weNG/qRuhN4FsbNLKrAE7gsi49g2+Ry46jRaGf4U6UlosOSdpWzglRDFIT35vIj8
XHqeO+L7kh0G4INk/NItVOC5uMjdykME+Y8U00UwHSjzOx4MaN4kEhczq3wW2bZW
=8jII
-----END PGP SIGNATURE-----

Re: Creating aliases for epa-* comands => crypt-* commands?

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> If there is no counterproposals soon, let me know and I will create
>>>> the aliases for epa-* autoloaded functions.
>>> I think that as long as there is no existing alternative, it makes no
>>> sense to provide aliases.  And we're talking about 30 autoloaded
>>> functions.
>> The idea was to make epa-* easier to discover by providing a better
>> prefix.  But I agree 30 aliases sounds too much.
>
> I use EPA but have never needed to call something that has "epa" it
> its name.

Outside email encryption, where I don't need to remember the epa-*
prefix, I use epa-list-keys and occasionnally epa-import-keys.

When I forget about the prefix, I use the GUI gpa tool instead.

> I just open a foo.gpg file and things "just work".
> There's an "Encryption/Decryption" submenu which seems "discoverable".
> In what sense does it need to be more "discoverable"?

To help those who don't use the menu bar, I'd say.

Actually, gpg-* would be the best prefix for me.

If I tell a friend "You can list your keys from Emacs", that's what
he will certainly try first.  Not epa-list-keys, which is not even
available from a menu.

-- 
 Bastien

Re: Creating aliases for epa-* comands => crypt-* commands?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    I use EPA but have never needed to call something that has "epa" it
    its name.  I just open a foo.gpg file and things "just work".
    There's an "Encryption/Decryption" submenu which seems "discoverable".
    In what sense does it need to be more "discoverable"?

I never tried doing encryption by visiting a file named .gpg.
It never occurred to me to try that.  Mostly I do it in emails,
incoming and outgoing.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Creating aliases for epa-* comands => crypt-* commands?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    The idea was to make epa-* easier to discover by providing a better
    prefix.  But I agree 30 aliases sounds too much.

The aliases cost very little; what's wrong with 30 of them?
Or maybe we need fewer aliases, only for the commands you would
not get at thru the menu in a .gpg file.

The main job will be to change the documentation.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Creating aliases for epa-* comands => crypt-* commands?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > If there is no counterproposals soon, let me know and I will create
    > the aliases for epa-* autoloaded functions.

    I think that as long as there is no existing alternative, it makes no
    sense to provide aliases.  And we're talking about 30 autoloaded functions.

The purpose of this change is to get rid of one case where users have
to say, "What did they call that?"  If the command to encrypt a file
is called `epa-mail-encrypt, "epa" is a gratuitous memory obstacle.
If it is `crypt-encrypt-message' or `encrypt-message'.

Let's make Emacs easier for people to learn by cleaning up these
unnecessary rough spots.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Creating aliases for epa-* comands => crypt-* commands?

[Stefan Monnier]

> The purpose of this change is to get rid of one case where users have
> to say, "What did they call that?"  If the command to encrypt a file
> is called `epa-mail-encrypt, "epa" is a gratuitous memory obstacle.
> If it is `crypt-encrypt-message' or `encrypt-message'.

I'm not necessarily opposed to such targeted aliases.
This said, this is no bug fix, so it can wait for after 24.4.
In the mean time, you can come up with a list of commands and good
aliases for them.


        Stefan

Re: Creating aliases for epa-* comands => crypt-* commands?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    I'm not necessarily opposed to such targeted aliases.
    This said, this is no bug fix, so it can wait for after 24.4.

We should fix it before the next reprinting of the Emacs manual.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

      (define-alternatives web)
      (setq web-alternatives '(("eww" . eww)))
      M-x web RET TAB RET

This calling convention has the drawback that (define-alternatives web)
isn't recognized as a definition for the variable web-alternatives.

Should we tell people to write a defvar for web-alternatives
just after the define-alternatives for web?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> This calling convention has the drawback that (define-alternatives web)
> isn't recognized as a definition for the variable web-alternatives.

I'm not sure I understand.

> Should we tell people to write a defvar for web-alternatives
> just after the define-alternatives for web?

I enhanced the docstring a bit---it now reads:

  Define the new command `COMMAND'.
  
  The argument `COMMAND' should be a symbol.
  
  Running `M-x COMMAND RET' for the first time prompts for which
  alternative to use and records the selected command as a custom
  variable.
  
  Running `C-u M-x COMMAND RET' prompts again for an alternative
  and overwrites the previous choice.
  
  The variable `COMMAND-alternatives' contains an alist with
  alternative implementations of COMMAND.  `define-alternatives'
  does not have any effect until this variable is set.
  
  CUSTOMIZATIONS, if non-nil, should be composed of alternating
  `defcustom' keywords and values to add to the declaration of
  `COMMAND-alternatives' (typically :group and :version).

I hope this is clearer.

-- 
 Bastien

Re: eww

[Stefan Monnier]

>> This calling convention has the drawback that (define-alternatives web)
>> isn't recognized as a definition for the variable web-alternatives.
> I'm not sure I understand.

If you try to jump to the source from "C-h v web-alternatives", Emacs
won't find the right spot.

You should be able to work around this use by adding to the macro
something like

       (put ',varname 'definition-name ',cmdname)


-- Stefan

Re: eww

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> This calling convention has the drawback that (define-alternatives web)
>>> isn't recognized as a definition for the variable web-alternatives.
>> I'm not sure I understand.
>
> If you try to jump to the source from "C-h v web-alternatives", Emacs
> won't find the right spot.

M-: (define-alternatives web) RET
C-h web-alternatives RET

will display a correct docstring for `web-alternatives'.

What am I missing?

-- 
 Bastien

Re: eww

[Nicolas Richard]

Bastien <bzg@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>> This calling convention has the drawback that (define-alternatives web)
>>>> isn't recognized as a definition for the variable web-alternatives.
>>> I'm not sure I understand.
>>
>> If you try to jump to the source from "C-h v web-alternatives", Emacs
>> won't find the right spot.
>
> M-: (define-alternatives web) RET
> C-h web-alternatives RET
>
> will display a correct docstring for `web-alternatives'.
>
> What am I missing?

The link to the source (when (define-alternatives web) is done in an .el
file) won't work right, and result in "Unable to find location in file".
It's a common problem with macros that define things.

Here's a patch to implement Stefan's solution:

--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -7675,7 +7675,7 @@ ALTFUN  - The function called to implement this alternative."
                   command-name)
          :type '(alist :key-type string :value-type function)
          ,@customizations)
-
+       (put ',varalt-sym 'definition-name ',command)
        (defvar ,varimp-sym nil "Internal use only.")
 
        (defun ,command (&optional arg)


-- 
Nico.

Re: eww

[Bastien]

Hi Nicolas,

"Nicolas Richard" <theonewiththeevillook@yahoo.fr> writes:

> The link to the source (when (define-alternatives web) is done in an .el
> file) won't work right, and result in "Unable to find location in file".
> It's a common problem with macros that define things.

Sorry, I still don't get it.

Put this in ~/web.el

(define-alternatives web)
(setq web-alternatives '(("eww" . eww) ("w3m" . w3m)))

M-x eval-buffer RET

then C-h f web RET and C-h v web-alternatives RET will
display the correct location.

-- 
 Bastien

Re: eww

[Nicolas Richard]

Hi Bastien,

Le 14/01/2014 17:39, Bastien a écrit :
> then C-h f web RET and C-h v web-alternatives RET will
> display the correct location.

Put this in web.el :
;; some useful comments
(define-alternatives web)
(setq web-alternatives '(("eww" . eww) ("w3m" . w3m)))
;; End of file.

now load it as emacs -Q -l /path/to/web.el

and do:
C-h v web-alternatives RET
C-x b *Help* RET
TAB

at this point, your echo area should read:
  mouse-2, RET: find variable's definition
now go ahead and hit RET. echo area now displays:
  Unable to find location in file
and point is in a buffer visiting web.el, at beginning of buffer.

With the patch, the last message will not show up, and point will be
left at beginning of the line `(define-alternatives web)'

-- 
Nico.

Re: eww

[Bastien]

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:

> Put this in web.el :
> ;; some useful comments
> (define-alternatives web)
> (setq web-alternatives '(("eww" . eww) ("w3m" . w3m)))
> ;; End of file.
>
> now load it as emacs -Q -l /path/to/web.el
>
> and do:
> C-h v web-alternatives RET
> C-x b *Help* RET
> TAB
>
> at this point, your echo area should read:
>   mouse-2, RET: find variable's definition
> now go ahead and hit RET. echo area now displays:
>   Unable to find location in file
> and point is in a buffer visiting web.el, at beginning of buffer.

I cannot reproduce this, with the recipe above, RET jumps to the
correct location.

See http://bzg.fr/u/emacs-web-alternatives-jump.ogv

define-alternatives uses defcustom and defun internally, the behavior
I observe seems the right one to me.

-- 
 Bastien

Re: eww

[Nicolas Richard]

Bastien <bzg@gnu.org> writes:

> Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
>
>> Put this in web.el :
>> ;; some useful comments
>> (define-alternatives web)
>> (setq web-alternatives '(("eww" . eww) ("w3m" . w3m)))
>> ;; End of file.
>>
>> now load it as emacs -Q -l /path/to/web.el
>>
>> and do:
>> C-h v web-alternatives RET
>> C-x b *Help* RET
>> TAB
>>
>> at this point, your echo area should read:
>>   mouse-2, RET: find variable's definition
>> now go ahead and hit RET. echo area now displays:
>>   Unable to find location in file
>> and point is in a buffer visiting web.el, at beginning of buffer.
>
> I cannot reproduce this, with the recipe above, RET jumps to the
> correct location.

Oops, I'm sorry, I made the test with the wrong file and thus gave the
wrong recipe.

Try this as a web.el:
;; some useful comments
(define-alternatives web)
;; End of file.

> See http://bzg.fr/u/emacs-web-alternatives-jump.ogv

Notice that point is moved in front of (setq ...), and not
(define-alternatives ...) although that is where the defcustom happens.
This is because the mechanism searches for the following regexp :
"^([^ ]+\\(?:\\s-\\|
\\|;.*
\\)+['(]?web-alternatives\\_>"

(this happens in find-function-search-for-symbol).

-- 
Nico.

Re: eww

[Bastien]

"Nicolas Richard" <theonewiththeevillook@yahoo.fr> writes:

> Oops, I'm sorry, I made the test with the wrong file and thus gave the
> wrong recipe.
>
> Try this as a web.el:
> ;; some useful comments
> (define-alternatives web)
> ;; End of file.

Ahhh, okay!

(I did not try this use-case because I don't see the point of using
(define-alternatives ...) without defining the set of alternatives.)

I applied the patch, thanks for your patience.

-- 
 Bastien

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I am pretty sure that etags can't see the definition of the variable
that define-alternatives defines.  It scans textually and can't
recognize macros unless it is specifically taught about them.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> I am pretty sure that etags can't see the definition of the variable
> that define-alternatives defines.  It scans textually and can't
> recognize macros unless it is specifically taught about them.

etags treats all toplevel forms with a symbol starting with "def" as
defining a word, and registers the next word as a tag.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: eww

[Nicolas Richard]

Le 15/01/2014 15:07, Andreas Schwab a écrit :
> Richard Stallman <rms@gnu.org> writes:
> 
>> I am pretty sure that etags can't see the definition of the variable
>> that define-alternatives defines.  It scans textually and can't
>> recognize macros unless it is specifically taught about them.
> 
> etags treats all toplevel forms with a symbol starting with "def" as
> defining a word, and registers the next word as a tag.

Which means that 'web' will be a tag, but not web-alternatives, right ?
Is that a problem ? (I don't use tags for elisp)

-- 
Nico.

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > etags treats all toplevel forms with a symbol starting with "def" as
    > defining a word, and registers the next word as a tag.

    Which means that 'web' will be a tag, but not web-alternatives, right ?

Right.

    Is that a problem ? (I don't use tags for elisp)

It is a problem for anyone that uses tags for elisp.

So I think we should recommend writing (defvar web-alternatives)
after (define-alternatives 'web).

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> So I think we should recommend writing (defvar web-alternatives)
> after (define-alternatives 'web).

That won't help, as etags will specifically ignore a defvar that just
declares a variable.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > So I think we should recommend writing (defvar web-alternatives)
    > after (define-alternatives 'web).

    That won't help, as etags will specifically ignore a defvar that just
    declares a variable.

I forgot.

What does it need, then?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Stefan Monnier]

> What does it need, then?

Nothing at all.  This problem with etags exists already with many other
macros and noone cares.  That's just life: etags is approximate, it
includes unneeded elements and lacks some elements it should have.
It is still 99% correct for Elisp, so some people use it very happily,
but there's no point uglifying the code just to try and make it work
99.01% instead.


        Stefan

Re: eww

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 17 Jan 2014 10:04:57 -0500
> Cc: bzg@gnu.org, theonewiththeevillook@yahoo.fr,
> 	Andreas Schwab <schwab@linux-m68k.org>, emacs-devel@gnu.org
> 
> > What does it need, then?
> 
> Nothing at all.  This problem with etags exists already with many other
> macros and noone cares.  That's just life: etags is approximate, it
> includes unneeded elements and lacks some elements it should have.
> It is still 99% correct for Elisp, so some people use it very happily,
> but there's no point uglifying the code just to try and make it work
> 99.01% instead.

If tagging those is important, we could use the --regex option to
etags.

Re: eww

[Stefan Monnier]

> If tagging those is important, we could use the --regex option to
> etags.

Since noone ever bothered to create those for define-derived-mode and
other such macros, I can't imagine that it's important to do it for
define-alternative which is used just about nowhere.


        Stefan

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Nothing at all.  This problem with etags exists already with many other
    macros and noone cares.

Are you sure no one cares?  When people look for a tag, and it isn't
defined, they will hunt around and find it somehow.

These problems are sloppinesses, and we can avoid them by taking a little
care in defining the macros, or by making etags recognize them specially.

    Since noone ever bothered to create those for define-derived-mode and
    other such macros, I can't imagine that it's important to do it for
    define-alternative which is used just about nowhere.

It's bad in define-derived-mode, too.  It's unfortunate
that there is no tag for `...-mode-map'.  However, at least
the presence of `mode' will suggest to people where they should look.
There is no comparable word in `web-alternatives' to suggest where
to look.

We could make find-tag know about these cases, so it will find
the tags anyway.  That won't even make tag tables do it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Stefan Monnier]

>     Nothing at all.  This problem with etags exists already with many other
>     macros and noone cares.
> Are you sure no one cares?

I guess that's a rhetorical question, since you seem to care, and
obviously I can't be sure anyway.

> When people look for a tag, and it isn't defined, they will hunt
> around and find it somehow.

As stated it's part of etags's problems, and it's true for uses of etags
with any language that provides a macro facility, AFAIK.  etags probably
also suffers from similar problems (missed tags) in various other corner
cases even for language without macros.

People who care enough about these issues probably just use something
else than etags.  Otherwise we'd already have had plenty more bug reports
along these lines.

> These problems are sloppinesses, and we can avoid them by taking a little
> care in defining the macros, or by making etags recognize them specially.

I wouldn't call it "a little care defining the macro" but rather
"disfiguring the macro".

> It's bad in define-derived-mode, too.  It's unfortunate
> that there is no tag for `...-mode-map'.

It's not just ..-mode-map, but also ..-abbrev-table, ..-syntax-table,
and ..-mode-hook.

> However, at least the presence of `mode' will suggest to people where
> they should look.  There is no comparable word in `web-alternatives'
> to suggest where to look.

My guess is that they'll do `C-h v web-alternatives' then click on the
button to jump to the source code, and ... tadaa!!
No problem with etags because they didn't need to use etags for that.

> We could make find-tag know about these cases, so it will find
> the tags anyway.

`find-tag' works for dozens of different languages.  Why should it
suddenly be uglified with special hacks for one of those languages (and
one where etags is particularly less important because this one language
happens to be the one that's only edited from Emacs where things like
`C-h v' and `C-h f' work even more reliably than etags and without
having to build and update any TAGS table)?

> That won't even make tag tables do it.

If we want find-tag to do the right thing, the right way to do it is by
teaching `etags' to recognizes macros like define-derived-mode and add
corresponding entries in the TAGS file.


        Stefan

Re: eww

[Francesco Potortì]

>If we want find-tag to do the right thing, the right way to do it is by
>teaching `etags' to recognizes macros like define-derived-mode and add
>corresponding entries in the TAGS file.

I agree, and it's very easy.  Just create a file containing regexps to
be distributed allong with the Makefile, or else (uglier but does not
require a separate file) just put the regexps on the Makefile's etags
command line.

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > It's bad in define-derived-mode, too.  It's unfortunate
    > that there is no tag for `...-mode-map'.

    It's not just ..-mode-map, but also ..-abbrev-table, ..-syntax-table,
    and ..-mode-hook.

That's right.  I mentioned just the one that matters most.
The others add a little to the point.

    `find-tag' works for dozens of different languages.  Why should it
    suddenly be uglified with special hacks for one of those languages

The code would be a tiny bit more complex, but the behavior
would be simpler and more regular.  I think that is cleaner
than generating extra tags.  Also it's better to change Lisp code
than change C code.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     > So I think we should recommend writing (defvar web-alternatives)
>     > after (define-alternatives 'web).
>
>     That won't help, as etags will specifically ignore a defvar that just
>     declares a variable.
>
> I forgot.
>
> What does it need, then?

This is the only exception, otherwise it will take anything.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: eww

[Francesco Potortì]

>    > So I think we should recommend writing (defvar web-alternatives)
>    > after (define-alternatives 'web).
>
>    That won't help, as etags will specifically ignore a defvar that just
>    declares a variable.
>
>I forgot.
>
>What does it need, then?

A regexp file where elisp regexps are defined, or just definition of
command-line regexps on the command line in the Makefile:


-r REGEXP, --regex=REGEXP or --regex=@regexfile
        Make a tag for each line matching a regular expression pattern
	in the following files.  {LANGUAGE}REGEXP uses REGEXP for LANGUAGE
	files only.  REGEXFILE is a file containing one REGEXP per line.
	REGEXP takes the form /TAGREGEXP/TAGNAME/MODS, where TAGNAME/ is
	optional.  The TAGREGEXP pattern is anchored (as if preceded by ^).
	If TAGNAME/ is present, the tags created are named.
	For example Tcl named tags can be created with:
	  --regex="/proc[ \t]+\([^ \t]+\)/\1/.".
	MODS are optional one-letter modifiers: `i' means to ignore case,
	`m' means to allow multi-line matches, `s' implies `m' and
	causes dot to match any character, including newline.

Re: eww

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> So I think we should recommend writing (defvar web-alternatives)
> after (define-alternatives 'web).

I pushed a docstring fix and here is how the docstring reads now:

  Define the new command `COMMAND'.
  
  The argument `COMMAND' should be a symbol.
  
  Running `M-x COMMAND RET' for the first time prompts for which
  alternative to use and records the selected command as a custom
  variable.
  
  Running `C-u M-x COMMAND RET' prompts again for an alternative
  and overwrites the previous choice.
  
  The variable `COMMAND-alternatives' contains an alist with
  alternative implementations of COMMAND.  Developers should
  use (defvar COMMAND-alternatives) to declare this variable
  after they write (define-alternatives COMMAND), otherwise
  the variable will not be handled by programs like etags.
  
  CUSTOMIZATIONS, if non-nil, should be composed of alternating
  `defcustom' keywords and values to add to the declaration of
  `COMMAND-alternatives' (typically :group and :version).

Let me know if this is clearer and correct.

-- 
 Bastien

Re: eww

[Stefan Monnier]

> I pushed a docstring fix and here is how the docstring reads now:

Bad idea, since (defvar web-alternatives) won't help etags anyway.


        Stefan

Re: eww

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I pushed a docstring fix and here is how the docstring reads now:
>
> Bad idea, since (defvar web-alternatives) won't help etags anyway.

Yes, I reverted the change.

-- 
 Bastien

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > So I think we should recommend writing (defvar web-alternatives)
    > after (define-alternatives 'web).

    I pushed a docstring fix and here is how the docstring reads now:

Unfortunately, someone pointed out that my recommendation
won't actually do the job.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > I am pretty sure that etags can't see the definition of the variable
    > that define-alternatives defines.  It scans textually and can't
    > recognize macros unless it is specifically taught about them.

    etags treats all toplevel forms with a symbol starting with "def" as
    defining a word, and registers the next word as a tag.

Right.  And the tag it registers is the next symbol.

So  (define-alternatives web ...)
will define web as a tag
but won't define web-alternative as a tag.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Stefan Monnier]

>> If you try to jump to the source from "C-h v web-alternatives", Emacs
>> won't find the right spot.
> M-: (define-alternatives web) RET
> C-h web-alternatives RET
> will display a correct docstring for `web-alternatives'.
> What am I missing?

You're missing "you try to jump to the source".


        Stefan

Re: eww

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> If you try to jump to the source from "C-h v web-alternatives", Emacs
>>> won't find the right spot.
>> M-: (define-alternatives web) RET
>> C-h web-alternatives RET
>> will display a correct docstring for `web-alternatives'.
>> What am I missing?
>
> You're missing "you try to jump to the source".

Well, that's because define-alternatives already lets
me jump to the source -- see my answer to Nicolas (with
video inside :)

-- 
 Bastien

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    If you try to jump to the source from "C-h v web-alternatives", Emacs
    won't find the right spot.

    You should be able to work around this use by adding to the macro
    something like

	   (put ',varname 'definition-name ',cmdname)

That would help with some tools, but etags still won't
recognize it.

Writing a defvar for the variable after the define-alternatives
would provide info to all the tools.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Bastien]

Bastien <bzg@gnu.org> writes:

> Try this:
>
>   (define-alternatives web)
>   (setq web-alternatives '(("eww" . eww)))
>   M-x web RET TAB RET
>
> Does not work without the attached patch.

I fixed the bug about using funcall where call-interactively is
needed.

> I think it's safe to recommend `define-alternatives' for commands
> only, not for function, and the docstring suggests this too.  If so,
> I'll apply the patch.
>
> Two other problems:
>
> 1) when there is only one "alternative", the user is asked which
>    one he wants.  I think COMMAND should use the alternative without
>    asking, and tell the user how to add other alternatives through
>    COMMAND-alternatives for 2 secs the first time the alternative is
>    chosen.

I enhanced the macro like this: when the choice is made for the first
time, the user gets a message telling him about C-u M-x web RET

> 2) Once an alternative is chosen, setting COMMAND-alternatives will
>    not take any effect, and I don't see a way to cancel the first
>    choice.

This is solved by C-u M-x web RET.

Maybe it would be nice to chose an alternative temporarily
(with C-u C-u M-x web RET) but let's wait after the release
and... when this macro will be used for the first time.

-- 
 Bastien

Re: eww

[Juanma Barranquero]

On Mon, Jan 13, 2014 at 11:18 PM, Bastien <bzg@gnu.org> wrote:

> I fixed the bug about using funcall where call-interactively is
> needed.

Thanks.

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > I think epa also needs a set of natural aliases, with "crypt" instead
    > of "epa".

    We introduced define-alternatives for exactly that case. It's just
    that nobody has used it yet.

We may be miscommunicating.  I don't see a need for
define-alternatives here, because simple defalias would work: e.g.,

(defalias 'crypt-mail-encrypt 'epa-mail-encrypt)

Why not?  Do you have in mind something else it should mean?

It's easy enough to do this, but then the documentation needs
updating.

For browsing, perhaps define-alternatives should be used.  I never use
those features, so I am not sure what commands should be defined, or
what their alternative meaning should be.

The doc string of define-alternatives is not very clear but I think it
does the wrong thing.  I have think the user should be able to specify
a choice of browsing package just once, and it should affect all such
commands for browsing.

My point is that this really needs to be done before the release.
We should prevent an ugliness from ever getting into a release.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Lars Magne Ingebrigtsen]

`browse-web' is the alias for `eww'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    `browse-web' is the alias for `eww'.

That's a good, natural name.  However, the Emacs manual mentions
`eww', not `browse-web'.  I think that is a bug and needs to be
fixed.

The manual section on EWW says that itcan be one of the browsers used
by `browse-url'.  In effect, `browse-url' is an instance of the sort
of feature that `define-alternative' defines.

Perhaps we should set it up to ask the user, as if it were defined
with `define-alternative'.

Perhaps `eww' should be the default.  (Should it be the default?)

Perhaps the manual should document only `browse-url', not the
internals of the various alternatives.

I am not sure what is best, since I don't use those features.  But I
am sure we should get the user interface maximally simplified before
the release.  What do people think is best?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     `browse-web' is the alias for `eww'.
>
> That's a good, natural name.  However, the Emacs manual mentions
> `eww', not `browse-web'.  I think that is a bug and needs to be
> fixed.

Before we go and fix the manual, I think the way people chose
the program for browsing the web can be made simpler.

Having both `browse-url' and `browse-web' is confusing IMHO.

What about:

1. replace the `browse-web' alias with `emacs-web-browser'.

2. let `browse-url' use `browse-url-graphical' or `browse-url-text'
   depending on whether (display-graphic-p) and on a a user option
   (if the user always want to use a text browser, for example.)

3. set the options `browse-url-graphical-alternatives' and
   `browse-url-text-alternatives' with `define-alternatives'
   which would offer relevant choices depending on what the user
   can use on its system.

When hitting `browse-url' for the first time in a terminal, the user
would have the choice between eww, w3 or w3m, for example.

When hitting `browse-url' for the first time in a window system,
the user would first have the choice to browse with a text browser,
or a window browser, then between (text or window) browsers.

C-u M-x browse-url RET would let him pick up another alternative
by passing the prefix universal argument to browse-url-graphical
or browse-url-text (for now the prefix tells whether to open a
new window/tab in the browser.)

It's probably a lot of work, but it would makes life easier for
users.  For now they rely on `browse-url' and will hardly hear
of `browse-web', wondering why there is a separate interface.

-- 
 Bastien

Re: eww

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Your proposal seems good to me, but maybe it could be simplified.  I
am not sure we need the complexity of choosing a text browser and
separately a graphical browser.  Most new users only use Emacs in
graphical mode and will want only a graphical browser.

So I suggest this:

browse-url-text uses the preferred text browser.  The first time, it asks
the user to choose the preferred text browser.

browse-url-graphical uses the preferred graphical browser.  The first
time, it asks the user to choose the preferred graphical browser.

browse-url on a text terminal runs browse-url-text.

browse-url on a graphical terminal runs browse-url-graphical.

This way, most users will only need to remember browse-url,
and will only be asked once to choose a preferred browser.

Any comments?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

eww

[Lars Magne Ingebrigtsen]

eww probably has a lot of stuff that could still be fixed up, but the
basics are working now.  That is, you can search for stuff on Google and
visit Wikipedia.  :-)

I wrote it up a bit here:

http://lars.ingebrigtsen.no/2013/06/eww.html

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Adam Sjøgren]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> eww probably has a lot of stuff that could still be fixed up, but the
> basics are working now.  That is, you can search for stuff on Google and
> visit Wikipedia.  :-)

Cool!

It looks like input elements are supported, but textarea less so?

 * http://koldfront.dk/misc/browsers/textarea.html


  Best regards,

    Adam

-- 
 "Tell them to give it to Donovan."                           Adam Sjøgren
                                                         asjo@koldfront.dk

Re: eww

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> It looks like input elements are supported, but textarea less so?
>
>  * http://koldfront.dk/misc/browsers/textarea.html

Ah, yeah.  I forgot about textarea.  I'll add that.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>>  * http://koldfront.dk/misc/browsers/textarea.html
>
> Ah, yeah.  I forgot about textarea.  I'll add that.

I'm using widget.el to do the inputs, and the `text' type seems to be
appropriate:

---
This is just like `editable-field', but intended for multiline text
fields.  The default `:keymap' is `widget-text-keymap', which does not
rebind the <RET> key.
---

But how does one specify the height of the text field?  There's the
:size parameter, bit that's only the width, apparently...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Dmitry Gutov]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> But how does one specify the height of the text field?  There's the
> :size parameter, bit that's only the width, apparently...

<textarea> has `rows':
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea

But the height can be also specified via CSS.

Re: eww

[Lars Magne Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> But how does one specify the height of the text field?  There's the
>> :size parameter, bit that's only the width, apparently...
>
> <textarea> has `rows':
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea

I meant in the widget.el specification.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Lars Magne Ingebrigtsen]

I spent some time doing rendering optimisations in shr today, including
the `add-face-text-properties' C-level functionality.  That, combined
with various caching strategies and trying to avoid doing unnecessary
work when computing how tables should be rendered has made viewing a
typical Wikipedia page 4x faster or something.

So it's still slow, but it's getting more useful.  There's still
probably bugs in there, though.  Give it a whirl:

M-x eww RET google.com

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Stefan Monnier]

> I spent some time doing rendering optimisations in shr today, including
> the `add-face-text-properties' C-level functionality.  That, combined
> with various caching strategies and trying to avoid doing unnecessary
> work when computing how tables should be rendered has made viewing a
> typical Wikipedia page 4x faster or something.

I really like it.  Of course, I don't see why it's in lisp/gnus/ rather
than some other place.

> So it's still slow, but it's getting more useful.  There's still
> probably bugs in there, though.  Give it a whirl:

> M-x eww RET google.com

I try and stay away from Google, but `eww' doesn't work well with
duckduckgo.com (my current least bad choice), it seems.


        Stefan

Re: eww

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I really like it.  Of course, I don't see why it's in lisp/gnus/ rather
> than some other place.

It was just convenient to put it in the Gnus repo while doing the
initial development, since shr had to be changed at the same time, and
Gnus is the primary (or only) user of shr.  But both shr and eww should
be moved to lisp/net.

>> So it's still slow, but it's getting more useful.  There's still
>> probably bugs in there, though.  Give it a whirl:
>
>> M-x eww RET google.com

I forgot that all the latest changes haven't been folded into Emacs bzr
yet, so perhaps one should hold off testing until that happens.  :-)

> I try and stay away from Google, but `eww' doesn't work well with
> duckduckgo.com (my current least bad choice), it seems.

That doesn't work at all, apparently.  I'll have a look what's going on
there...  looks like eww is rendering the form completely wrong.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> That doesn't work at all, apparently.  I'll have a look what's going on
> there...  looks like eww is rendering the form completely wrong.

Ok; I've now gotten duckduckgo to work.  It was a combination of
different rendering bugs and calling widget-convert on the wrong bits.

But the result page displays a problem related to not fetching external
CSS before rendering.  shr doesn't render elements that have "diplay:
none" in style sheets embedded in the page, but eww doesn't fetch
externally linked style sheets.  And the duckduckgo result page
apparently displays a hidden input field at the start of the page, for
some reason or other, so it looks a bit confusing in eww.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Rasmus]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> That doesn't work at all, apparently.  I'll have a look what's going on
>> there...  looks like eww is rendering the form completely wrong.
>
> Ok; I've now gotten duckduckgo to work.  It was a combination of
> different rendering bugs and calling widget-convert on the wrong bits.
>
> But the result page displays a problem related to not fetching external
> CSS before rendering.  shr doesn't render elements that have "diplay:
> none" in style sheets embedded in the page, but eww doesn't fetch
> externally linked style sheets.  And the duckduckgo result page
> apparently displays a hidden input field at the start of the page, for
> some reason or other, so it looks a bit confusing in eww.

Speaking of search engines, I tested startpage.com in eww from the
latest bzr pull of emacs (not Gnus), and the search box doesn't
appear.

Oh, and eww seems quite enjoyable.  Thanks!

–Rasmus

-- 
Don't panic!!!

Re: eww

[Lars Magne Ingebrigtsen]

Rasmus <rasmus@gmx.us> writes:

> Speaking of search engines, I tested startpage.com in eww from the
> latest bzr pull of emacs (not Gnus), and the search box doesn't
> appear.

Is that after the changes that Katsumi pushed half an hour ago?  The
page seems to work for me...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Ted Zlatanov]

On Mon, 17 Jun 2013 23:00:17 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> I spent some time doing rendering optimisations in shr today, including
LMI> the `add-face-text-properties' C-level functionality.  That, combined
LMI> with various caching strategies and trying to avoid doing unnecessary
LMI> work when computing how tables should be rendered has made viewing a
LMI> typical Wikipedia page 4x faster or something.

LMI> So it's still slow, but it's getting more useful.  There's still
LMI> probably bugs in there, though.  Give it a whirl:

LMI> M-x eww RET google.com

You should add commentary with short instructions on making it the
default URL browse action in Gnus.

It's pretty awesome otherwise.

Ted

Re: eww

[Thomas Fitzsimmons]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I spent some time doing rendering optimisations in shr today, including
> the `add-face-text-properties' C-level functionality.  That, combined
> with various caching strategies and trying to avoid doing unnecessary
> work when computing how tables should be rendered has made viewing a
> typical Wikipedia page 4x faster or something.
>
> So it's still slow, but it's getting more useful.  There's still
> probably bugs in there, though.  Give it a whirl:
>
> M-x eww RET google.com

This is fantastic!  I'm going to try to use it wherever Javascript is
not a hard requirement.

Have you considered adopting the same default keybindings as Conkeror?

Thomas

Re: eww

[Lars Magne Ingebrigtsen]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> Have you considered adopting the same default keybindings as Conkeror?

I have no idea what those are, so no.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Thomas Fitzsimmons]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> Have you considered adopting the same default keybindings as Conkeror?
>
> I have no idea what those are, so no.  :-)

Here is a page with exampe key bindings:

http://www.conkeror.org/QuickStart

which eww renders nicely :-)

Conkeror has solved a bunch of problems when it comes to providing an
Emacs-like interface to the web, so it could offer inspiration for eww's
interface.

Thomas

Re: eww

[Lars Magne Ingebrigtsen]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> Here is a page with exampe key bindings:
>
> http://www.conkeror.org/QuickStart

Those keybindings don't seem that obvious to me.  For instance, `g' for
"go to url" when lots of other Emacs modes uses `g' for "reload".  Etc.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Tom Tromey]

Thomas> This is fantastic!  I'm going to try to use it wherever Javascript is
Thomas> not a hard requirement.

One hesitates to mention http://code.google.com/p/ejacs/

Tom

Re: eww

[Lars Magne Ingebrigtsen]

Tom Tromey <tromey@redhat.com> writes:

> Thomas> This is fantastic!  I'm going to try to use it wherever Javascript is
> Thomas> not a hard requirement.
>
> One hesitates to mention http://code.google.com/p/ejacs/

shr doesn't maintain the DOM -- it just renders the HTML as text.  So
there's nothing for a Javascript engine to work against.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Tom Tromey]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

Lars> eww probably has a lot of stuff that could still be fixed up, but
Lars> the basics are working now.  That is, you can search for stuff on
Lars> Google and visit Wikipedia.  :-)

Very nice.

I played with it a bit.

It doesn't render parts of the gdb manual very nicely.
For example in the reverse execution node, the info looks like:

================================================================
   If you are debugging in a target environment that supports reverse
execution, GDB provides the following commands.

`reverse-continue [IGNORE-COUNT]'
`rc [IGNORE-COUNT]'
     Beginning at the point where your program last stopped, start
     executing in reverse.  Reverse execution will stop for breakpoints
     and synchronous exceptions (signals), just like normal execution.
     Behavior of asynchronous signals depends on the target environment.
================================================================

but eww renders it as

================================================================
If you are debugging in a target environment that supports reverse execution,
gdb provides the following commands.

reverse-continue [ignore-count]rc [ignore-count]Beginning at the point where
your program last stopped, start executing in reverse. Reverse execution will
stop for breakpoints and synchronous exceptions (signals), just like normal
execution. Behavior of asynchronous signals depends on the target environment.
================================================================


Also, please consider the appended patch.  It makes eww pick up on
<link> and <a rel=...> to give it a more info-ish flavor.  I'm
interested in the possibility of replacing info with html+eww.

The patch isn't perfect but I thought I'd see what you think before
going any further.

Tom

=== modified file 'lisp/gnus/eww.el'
--- lisp/gnus/eww.el	2013-06-17 23:11:40 +0000
+++ lisp/gnus/eww.el	2013-06-18 02:06:16 +0000
@@ -56,6 +56,15 @@
   "Title of current page.")
 (defvar eww-history nil)
 
+(defvar eww-next-url nil)
+(make-variable-buffer-local 'eww-next-url)
+(defvar eww-previous-url nil)
+(make-variable-buffer-local 'eww-previous-url)
+(defvar eww-up-url nil)
+(make-variable-buffer-local 'eww-up-url)
+(defvar eww-top-url nil)
+(make-variable-buffer-local 'eww-top-url)
+
 ;;;###autoload
 (defun eww (url)
   "Fetch URL and render the page."
@@ -64,6 +73,12 @@
     (setq url (concat "http://" url)))
   (url-retrieve url 'eww-render (list url)))
 
+;;;###autoload
+(defun eww-open-file (file)
+  (interactive "fFile: ")
+  (let ((browse-url-browser-function #'eww-browse-url))
+    (browse-url-of-file (expand-file-name file))))
+
 (defun eww-detect-charset (html-p)
   (let ((case-fold-search t)
 	(pt (point)))
@@ -80,6 +95,10 @@
   (let ((redirect (plist-get status :redirect)))
     (when redirect
       (setq url redirect)))
+  (setq eww-next-url nil)
+  (setq eww-previous-url nil)
+  (setq eww-up-url nil)
+  (setq eww-top-url nil)
   (let* ((headers (eww-parse-headers))
 	 (shr-target-id
 	  (and (string-match "#\\(.*\\)" url)
@@ -146,10 +165,32 @@
 	     (input . eww-tag-input)
 	     (textarea . eww-tag-textarea)
 	     (body . eww-tag-body)
-	     (select . eww-tag-select))))
+	     (select . eww-tag-select)
+	     (link . eww-tag-link)
+	     (a . eww-tag-a))))
       (shr-insert-document document)
       (eww-convert-widgets))
-    (goto-char (point-min))))
+      (goto-char (point-min))))
+
+(defun eww-handle-link (cont)
+  (let* ((rel (assq :rel cont))
+  	(href (assq :href cont))
+	(where (assoc (cdr rel)
+		      '(("next" . eww-next-url)
+			("previous" . eww-previous-url)
+			("start" . eww-top-url)
+			("up" . eww-up-url)))))
+    (and href
+	 where
+	 (set (cdr where) (cdr href)))))
+
+(defun eww-tag-link (cont)
+  (eww-handle-link cont)
+  (shr-generic cont))
+
+(defun eww-tag-a (cont)
+  (eww-handle-link cont)
+  (shr-tag-a cont))
 
 (defun eww-update-header-line-format ()
   (if eww-header-line-format
@@ -218,8 +259,11 @@
     (define-key map [delete] 'scroll-down-command)
     (define-key map "\177" 'scroll-down-command)
     (define-key map " " 'scroll-up-command)
+    (define-key map "l" 'eww-back-url)
+    (define-key map "n" 'eww-next-url)
     (define-key map "p" 'eww-previous-url)
-    ;;(define-key map "n" 'eww-next-url)
+    (define-key map "u" 'eww-up-url)
+    (define-key map "t" 'eww-top-url)
     map))
 
 (define-derived-mode eww-mode nil "eww"
@@ -240,7 +284,7 @@
   (setq eww-history nil)
   (kill-buffer (current-buffer)))
 
-(defun eww-previous-url ()
+(defun eww-back-url ()
   "Go to the previously displayed page."
   (interactive)
   (when (zerop (length eww-history))
@@ -248,6 +292,30 @@
   (let ((prev (pop eww-history)))
     (url-retrieve (car prev) 'eww-render (list (car prev) (cadr prev)))))
 
+(defun eww-next-url ()
+  (interactive)
+  (if eww-next-url
+      (eww-browse-url (shr-expand-url eww-next-url eww-current-url))
+    (error "No `next' on this node")))
+
+(defun eww-previous-url ()
+  (interactive)
+  (if eww-previous-url
+      (eww-browse-url (shr-expand-url eww-previous-url eww-current-url))
+    (error "No `previous' on this node")))
+
+(defun eww-up-url ()
+  (interactive)
+  (if eww-up-url
+      (eww-browse-url (shr-expand-url eww-up-url eww-current-url))
+    (error "No `up' on this node")))
+
+(defun eww-top-url ()
+  (interactive)
+  (if eww-top-url
+      (eww-browse-url (shr-expand-url eww-top-url eww-current-url))
+    (error "No `top' on this node")))
+
 (defun eww-reload ()
   "Reload the current page."
   (interactive)

Re: eww

[Lars Magne Ingebrigtsen]

Tom Tromey <tromey@redhat.com> writes:

> It doesn't render parts of the gdb manual very nicely.
> For example in the reverse execution node, the info looks like:
>
> ================================================================
>    If you are debugging in a target environment that supports reverse
> execution, GDB provides the following commands.
>
> `reverse-continue [IGNORE-COUNT]'
> `rc [IGNORE-COUNT]'
>      Beginning at the point where your program last stopped, start
>      executing in reverse.  Reverse execution will stop for breakpoints
>      and synchronous exceptions (signals), just like normal execution.
>      Behavior of asynchronous signals depends on the target environment.
> ================================================================

Heh.  This is because the manual uses the <dl>, <dd> and <dt> tags,
which I didn't even know existed.  :-)

I've now added support for this.

> Also, please consider the appended patch.  It makes eww pick up on
> <link> and <a rel=...> to give it a more info-ish flavor.  I'm
> interested in the possibility of replacing info with html+eww.

Supporting <link> and <a rel=> is a good idea.  The code looks good, but
here's a couple of comments:

> +(defvar eww-next-url nil)
> +(make-variable-buffer-local 'eww-next-url)
> +(defvar eww-previous-url nil)
> +(make-variable-buffer-local 'eww-previous-url)
> +(defvar eww-up-url nil)
> +(make-variable-buffer-local 'eww-up-url)
> +(defvar eww-top-url nil)
> +(make-variable-buffer-local 'eww-top-url)

I think that for package-specific variables like this we're supposed to
use

(set (make-local-variable 'eww-top-url) nil)

in the mode setup instead, so that we're not making variables needlessly
globally buffer-local.

> +(defun eww-open-file (file)
> +  (interactive "fFile: ")
> +  (let ((browse-url-browser-function #'eww-browse-url))
> +    (browse-url-of-file (expand-file-name file))))

Can't we just prepend "file://" to the file name and call `eww'
directly?

> +(defun eww-next-url ()
> +  (interactive)
> +  (if eww-next-url
> +      (eww-browse-url (shr-expand-url eww-next-url eww-current-url))
> +    (error "No `next' on this node")))

Perhaps say "page" instead of "node".

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Tom Tromey]

Lars> Heh.  This is because the manual uses the <dl>, <dd> and <dt> tags,
Lars> which I didn't even know existed.  :-)

Lars> I've now added support for this.

Thanks.

On the same node in the gdb manual, on an 80-column terminal, some of
the paragraph wrap improperly.  E.g., shr renders one as:

================================================================
When you are debugging a program, it is not unusual to realize that you have
gone too far, and some event of interest has already happened. If the target
environment supports it, gdb can allow you to “rewind” the program by running i\
t
backward.
================================================================


If you have 80 columns, the "it" at the end of the 3rd line is split in
the middle.

Can shr not use word-wrap?  Anyhow, the wrapping code is complicated &
spread out enough that I didn't look into it.

Tom

Re: eww

[Lars Magne Ingebrigtsen]

Tom Tromey <tromey@redhat.com> writes:

> On the same node in the gdb manual, on an 80-column terminal, some of
> the paragraph wrap improperly.  E.g., shr renders one as:
>
> ================================================================
> When you are debugging a program, it is not unusual to realize that you have
> gone too far, and some event of interest has already happened. If the target
> environment supports it, gdb can allow you to “rewind” the program by running i\
> t
> backward.
> ================================================================
>
> If you have 80 columns, the "it" at the end of the 3rd line is split in
> the middle.
>
> Can shr not use word-wrap?  Anyhow, the wrapping code is complicated &
> spread out enough that I didn't look into it.

Oh course shr wraps the text, but it was using `window-width' as the
width, while it should have used one less than that.  Fixed now.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Tom Tromey]

>> Can shr not use word-wrap?  Anyhow, the wrapping code is complicated &
>> spread out enough that I didn't look into it.

Lars> Oh course shr wraps the text, but it was using `window-width' as the
Lars> width, while it should have used one less than that.  Fixed now.

Yeah, I was curious about why it doesn't use (setq word-wrap t) and then
not insert hard newlines.

Thanks for the fix.

Tom

Re: eww

[Tom Tromey]

Lars> Supporting <link> and <a rel=> is a good idea.  The code looks good, but
Lars> here's a couple of comments:

Thanks.

Here's a version that addresses your comments and adds doc strings and a
ChangeLog entry.  Let me know what you think.

Tom

=== modified file 'lisp/gnus/ChangeLog'
--- lisp/gnus/ChangeLog	2013-06-18 11:24:16 +0000
+++ lisp/gnus/ChangeLog	2013-06-18 14:39:03 +0000
@@ -1,3 +1,16 @@
+2013-06-18  Tom Tromey  <tromey@barimba>
+
+	* eww.el (eww-next-url, eww-previous-url, eww-up-url, eww-top-url):
+	New defvars.
+	(eww-open-file): New defun.
+	(eww-render): Initialize new variables.
+	(eww-display-html): Handle "link" and "a".
+	(eww-handle-link, eww-tag-link, eww-tag-a): New defuns.
+	(eww-mode-map): Move "p" to "l".  Bind "p", "n", "t", and "u".
+	(eww-back-url): Rename from eww-previous-url.
+	(eww-next-url, eww-previous-url, eww-up-url, eww-top-url): New
+	defuns.
+
 2013-06-18  Lars Magne Ingebrigtsen  <larsi@gnus.org>
 
 	* shr.el (shr-tag-table): Insert the images after the table, so that

=== modified file 'lisp/gnus/eww.el'
--- lisp/gnus/eww.el	2013-06-18 09:29:20 +0000
+++ lisp/gnus/eww.el	2013-06-18 14:39:01 +0000
@@ -56,6 +56,11 @@
   "Title of current page.")
 (defvar eww-history nil)
 
+(defvar eww-next-url nil)
+(defvar eww-previous-url nil)
+(defvar eww-up-url nil)
+(defvar eww-top-url nil)
+
 ;;;###autoload
 (defun eww (url)
   "Fetch URL and render the page."
@@ -64,10 +69,20 @@
     (setq url (concat "http://" url)))
   (url-retrieve url 'eww-render (list url)))
 
+;;;###autoload
+(defun eww-open-file (file)
+  "Render a file using EWW."
+  (interactive "fFile: ")
+  (eww (concat "file://" (expand-file-name file))))
+
 (defun eww-render (status url &optional point)
   (let ((redirect (plist-get status :redirect)))
     (when redirect
       (setq url redirect)))
+  (set (make-local-variable 'eww-next-url) nil)
+  (set (make-local-variable 'eww-previous-url) nil)
+  (set (make-local-variable 'eww-up-url) nil)
+  (set (make-local-variable 'eww-top-url) nil)
   (let* ((headers (eww-parse-headers))
 	 (shr-target-id
 	  (and (string-match "#\\(.*\\)" url)
@@ -146,11 +161,33 @@
 	     (input . eww-tag-input)
 	     (textarea . eww-tag-textarea)
 	     (body . eww-tag-body)
-	     (select . eww-tag-select))))
+	     (select . eww-tag-select)
+	     (link . eww-tag-link)
+	     (a . eww-tag-a))))
       (shr-insert-document document)
       (eww-convert-widgets))
     (goto-char (point-min))))
 
+(defun eww-handle-link (cont)
+  (let* ((rel (assq :rel cont))
+  	(href (assq :href cont))
+	(where (assoc (cdr rel)
+		      '(("next" . eww-next-url)
+			("previous" . eww-previous-url)
+			("start" . eww-top-url)
+			("up" . eww-up-url)))))
+    (and href
+	 where
+	 (set (cdr where) (cdr href)))))
+
+(defun eww-tag-link (cont)
+  (eww-handle-link cont)
+  (shr-generic cont))
+
+(defun eww-tag-a (cont)
+  (eww-handle-link cont)
+  (shr-tag-a cont))
+
 (defun eww-update-header-line-format ()
   (if eww-header-line-format
       (setq header-line-format (format-spec eww-header-line-format
@@ -218,8 +255,11 @@
     (define-key map [delete] 'scroll-down-command)
     (define-key map "\177" 'scroll-down-command)
     (define-key map " " 'scroll-up-command)
+    (define-key map "l" 'eww-back-url)
+    (define-key map "n" 'eww-next-url)
     (define-key map "p" 'eww-previous-url)
-    ;;(define-key map "n" 'eww-next-url)
+    (define-key map "u" 'eww-up-url)
+    (define-key map "t" 'eww-top-url)
     map))
 
 (define-derived-mode eww-mode nil "eww"
@@ -240,7 +280,7 @@
   (setq eww-history nil)
   (kill-buffer (current-buffer)))
 
-(defun eww-previous-url ()
+(defun eww-back-url ()
   "Go to the previously displayed page."
   (interactive)
   (when (zerop (length eww-history))
@@ -248,6 +288,42 @@
   (let ((prev (pop eww-history)))
     (url-retrieve (car prev) 'eww-render (list (car prev) (cadr prev)))))
 
+(defun eww-next-url ()
+  "Go to the page marked `next'.
+A page is marked `next' if rel=\"next\" appears in a <link>
+or <a> tag."
+  (interactive)
+  (if eww-next-url
+      (eww-browse-url (shr-expand-url eww-next-url eww-current-url))
+    (error "No `next' on this page")))
+
+(defun eww-previous-url ()
+  "Go to the page marked `previous'.
+A page is marked `previous' if rel=\"previous\" appears in a <link>
+or <a> tag."
+  (interactive)
+  (if eww-previous-url
+      (eww-browse-url (shr-expand-url eww-previous-url eww-current-url))
+    (error "No `previous' on this page")))
+
+(defun eww-up-url ()
+  "Go to the page marked `up'.
+A page is marked `up' if rel=\"up\" appears in a <link>
+or <a> tag."
+  (interactive)
+  (if eww-up-url
+      (eww-browse-url (shr-expand-url eww-up-url eww-current-url))
+    (error "No `up' on this page")))
+
+(defun eww-top-url ()
+  "Go to the page marked `top'.
+A page is marked `top' if rel=\"start\" appears in a <link>
+or <a> tag."
+  (interactive)
+  (if eww-top-url
+      (eww-browse-url (shr-expand-url eww-top-url eww-current-url))
+    (error "No `top' on this page")))
+
 (defun eww-reload ()
   "Reload the current page."
   (interactive)

Re: eww

[Lars Magne Ingebrigtsen]

Tom Tromey <tromey@redhat.com> writes:

> Here's a version that addresses your comments and adds doc strings and a
> ChangeLog entry.  Let me know what you think.

Looks good; applied.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Lars Magne Ingebrigtsen]

Currently eww uses a single buffer, and whenever you ask it to display a
new URL, it discards everything in the buffer.  This means that when you
want to return to the previous page, eww has to re-fetch and re-render
the page.  And you lose the data in <form>s you have filled out.

Would it make more sense for eww to use new buffers every time?  eww
would have a backlog of, say, ten buffers, and going back to the
previous page would just mean popping to the previous buffer.  And it
could use `bury-buffer' and rename the previous buffer to a name with
something leading with " " when you go to a new page.

Opinions?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 18 Jun 2013 17:48:47 +0200
> 
> Would it make more sense for eww to use new buffers every time?  eww
> would have a backlog of, say, ten buffers, and going back to the
> previous page would just mean popping to the previous buffer.

Why do you want to limit the number of buffers Emacs keeps?  Other
browsers don't, I think.

When you go back to a previously visited URL, do you need to check if
it's outdated?  Do other browsers?  If not, just displaying the same
buffer is all you need to do.

> And it could use `bury-buffer' and rename the previous buffer to a
> name with something leading with " " when you go to a new page.

I'm confused: don't you name each buffer according to the URL it
shows?  (No, I didn't yet try eww.el.)  If so, the names are already
different.

Re: eww

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Why do you want to limit the number of buffers Emacs keeps?

C-x C-b, among others.  Of course if the names have leading spaces,
that's not a problem.

 > Other browsers don't, I think.

They don't have generic buffer-listing facilities.

 > When you go back to a previously visited URL, do you need to check if
 > it's outdated?

Yes, if it's expired.  Expiration should be parsed from the HTTP
headers and could be cached as a buffer-local.

 > Do other browsers?

Good ones do.

 > > And it could use `bury-buffer' and rename the previous buffer to a
 > > name with something leading with " " when you go to a new page.
 > 
 > I'm confused: don't you name each buffer according to the URL it
 > shows?  (No, I didn't yet try eww.el.)  If so, the names are already
 > different.

index.html?  Pages identified by long strings of query variables?

Re: eww

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Why do you want to limit the number of buffers Emacs keeps?  Other
> browsers don't, I think.

Other buffers don't keep the page around in memory at all, but most of
them have some sort of caching ability -- by writing the HTML/CSS/etc do
disk, and going back in history just fetches the data and re-renders it.

> When you go back to a previously visited URL, do you need to check if
> it's outdated?  Do other browsers?

Other browsers do, and I hate that behaviour.  If I want to see the page
I just saw, why shouldn't I be able to?  Other browsers respect cache
settings and (sensibly) don't write stuff to the disk cache if the
server says it shouldn't.  But Emacs could keep (some) buffers around
and avoid the problem.

There's a potential security issue here, though -- if the server said
"don't cache this page", then it might be because there's secret stuff
that we shouldn't keep around longer than the user expects it to be kept
around.

> I'm confused: don't you name each buffer according to the URL it
> shows?

No, the eww buffer is currently called "*eww*".

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 19 Jun 2013 08:58:36 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why do you want to limit the number of buffers Emacs keeps?  Other
> > browsers don't, I think.
> 
> Other buffers don't keep the page around in memory at all, but most of
> them have some sort of caching ability -- by writing the HTML/CSS/etc do
> disk, and going back in history just fetches the data and re-renders it.

Well, the best cache in Emacs is a buffer. ;-)

Re: eww

[Karl Fogel]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>Currently eww uses a single buffer, and whenever you ask it to display a
>new URL, it discards everything in the buffer.  This means that when you
>want to return to the previous page, eww has to re-fetch and re-render
>the page.  And you lose the data in <form>s you have filled out.
>
>Would it make more sense for eww to use new buffers every time?  eww
>would have a backlog of, say, ten buffers, and going back to the
>previous page would just mean popping to the previous buffer.  And it
>could use `bury-buffer' and rename the previous buffer to a name with
>something leading with " " when you go to a new page.
>
>Opinions?

I second the questions Eli asked, but FWIW:

No reason to limit the number of buffers here.  It makes sense to always
keep them except when the user explicitly kills one (or sets some var
indicating that eww should kill buffers).  Each buffer has a "reload"
keybinding, right?  And when a user goes to a URL that eww already has a
buffer for, it can reuse that buffer and do the reload.

The edge case question is: if you have filled-out form data in a buffer,
and then eww does a reload, should it toss your data?  In that case, I
think it makes sense to rename the original buffer -- the one with the
filled-out form data -- to "buffer<N>" where N increases, and reload
into "buffer".  In other words, if someone panics and realizes they
shouldn't have thrown away the novel they wrote in that gigantic text
form, at least there is a way to recover it (from the "<N>" buffer).

Very excited about eww!

-K

Re: eww

[Eli Zaretskii]

EWW looks quite good, thanks.  A few comments, based on 5 min of using
it:

 . Mouse clicks on hyper links don't do what I'd expect in a Web
   browser.

 . Images embedded in the pages somehow get newlines before and after
   them, which looks ugly: each image is alone on its own line.  E.g.,
   in Wikipedia, look at any page that shows formulae.  Ugly.

 . Need more key bindings (I see only 3 for now).  E.g., using 'p' to
   go to the previous URL should be augmented by at least M-<left>.

 . Buttons on the tool bar are sorely missed.

Re: eww

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> EWW looks quite good, thanks.  A few comments, based on 5 min of using
> it:
>
>  . Mouse clicks on hyper links don't do what I'd expect in a Web
>    browser.

I've now bound mouse-1:

+    (define-key map [down-mouse-1] 'shr-browse-url)

But I seem to remember there being different conventions for what mouse
button should be the "action" button?  Or is binding mouse-1 still the
right thing to do?

Speaking of keymaps, eww/shr uses the `local-map' text property to bind
actions on links.  Is there a way to make the major mode map keys work
even if you're standing on text with `local-map'?

That is, eww-mode binds (for instance) the `g' key (for reloading the
page), but if I hit `g' on text that has a `local-map' text property
(and which doesn't bind `g' itself), it's then bound to
`self-insert-command', which is not what I want.

>  . Images embedded in the pages somehow get newlines before and after
>    them, which looks ugly: each image is alone on its own line.  E.g.,
>    in Wikipedia, look at any page that shows formulae.  Ugly.

Yes.  There's two problems:

1) Images are inserted asynchronously, so shr has no idea how big the
images are when it renders the text.  shr could wait until it's loaded
all the images, but that would be slow and awkward, or it could re-flow
the text, which it doesn't have enough data at that point to do.

2) When rendering tables, shr tries to keep everything lined up.  Even
if it knew how big the images are (which it doesn't), the Emacs display
engine isn't powerful enough to line stuff up vertically when there's
elements of different sizes.  So it can't.

>  . Need more key bindings (I see only 3 for now).  E.g., using 'p' to
>    go to the previous URL should be augmented by at least M-<left>.

I don't want to re-bind any common cursor-related keys.

>  . Buttons on the tool bar are sorely missed.

What kind of buttons?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Is there a way to make the major mode map keys work even if you're
> standing on text with `local-map'?

Make the current local map the parent of the local-map property.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: eww

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@suse.de> writes:

>> Is there a way to make the major mode map keys work even if you're
>> standing on text with `local-map'?
>
> Make the current local map the parent of the local-map property.

Hm...  the button keymap (in this case, `shr-map') would then have to be
copied in some sort of setup function, because `set-keymap-parent' is
destructive, isn't it?  And you can use shr to render HTML i various
modes.

If you use overlays with :keymap, then Emacs will automatically "fall
through" the map if you hit a key which isn't bound in the :keymap
keymap, I think.  Would it be possible to make text properties
`local-map' work the same way?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Would it be possible to make text properties `local-map' work the same
> way?

What's wrong with the keymap property?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: eww

[Stefan Monnier]

> I've now bound mouse-1:
> +    (define-key map [down-mouse-1] 'shr-browse-url)

Please don't do that and use the follow-link thingy instead, so that it
obeys mouse-1-click-follows-link.

> Speaking of keymaps, eww/shr uses the `local-map' text property to bind
> actions on links.

Don't.  You want to use the `keymap' property (the `local-map' property
is mostly a historical accident).

> Is there a way to make the major mode map keys work
> even if you're standing on text with `local-map'?

Yes: use the `keymap' property.


        Stefan

Re: eww

[Stefan Monnier]

> Don't.  You want to use the `keymap' property (the `local-map' property
> is mostly a historical accident).

Of course, the `local-map' can be occasionally useful.  E.g. for
editable fields in a buffer that's mostly read-only.


        Stefan

Re: eww

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I've now bound mouse-1:
>> +    (define-key map [down-mouse-1] 'shr-browse-url)
>
> Please don't do that and use the follow-link thingy instead, so that it
> obeys mouse-1-click-follows-link.

I tried grepping around.  Should that be?

    (define-key map [follow-link] 'mouse-face)

It doesn't seem to do anything...

>> Is there a way to make the major mode map keys work
>> even if you're standing on text with `local-map'?
>
> Yes: use the `keymap' property.

Well, that was easy.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Stefan Monnier]

>>> I've now bound mouse-1:
>>> +    (define-key map [down-mouse-1] 'shr-browse-url)
>> Please don't do that and use the follow-link thingy instead, so that it
>> obeys mouse-1-click-follows-link.
> I tried grepping around.  Should that be?
>     (define-key map [follow-link] 'mouse-face)

Yes.

> It doesn't seem to do anything...

It should.  Maybe you put it in the wrong map?


        Stefan

Re: eww

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I tried grepping around.  Should that be?
>>     (define-key map [follow-link] 'mouse-face)
>
> Yes.
>
>> It doesn't seem to do anything...
>
> It should.  Maybe you put it in the wrong map?

I don't think so -- it's in the keymap that shr puts on links, and the
rest of the keys work.  But hitting mouse-1, for instance, just gives
me:

<down-mouse-1> at that spot runs the command mouse-drag-region, which
is an interactive compiled Lisp function in `mouse.el'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 19 Jun 2013 09:13:07 +0200
> 
> >  . Images embedded in the pages somehow get newlines before and after
> >    them, which looks ugly: each image is alone on its own line.  E.g.,
> >    in Wikipedia, look at any page that shows formulae.  Ugly.
> 
> Yes.  There's two problems:
> 
> 1) Images are inserted asynchronously, so shr has no idea how big the
> images are when it renders the text.

Don't you have some pixel size information about each image in the
page?

> shr could wait until it's loaded all the images, but that would be
> slow and awkward, or it could re-flow the text, which it doesn't
> have enough data at that point to do.

You could have an option to make it wait, I personally don't believe
it will slow things down.  Alternatively, reflowing when an image is
inserted doesn't sound too hard, either.

> 2) When rendering tables, shr tries to keep everything lined up.  Even
> if it knew how big the images are (which it doesn't), the Emacs display
> engine isn't powerful enough to line stuff up vertically when there's
> elements of different sizes.  So it can't.

Does the 'space' display spec fit that bill?

> >  . Buttons on the tool bar are sorely missed.
> 
> What kind of buttons?

At the very least, Back, Forward, Reload, and Cancel.

Re: eww

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Don't you have some pixel size information about each image in the
> page?

Usually not.

> You could have an option to make it wait, I personally don't believe
> it will slow things down.  Alternatively, reflowing when an image is
> inserted doesn't sound too hard, either.

Fetching and inserting images is a huge slow-down.  I've been using shr
to read blogs for years, and the images sometimes arrive, and sometimes
they don't.

>> 2) When rendering tables, shr tries to keep everything lined up.  Even
>> if it knew how big the images are (which it doesn't), the Emacs display
>> engine isn't powerful enough to line stuff up vertically when there's
>> elements of different sizes.  So it can't.
>
> Does the 'space' display spec fit that bill?

Hm.  I didn't know about that one, but it seems promising.  However,
images are displayed thusly:

    (add-text-properties start (point)
			 `(display ,(if slice
					(list (cons 'slice slice) image)
				      image) rear-nonsticky (display)))))

Can `display' have both an image and a `space' spec?

>> What kind of buttons?
>
> At the very least, Back, Forward, Reload, and Cancel.

Yeah, that makes sense.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 19 Jun 2013 21:46:37 +0200
> 
>     (add-text-properties start (point)
> 			 `(display ,(if slice
> 					(list (cons 'slice slice) image)
> 				      image) rear-nonsticky (display)))))
> 
> Can `display' have both an image and a `space' spec?

I don't see why not.

Re: eww

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Can `display' have both an image and a `space' spec?
>
> I don't see why not.

I tried altering `insert-image' to the the following, and I got nothing
but blankness:

    (add-text-properties start (point)
			 `(display
			   (list
			    (space :align-to 40)
			    ,(if slice
				 (list (cons 'slice slice) image)
			       image))
			   rear-nonsticky (display)))))


-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Johan Bockgård]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 19 Jun 2013 21:46:37 +0200
>> 
>>     (add-text-properties start (point)
>> 			 `(display ,(if slice
>> 					(list (cons 'slice slice) image)
>> 				      image) rear-nonsticky (display)))))
>> 
>> Can `display' have both an image and a `space' spec?
>
> I don't see why not.

(info "(elisp) Replacing Specs")

    If a list of display specifications includes more than one replacing
    display specification, the first overrides the rest.

Re: eww

[Stefan Monnier]

>     (add-text-properties start (point)
> 			 `(display ,(if slice
> 					(list (cons 'slice slice) image)
> 				      image) rear-nonsticky (display)))))

> Can `display' have both an image and a `space' spec?

Usually the space spec is placed on the text before the image, so it's
not applied to the same text.


        Stefan

Re: eww

[Ted Zlatanov]

On Tue, 18 Jun 2013 17:48:47 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Currently eww uses a single buffer, and whenever you ask it to display a
LMI> new URL, it discards everything in the buffer.  This means that when you
LMI> want to return to the previous page, eww has to re-fetch and re-render
LMI> the page.  And you lose the data in <form>s you have filled out.

LMI> Would it make more sense for eww to use new buffers every time?  eww
LMI> would have a backlog of, say, ten buffers, and going back to the
LMI> previous page would just mean popping to the previous buffer.  And it
LMI> could use `bury-buffer' and rename the previous buffer to a name with
LMI> something leading with " " when you go to a new page.

At least I would prefer undo/redo to go back and forth in the history of
the current eww buffer, and an explicit "browse in new eww buffer"
command.

Speaking of conveniences, could `next-error' and `previous-error' move
between anchors?

Thanks!
Ted

Re: eww

[Stefan Monnier]

> At least I would prefer undo/redo to go back and forth in the history of
> the current eww buffer, and an explicit "browse in new eww buffer"
> command.

Agreed.  I don't think creating a new buffer for every page is
a good idea.  Also going back to a previously displayed page should be
"immediate" and not require any network communication.
You might start with something like:

  (push (cons (buffer-string) (buffer-local-variables)) eww-history)

> Speaking of conveniences, could `next-error' and `previous-error' move
> between anchors?

Sounds like a bad idea.


        Stefan

Re: eww

[Ted Zlatanov]

On Tue, 18 Jun 2013 16:19:21 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

Ted wrote:
>> Speaking of conveniences, could `next-error' and `previous-error' move
>> between anchors?

SM> Sounds like a bad idea.

The most common navigations in a web page are page up/page down
and next/previous anchor.

Typically (e.g. emacs-w3m integration) TAB and S-TAB move between
anchors, but I see no reason `next-error' and `previous-error' can't
also be used.  Do you?

Ted

Re: eww

[Stefan Monnier]

> Typically (e.g. emacs-w3m integration) TAB and S-TAB move between
> anchors, but I see no reason `next-error' and `previous-error' can't
> also be used.  Do you?

They're completely different operations.  `next-error' lets you step
through the destination points of references (which are in
a "compilation" buffer).  The commands you suggest move between
different points of the current buffer with no reference to some
"compilation" buffer.


        Stefan

Re: eww

[Ted Zlatanov]

On Tue, 18 Jun 2013 19:21:26 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Typically (e.g. emacs-w3m integration) TAB and S-TAB move between
>> anchors, but I see no reason `next-error' and `previous-error' can't
>> also be used.  Do you?

SM> They're completely different operations.  `next-error' lets you step
SM> through the destination points of references (which are in
SM> a "compilation" buffer).  The commands you suggest move between
SM> different points of the current buffer with no reference to some
SM> "compilation" buffer.

OK.  Thanks for explaining, I'll keep that distinction in mind.

Ted

Re: eww

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Agreed.  I don't think creating a new buffer for every page is
> a good idea.  Also going back to a previously displayed page should be
> "immediate" and not require any network communication.
> You might start with something like:
>
>   (push (cons (buffer-string) (buffer-local-variables)) eww-history)

eww currently uses widget.el to render forms, and that uses overlays and
... stuff.  But I think I'm going to rewrite that code to avoid widget,
because it turns out that it's more hassle than it's worth.  And
implementing the form elements myself probably won't be more code than
shoehorning the widget code into eww.

And then keeping the history in a variable instead of in buffers would
be simpler.

Speaking of forms, perhaps form data should be nixed out before saving
to history -- we wouldn't want passwords and the like to live in memory
forever.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Christopher Schmidt]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>  Also going back to a previously displayed page should be "immediate"
> and not require any network communication.

The Cache-Control header field of the response should be honoured,
though?

        Christopher

Re: eww

[Stefan Monnier]

>> Also going back to a previously displayed page should be "immediate"
>> and not require any network communication.
> The Cache-Control header field of the response should be honoured,
> though?

That's for the case where you go the same URL.  When I go back in my
history, I don't just want to see the same web-page, I want to see it in
the exact state I left it (e.g. with whatever text I had typed into the
forms, with point at the same place, ...).
And most importantly, I want to be able to see it even if the network
connection went down.

So, no, when going back in my history I do *not* want to honor stuff
like Cache-Control.


        Stefan

Re: eww

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> That's for the case where you go the same URL.  When I go back in my
> history, I don't just want to see the same web-page, I want to see it in
> the exact state I left it (e.g. with whatever text I had typed into the
> forms, with point at the same place, ...).
> And most importantly, I want to be able to see it even if the network
> connection went down.
>
> So, no, when going back in my history I do *not* want to honor stuff
> like Cache-Control.

That would be my preference, too, but there are security implications.
Like today's story:

http://it.slashdot.org/story/13/06/20/0250206/21-financial-sites-found-to-store-sensitive-data-in-browser-disk-cache

Now, eww won't store things in on disk, but if we're storing all this
stuff in memory indefinitely, we're leaving the users open for various
attacks on their privacy.

Like I said, my preference would be to leave everything in memory
myself, because I think this attack vector is pretty, er, slim (i.e.,
"if this is a problem, then my machine is already hacked, so why
worry?"), but as a default policy, I think it's problematic.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Stefan Monnier]

> Now, eww won't store things in on disk, but if we're storing all this
> stuff in memory indefinitely, we're leaving the users open for various
> attacks on their privacy.

Sounds highly hypothetical.  If/when eww can be used to access such
sites, maybe we can start worrying, but then even if you don't keep it
in live data, the sensitive data may linger around in
"garbage/free" memory.  If you need to worry about that, you need to
worry about a lot more than that.


        Stefan

Re: eww

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Sounds highly hypothetical.  If/when eww can be used to access such
> sites, maybe we can start worrying, but then even if you don't keep it
> in live data, the sensitive data may linger around in
> "garbage/free" memory.  If you need to worry about that, you need to
> worry about a lot more than that.

It's a matter of how big the attack surface is.  Leaving the data in
easily accessible structures indefinitely is a larger attack surface
than killing off the buffer where the offending data is.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Ted Zlatanov]

On Fri, 21 Jun 2013 08:58:09 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Sounds highly hypothetical.  If/when eww can be used to access such
>> sites, maybe we can start worrying, but then even if you don't keep it
>> in live data, the sensitive data may linger around in
>> "garbage/free" memory.  If you need to worry about that, you need to
>> worry about a lot more than that.

LMI> It's a matter of how big the attack surface is.  Leaving the data in
LMI> easily accessible structures indefinitely is a larger attack surface
LMI> than killing off the buffer where the offending data is.

This seems like a sensible use case for an opaque data type (as I've
proposed before) that offers some guarantees that it's stored and wiped
in a more secure manner than the default.

Ted

Re: eww

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> This seems like a sensible use case for an opaque data type (as I've
> proposed before) that offers some guarantees that it's stored and wiped
> in a more secure manner than the default.

Yes, I think the eww history would be an excellent place to use an
opaque data type.  That way passwords and the like won't possibly be
accidentally displayed when dumping variables in bug reports and the
like, for instance.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Lars Magne Ingebrigtsen]

I've now implemented a version of the history that I think might make
sense, and I've done it by stashing the rendered data in a variable, not
by renaming buffers.

There's now no re-rendering when traversing the history.

The main thing I had to figure out was how to handle back/forth history
movements.  Let me explain.

Here's how Firefox does it:

You're on page A, go to page B, go back to A, go to C.  Back will then
take you to A, and there the history stops.  Going forward will only
take you to C, never to B, which is now inaccessible, as far as I can
tell.

That's supremely annoying, so here's how eww does it:

You're on page A, go to page B, go back to A, go to C.  Back goes to A.
Back again goes to B.  Back again goes to A.  Forward to B, forward to
A, forward to C.  Etc.  If I've implemented it correctly.

So Firefox lets you explore the branch of the tree you're in, and other
branches are cut off, while eww gives you a strict, er, temporal, flat
view of history, so all parts of the history are accessible.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Daimrod]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I've now implemented a version of the history that I think might make
> sense, and I've done it by stashing the rendered data in a variable, not
> by renaming buffers.
>
> There's now no re-rendering when traversing the history.
>
> The main thing I had to figure out was how to handle back/forth history
> movements.  Let me explain.
>
> Here's how Firefox does it:
>
> You're on page A, go to page B, go back to A, go to C.  Back will then
> take you to A, and there the history stops.  Going forward will only
> take you to C, never to B, which is now inaccessible, as far as I can
> tell.
>
> That's supremely annoying, so here's how eww does it:
>
> You're on page A, go to page B, go back to A, go to C.  Back goes to A.
> Back again goes to B.  Back again goes to A.  Forward to B, forward to
> A, forward to C.  Etc.  If I've implemented it correctly.

That sounds nice but what about providing an interface to visualize the
tree? w3m-history in emacs-w3m does exactly that and IMHO it's easier to
use, in the same way, undo-tree is easier to use than the undo/redo
commands.

> So Firefox lets you explore the branch of the tree you're in, and other
> branches are cut off, while eww gives you a strict, er, temporal, flat
> view of history, so all parts of the history are accessible.

-- 
Daimrod/Greg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: eww

[Lars Magne Ingebrigtsen]

Daimrod <daimrod@gmail.com> writes:

> That sounds nice but what about providing an interface to visualize the
> tree? w3m-history in emacs-w3m does exactly that and IMHO it's easier to
> use, in the same way, undo-tree is easier to use than the undo/redo
> commands.

Sure, displaying the history would probably also be nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Ted Zlatanov]

On Tue, 18 Jun 2013 17:48:47 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Currently eww uses a single buffer, and whenever you ask it to display a
LMI> new URL, it discards everything in the buffer.  This means that when you
LMI> want to return to the previous page, eww has to re-fetch and re-render
LMI> the page.  And you lose the data in <form>s you have filled out.

(Let me know if I should implement the following ideas, or if they suck :)

Besides the already-discussed navigation buffer, IMO eww should create a
new buffer on demand when the user asks to see the HTML source.
Probably `v' would be the right command for that.

For accessibility (e.g. if the HTML is completely garbled or if the user
is unable to read it), it would be very nice to pop up a buffer with
just the list of anchors, where up/down are bound to step through the
list and RET browses the anchor.

Ted

Re: eww

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Besides the already-discussed navigation buffer, IMO eww should create a
> new buffer on demand when the user asks to see the HTML source.
> Probably `v' would be the right command for that.

Sure, popping to a new buffer would make sense to view source.

> For accessibility (e.g. if the HTML is completely garbled or if the user
> is unable to read it), it would be very nice to pop up a buffer with
> just the list of anchors, where up/down are bound to step through the
> list and RET browses the anchor.

Hm...  I'm not sure that sounds very useful to me.  libxml2 is pretty
good at parsing HTML, and TAB works fine for stepping though all the
links.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Ted Zlatanov]

On Wed, 19 Jun 2013 09:25:24 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Besides the already-discussed navigation buffer, IMO eww should create a
>> new buffer on demand when the user asks to see the HTML source.
>> Probably `v' would be the right command for that.

LMI> Sure, popping to a new buffer would make sense to view source.

Let me know if you're planning to implement this or not (so I can do it,
if not you).

Ted

Re: eww

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Let me know if you're planning to implement this or not (so I can do it,
> if not you).

Sure, go ahead.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

On Thu, 20 Jun 2013 11:01:47 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Let me know if you're planning to implement this or not (so I can do it,
>> if not you).

LMI> Sure, go ahead.  :-)

I'm not sure I understand all the buffer magic eww does, so here's an
attempt to provide `eww-view-source' under `v' (right now it just calls
`debug' on the data).  If I edebug `eww-view-source' it has the right
data, but I think something is getting lost in translation because the
data doesn't show up when I actually hit `v'.

If you or someone else know what I've missed, please let me know.  It's
probably something really simple...

Thanks
Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: eww-view-source.patch --]
[-- Type: text/x-diff, Size: 2098 bytes --]

=== modified file 'lisp/net/eww.el'
--- lisp/net/eww.el	2013-06-28 07:54:42 +0000
+++ lisp/net/eww.el	2013-07-01 22:42:27 +0000
@@ -100,6 +100,7 @@
 (defvar eww-home-url nil)
 (defvar eww-start-url nil)
 (defvar eww-contents-url nil)
+(defvar eww-source-code nil)
 
 ;;;###autoload
 (defun eww (url)
@@ -200,11 +201,12 @@
 (defun eww-display-html (charset url)
   (unless (eq charset 'utf8)
     (decode-coding-region (point) (point-max) charset))
-  (let ((document
+  (let ((source-code (buffer-substring (point) (point-max)))
+        (document
 	 (list
 	  'base (list (cons 'href url))
 	  (libxml-parse-html-region (point) (point-max)))))
-    (eww-setup-buffer)
+    (eww-setup-buffer source-code)
     (setq eww-current-url url)
     (eww-update-header-line-format)
     (let ((inhibit-read-only t)
@@ -296,7 +298,7 @@
 
 (defun eww-display-raw (charset)
   (let ((data (buffer-substring (point) (point-max))))
-    (eww-setup-buffer)
+    (eww-setup-buffer data)
     (let ((inhibit-read-only t))
       (insert data))
     (goto-char (point-min))))
@@ -308,11 +310,12 @@
       (shr-put-image data nil))
     (goto-char (point-min))))
 
-(defun eww-setup-buffer ()
+(defun eww-setup-buffer (&optional source-code)
   (pop-to-buffer (get-buffer-create "*eww*"))
   (let ((inhibit-read-only t))
     (remove-overlays)
     (erase-buffer))
+  (set (make-local-variable 'eww-source-code) source-code)
   (unless (eq major-mode 'eww-mode)
     (eww-mode)))
 
@@ -334,6 +337,7 @@
     (define-key map "t" 'eww-top-url)
     (define-key map "&" 'eww-browse-with-external-browser)
     (define-key map "d" 'eww-download)
+    (define-key map "v" 'eww-view-source)
     (define-key map "w" 'eww-copy-page-url)
     (define-key map "C" 'url-cookie-list)
 
@@ -391,6 +395,13 @@
   (setq eww-history nil)
   (kill-buffer (current-buffer)))
 
+(defun eww-view-source ()
+  "View the page source code."
+  (interactive)
+  (if eww-source-code
+      (debug eww-source-code)
+    (error "No source code available")))
+
 (defun eww-back-url ()
   "Go to the previously displayed page."
   (interactive)

Re: eww

[Thierry Volpiatto]

First try to eww:
M-x eww RET google.fr
I go in the search bar, enter some characters, then, C-a, C-k, the
search bar disappear.
Otherwise thanks to develop this.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: eww

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I'm not sure I understand all the buffer magic eww does, so here's an
> attempt to provide `eww-view-source' under `v' (right now it just calls
> `debug' on the data).  If I edebug `eww-view-source' it has the right
> data, but I think something is getting lost in translation because the
> data doesn't show up when I actually hit `v'.

Calling `debug' is probably not the right thing to do.  Just pop to a
buffer called "*eww source*" or something, with a very minor mode that
would just bind `q' to exit.

But otherwise, looks good.  Please apply.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Xue Fuqiao]

On Sat, Jul 6, 2013 at 11:19 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> I'm not sure I understand all the buffer magic eww does, so here's an
>> attempt to provide `eww-view-source' under `v' (right now it just calls
>> `debug' on the data).  If I edebug `eww-view-source' it has the right
>> data, but I think something is getting lost in translation because the
>> data doesn't show up when I actually hit `v'.
>
> Calling `debug' is probably not the right thing to do.  Just pop to a
> buffer called "*eww source*" or something, with a very minor mode that
> would just bind `q' to exit.

I think deriving from special-mode is better, because it has very
convenient binding for beginning/end-of-buffer, scroll-down/up-commnd,
and also bind `q' to exit.

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Re: eww

[Lars Ingebrigtsen]

Xue Fuqiao <xfq.free@gmail.com> writes:

> I think deriving from special-mode is better, because it has very
> convenient binding for beginning/end-of-buffer, scroll-down/up-commnd,
> and also bind `q' to exit.

Ah, I didn't know about `special-mode'.  I'll make `eww-bookmark-mode'
and `url-cookie-mode' (introduced a couple of weeks ago) derive from
that instead of re-implementing some of that stuff.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Ted Zlatanov]

On Sat, 06 Jul 2013 17:19:54 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I'm not sure I understand all the buffer magic eww does, so here's an
>> attempt to provide `eww-view-source' under `v' (right now it just calls
>> `debug' on the data).  If I edebug `eww-view-source' it has the right
>> data, but I think something is getting lost in translation because the
>> data doesn't show up when I actually hit `v'.

LI> Calling `debug' is probably not the right thing to do.

I know, but it wasn't working for me so I left it like that :)

Do you mean to say it works for you?  If so, there must be something
wrong with my setup!

LI> Just pop to a buffer called "*eww source*" or something, with a very
LI> minor mode that would just bind `q' to exit.

LI> But otherwise, looks good.  Please apply.  :-)

As Xue suggested I can use `special-mode' (which gets my award for
Unhelpful Name of the Year, btw).  But if you tested this and it worked,
why is it failing for me?  Hmm.

Ted

Re: eww

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I know, but it wasn't working for me so I left it like that :)
>
> Do you mean to say it works for you?  If so, there must be something
> wrong with my setup!

No, I didn't actually test it.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[chad]

On 18 Jun 2013, at 21:21, Ted Zlatanov <tzz@lifelogs.com> wrote:
> For accessibility (e.g. if the HTML is completely garbled or if the user
> is unable to read it), it would be very nice to pop up a buffer with
> just the list of anchors, where up/down are bound to step through the
> list and RET browses the anchor.

Sounds like completion to me.

On 19 Jun 2013, at 00:34, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

>> So its User-Agent would be more informative with something like
>> "eww/5.130008 URL/1.1 Emacs/24.3.50 (gnu/linux)"...
> 
> I'm kinda for keeping the User-Agent short and sweet.  But is URL/Emacs
> valid?  It's supposed to be Client/Version.  I guess "Emacs" is a
> version of sorts...

I know it seems cool just to say `EWW/Emacs', but Juri's suggestion
is better, assuming that you care about standards compliance.
Reasonable humans can be forgiven for thinking that the web standards
aren't reasonable, but please *at least* include a version number.

Thanks for an exciting new tool!
~Chad

Re: eww

[Stefan Monnier]

> I know it seems cool just to say `EWW/Emacs', but Juri's suggestion
> is better, assuming that you care about standards compliance.
> Reasonable humans can be forgiven for thinking that the web standards
> aren't reasonable, but please *at least* include a version number.

If the format is syntactically incorrect, we need to fix it, indeed.
But we should not give more information (e.g. if it wants a "version
number", then let's fill it with some dummy "3.14").


        Stefan

Re: eww

[Juri Linkov]

>> For accessibility (e.g. if the HTML is completely garbled or if the user
>> is unable to read it), it would be very nice to pop up a buffer with
>> just the list of anchors, where up/down are bound to step through the
>> list and RET browses the anchor.
>
> Sounds like completion to me.

Yes, this is like `f TAB' in Info.

Re: eww

[Tom Tromey]

>>>>> "Juri" == Juri Linkov <juri@jurta.org> writes:

Juri> Yes, this is like `f TAB' in Info.

FWIW I have "f" (and "m") bindings working here (plus other easy info
stuff, like "T", "<", and the digits).  I can send a patch tomorrow.

Tom

Re: eww

[Tom Tromey]

Lars> Would it make more sense for eww to use new buffers every time?  eww
Lars> would have a backlog of, say, ten buffers, and going back to the
Lars> previous page would just mean popping to the previous buffer.  And it
Lars> could use `bury-buffer' and rename the previous buffer to a name with
Lars> something leading with " " when you go to a new page.

FWIW w3m reuses the buffer by default, but lets you request a new buffer
when following a link.  That is, it works like other web browsers, where
a click usually reuses the tab, and middle-click or whatever opens a new
one.

Tom

Re: eww

[Tom Tromey]

>> Here's a version that addresses your comments and adds doc strings and a
>> ChangeLog entry.  Let me know what you think.

Lars> Looks good; applied.

I didn't see it in bzr.

Anyway here is a slightly better version.

Differences:

HTML seems to specify "prev", not "previous" (though texinfo still seems
to use "previous").

HTML specifies "start" as well as "contents"; but I noticed that Gtk is
using "home" here.  So now it handles all 3 and picks the "best" one.

Finally, the "rel" value is supposed to be case-insensitive, so downcase it.

Tom

=== modified file 'lisp/gnus/ChangeLog'
--- lisp/gnus/ChangeLog	2013-06-18 11:24:16 +0000
+++ lisp/gnus/ChangeLog	2013-06-18 16:15:25 +0000
@@ -1,3 +1,17 @@
+2013-06-18  Tom Tromey  <tromey@barimba>
+
+	* eww.el (eww-next-url, eww-previous-url, eww-up-url)
+	(eww-start-url, eww-home-url, eww-contents-url):
+	New defvars.
+	(eww-open-file): New defun.
+	(eww-render): Initialize new variables.
+	(eww-display-html): Handle "link" and "a".
+	(eww-handle-link, eww-tag-link, eww-tag-a): New defuns.
+	(eww-mode-map): Move "p" to "l".  Bind "p", "n", "t", and "u".
+	(eww-back-url): Rename from eww-previous-url.
+	(eww-next-url, eww-previous-url, eww-up-url, eww-top-url): New
+	defuns.
+
 2013-06-18  Lars Magne Ingebrigtsen  <larsi@gnus.org>
 
 	* shr.el (shr-tag-table): Insert the images after the table, so that

=== modified file 'lisp/gnus/eww.el'
--- lisp/gnus/eww.el	2013-06-18 09:29:20 +0000
+++ lisp/gnus/eww.el	2013-06-18 16:14:31 +0000
@@ -56,6 +56,13 @@
   "Title of current page.")
 (defvar eww-history nil)
 
+(defvar eww-next-url nil)
+(defvar eww-previous-url nil)
+(defvar eww-up-url nil)
+(defvar eww-home-url nil)
+(defvar eww-start-url nil)
+(defvar eww-contents-url nil)
+
 ;;;###autoload
 (defun eww (url)
   "Fetch URL and render the page."
@@ -64,10 +71,22 @@
     (setq url (concat "http://" url)))
   (url-retrieve url 'eww-render (list url)))
 
+;;;###autoload
+(defun eww-open-file (file)
+  "Render a file using EWW."
+  (interactive "fFile: ")
+  (eww (concat "file://" (expand-file-name file))))
+
 (defun eww-render (status url &optional point)
   (let ((redirect (plist-get status :redirect)))
     (when redirect
       (setq url redirect)))
+  (set (make-local-variable 'eww-next-url) nil)
+  (set (make-local-variable 'eww-previous-url) nil)
+  (set (make-local-variable 'eww-up-url) nil)
+  (set (make-local-variable 'eww-home-url) nil)
+  (set (make-local-variable 'eww-start-url) nil)
+  (set (make-local-variable 'eww-contents-url) nil)
   (let* ((headers (eww-parse-headers))
 	 (shr-target-id
 	  (and (string-match "#\\(.*\\)" url)
@@ -146,11 +165,45 @@
 	     (input . eww-tag-input)
 	     (textarea . eww-tag-textarea)
 	     (body . eww-tag-body)
-	     (select . eww-tag-select))))
+	     (select . eww-tag-select)
+	     (link . eww-tag-link)
+	     (a . eww-tag-a))))
       (shr-insert-document document)
       (eww-convert-widgets))
     (goto-char (point-min))))
 
+(defun eww-handle-link (cont)
+  (let* ((rel (assq :rel cont))
+  	(href (assq :href cont))
+	(where (assoc
+		;; The text associated with :rel is case-insensitive.
+		(if rel (downcase (cdr rel)))
+		      '(("next" . eww-next-url)
+			;; Texinfo uses "previous", but HTML specifies
+			;; "prev", so recognize both.
+			("previous" . eww-previous-url)
+			("prev" . eww-previous-url)
+			;; HTML specifies "start" but also "contents",
+			;; and Gtk seems to use "home".  Recognize
+			;; them all; but store them in different
+			;; variables so that we can readily choose the
+			;; "best" one.
+			("start" . eww-start-url)
+			("home" . eww-home-url)
+			("contents" . eww-contents-url)
+			("up" . eww-up-url)))))
+    (and href
+	 where
+	 (set (cdr where) (cdr href)))))
+
+(defun eww-tag-link (cont)
+  (eww-handle-link cont)
+  (shr-generic cont))
+
+(defun eww-tag-a (cont)
+  (eww-handle-link cont)
+  (shr-tag-a cont))
+
 (defun eww-update-header-line-format ()
   (if eww-header-line-format
       (setq header-line-format (format-spec eww-header-line-format
@@ -218,8 +271,11 @@
     (define-key map [delete] 'scroll-down-command)
     (define-key map "\177" 'scroll-down-command)
     (define-key map " " 'scroll-up-command)
+    (define-key map "l" 'eww-back-url)
+    (define-key map "n" 'eww-next-url)
     (define-key map "p" 'eww-previous-url)
-    ;;(define-key map "n" 'eww-next-url)
+    (define-key map "u" 'eww-up-url)
+    (define-key map "t" 'eww-top-url)
     map))
 
 (define-derived-mode eww-mode nil "eww"
@@ -240,7 +296,7 @@
   (setq eww-history nil)
   (kill-buffer (current-buffer)))
 
-(defun eww-previous-url ()
+(defun eww-back-url ()
   "Go to the previously displayed page."
   (interactive)
   (when (zerop (length eww-history))
@@ -248,6 +304,45 @@
   (let ((prev (pop eww-history)))
     (url-retrieve (car prev) 'eww-render (list (car prev) (cadr prev)))))
 
+(defun eww-next-url ()
+  "Go to the page marked `next'.
+A page is marked `next' if rel=\"next\" appears in a <link>
+or <a> tag."
+  (interactive)
+  (if eww-next-url
+      (eww-browse-url (shr-expand-url eww-next-url eww-current-url))
+    (error "No `next' on this page")))
+
+(defun eww-previous-url ()
+  "Go to the page marked `previous'.
+A page is marked `previous' if rel=\"previous\" appears in a <link>
+or <a> tag."
+  (interactive)
+  (if eww-previous-url
+      (eww-browse-url (shr-expand-url eww-previous-url eww-current-url))
+    (error "No `previous' on this page")))
+
+(defun eww-up-url ()
+  "Go to the page marked `up'.
+A page is marked `up' if rel=\"up\" appears in a <link>
+or <a> tag."
+  (interactive)
+  (if eww-up-url
+      (eww-browse-url (shr-expand-url eww-up-url eww-current-url))
+    (error "No `up' on this page")))
+
+(defun eww-top-url ()
+  "Go to the page marked `top'.
+A page is marked `top' if rel=\"start\", rel=\"home\", or rel=\"contents\"
+appears in a <link> or <a> tag."
+  (interactive)
+  (let ((best-url (or eww-start-url
+		      eww-contents-url
+		      eww-home-url)))
+    (if best-url
+	(eww-browse-url (shr-expand-url best-url eww-current-url))
+      (error "No `top' for this page"))))
+
 (defun eww-reload ()
   "Reload the current page."
   (interactive)

Re: eww

[Christopher Schmidt]

Tom Tromey <tromey@redhat.com> writes:
> I didn't see it in bzr.

Wait until the Gnus git repository is synced.

    http://git.gnus.org/cgit/gnus.git/commit/?id=39cb12ac94b96e035dcffe7f419eb77b5a41226f

        Christopher

Re: eww

[Steinar Bang]

>>>>> Tom Tromey <tromey@redhat.com>:

>>> Here's a version that addresses your comments and adds doc strings and a
>>> ChangeLog entry.  Let me know what you think.

Lars> Looks good; applied.

> I didn't see it in bzr.

It's probably onlt in the gnus git, so far: http://git.gnus.org/ 

Re: eww

[Lars Magne Ingebrigtsen]

Tom Tromey <tromey@redhat.com> writes:

>>> Here's a version that addresses your comments and adds doc strings and a
>>> ChangeLog entry.  Let me know what you think.
>
> Lars> Looks good; applied.
>
> I didn't see it in bzr.
>
> Anyway here is a slightly better version.

Could you re-send the patch against the current tree?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Tom Tromey]

Lars> Could you re-send the patch against the current tree?

Here you go.
I can push directly if you prefer.
I think it would be best if you reviewed patches, though.

Tom

=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2013-06-19 13:14:24 +0000
+++ lisp/ChangeLog	2013-06-19 17:13:17 +0000
@@ -1,3 +1,12 @@
+2013-06-19  Tom Tromey  <tromey@redhat.com>
+
+	* net/eww.el (eww-top-url): Remove.
+	(eww-home-url, eww-start-url, eww-contents-url): New defvars.
+	(eww-render): Set new variables.  Don't set eww-top-url.
+	(eww-handle-link): Handle "prev", "home", and "contents".
+	Downcase the rel text.
+	(eww-top-url): Choose best top URL.
+
 2013-06-19  Michael Albinus  <michael.albinus@gmx.de>
 
 	* net/tramp-adb.el (tramp-adb-get-toolbox): Remove function, it is

=== modified file 'lisp/net/eww.el'
--- lisp/net/eww.el	2013-06-18 22:38:34 +0000
+++ lisp/net/eww.el	2013-06-19 17:10:12 +0000
@@ -59,7 +59,9 @@
 (defvar eww-next-url nil)
 (defvar eww-previous-url nil)
 (defvar eww-up-url nil)
-(defvar eww-top-url nil)
+(defvar eww-home-url nil)
+(defvar eww-start-url nil)
+(defvar eww-contents-url nil)
 
 ;;;###autoload
 (defun eww (url)
@@ -82,7 +84,9 @@
   (set (make-local-variable 'eww-next-url) nil)
   (set (make-local-variable 'eww-previous-url) nil)
   (set (make-local-variable 'eww-up-url) nil)
-  (set (make-local-variable 'eww-top-url) nil)
+  (set (make-local-variable 'eww-home-url) nil)
+  (set (make-local-variable 'eww-start-url) nil)
+  (set (make-local-variable 'eww-contents-url) nil)
   (let* ((headers (eww-parse-headers))
 	 (shr-target-id
 	  (and (string-match "#\\(.*\\)" url)
@@ -171,10 +175,22 @@
 (defun eww-handle-link (cont)
   (let* ((rel (assq :rel cont))
   	(href (assq :href cont))
-	(where (assoc (cdr rel)
+	(where (assoc
+		;; The text associated with :rel is case-insensitive.
+		(if rel (downcase (cdr rel)))
 		      '(("next" . eww-next-url)
+			;; Texinfo uses "previous", but HTML specifies
+			;; "prev", so recognize both.
 			("previous" . eww-previous-url)
-			("start" . eww-top-url)
+			("prev" . eww-previous-url)
+			;; HTML specifies "start" but also "contents",
+			;; and Gtk seems to use "home".  Recognize
+			;; them all; but store them in different
+			;; variables so that we can readily choose the
+			;; "best" one.
+			("start" . eww-start-url)
+			("home" . eww-home-url)
+			("contents" . eww-contents-url)
 			("up" . eww-up-url)))))
     (and href
 	 where
@@ -317,12 +333,15 @@
 
 (defun eww-top-url ()
   "Go to the page marked `top'.
-A page is marked `top' if rel=\"start\" appears in a <link>
-or <a> tag."
+A page is marked `top' if rel=\"start\", rel=\"home\", or rel=\"contents\"
+appears in a <link> or <a> tag."
   (interactive)
-  (if eww-top-url
-      (eww-browse-url (shr-expand-url eww-top-url eww-current-url))
-    (error "No `top' on this page")))
+  (let ((best-url (or eww-start-url
+		      eww-contents-url
+		      eww-home-url)))
+    (if best-url
+	(eww-browse-url (shr-expand-url best-url eww-current-url))
+      (error "No `top' for this page"))))
 
 (defun eww-reload ()
   "Reload the current page."

Re: eww

[Lars Magne Ingebrigtsen]

Tom Tromey <tromey@redhat.com> writes:

> Here you go.

Thanks; applied.

> I can push directly if you prefer.
> I think it would be best if you reviewed patches, though.

Perhaps for now -- things are changing pretty rapidly in eww at the
moment.

After ejecting the widget code from eww, here's how it looks now:

http://lars.ingebrigtsen.no/2013/06/eww-improvements.html

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Stefan Monnier]

>> +(defvar eww-next-url nil)
>> +(make-variable-buffer-local 'eww-next-url)
>> +(defvar eww-previous-url nil)
>> +(make-variable-buffer-local 'eww-previous-url)
>> +(defvar eww-up-url nil)
>> +(make-variable-buffer-local 'eww-up-url)
>> +(defvar eww-top-url nil)
>> +(make-variable-buffer-local 'eww-top-url)

> I think that for package-specific variables like this we're supposed to
> use

> (set (make-local-variable 'eww-top-url) nil)

> in the mode setup instead, so that we're not making variables needlessly
> globally buffer-local.

For variables whose global value is of no use anyway, you're just as
well to use defvar-local (or equivalent) like Tom did.


        Stefan

Re: eww

[Lars Magne Ingebrigtsen]

Tom Tromey <tromey@redhat.com> writes:

> I'm interested in the possibility of replacing info with html+eww.

As for this, that's not very realistic.  info has a ton of commands
specially suited for navigating manuals, and does a really good job.
eww is a general web browser, and trying to shoe-horn all the missing
info functionality into it would be a mess, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Tom Tromey]

Tom> I'm interested in the possibility of replacing info with html+eww.

Lars> As for this, that's not very realistic.  info has a ton of commands
Lars> specially suited for navigating manuals, and does a really good job.
Lars> eww is a general web browser, and trying to shoe-horn all the missing
Lars> info functionality into it would be a mess, I think.

I'm more optimistic about the possibility.
Is there a particular thing you think would be difficult or messy?

Maybe there is a way to do it as a derived mode so that it doesn't
conflict too much with the web-browsing aspect of eww.

Tom

Re: eww

[Lars Magne Ingebrigtsen]

Tom Tromey <tromey@redhat.com> writes:

> I'm more optimistic about the possibility.
> Is there a particular thing you think would be difficult or messy?

info has a bunch of commands for jumping to the index and searching the
entire manual, etc.  Reading the HTML version of the manual will never
be as convenient as reading the info version.

> Maybe there is a way to do it as a derived mode so that it doesn't
> conflict too much with the web-browsing aspect of eww.

Or just continue to use info, which is really good at this sort of
thing.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Stefan Monnier]

>> I'm more optimistic about the possibility.
>> Is there a particular thing you think would be difficult or messy?
> Info has a bunch of commands for jumping to the index and searching the
> entire manual, etc.  Reading the HTML version of the manual will never
> be as convenient as reading the info version.

AFAIK, it's easy to make HTML pages which includes most/all the meta
information that Info pages contain.  So you can then provide the "bunch
of commands" without much trouble.

>> Maybe there is a way to do it as a derived mode so that it doesn't
>> conflict too much with the web-browsing aspect of eww.
> Or just continue to use info, which is really good at this sort of
> thing.  :-)

Info has serious shortcomings which are hard to circumvent.  E.g. it's
pre-formatted.


        Stefan

Re: eww

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Tue, 18 Jun 2013 15:13:22 -0400
> Cc: Tom Tromey <tromey@redhat.com>, ding@gnus.org,
> 	emacs-devel <emacs-devel@gnu.org>
> 
> Info has serious shortcomings which are hard to circumvent.  E.g. it's
> pre-formatted.

For manuals we produce ourselves, using the --fill-column switch to
makeinfo can easily overcome the pre-formatted thing.

Any other serious shortcomings?

Re: eww

[Stefan Monnier]

>> Info has serious shortcomings which are hard to circumvent.  E.g. it's
>> pre-formatted.
> For manuals we produce ourselves, using the --fill-column switch to
> makeinfo can easily overcome the pre-formatted thing.

I'm not sure how that helps refill Info documents to adapt to the size
of the Emacs window, or reliably recognize elements to display them
using face attributes rather than ascii annotations.


        Stefan

Re: eww

[James Cloos]

>>>>> "SM" == Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

SM> I'm not sure how that helps refill Info documents to adapt to the
SM> size of the Emacs window,

If that ever is done, please be sure not to refill wider, only narrower.

Even with a wide window (such as a landscape-aspect full-screen window)
one doesn't want the text column to be full width.

But refilling to work with a too-narrow window is a good idea.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: eww

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: larsi@gnus.org, tromey@redhat.com, ding@gnus.org, emacs-devel@gnu.org
> Date: Tue, 18 Jun 2013 16:21:23 -0400
> 
> >> Info has serious shortcomings which are hard to circumvent.  E.g. it's
> >> pre-formatted.
> > For manuals we produce ourselves, using the --fill-column switch to
> > makeinfo can easily overcome the pre-formatted thing.
> 
> I'm not sure how that helps refill Info documents to adapt to the size
> of the Emacs window

Use a huge number as the argument of --fill-column, and you have
unbroken physical lines.  The rest is up to us.

> or reliably recognize elements to display them using face attributes
> rather than ascii annotations.

We do that already, don't we?

Re: eww

[Stefan Monnier]

>> or reliably recognize elements to display them using face attributes
>> rather than ascii annotations.
> We do that already, don't we?

Not reliably, sadly.


        Stefan

Re: eww

[Stephen Leake]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> Info has serious shortcomings which are hard to circumvent.
> ... or reliably recognize elements to display them
> using face attributes rather than ascii annotations.

For example, the Ada manual uses italics to distinguish important
features: <i>function_</i>name is very different semantically from
function_name.

This is completely lost in the info version, but present in the HTML
version.

-- 
-- Stephe

Re: eww

[Xue Fuqiao]

On Wed, Jun 19, 2013 at 3:17 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
>> Date: Tue, 18 Jun 2013 15:13:22 -0400
>> Cc: Tom Tromey <tromey@redhat.com>, ding@gnus.org,
>>       emacs-devel <emacs-devel@gnu.org>
>>
>> Info has serious shortcomings which are hard to circumvent.  E.g. it's
>> pre-formatted.
>
> For manuals we produce ourselves, using the --fill-column switch to
> makeinfo can easily overcome the pre-formatted thing.
>
> Any other serious shortcomings?

Well, I don't see any serious shortcomings, but I found a minor problem:
"texi2any --info" still use the convention of backtick ` and straight
single quote ' to emulate curly quotes “ ” or ‘ ’.  It also use other
ASCII kludge such as => instead of ⇒.  Emacs itself support Unicode
several years ago, what about replacing these characters?  At least add
a switch to texi2any.

(Sorry for the off-topic.)

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Re: eww

[Paul Eggert]

On 06/18/13 16:03, Xue Fuqiao wrote:
> "texi2any --info" still use the convention of backtick ` and straight
> single quote ' to emulate curly quotes “ ” or ‘ ’.

That's not what I observe: texi2any outputs ASCII apostrophe ' for
single quotes (both left and right) and ASCII quote " for double
quotes (both left and right).  This looks OK, though admittedly
curly quotes look a bit nicer.

> Emacs itself support Unicode
> several years ago, what about replacing these characters?  At least add
> a switch to texi2any.

It might be nice to add an option to do that, but
I'm not sure I'd make it the default.  Even today, I often use Emacs
in environments that are ASCII-only, e.g., I may set LC_ALL=C to bypass
some internationalization brain damage elsewhere (a performance issue,
or a remote login issue).

Re: eww

[Xue Fuqiao]

On Wed, Jun 19, 2013 at 7:56 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 06/18/13 16:03, Xue Fuqiao wrote:
>> "texi2any --info" still use the convention of backtick ` and straight
>> single quote ' to emulate curly quotes “ ” or ‘ ’.
>
> That's not what I observe: texi2any outputs ASCII apostrophe ' for
> single quotes (both left and right) and ASCII quote " for double
> quotes (both left and right).  This looks OK, though admittedly
> curly quotes look a bit nicer.

In my infodir/elisp.info(.gz):

  For a beginner's introduction to Emacs Lisp, see `An Introduction to
  Emacs Lisp Programming', by Bob Chassell, also published by the Free
  Software Foundation.

In doc/lispref/intro.texi:

  For a beginner's introduction to Emacs Lisp, see @cite{An Introduction
  to Emacs Lisp Programming}, by Bob Chassell, also published by the
  Free Software Foundation.

This is produced by makeinfo version 4.8, maybe I should try it with a
newer version?

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Re: eww

[Eli Zaretskii]

> Date: Wed, 19 Jun 2013 15:52:58 +0800
> From: Xue Fuqiao <xfq.free@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> In my infodir/elisp.info(.gz):
> 
>   For a beginner's introduction to Emacs Lisp, see `An Introduction to
>   Emacs Lisp Programming', by Bob Chassell, also published by the Free
>   Software Foundation.
> 
> In doc/lispref/intro.texi:
> 
>   For a beginner's introduction to Emacs Lisp, see @cite{An Introduction
>   to Emacs Lisp Programming}, by Bob Chassell, also published by the
>   Free Software Foundation.
> 
> This is produced by makeinfo version 4.8, maybe I should try it with a
> newer version?

Definitely.

Re: eww

[Eli Zaretskii]

> Date: Wed, 19 Jun 2013 07:03:58 +0800
> From: Xue Fuqiao <xfq.free@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, tromey@redhat.com, larsi@gnus.org, 
> 	ding@gnus.org, emacs-devel <emacs-devel@gnu.org>
> 
> Well, I don't see any serious shortcomings, but I found a minor problem:
> "texi2any --info" still use the convention of backtick ` and straight
> single quote ' to emulate curly quotes “ ” or ‘ ’.  It also use other
> ASCII kludge such as => instead of ⇒.  Emacs itself support Unicode
> several years ago, what about replacing these characters?  At least add
> a switch to texi2any.

There's already a switch.

Re: eww

[Tom Tromey]

>> Info has a bunch of commands for jumping to the index and searching the
>> entire manual, etc.  Reading the HTML version of the manual will never
>> be as convenient as reading the info version.

Stefan> AFAIK, it's easy to make HTML pages which includes most/all the meta
Stefan> information that Info pages contain.  So you can then provide the "bunch
Stefan> of commands" without much trouble.

makeinfo (I'm looking at the output of makeinfo 5.0) already supplies a
link to the index, like:

<link href="Concept-Index.html#Concept-Index" rel="index" title="Concept Index">

This seems to be in every node.
So I think implementing "i" isn't too bad.


makeinfo also lets us know if the node has a menu:

<table class="menu" border="0" cellspacing="0">

So "m" and the digit arguments seem doable.


Searching seems a bit trickier.

I didn't look at issues if the HTML is in a single file rather than a
file per node.

I also didn't look at info-lookup-symbol.  Though I note that at least
the Gtk manuals use some similar markup, so moving to HTML would
potentially broaden the documentation conveniently available to Emacs
users.

Tom

Re: eww

[Juri Linkov]

>> I'm interested in the possibility of replacing info with html+eww.
>
> As for this, that's not very realistic.  info has a ton of commands
> specially suited for navigating manuals, and does a really good job.
> eww is a general web browser, and trying to shoe-horn all the missing
> info functionality into it would be a mess, I think.

There are two ways to integrate eww and info:

1. eww could support browser extensions, so e.g. when it detects
a navigable manual, it could load a new extension eww-info.el
that will support next/prev/up navigation and specific commands
such as index and search, etc.

2. Info could reuse the layout engine from shr to render
its content to produce nicer output.

BTW, two additional questions: I noticed that in net/browse-url.el you added
eww between Mosaic and Mosaic CCI in `browse-url-browser-function'.
Why such a strange place?  I think eww as a native browser deserves
to be placed first in the list of supported browsers.

Also while trying to customize `browse-url-browser-function' to eww,
it fails to browse links.  Perhaps, this should be fixed by creating a new
function `browse-url-eww' similar to other `browse-url-...' functions?

Another question is that
`M-x eww RET http://duckduckgo.com/?q=my+user+agent RET'
says that the user agent of eww is just "URL/Emacs".
Any respectable browser has a longish text for the User-Agent.
So its User-Agent would be more informative with something like
"eww/5.130008 URL/1.1 Emacs/24.3.50 (gnu/linux)"...

Re: eww

[Stefan Monnier]

> Another question is that
> `M-x eww RET http://duckduckgo.com/?q=my+user+agent RET'
> says that the user agent of eww is just "URL/Emacs".
> Any respectable browser has a longish text for the User-Agent.
> So its User-Agent would be more informative with something like
> "eww/5.130008 URL/1.1 Emacs/24.3.50 (gnu/linux)"...

I think less is more here.


        Stefan

Re: eww

[Christopher Schmidt]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Another question is that
>> `M-x eww RET http://duckduckgo.com/?q=my+user+agent RET'
>> says that the user agent of eww is just "URL/Emacs".
>> Any respectable browser has a longish text for the User-Agent.
>> So its User-Agent would be more informative with something like
>> "eww/5.130008 URL/1.1 Emacs/24.3.50 (gnu/linux)"...
>
> I think less is more here.

Why do you think so?

In my opinion, it does not make any practical difference considering the
minimal userbase.

        Christopher

Re: eww

[Lars Magne Ingebrigtsen]

Juri Linkov <juri@jurta.org> writes:

> BTW, two additional questions: I noticed that in net/browse-url.el you added
> eww between Mosaic and Mosaic CCI in `browse-url-browser-function'.
> Why such a strange place?

I just picked a place at random after the more popular browsers.

Speaking of which, should that list be cleaned up a bit?  There's a lot
of browsers in there which haven't existed in a decade...

> Also while trying to customize `browse-url-browser-function' to eww,
> it fails to browse links.  Perhaps, this should be fixed by creating a new
> function `browse-url-eww' similar to other `browse-url-...' functions?

It should have been `eww-browse-url' instead of the plain `eww'
command.  I'll fix that.

> Another question is that
> `M-x eww RET http://duckduckgo.com/?q=my+user+agent RET'
> says that the user agent of eww is just "URL/Emacs".
> Any respectable browser has a longish text for the User-Agent.
> So its User-Agent would be more informative with something like
> "eww/5.130008 URL/1.1 Emacs/24.3.50 (gnu/linux)"...

I'm kinda for keeping the User-Agent short and sweet.  But is URL/Emacs
valid?  It's supposed to be Client/Version.  I guess "Emacs" is a
version of sorts...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[Juri Linkov]

>> Also while trying to customize `browse-url-browser-function' to eww,
>> it fails to browse links.  Perhaps, this should be fixed by creating a new
>> function `browse-url-eww' similar to other `browse-url-...' functions?
>
> It should have been `eww-browse-url' instead of the plain `eww'
> command.  I'll fix that.

Thanks.  Now there is another problem - when
`browse-url-browser-function' is customized to `eww-browse-url',
typing `M-x webjump RET duckduckgo RET C-x C-q RET'
visits the URL https://duckduckgo.com/?q=C%2Dx+C%2Dq
with the information about Emacs keybindings and commands.
Or to get more relevant results prepend the query with the keyword
"emacs", e.g. https://duckduckgo.com/?q=emacs+C%2Dx+C%2Dq

The problem is that the header line is broken - it doesn't handle %
in the URL.  This could be fixed the same way as `Info-set-mode-line'
replaces a single % with double %%.

Re: eww

[Lars Magne Ingebrigtsen]

Juri Linkov <juri@jurta.org> writes:

> The problem is that the header line is broken - it doesn't handle %
> in the URL.  This could be fixed the same way as `Info-set-mode-line'
> replaces a single % with double %%.

Ok; I've now added % quoting.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

RE: eww

[Drew Adams]

From http://lars.ingebrigtsen.no/2013/06/eww.html:

> I came up with the name of the browser while half-asleep: eww!
> I don't quite know what the second w is supposed to stand for
> (Emacs Web Wowser?)...

Another name suggestion, in the tradition of Gnu, Bison, Yacc,...

Ewe - Emacs web environment

Presumably, like all things Emacs, it will grow to be more than
your average browser (or even wowser).

Re: eww

[Jambunathan K]

Drew Adams <drew.adams@oracle.com> writes:

> From http://lars.ingebrigtsen.no/2013/06/eww.html:
>
>> I came up with the name of the browser while half-asleep: eww!
>> I don't quite know what the second w is supposed to stand for
>> (Emacs Web Wowser?)...

> Another name suggestion, in the tradition of Gnu, Bison, Yacc,...
>
> Ewe - Emacs web environment
>
> Presumably, like all things Emacs, it will grow to be more than
> your average browser (or even wowser).

        eww => Emacs Walks the Web

"Walking the web" is same as "Navigating the Netscape".

----------------------------------------------------------------

Can M-x browse-url-emacs RET do what the new wowser does (or what the
shr.el does)

As a side note, browse-url-emacs surprises me.  It leaves the HTML tags
around.  May be, it shouldn't.

Re: eww

[Richard Stallman]

"Eww" sounds like a common expression of disgust.  Is the code really
that ugly?  ;-).

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.
NSA and FBI agents reading my email: consider whether
  defending the US Constitution against all enemies,
  foreign or domestic, requires you to follow Snowden's path.

Re: eww

[Paul Eggert]

On 06/19/2013 09:10 PM, Richard Stallman wrote:
> "Eww" sounds like a common expression of disgust.  Is the code really
> that ugly?  ;-).

"Eww" stands for "Extreme web winning", right?
So it should be OK.  Eww, what a hack!

Re: eww

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> "Eww" sounds like a common expression of disgust.  Is the code really
> that ugly?  ;-).

I hope the code isn't, but I think the normal response to a
non-pixel-based rendering of HTML is "eww".  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[joakim]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> eww probably has a lot of stuff that could still be fixed up, but the
> basics are working now.  That is, you can search for stuff on Google and
> visit Wikipedia.  :-)
>
> I wrote it up a bit here:
>
> http://lars.ingebrigtsen.no/2013/06/eww.html


While you are at it, could you implement something like the patch below?

I use it in the xwidget branch for simplifying browsing in emacs.


diff --git a/lisp/net/browse-url.el b/lisp/net/browse-url.el
index 695b7a1..1fa52ce 100644
--- a/lisp/net/browse-url.el
+++ b/lisp/net/browse-url.el
@@ -667,7 +667,7 @@ regarding its parameter treatment."
 ;; functions allows them to be stand-alone commands, making it easier
 ;; to switch between browsers.
 
-(defun browse-url-interactive-arg (prompt)
+(defun browse-url-interactive-arg (prompt &optional default-url)
   "Read a URL from the minibuffer, prompting with PROMPT.
 If `transient-mark-mode' is non-nil and the mark is active,
 it defaults to the current region, else to the URL at or before
@@ -684,7 +684,8 @@ for use in `interactive'."
 				      "[\t\r\f\n ]+" ""
 				      (buffer-substring-no-properties
 				       (region-beginning) (region-end))))
-				(browse-url-url-at-point)))
+				(browse-url-url-at-point)
+                                default-url))
 	(not (eq (null browse-url-new-window-flag)
 		 (null current-prefix-arg)))))
 
@@ -791,6 +792,13 @@ narrowed."
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;; Browser-independent commands
 
+(defun url-tidy (url)
+  "Tidy up URL as much as possible."
+  (if (equal 0 (string-match ".*://" url))
+      url
+    (concat "http://" url) ;;TODO guess more url forms, like mailto
+    ))
+
 ;; A generic command to call the current browse-url-browser-function
 
 ;;;###autoload
@@ -803,6 +811,7 @@ first, if that exists."
   (interactive (browse-url-interactive-arg "URL: "))
   (unless (called-interactively-p 'interactive)
     (setq args (or args (list browse-url-new-window-flag))))
+  (setq url (url-tidy url))
   (let ((process-environment (copy-sequence process-environment))
 	(function (or (and (string-match "\\`mailto:" url)
 			   browse-url-mailto-function)

-- 
Joakim Verona

Re: eww

[Andreas Schwab]

joakim@verona.se writes:

> +  (if (equal 0 (string-match ".*://" url))
         (string-match "://" url)

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: eww

[Lars Magne Ingebrigtsen]

joakim@verona.se writes:

>    (interactive (browse-url-interactive-arg "URL: "))
>    (unless (called-interactively-p 'interactive)
>      (setq args (or args (list browse-url-new-window-flag))))
> +  (setq url (url-tidy url))

I'm not sure I see the utility here.  I think `browse-url' should (at
least when called from a program) fetch exactly what it's being asked to
fetch, and not do a DWIM analysis.  That should be up to the callers.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: eww

[joakim]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> joakim@verona.se writes:
>
>>    (interactive (browse-url-interactive-arg "URL: "))
>>    (unless (called-interactively-p 'interactive)
>>      (setq args (or args (list browse-url-new-window-flag))))
>> +  (setq url (url-tidy url))
>
> I'm not sure I see the utility here.  I think `browse-url' should (at
> least when called from a program) fetch exactly what it's being asked to
> fetch, and not do a DWIM analysis.  That should be up to the callers.

It was meant only for interactive use. Maybe that wasnt obvious.

-- 
Joakim Verona

Re: eww

[Ivan Kanis]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

June, 16 at 16:53 Lars Magne Ingebrigtsen wrote:

> eww probably has a lot of stuff that could still be fixed up, but the
> basics are working now.  That is, you can search for stuff on Google and
> visit Wikipedia.  :-)

Exciting stuff.

I tried it on today's git mirror of bzr. It doesn't display anything. I
have tried:

 - google.com
 - kanis.fr
 - ivan.kanis.fr

I have attached a snapshot.


[-- Attachment #2: 2013-06-19-121709_820x960_scrot.png --]
[-- Type: image/png, Size: 32726 bytes --]

Re: eww

[Steinar Bang]

>>>>> Ivan Kanis <ivan@kanis.fr>:

> I tried it on today's git mirror of bzr. It doesn't display anything.

I'm guessing Lars works directly against the gnus git repo, so both
Emacs bzr and the git mirror of Emacs bzr would lag in comparison to
that.

The Gnus git repo is here:
 http://git.gnus.org/

Re: eww

[Ivan Kanis]

June, 19 at 12:21 Ivan wrote:

> I tried it on today's git mirror of bzr. It doesn't display anything. I
> have tried:
>
>  - google.com
>  - kanis.fr
>  - ivan.kanis.fr
>
> I have attached a snapshot.

It works with -Q. Something is wrong with my configuration. Sorry for
the noise...


-- 
Rule your mind or it will rule you.
    -- Horace

Re: eww

[John Williams]

I would like to help test eww, but I am not a Lisp programmer (although
I have hobby-level development experience with other programming
languages). I can see here:

http://git.gnus.org/cgit/gnus.git/tree/lisp?id=d54fa592ab919f897f6d0505b70beb90153e561f

that eww.el is in some git branch, but when I follow the instructions
here:

http://git.gnus.org/cgit/gnus.git/about/

and say:

"git clone http://git.gnus.org/gnus.git && cd gnus && git checkout m0-7"

I cannot see this file.  Could someone help me check out a
revision/branch/whatever that includes eew please?  And also, tell me
how a non-coder (or "a little knowledge is a dangerous thing" coder)
could help with the development of this very, very exciting project?

Thanks heaps,

John

Re: eww

[John Williams]

Actually, never mind.  I've downloaded (via git) and compiled the
current version of Emacs (GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu,
GTK+ Version 3.8.2) of 2013-08-02 on localhost.localdomain).

But when I say "M-x eww RET http://www.gnu.org RET" I get a totally
blank buffer.  The eww menu shows up, but when I choose the option
"Browse with external browser", I get the error:

call-interactively: Symbol's value as variable is void: shr-external-browser

Thanks for your work on this great project,

John

Re: eww

[Lars Magne Ingebrigtsen]

John Williams <john.williams@otago.ac.nz> writes:

> But when I say "M-x eww RET http://www.gnu.org RET" I get a totally
> blank buffer. 

I don't get a blank buffer.  Have you compiled your Emacs with libxml
support?

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php

Re: eww

[John Williams]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> John Williams <john.williams@otago.ac.nz> writes:
>
>> But when I say "M-x eww RET http://www.gnu.org RET" I get a totally
>> blank buffer. 
>
> I don't get a blank buffer.  Have you compiled your Emacs with libxml
> support?
Yes, AFAICT.  When I ran `sh autogen.sh && configure' I get the result
below. Thanks so much for your quick reply, Lars.  You are amazing, and
I really appreciate your work on Gnus and Gmane.

Configured for `x86_64-unknown-linux-gnu'.

  Where should the build process find the source code?    /home/john/Downloads/emacs
  What compiler should emacs be built with?               gcc -std=gnu99 -g3 -O2
  Should Emacs use the GNU version of malloc?             yes
      (Using Doug Lea's new malloc from the GNU C Library.)
  Should Emacs use a relocating allocator for buffers?    no
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    x11
  What toolkit should Emacs use?                          GTK3
  Where do we find X Windows header files?                Standard dirs
  Where do we find X Windows libraries?                   Standard dirs
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   yes
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes -lgif
  Does Emacs use -lpng?                                   yes
  Does Emacs use -lrsvg-2?                                no
  Does Emacs use imagemagick?                             no
  Does Emacs support sound?                               yes
  Does Emacs use -lgpm?                                   no
  Does Emacs use -ldbus?                                  yes
  Does Emacs use -lgconf?                                 no
  Does Emacs use GSettings?                               yes
  Does Emacs use a file notification library?             yes -lgio (gfile)
  Does Emacs use access control lists?                    no
  Does Emacs use -lselinux?                               no
  Does Emacs use -lgnutls?                                yes
  Does Emacs use -lxml2?                                  yes
  Does Emacs use -lfreetype?                              yes
  Does Emacs use -lm17n-flt?                              no
  Does Emacs use -lotf?                                   no
  Does Emacs use -lxft?                                   yes
  Does Emacs use toolkit scroll bars?                     yes

Re: eww

[Lars Magne Ingebrigtsen]

John Williams <john.williams@otago.ac.nz> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> John Williams <john.williams@otago.ac.nz> writes:
>>
>>> But when I say "M-x eww RET http://www.gnu.org RET" I get a totally
>>> blank buffer. 
>>
>> I don't get a blank buffer.  Have you compiled your Emacs with libxml
>> support?
> Yes, AFAICT.

[...]

>   Does Emacs use -lxml2?                                  yes

Hm.  So that should be OK, then.  And since it pops you to the eww
buffer, then it means that it got a response.

You just get a blank buffer?  No error messages?  `(setq debug-on-error t)'
gives you no backtrace?

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php

Re: eww

[John Williams]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> John Williams <john.williams@otago.ac.nz> writes:
>
>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> John Williams <john.williams@otago.ac.nz> writes:
>>>
>>>> But when I say "M-x eww RET http://www.gnu.org RET" I get a totally
>>>> blank buffer. 
>>>
>>> I don't get a blank buffer.  Have you compiled your Emacs with libxml
>>> support?
>> Yes, AFAICT.
>
> [...]
>
>>   Does Emacs use -lxml2?                                  yes
>
> Hm.  So that should be OK, then.  And since it pops you to the eww
> buffer, then it means that it got a response.
>
> You just get a blank buffer?  No error messages?  `(setq debug-on-error t)'
> gives you no backtrace?
Nope, nothing.  Here is the entire contents of the *Messages* buffer
after stating a new session and immediately saying `M-x eww RET RET',
i.e. visiting "https://duckduckgo.com/html/?q=" :

-------------------
Loading /home/john/.recentf...done
Could not deduce mode name from keymap name [8 times]
For information about GNU Emacs and the GNU system, type C-h C-a.
Package assoc is obsolete!
Contacting host: duckduckgo.com:443
gnutls.c: [1] Note that the security level of the Diffie-Hellman key exchange has been lowered to 256 bits and this may allow decryption of the session data
-------------------

Is the message about assoc being obsolete relevant?

Lars, thank you so much for your help.  I know how busy you are and I
really apreciate you taking the time to help me!

Cheers,

John

Re: eww

[Lars Magne Ingebrigtsen]

John Williams <john.williams@otago.ac.nz> writes:

> Loading /home/john/.recentf...done
> Could not deduce mode name from keymap name [8 times]
> For information about GNU Emacs and the GNU system, type C-h C-a.
> Package assoc is obsolete!
> Contacting host: duckduckgo.com:443
> gnutls.c: [1] Note that the security level of the Diffie-Hellman key
> exchange has been lowered to 256 bits and this may allow decryption of
> the session data
> -------------------
>
> Is the message about assoc being obsolete relevant?

Is it output by eww, or something before you call eww?

What does

(url-retrieve "https://duckduckgo.com/"
               (lambda (&rest ignore)
                 (switch-to-buffer (current-buffer))))

do for you?                 
                 
-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php

Re: eww

[John Williams]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> John Williams <john.williams@otago.ac.nz> writes:
>
>> Loading /home/john/.recentf...done
>> Could not deduce mode name from keymap name [8 times]
>> For information about GNU Emacs and the GNU system, type C-h C-a.
>> Package assoc is obsolete!
>> Contacting host: duckduckgo.com:443
>> gnutls.c: [1] Note that the security level of the Diffie-Hellman key
>> exchange has been lowered to 256 bits and this may allow decryption of
>> the session data
>> -------------------
>>
>> Is the message about assoc being obsolete relevant?
>
> Is it output by eww, or something before you call eww?
By something I call before eww.

> What does
>
> (url-retrieve "https://duckduckgo.com/"
>                (lambda (&rest ignore)
>                  (switch-to-buffer (current-buffer))))
>
> do for you?                 
It retrieves and displays the requested page in its full HTML glory
(i.e. as text, not rendered).  As I mentioned, calling eww with my
.emacs included produces an error, but `emacs -q` does not.  I saved the two
buffers and diffed them.  The only difference was the timestamps ("Date"
and "Expires").

But now something is different with the way the page is rendered.  When
I previously reported this (perhaps) bug, nothing was displayed at all.
In the intervening time I've changed my .emacs (but don't have a
changelog, sorry) and now the DDG page is _partially_ displayed.  The
top line of the buffer reads "https://duckduckgo.com/html/?q=" and the
cursor is blinking on the next line.

But I can't enter anything, and the text entry field is not displayed.
The eww menu is displayed and works fine.

Thanks for your help,

John

Re: eww

[Lars Magne Ingebrigtsen]

John Williams <john.williams@otago.ac.nz> writes:

> As I mentioned, calling eww with my .emacs included produces an error,
> but `emacs -q` does not.  I saved the two buffers and diffed them.
> The only difference was the timestamps ("Date" and "Expires").

What two buffers are you diffing?

> But now something is different with the way the page is rendered.  When
> I previously reported this (perhaps) bug, nothing was displayed at all.
> In the intervening time I've changed my .emacs (but don't have a
> changelog, sorry) and now the DDG page is _partially_ displayed.  The
> top line of the buffer reads "https://duckduckgo.com/html/?q=" and the
> cursor is blinking on the next line.
>
> But I can't enter anything, and the text entry field is not displayed.
> The eww menu is displayed and works fine.

But if you start emacs with -Q, then everything works fine?  Then I'd
suggest trying to remove stuff from your .emacs until it starts working.

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php
  and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html

Re: eww

[John Williams]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> John Williams <john.williams@otago.ac.nz> writes:
>
>> As I mentioned, calling eww with my .emacs included produces an error,
>> but `emacs -q` does not.  I saved the two buffers and diffed them.
>> The only difference was the timestamps ("Date" and "Expires").
>
> What two buffers are you diffing?
Sorry, I should have been more explicit.  The buffers are the data
returned from DDG after saying `M-x eww RET RET`.  One was the result
after launching emacs with no arguments; the other was after launching
`emacs -q`.

> But if you start emacs with -Q, then everything works fine?  Then I'd
> suggest trying to remove stuff from your .emacs until it starts
> working.
You're absolutely right.  I will do so and let you know what seems to be
causing this problem.  Thanks for your help!

Re: eww

[John Williams]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> John Williams <john.williams@otago.ac.nz> writes:
>
>> As I mentioned, calling eww with my .emacs included produces an error,
>> but `emacs -q` does not.  I saved the two buffers and diffed them.
>> The only difference was the timestamps ("Date" and "Expires").
>
> What two buffers are you diffing?
>
>> But now something is different with the way the page is rendered.  When
>> I previously reported this (perhaps) bug, nothing was displayed at all.
>> In the intervening time I've changed my .emacs (but don't have a
>> changelog, sorry) and now the DDG page is _partially_ displayed.  The
>> top line of the buffer reads "https://duckduckgo.com/html/?q=" and the
>> cursor is blinking on the next line.
>>
>> But I can't enter anything, and the text entry field is not displayed.
>> The eww menu is displayed and works fine.
>
> But if you start emacs with -Q, then everything works fine?  Then I'd
> suggest trying to remove stuff from your .emacs until it starts working.
Ironically, it was the latest version of Gnus that seemed to be causing
the problem!  When I commented out:

(setq load-path (cons (expand-file-name "~/.emacs.d/src/gnus/lisp") load-path))
(require 'gnus-load)

the warning about package assoc being obsolete disappeared, and eww now
works fine!  

The code in that directory was cloned from git a couple of weeks ago. I
can't tell what version it is, because the ChangeLog does not seem to be
current.

Is there anything else I can do to help track down this behaviour?

Cheers,

John

Re: eww

[Lars Magne Ingebrigtsen]

John Williams <john.williams@otago.ac.nz> writes:

> (setq load-path (cons (expand-file-name "~/.emacs.d/src/gnus/lisp") load-path))

You're probably just picking up an old version of shr or something.  

> Is there anything else I can do to help track down this behaviour?

I don't think there's anything much to track down.  >"?

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php
  and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html

Re: eww

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    > But when I say "M-x eww RET http://www.gnu.org RET" I get a totally
    > blank buffer. 

    I don't get a blank buffer.  Have you compiled your Emacs with libxml
    support?

Suppose he has done that: isn't it a bug that M-x eww gives a blank
buffer rather than a clear and specific error message?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: eww

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> Suppose he has done that: isn't it a bug that M-x eww gives a blank
> buffer rather than a clear and specific error message?

Definitely.  But we're trying to determine what actually bugs out here,
which is still unclear.

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php