Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Stefan Monnier]

> +(defun eww-exit ()
> +  "Exit the Emacs Web Wowser."
> +  (interactive)
> +  (setq eww-history nil)
> +  (kill-buffer (current-buffer)))
> +
> +(defun eww-close ()
> +  "Close the Emacs Web Wowser browser, leaving history intact."
> +  (interactive)
> +  (quit-window))

I think this is a step backward.  The names `eww-close' and `eww-exit'
don't help the user understand what those commands do.  To me they sound
like different names for the same thing.

I'd rather use commands `kill-this-buffer' and `quit-window' which are
much more clear and which the user might already know.

I'm not sure how (setq eww-history nil) fits in there, because I don't
know why it's there, so I can't comment on how best to go about it in
this respect.


        Stefan

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Ted Zlatanov]

On Thu, 12 Dec 2013 13:52:48 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> +(defun eww-exit ()
>> +  "Exit the Emacs Web Wowser."
>> +  (interactive)
>> +  (setq eww-history nil)
>> +  (kill-buffer (current-buffer)))
>> +
>> +(defun eww-close ()
>> +  "Close the Emacs Web Wowser browser, leaving history intact."
>> +  (interactive)
>> +  (quit-window))

SM> I think this is a step backward.  The names `eww-close' and `eww-exit'
SM> don't help the user understand what those commands do.  To me they sound
SM> like different names for the same thing.

I think `close' and `exit' in the context of a web browser are very
clear concepts.  Do you think any users are unfamiliar with web
browsers?  Or do you want to give Emacs-specific names to these
concepts?

I would rather avoid this Emacsification[1], personally, and have done
my best to help eww users, but eww is not my project so I'll leave it to
Lars and you to settle it.

SM> I'd rather use commands `kill-this-buffer' and `quit-window' which are
SM> much more clear and which the user might already know.

SM> I'm not sure how (setq eww-history nil) fits in there, because I don't
SM> know why it's there, so I can't comment on how best to go about it in
SM> this respect.

It ensures that the browsing history is erased, which `kill-buffer' may
not do.  This was in Lars' original code as `eww-quit' so I kept it.

Ted

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Stefan Monnier]

> I think `close' and `exit' in the context of a web browser are very
> clear concepts.

But they don't map cleanly to the use of eww, i.e. with Emacs.

> Do you think any users are unfamiliar with web browsers?

I think all users of eww are first and foremost Emacs users rather than
"browser users" (at least for foreseeable future), so they will be
familiar with quit-window and with the notion of killing a buffer,
whereas they won't know (without looking at the code) whether `close'
actually kills the buffer, or deletes the window, or both, or whether
it's eww-exit which does it, and in which cases.

> Or do you want to give Emacs-specific names to these concepts?

Your commands don't really do what they do in a web-browser.  I guess in
some case, depending on how you look at it, and how you configured your
display-buffer-alist and your dedicated windows, and how you started
ewww, etc... they may occasionally behave similarly to Firefox's "close"
and "exit" (tho it also depends on the window-manager in which you run
firefox).  But in the general case they don't.

SM> I'm not sure how (setq eww-history nil) fits in there, because I don't
SM> know why it's there, so I can't comment on how best to go about it in
SM> this respect.
> It ensures that the browsing history is erased,

That part was clear, the question is why do it here rather than elsewhere.

> which `kill-buffer' may not do.

Why not?  If the variable is buffer-local, kill-buffer will do it, and
if the variable is global, then we have a problem since it's then shared
between all eww buffers, right?


        Stefan

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Ted Zlatanov]

On Thu, 12 Dec 2013 17:14:28 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> I think `close' and `exit' in the context of a web browser are very
>> clear concepts.

SM> But they don't map cleanly to the use of eww, i.e. with Emacs.

OK, we have to disagree there.  Explanation below.

>> Do you think any users are unfamiliar with web browsers?

SM> I think all users of eww are first and foremost Emacs users rather than
SM> "browser users" (at least for foreseeable future), so they will be
SM> familiar with quit-window and with the notion of killing a buffer,
SM> whereas they won't know (without looking at the code) whether `close'
SM> actually kills the buffer, or deletes the window, or both, or whether
SM> it's eww-exit which does it, and in which cases.

(I will try to answer, but please remember I am not trying to dictate
the direction of eww.  It's not my package and I'm OK with reverting my
changes if you and Lars feel it's necessary.  My intent is only to make
the user experience better.)

Web browsing is a separate UI domain from the other UI domains Emacs
covers.  The UI for navigation, input, and even scrolling is different.
It's most like an Info file but there are fundamental differences (no
clear hierarchy, interactive, etc.)  So my idea was to make web browsing
in Emacs more like web browsing outside Emacs, and I thought my changes
were a step in that direction.

