unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] trunk r115470: eww: exit and close actions
Date: Fri, 13 Dec 2013 09:36:10 -0500	[thread overview]
Message-ID: <878uvoq0md.fsf@flea.lifelogs.com> (raw)
In-Reply-To: jwviout67wi.fsf-monnier+emacsdiffs@gnu.org

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




  reply	other threads:[~2013-12-13 14:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1Vqp1Z-0004La-IR@vcs.savannah.gnu.org>
2013-12-12 18:52 ` [Emacs-diffs] trunk r115470: eww: exit and close actions Stefan Monnier
2013-12-12 19:17   ` Ted Zlatanov
2013-12-12 22:14     ` Stefan Monnier
2013-12-13 14:36       ` Ted Zlatanov [this message]
2013-12-13 15:06         ` Stefan Monnier
2013-12-13 19:36           ` Ted Zlatanov
2013-12-14  2:07             ` Stefan Monnier
2013-12-14 17:33               ` Ted Zlatanov
2013-12-14 17:49             ` Lars Magne Ingebrigtsen
2013-12-16  0:21               ` T.V. Raman
2013-12-16 22:25               ` Ted Zlatanov
2013-12-16 22:30                 ` Glenn Morris
2013-12-19 16:27                   ` Ted Zlatanov
2013-12-20  0:41                     ` Stephen J. Turnbull
2013-12-20  1:07                       ` Ted Zlatanov
2013-12-20 11:15                         ` Andreas Schwab
2013-12-20 11:32                           ` Ted Zlatanov
2013-12-20 12:00                           ` Stephen J. Turnbull
2013-12-20 13:12                           ` Steinar Bang
2013-12-20 14:36                             ` Ted Zlatanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878uvoq0md.fsf@flea.lifelogs.com \
    --to=tzz@lifelogs.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).