From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Temporary notes in Emacs buffers? Date: Tue, 31 Dec 2019 22:25:37 -0800 (PST) Message-ID: <73dc0d0e-f208-4169-a70d-f2f17994a4f4@default> References: <87zhfecbpt.fsf@mbork.pl> <87sgl0osts.fsf@web.de> <65742f83-393a-4df2-9562-7c500b40adcd@default> <87a777ydnh.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="677"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Help Gnu Emacs mailing list To: Michael Heerdegen Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Jan 01 07:28:04 2020 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1imXUB-0018BN-BU for geh-help-gnu-emacs@m.gmane.org; Wed, 01 Jan 2020 07:28:03 +0100 Original-Received: from localhost ([::1]:48784 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imXU9-0001Zp-HB for geh-help-gnu-emacs@m.gmane.org; Wed, 01 Jan 2020 01:28:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52058) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imXTw-0001ZX-6f for help-gnu-emacs@gnu.org; Wed, 01 Jan 2020 01:27:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1imXTu-0004iB-Lh for help-gnu-emacs@gnu.org; Wed, 01 Jan 2020 01:27:47 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:50882) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1imXTu-0004er-CY for help-gnu-emacs@gnu.org; Wed, 01 Jan 2020 01:27:46 -0500 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 0016Rfiv083125; Wed, 1 Jan 2020 06:27:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=lKYuw2ZDh3CQHF38XbFN4df/zYuw2OOoH84Xy3/Cujw=; b=ckJvFf51AgYDxV59+aqPllbH3l9YCdkCY5NUg2otXulpiCpmHAOCFm2F6OheCAoh7ojB YJ35rXbmuNlDSls/gFtB7y+piEgOvHEZ2RlVX2icOSM/Pks6kZR+n5gXx8KpwOGhpQI4 2jESBGHQ2NmIHp9m5Xzke4Dpj+ik0BNASKVSxovEXQSOuEyas1vT2ZDzktyQzgCx6rJk VBjoIKc3A6qAIXx9atUsUNM/4Ra9e96bo0wpCKRfqSy5VuO25eZtLBUyJ+ovIkFze4yI 7jZkkmMsvLEzrIuNabPVV1EEHxdz7sgHnIylXu+WtRkoob+91qZiaztd+u717puWmtFp Gg== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2x5ypqkce6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 01 Jan 2020 06:27:41 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 0016NYW9061266; Wed, 1 Jan 2020 06:25:40 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 2x8gufvfc6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 01 Jan 2020 06:25:40 +0000 Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0016Pcir029791; Wed, 1 Jan 2020 06:25:38 GMT In-Reply-To: <87a777ydnh.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4939.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9487 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001010058 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9487 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001010058 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.85 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:122120 Archived-At: > > Bookmarks are pretty flexible. You can use > > them in lots of different ways. >=20 > Yeah - probably. What I dislike I think: if I move a file to a > different location, the relation to the notes is lost, and I have to > manually relocate the file. That might be annoying. That's why my > favorite approach would be to save the data in the file itself or at > least in its directory instead of a central place. Or is there a > solution for that problem using bookmarks, too? If you move the destination of a bookmark (the file or the positions in it) then, when you try to jump to it: * If the file is available, but the contexts for the recorded positions within it can't be found, then an attempt is made to relocate - searching for the recorded contexts (text before & after the positions. If that's not successful, because the file has changed too much, then you're prompted to relocate the positions. * If the general location (e.g. file) has moved, then you're prompted to relocate it. You can also manually relocate a bookmark's target any time, of course. But normally, if the file has not moved, when you jump to a bookmark the target positions are automatically updated (well, it's optional): The recorded positions are used as a starting point, and then the recorded contexts are found. If those have moved then the new location is recorded. --- There are advantages to saving annotations (e.g. bookmarks) in a separate file from their targets. And there are advantages of saving them in the same file. An annotation is a kind of metadata - a note about the file content or a location. There are pros and cons for storing metadata and data together. This isn't special to file annotations. --- You can have any number of bookmark files, and they can be stored anywhere. You can, as you mention, store a file of bookmarks in the same directory as the file or files that they target. So you can, if you like, easily move both at the same time, e.g. to another directory. However, yes, the target file names recorded in the bookmarks are absolute names. So you would want to define a command that not only moves the bookmark file and its targeted files, together, to the same new directory, but also updates the recorded file names in the bookmarks, to reflect the new target directory. That wouldn't be hard. You can also have bookmark lists composed of bookmark lists. And mappings between bookmark files and bookmark lists need not be 1:1. You can have a bookmark file for a book you're writing, and bookmark lists for each of its chapters. Or separate bookmark files for the chapters. And you can bookmark a bookmark list, e.g., switch to a different chapter just by jumping to a bookmark-list bookmark. The only requirement is that a bookmark file be separate from the files targeted by its bookmarks. Why? Because, like a directory, a bookmark file is a list of a bunch of files and their metadata.