>> Or do you want to give Emacs-specific names to these concepts?

SM> Your commands don't really do what they do in a web-browser.  I guess in
SM> some case, depending on how you look at it, and how you configured your
SM> display-buffer-alist and your dedicated windows, and how you started
SM> ewww, etc... they may occasionally behave similarly to Firefox's "close"
SM> and "exit" (tho it also depends on the window-manager in which you run
SM> firefox).  But in the general case they don't.

The idea was to separate "close" from "exit" even if the current
implementation doesn't do it perfectly, because tha separation is
typical in the "web browsing" UI domain.

If we agree on that piece, we can discuss how the implementations of
"close" and "exit" should differ in theory and in practice.  If we
don't, there's no point in analyzing the specific implementations and
you and Lars can choose to revert them.

SM> I'm not sure how (setq eww-history nil) fits in there, because I don't
SM> know why it's there, so I can't comment on how best to go about it in
SM> this respect.
>> It ensures that the browsing history is erased,

SM> That part was clear, the question is why do it here rather than elsewhere.

>> which `kill-buffer' may not do.

SM> Why not?  If the variable is buffer-local, kill-buffer will do it, and
SM> if the variable is global, then we have a problem since it's then shared
SM> between all eww buffers, right?

Right.  Lars?  Can you clarify?

Ted

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Stefan Monnier]

> Web browsing is a separate UI domain from the other UI domains Emacs
> covers.  The UI for navigation, input, and even scrolling is different.
> It's most like an Info file but there are fundamental differences (no
> clear hierarchy, interactive, etc.)  So my idea was to make web browsing
> in Emacs more like web browsing outside Emacs, and I thought my changes
> were a step in that direction.

I view it as trying to lie to the user ;-)

> The idea was to separate "close" from "exit" even if the current
> implementation doesn't do it perfectly, because tha separation is
> typical in the "web browsing" UI domain.

AFAIK "close" should mean "close the current tab", and "exit" should
mean "exit the application, closing all tabs and killing the process".

Some of the problems I see in the context of eww:
- eww doesn't have tabs.
- eww-exit doesn't exit the application.
- eww-exit does not close all the eww buffers/tabs/windows you might
  have opened in the current Emacs session.
- eww can display a web page multiple times in different windows, so the
  meaning of "close the tab" is unclear.

I really see it as trying to put a square peg in a round hole.
And I really don't see the benefit since eww users will be familiar with
Emacs anyway, so it's not like we'd impose them some new concepts they
shouldn't need to know.


        Stefan

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Ted Zlatanov]

On Fri, 13 Dec 2013 10:06:41 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> Web browsing is a separate UI domain from the other UI domains Emacs
>> covers.  The UI for navigation, input, and even scrolling is different.
>> It's most like an Info file but there are fundamental differences (no
>> clear hierarchy, interactive, etc.)  So my idea was to make web browsing
>> in Emacs more like web browsing outside Emacs, and I thought my changes
>> were a step in that direction.

SM> I view it as trying to lie to the user ;-)

All computing is lying to the user, so I am OK with that.

>> The idea was to separate "close" from "exit" even if the current
>> implementation doesn't do it perfectly, because tha separation is
>> typical in the "web browsing" UI domain.

SM> AFAIK "close" should mean "close the current tab", and "exit" should
SM> mean "exit the application, closing all tabs and killing the process".

Right.

SM> Some of the problems I see in the context of eww:
SM> - eww doesn't have tabs.
SM> - eww-exit doesn't exit the application.
SM> - eww-exit does not close all the eww buffers/tabs/windows you might
SM>   have opened in the current Emacs session.
SM> - eww can display a web page multiple times in different windows, so the
SM>   meaning of "close the tab" is unclear.

I agree the current implementation is suboptimal but your problem is
with the fundamental idea of separating "close" from "exit."  So unless
you want to separate them at some level or at least acknowledge the
difference between them, there's no point in discussing the items above
and we should instead focus on improving `quit-window' or the eww
equivalent thereof.

SM> I really see it as trying to put a square peg in a round hole.
SM> And I really don't see the benefit since eww users will be familiar with
SM> Emacs anyway, so it's not like we'd impose them some new concepts they
SM> shouldn't need to know.

OK, so what would you like (and let's wait for Lars to comment before we
take action, if you want to revert)?

- revert back to `q' being `quit-window', no "close" or "exit" concepts
- implement some way to quit all eww windows for privacy and security
- implement "close" and "exit" differently but still try to separate them
- implement "close" and "exit" separately with different names
- some combination?  something else?

Thanks
Ted

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Stefan Monnier]

> I agree the current implementation is suboptimal but your problem is
> with the fundamental idea of separating "close" from "exit."

No, the problem is with calling eww-close instead of quit-window, and
with calling eww-exit instead of kill-this-buffer.  To me, this is
just obfuscation.

