From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 83F5A783A6 for ; Tue, 15 Sep 2015 08:47:36 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-06v.sys.comcast.net with comcast id HTpu1r0042Bo0NV01TqRK1; Tue, 15 Sep 2015 15:50:25 +0000 Received: from eklhad ([IPv6:2601:405:4002:b0a:21e:4fff:fec2:a0f1]) by resomta-ch2-05v.sys.comcast.net with comcast id HTqR1r00B0GArqr01TqRBj; Tue, 15 Sep 2015 15:50:25 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.5.4.2+ Date: Tue, 15 Sep 2015 11:50:25 -0400 Message-ID: <20150815115025.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1442332225; bh=EecorAscPc3EWhz89jqBZTYWOLIspJkXtDPyXmyWT+Y=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=huQJJrEFetabnH1gYcfiFc8PgHJiGxJKhe4DKtqDrwWZGHq1EygV4kM0eCjGDHn98 gAVa20FpIMbjfXf1PSrJIqv0EHwPim0XNEpdig8fmBoyURzm608xszIvK+XlV9oCuX ue53ZfB0nCrqTfYURoUswZogjdc8fam0iObHXG1LDEB/l6t29mykyb2BKkIropH1B9 8JYirDSEaBNIY8t+s6Y6KaZuFMReR24j8vwEnF9B5gwlPmEoeoVkbySmgeqeKbMZTj OzTDsMIsIo2UA3hvBMOS+yPwPTjchARgGq79M8sjXfzhZYDeEhw+KHUOBkM3MMN65r UraEI5Q9IRnSQ== Subject: [Edbrowse-dev] Bringing Delete Back X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 15:47:36 -0000 Here are some thoughts on bringing the d command back in browse mode. Every implementation has some caveats on certain web pages. We just have to be ok with that. When a line is deleted, mark all nodes on that line as deleted, or invisible or some such. Also mark any descendant nodes of these nodes. They might not appear on the page at this time, but innerHTML could add text to them later, and then they would appear on the page, and we don't want that, since we deleted the structure that contains it. With nodes so marked, they would not render, and the line would not reappear. It would be difficult, though not impossible, to undo this change. Very likely there would be no undo command. This is not unusual. Delete in directory mode deletes the file, and delete in database mode deletes the row, and there is no undo. So I think this is ok. You can always rebrowse or refresh the page if you screwed up. The last node deleted could extend well beyond the current line. It could be a preformatted 
 poem that goes on for 3 pages.
So you delete a line and after rerender, or any javascript action,
the whole poem is gone.
This seems to be quite rare.
A web page can barely put to words together without changing font or style or something.
So I think this would be a very rare case, I'm just saying it could happen.

On the other side, if you delete the fifth line from a preformatted poem,
you haven't deleted any nodes, and upon rerender the entire poem reappears,
including the line you deleted.
Again I think this is rare.
In practice people delete entire blocks or logical sections from a web page,
not the middle of a paragraph.

I'll continue to think about this and other d implementations for a bit.

Karl Dahlke