From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Window configurations Date: Mon, 03 May 2010 03:57:03 +0300 Organization: JURTA Message-ID: <87ljc1pyo4.fsf@mail.jurta.org> References: <4BB4CF6B.2000007@alice.it> <87eii63v4j.fsf@mail.jurta.org> <0840B3F4D9E84706874EDD2CA2CC4236@us.oracle.com> <87vdbhgqgd.fsf@mail.jurta.org> <828BB36311A84C43B96D1F2A559DACAE@us.oracle.com> <87d3xo662u.fsf@mail.jurta.org> <69D40D69CC6F4982A8E91D8D8F0F494F@us.oracle.com> <87r5m4hz39.fsf@mail.jurta.org> <4BD40821.70808@gmx.at> <87zl0rtmqy.fsf@mail.jurta.org> <878w822i5a.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1272850077 15379 80.91.229.12 (3 May 2010 01:27:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 3 May 2010 01:27:57 +0000 (UTC) Cc: Ken Hori , martin rudalics , Drew Adams , Emacs To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 03 03:27:55 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O8kRu-00020D-L2 for ged-emacs-devel@m.gmane.org; Mon, 03 May 2010 03:27:55 +0200 Original-Received: from localhost ([127.0.0.1]:54688 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O8kRt-000886-PN for ged-emacs-devel@m.gmane.org; Sun, 02 May 2010 21:27:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O8kRo-00087I-Aw for emacs-devel@gnu.org; Sun, 02 May 2010 21:27:48 -0400 Original-Received: from [140.186.70.92] (port=49110 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O8kRn-00086h-6u for emacs-devel@gnu.org; Sun, 02 May 2010 21:27:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O8kRl-00019H-9B for emacs-devel@gnu.org; Sun, 02 May 2010 21:27:47 -0400 Original-Received: from smtp-out2.starman.ee ([85.253.0.4]:39953 helo=mx2.starman.ee) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O8kRk-000193-VO for emacs-devel@gnu.org; Sun, 02 May 2010 21:27:45 -0400 X-Virus-Scanned: by Amavisd-New at mx2.starman.ee Original-Received: from mail.starman.ee (82.131.92.108.cable.starman.ee [82.131.92.108]) by mx2.starman.ee (Postfix) with ESMTP id 3D4BD3F40A6; Mon, 3 May 2010 04:27:39 +0300 (EEST) In-Reply-To: (Stefan Monnier's message of "Sun, 02 May 2010 20:50:01 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:124455 Archived-At: >>> There is one problem of using bookmark records for desktop.el. >>> Some bookmarks take too much time to restore when reading >>> from the desktop file. > > Juri, do you have more details on this? I don't know of this problem. Currently, Info mode doesn't save/restore virtual Info nodes to the desktop file at all. Even `dir' is not saved (which is a virtual file now). The patch I sent on 2010-04-27 allows Info-desktop-buffer-misc-data to save all virtual nodes to the desktop, except Info-apropos. Info-apropos takes too much time to create a node with the search results. So restoring an Info-apropos node from the desktop file would be unacceptably slow. One variant is to save the apropos search results as text in the desktop file, but then it will grow too big. There is no such problem for bookmarks because when the user decides to restore a bookmark for an Info-apropos node, then the user is ready to wait until this Info node is created and displayed. > Noone's trying to unify the two: desktop.el uses internally > a representation of "the content and position of a given buffer" to be > able to reproduce it later, and as it turns out, this is the exact same > problem that bookmark tries to solve. So it might make sense for > desktop.el to use bookmarks for that internal thingy. > > I'm not 100% positive it does since the purpose is slightly different > (e.g. a bookmark is expected to be useful for a potentially long period > of time during which the file referenced might be modified many times, > so bookmark doesn't just record the buffer position but also some > context so as to find the same spot even if it's not at the same line > number any more. It's probably less important for desktop.el). There is another package that could benefit from the functionality of bookmark.el - saveplace.el that saves places in files. For instance, when I put point on the `* Elisp: (elisp)' line in `dir', kill the *info* buffer, and type `C-h i' again, then I'd like if point was on the same `* Elisp: (elisp)' line. -- Juri Linkov http://www.jurta.org/emacs/