> - revert back to `q' being `quit-window',

Yes.  As I said elsewhere, I think this binding should basically be
inherited from special-mode-map.

> - no "close" or "exit" concepts

Yup.

> - implement some way to quit all eww windows for privacy and security

If someone wants that, I'm not opposed to it (tho "quitting all windows"
won't give you any privacy or security benefits, so it will presumably
do something else).  But I wouldn't call it "exit".  The name should
instead include something like clear/wipe/flush/...

> - implement "close" and "exit" differently but still try to separate them

As explained in my previous email those two concepts don't make sense in
the context of eww, so those names shouldn't be used.


        Stefan

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Ted Zlatanov]

On Fri, 13 Dec 2013 21:07:00 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> I agree the current implementation is suboptimal but your problem is
>> with the fundamental idea of separating "close" from "exit."

SM> No, the problem is with calling eww-close instead of quit-window, and
SM> with calling eww-exit instead of kill-this-buffer.  To me, this is
SM> just obfuscation.

I understand we disagree on this.

>> - revert back to `q' being `quit-window',

SM> Yes.  As I said elsewhere, I think this binding should basically be
SM> inherited from special-mode-map.

>> - implement some way to quit all eww windows for privacy and security

SM> If someone wants that, I'm not opposed to it (tho "quitting all windows"
SM> won't give you any privacy or security benefits, so it will presumably
SM> do something else).  But I wouldn't call it "exit".  The name should
SM> instead include something like clear/wipe/flush/...

I will wait for Lars to make the final decision.  If he agrees with you,
going to just `special-mode-map' is probably the best way, and we can
forget about special "quit all" functionality.

Ted

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> OK, so what would you like (and let's wait for Lars to comment before we
> take action, if you want to revert)?
>
> - revert back to `q' being `quit-window', no "close" or "exit" concepts

I think adding all these different concepts to eww is overcomplicating
things.  `q' (with `quit-buffer') makes the buffer "go away" in the
manner that's normal for Emacs special mode buffers to do, and if the
user wants to really destroy the buffer, then `C-x k' does that
perfectly well.

eww seems more like something like Dired than Gnus or VM, so it should
behave more like Dired than Gnus...

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

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[T.V. Raman]

I  tend to agree with Lars -- also, if I really want persistence,
I can always rename the *eww* buffer to something more
meaningful, and pop up a secondary default eww session with M-x
eww
-- 

-- 


On 12/14/13, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> OK, so what would you like (and let's wait for Lars to comment before we
>> take action, if you want to revert)?
>>
>> - revert back to `q' being `quit-window', no "close" or "exit" concepts
>
> I think adding all these different concepts to eww is overcomplicating
> things.  `q' (with `quit-buffer') makes the buffer "go away" in the
> manner that's normal for Emacs special mode buffers to do, and if the
> user wants to really destroy the buffer, then `C-x k' does that
> perfectly well.
>
> eww seems more like something like Dired than Gnus or VM, so it should
> behave more like Dired than Gnus...
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
>

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Ted Zlatanov]

On Sat, 14 Dec 2013 18:49:40 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> OK, so what would you like (and let's wait for Lars to comment before we
>> take action, if you want to revert)?
>> 
>> - revert back to `q' being `quit-window', no "close" or "exit" concepts

LMI> I think adding all these different concepts to eww is overcomplicating
LMI> things.  `q' (with `quit-buffer') makes the buffer "go away" in the
LMI> manner that's normal for Emacs special mode buffers to do, and if the
LMI> user wants to really destroy the buffer, then `C-x k' does that
LMI> perfectly well.

LMI> eww seems more like something like Dired than Gnus or VM, so it should
LMI> behave more like Dired than Gnus...

OK.  I can't figure out how to revert a single commit in Bazaar so if
someone could revert 115470 I would appreciate it.  `bzr uncommit'
doesn't do it and I don't want to brute-force it as a reverse patch.

Thanks
Ted

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Glenn Morris]

Ted Zlatanov wrote:

> I don't want to brute-force it as a reverse patch.

That _is_ how you do it.

(You _can_ uncommit things, with a bit of effort, but don't do so unless
it is really, really essential. Eg a commit somehow triggered a bug in
the VCS itself.)

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Ted Zlatanov]

On Mon, 16 Dec 2013 17:30:06 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> Ted Zlatanov wrote:
>> I don't want to brute-force it as a reverse patch.

GM> That _is_ how you do it.

Thanks, pushed.

GM> (You _can_ uncommit things, with a bit of effort, but don't do so unless
GM> it is really, really essential. Eg a commit somehow triggered a bug in
GM> the VCS itself.)

I'm used to the Git workflow, where "git revert" will DTRT for this
situation (though I would patch it to retain the ChangeLog entry).
Thanks for explaining.

