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: Thu, 2 Jan 2020 07:41:25 -0800 (PST) Message-ID: <55128372-5012-407d-9b70-cbbd5e9225e0@default> References: <87zhfecbpt.fsf@mbork.pl> <87sgl0osts.fsf@web.de> <65742f83-393a-4df2-9562-7c500b40adcd@default> <87a777ydnh.fsf@web.de> <73dc0d0e-f208-4169-a70d-f2f17994a4f4@default> <87o8vmlkdq.fsf@web.de> <958f5d11-5d36-4627-a106-11b47b3e9c79@default> <87png2ed33.fsf@web.de> <1d24a14a-b38a-4a66-b6d0-cca8aff7dacc@default> 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="62421"; 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 Thu Jan 02 16:43:44 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 1in2dT-000G6l-UL for geh-help-gnu-emacs@m.gmane.org; Thu, 02 Jan 2020 16:43:44 +0100 Original-Received: from localhost ([::1]:42244 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1in2dS-00013L-NN for geh-help-gnu-emacs@m.gmane.org; Thu, 02 Jan 2020 10:43:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52040) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1in2dI-000121-In for help-gnu-emacs@gnu.org; Thu, 02 Jan 2020 10:43:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1in2dH-0006x7-3t for help-gnu-emacs@gnu.org; Thu, 02 Jan 2020 10:43:32 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:35746) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1in2dG-0006ws-R5 for help-gnu-emacs@gnu.org; Thu, 02 Jan 2020 10:43:31 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 002FdM3E179092; Thu, 2 Jan 2020 15:43:29 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=jxRl1GhpEFHrzJD5sDsQcXeThgQ/kb3rQhk+s7utv+Q=; b=CXATFi76Aa/7zGOHVUwVanJNnFjhTJNT9xHwc1xeKCnlTON/YCUGYSRmFc3ff0dLarw5 NdH4zLrQUI8HiyuZMlOQhynAhHTCt4lj7veUVc6TfX9UeOVKrvwvz1wLH97XU6rA2TTh K+hqkYte9/StZKYxkFeUwa0/WAmIh4qmHfXDqcaQ4A1hTpPgvad+AcvfFvdx6mTZeOYO TTus0igVbEtYqEAbCvk2KCTqKNJuu8XCia2trZ8XYcSeMiojrAzkGkLW4JI50MgAGauz BnEGiblJzyKHjcA2w9GFwbE5G/nZk2vnafDidqZ1nhIqqHuyMHAUvtXsOVf5A/iridcA WQ== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 2x5y0pqxjb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 02 Jan 2020 15:43:28 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 002FcdZ8155904; Thu, 2 Jan 2020 15:41:28 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 2x8bst5rwm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 02 Jan 2020 15:41:28 +0000 Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 002FfQp2029271; Thu, 2 Jan 2020 15:41:26 GMT In-Reply-To: <1d24a14a-b38a-4a66-b6d0-cca8aff7dacc@default> 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=9488 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-2001020138 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9488 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-2001020138 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.78 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:122131 Archived-At: > You can define a bookmark handler for any type of > bookmark. The handler could ignore the directory > part of the recorded file name, and get the needed > directory from somewhere else, e.g., from a global > variable or a function. (It has to come from > somewhere.) E.g., a variable could have an alist > value with keys for your different whatevers (even > nondir-filename keys) and with dirs as the values. >=20 > But then you'd have to update the variable value > when you move the targeted files. As I said before, > you can write code that does something like that > (my earlier suggestion was code that changes the > target-file names in the bookmarks, but that's not > great) - e.g. code that's kicked off by a bespoke > file-move command. (But then you have to remember > to use that command to move such files...) >=20 > However you look at it, the target file is separate > from bookmarks that refer to it - that's the nature > of the thing. Something has to let either the > bookmarks themselves or the bookmark-handling code > know where you moved the target file. Let me add this: If your use case is limited to being in the same directory as the file targeted by your bookmark(s), then you can just use `default-directory' in your handler, as the directory in which to look up the file name (ignoring any recorded directory). This could be the case, e.g., if you always accessed your bookmarks from the file itself (e.g., at their highlighted locations there). That's the case we've been discussing, at least in part. It's also possible to use `default-directory' if you want to use a relative file name that includes more than just the non-directory part. E.g., if your file is in a subdir of `default-directory` (current pwd), then you could look it up using the relevant part of the recorded absolute file name. (Or your new bookmark type could record only such a relevant part as the target location.) This could be the case if you access the bookmarks from a parent or other directory (relative file names can include `../' etc.), but you'll know where you'll access them from, so the handler can assume that directory - no need to look it up somewhere. There are various possibilities, depending on just what you might want to do.