From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?J=E9r=E9my_Compostella?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] window.el: Improve mark management Date: Sat, 21 Jan 2012 15:36:21 +0100 Message-ID: References: <87zkdjtr4v.fsf@Apollo.jerryland.fr> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=f46d043c077ed4513804b70ab950 X-Trace: dough.gmane.org 1327156616 30974 80.91.229.12 (21 Jan 2012 14:36:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 21 Jan 2012 14:36:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 21 15:36:49 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Roc3k-0005ZN-Lz for ged-emacs-devel@m.gmane.org; Sat, 21 Jan 2012 15:36:48 +0100 Original-Received: from localhost ([::1]:50343 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Roc3k-00029G-6h for ged-emacs-devel@m.gmane.org; Sat, 21 Jan 2012 09:36:48 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:44124) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Roc3g-00027r-IL for emacs-devel@gnu.org; Sat, 21 Jan 2012 09:36:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Roc3e-0002E1-S8 for emacs-devel@gnu.org; Sat, 21 Jan 2012 09:36:44 -0500 Original-Received: from mail-tul01m020-f169.google.com ([209.85.214.169]:53807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Roc3e-0002Dt-MF for emacs-devel@gnu.org; Sat, 21 Jan 2012 09:36:42 -0500 Original-Received: by obbta7 with SMTP id ta7so2168931obb.0 for ; Sat, 21 Jan 2012 06:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uVWsDoKdmBpQgrdwrc1WFmtALfF8F92kfhITXYgUWxI=; b=iesQqoha0Twlx0SD8VoC//Zp0lTnlEZWN38ZxFONYg1GuFzQQuUiRqq7Hmq6JB4/jM I6h+kGF3mpuzLQJmzc8KxT62+LiogT1WvB34ou+qQn58n2ZiaQkVMONQypR0cANVf/LW +nafgfR8DNPtR2pMPS4S4tCnc6QQ4buqaSCA4= Original-Received: by 10.182.0.106 with SMTP id 10mr1681596obd.72.1327156602097; Sat, 21 Jan 2012 06:36:42 -0800 (PST) Original-Received: by 10.60.49.103 with HTTP; Sat, 21 Jan 2012 06:36:21 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.214.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147816 Archived-At: --f46d043c077ed4513804b70ab950 Content-Type: multipart/alternative; boundary=f46d043c077ed4513504b70ab94e --f46d043c077ed4513504b70ab94e Content-Type: text/plain; charset=ISO-8859-1 2012/1/20 Stefan Monnier > >> I'm not completely sure. The current code doesn't seem that bad since, > >> as you say, it basically reproduces the behavior of > >> window-configurations. > >> So I'd like to first hear of what are concrete cases where the current > >> behavior is a problem. > > It's very simple : with the current code, when you call the > > `window-state-put' function, the mark is restored as active. > > That's easy to fix: use (set-marker (mark-marker)) instead of set-mark. > Interesting. > > > - Either, remove all the mark stuff from `window-state-get' and > > `window-state-put' functions. > > That's not a bad idea, actually. > Yes that's was my first idea in fact. After this discussion I think it's the good thing to do and ou I attached the corresponding patch to this email. `window-state-get' and `window-state-put' should not deal with mark as it's not relevant at all and leads to an unexpected behavior from user point of view. > > Stefan > > > PS: BTW, the "multiple push-mark" issue can be solved by saving the mark > only once per buffer rather than once per window (i.e. the window-state > object would have a separate list of affected buffers with their > corresponding state, including the mark, not sure what else could be > there). > I do agree but it will change several things and while we are in feature freeze I propose to remove the wrong mark management and see how to do it this way in future development. Thanks. --f46d043c077ed4513504b70ab94e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/1/20 Stefan Monnier <<= a href=3D"mailto:monnier@iro.umontreal.ca">monnier@iro.umontreal.ca>=
>> I'm not completely sure. =A0The current code= doesn't seem that bad since,
>> as you say, it basically reproduces the behavior of
>> window-configurations.
>> So I'd like to first hear of what are concrete cases where the= current
>> behavior is a problem.
> It's very simple : with the current code, when you call the
> `window-state-put' function, the mark is restored as active.

That's easy to fix: use (set-marker (mark-marker)) instead of set= -mark.
Interesting.=A0

> - Either, remove all the mark stuff from `window-state-get' and > `window-state-put' functions.

That's not a bad idea, actually.
Yes that= 9;s was my first idea in fact. After this discussion I think it's the g= ood
thing to do and ou I attached=A0the corresponding patch to th= is email.
`window-state-get' and `window-state-put' should not deal with= mark as it's not
relevant at all and leads to an unexpected = behavior from user point of view.



=A0 =A0 =A0 =A0Stefan


PS: BTW, the "multiple push-mark" issue can be solved by saving t= he mark
only once per buffer rather than once per window (i.e. the window-state
object would have a separate list of affected buffers with their
corresponding state, including the mark, not sure what else could be
there).
I do agree but it will change several things a= nd while we are in feature freeze I
propose to remove the wrong m= ark management and see how to do it this way
in future developmen= t.

Thanks.

--f46d043c077ed4513504b70ab94e-- --f46d043c077ed4513804b70ab950 Content-Type: text/x-patch; charset=US-ASCII; name="0001-window.el-Remove-mark-save-and-restore.patch" Content-Disposition: attachment; filename="0001-window.el-Remove-mark-save-and-restore.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gxoqos9p0 RnJvbSBlNTE3MzE5ZWUxZDVmYmI4Nzg5ZmRjZWQ5NmRkZThkMjEyZWZkMWIyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBKZXJlbXkgQ29tcG9zdGVsbGEgPGplcmVteS5jb21wb3N0ZWxs YUBnbWFpbC5jb20+CkRhdGU6IFRodSwgMTkgSmFuIDIwMTIgMTQ6MzM6MzIgKzAxMDAKU3ViamVj dDogW1BBVENIXSB3aW5kb3cuZWw6IFJlbW92ZSBtYXJrIHNhdmUgYW5kIHJlc3RvcmUKCkFzIGxv bmcgYXMgSSBrbm93IG1hcmsgaXMgcmVsYXRlZCB0byBhIGJ1ZmZlciBhbmQgbm90IHRvIGEgd2lu ZG93LiBJdCBzaG91bGQKYmUgc2F2ZWQgYnkgYnVmZmVyIGZ1bmN0aW9ucyBhbmQgbm90IHdpbmRv dyBmdW5jdGlvbnMuIE1vcmVvdmVyLCB3aGVuCkkgY2FsbCB3aW5kb3ctc3RhdGUtcHV0IG9uIGEg d2luZG93LXN0YXRlLWdldCBwcmV2aW91c2x5IHN0b3JlZCB0aGUKbWFyayBpcyBjaGFuZ2VkIGFu ZCBhY3RpdmF0ZWQgd2hpY2ggZG9lcyBub3QgbG9vayBsaWtlIHRoZSBkZXNpcmVkIGJlaGF2aW9y LgoKU2lnbmVkLW9mZi1ieTogSmVyZW15IENvbXBvc3RlbGxhIDxqZXJlbXkuY29tcG9zdGVsbGFA Z21haWwuY29tPgotLS0KIGxpc3Avd2luZG93LmVsIHwgICAxMSArKy0tLS0tLS0tLQogMSBmaWxl cyBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDkgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEv bGlzcC93aW5kb3cuZWwgYi9saXNwL3dpbmRvdy5lbAppbmRleCA5MTIyOTA0Li44MzJhMDhkIDEw MDY0NAotLS0gYS9saXNwL3dpbmRvdy5lbAorKysgYi9saXNwL3dpbmRvdy5lbApAQCAtMzYyMiwx MCArMzYyMiw3IEBAIHNwZWNpZmljIGJ1ZmZlcnMuIgogICAgICAgICAgICAgICAgICAgICAgICAo dnNjcm9sbCAuICwod2luZG93LXZzY3JvbGwgd2luZG93KSkKICAgICAgICAgICAgICAgICAgICAg ICAgKGRlZGljYXRlZCAuICwod2luZG93LWRlZGljYXRlZC1wIHdpbmRvdykpCiAgICAgICAgICAg ICAgICAgICAgICAgIChwb2ludCAuICwoaWYgd3JpdGFibGUgcG9pbnQgKGNvcHktbWFya2VyIHBv aW50KSkpCi0gICAgICAgICAgICAgICAgICAgICAgIChzdGFydCAuICwoaWYgd3JpdGFibGUgc3Rh cnQgKGNvcHktbWFya2VyIHN0YXJ0KSkpCi0gICAgICAgICAgICAgICAgICAgICAgICxAKHdoZW4g bWFyawotICAgICAgICAgICAgICAgICAgICAgICAgICAgYCgobWFyayAuICwoaWYgd3JpdGFibGUK LSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1hcmsgKGNvcHktbWFy a2VyIG1hcmspKSkpKSkpKSkpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgKHN0YXJ0IC4gLChp ZiB3cml0YWJsZSBzdGFydCAoY29weS1tYXJrZXIgc3RhcnQpKSkpKSkpKSkpCiAJICh0YWlsCiAJ ICAod2hlbiAobWVtcSB0eXBlICcodmMgaGMpKQogCSAgICAobGV0IChsaXN0KQpAQCAtMzgwOSwx MSArMzgwNiw3IEBAIHZhbHVlIGNhbiBiZSBhbHNvIHN0b3JlZCBvbiBkaXNrIGFuZCByZWFkIGJh Y2sgaW4gYSBuZXcgc2Vzc2lvbi4iCiAJICA7OyBoYXZlIGJlZW4gY3JlYXRlZCBhbmQgc2l6ZWQp LgogCSAgKGlnbm9yZS1lcnJvcnMKIAkgICAgKHNldC13aW5kb3ctc3RhcnQgd2luZG93IChjZHIg KGFzc3EgJ3N0YXJ0IHN0YXRlKSkpCi0JICAgIChzZXQtd2luZG93LXBvaW50IHdpbmRvdyAoY2Ry IChhc3NxICdwb2ludCBzdGF0ZSkpKQotCSAgICA7OyBJJ20gbm90IHN1cmUgd2hldGhlciB3ZSBz aG91bGQgc2V0IHRoZSBtYXJrIGhlcmUsIGJ1dCBtYXliZQotCSAgICA7OyBpdCBjYW4gYmUgdXNl ZC4KLQkgICAgKGxldCAoKG1hcmsgKGNkciAoYXNzcSAnbWFyayBzdGF0ZSkpKSkKLQkgICAgICAo d2hlbiBtYXJrIChzZXQtbWFyayBtYXJrKSkpKQorCSAgICAoc2V0LXdpbmRvdy1wb2ludCB3aW5k b3cgKGNkciAoYXNzcSAncG9pbnQgc3RhdGUpKSkpCiAJICA7OyBTZWxlY3Qgd2luZG93IGlmIGl0 J3MgdGhlIHNlbGVjdGVkIG9uZS4KIAkgICh3aGVuIChjZHIgKGFzc3EgJ3NlbGVjdGVkIHN0YXRl KSkKIAkgICAgKHNlbGVjdC13aW5kb3cgd2luZG93KSkpKSkpKQotLSAKMS43LjIuNQoK --f46d043c077ed4513804b70ab950--