Ted

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Stephen J. Turnbull]

Ted Zlatanov writes:
 > On Mon, 16 Dec 2013 17:30:06 -0500 Glenn Morris <rgm@gnu.org> wrote: 
 > 
 > GM> Ted Zlatanov wrote:
 > >> I don't want to brute-force it as a reverse patch.

 > I'm used to the Git workflow, where "git revert" will DTRT for this

"git revert" or "git reset"?  "git revert" *exactly* applies a reverse
patch, and can be used to precisely reverse the effect of any earlier
change in one operation (assuming no conflicts).  "git reset" OTOH
leaves no trace of the earlier patch -- or any changes since then, so
you need to reapply ("rebase") them.

Only Darcs allows you to literally "obliterate" any existing patch in
one operation (I forget whether the result is a conflicted repo or if
you need to resolve the conflicts immediately or the operation aborts
as in other VCSes).

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Ted Zlatanov]

On Fri, 20 Dec 2013 09:41:40 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:
>> On Mon, 16 Dec 2013 17:30:06 -0500 Glenn Morris <rgm@gnu.org> wrote: 
>> 
GM> Ted Zlatanov wrote:
>> >> I don't want to brute-force it as a reverse patch.

>> I'm used to the Git workflow, where "git revert" will DTRT for this

SJT> "git revert" or "git reset"?  "git revert" *exactly* applies a reverse
SJT> patch, and can be used to precisely reverse the effect of any earlier
SJT> change in one operation (assuming no conflicts).  "git reset" OTOH
SJT> leaves no trace of the earlier patch -- or any changes since then, so
SJT> you need to reapply ("rebase") them.

I meant "git revert" precisely.  "git reset" rewrites history, which in
a public repo is considered bad practice (no need to get into details).

Ted

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Andreas Schwab]

Ted Zlatanov <tzz@lifelogs.com> writes:

> "git reset" rewrites history

It does nothing like that, it *only* changes your worktree, like you can
do with our editor.

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: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Ted Zlatanov]

On Fri, 20 Dec 2013 12:15:10 +0100 Andreas Schwab <schwab@linux-m68k.org> wrote: 

AS> Ted Zlatanov <tzz@lifelogs.com> writes:
>> "git reset" rewrites history

AS> It does nothing like that, it *only* changes your worktree, like you can
AS> do with our editor.

I know what it does and how it can be used but was trying to avoid
getting into details irrelevant to this thread.  I shouldn't have
mentioned Git at all, sorry for the noise.

Ted

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Stephen J. Turnbull]

Andreas Schwab writes:
 > Ted Zlatanov <tzz@lifelogs.com> writes:
 > 
 > > "git reset" rewrites history
 > 
 > It does nothing like that, it *only* changes your worktree, like you can
 > do with our editor.

Nothing like that, either. :-)  git reset by itself only changes HEAD
and the index.  It only changes the tree with "--hard", "--merge", or
"--keep".

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Steinar Bang]

>>>>> Andreas Schwab <schwab@linux-m68k.org>:

[on "git reset"]
> It does nothing like that, it *only* changes your worktree, like you can
> do with our editor.

This is wrong (unless you take your editor down into the .git directory
and start messing with the local index manually... which is not
recommended...!).

What 
 git reset <commit>
does is reset the current branch to <commit>, where <commit> typically(*)
is a commit earlier than HEAD of the current branch.

The files in the work tree are left untouched (ie. local edits are not
removed).

The command
 git reset --hard <commit>
resets the current branch in the same manner, and make the files in the
work tree have the version in <commit>.

Until you try pushing the changes to a remote, the changes only have
local effect.  If you try pushing a branch that has been reset to an
earlier commit, git will refuse to do so.  If the remote repository
permits it, the branch can be pushed.

The forcibly pushed branch will create issues for other users that have
fetched that branch between the original push and the reset push.  How
bad the issues are depends on what has happened to the branch in the
different users' local git repositories... but there _will_ be issues.

(*) However <commit> can be any commit on any branch, or any tag or
    branch name which can have disastrous effects, like eg. overwriting
    your changes in a local-only branch with the contents of a different
    branch 

Re: [Emacs-diffs] trunk r115470: eww: exit and close actions

[Ted Zlatanov]

On Fri, 20 Dec 2013 14:12:09 +0100 Steinar Bang <sb@dod.no> wrote: 

>>>>>> Andreas Schwab <schwab@linux-m68k.org>:
SB> [on "git reset"]
>> It does nothing like that, it *only* changes your worktree, like you can
>> do with our editor.

SB> This is wrong (unless you take your editor down into the .git directory
SB> and start messing with the local index manually... which is not
SB> recommended...!).

Guys, please, this thread is over.

Ted