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: Wed, 1 Jan 2020 21:30:25 -0800 (PST) Message-ID: <1d24a14a-b38a-4a66-b6d0-cca8aff7dacc@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> 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="267749"; 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 06:30:56 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 1imt4Q-0017VX-MN for geh-help-gnu-emacs@m.gmane.org; Thu, 02 Jan 2020 06:30:54 +0100 Original-Received: from localhost ([::1]:36904 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imt4O-00048J-SL for geh-help-gnu-emacs@m.gmane.org; Thu, 02 Jan 2020 00:30:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45808) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imt4C-000487-Pq for help-gnu-emacs@gnu.org; Thu, 02 Jan 2020 00:30:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1imt4B-00037i-82 for help-gnu-emacs@gnu.org; Thu, 02 Jan 2020 00:30:40 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:60440) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1imt4A-00036K-8j for help-gnu-emacs@gnu.org; Thu, 02 Jan 2020 00:30:38 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 0025O8au134681; Thu, 2 Jan 2020 05:30:36 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=SwfB2UjlMgf6Vm8rv4fhq61AY8Sj6WsI+opshPRiZFY=; b=QTdlKjLyMHZDqwQ59u2ROwkFxHBHdWJ7HcGH/e4v4mpZxO3FKxKaC4H9s2utoJLkfJP7 wO4WtvaAlmkFDJZaUmNkrydHdgoIlGlXFm72hH4OmLVQ2lxPtRw7wYg6kMDEIq7THbM9 hJPfO2Q+vQmTt5dVgjhLSiT9BCQ8DHXEf3Zu4iTVkYrPtCsXUpZj8jR/TG3c0oA9Kep9 E/w2kLbjqzHDuRbcO70/0MkDu+Q6cNapLwJp5QWNDQHmlpqOi04Y3krKlF5P7CBMNbOs Ry9IDAhiZTTxqGCBK8r2YiXaK9wZ2uo7qemG6gzu41Y/6gYUKJ7pQFpiBIGa5e9pM/V+ 4g== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 2x5xftnnuh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 02 Jan 2020 05:30:36 +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 0025Te4g067934; Thu, 2 Jan 2020 05:30:35 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 2x8gunv3tr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 02 Jan 2020 05:30:35 +0000 Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0025UQRN031656; Thu, 2 Jan 2020 05:30:31 GMT In-Reply-To: <87png2ed33.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-2001020049 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-2001020049 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.86 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:122130 Archived-At: > > Do you really often move files for which you have associated notes? >=20 > I don't know yet. But the bookmarks should at least survive making > backups, and remain visible when viewing them at that other place, or > after moving the containing folder for archiving or so. I would say: > often enough that it matters, yes. I guess you mean just what you said before: You want to be able to move a file, and some bookmarks that target it, to a different directory, and have the bookmarks continue to work there. > > Or yes, not use bookmarks for your annotations. >=20 > Well, they mostly fit, if they would not force me to use absolute file > names. You are sure that there is no predefined way to use relative > names? 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. 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...) 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. (You can also define new types of bookmarks. E.g., you could define one that records a target location that's just the nondirectory part of a file name. But this isn't really necessary - the dir part of an absolute file name could just be ignored - see above.) Other than that (you define a handler), this kind of handling (look up the dir somewhere) could be added as a general (optional) feature. The use case hadn't occurred to me. Maybe give it a try (define a handler that looks up the dir somewhere), and let me know how useful you find it. (Add your new handler to the value of variable `bmkp-file-bookmark-handlers', so the bookmarks will satisfy `bmkp-file-bookmark-p'.)=20 Or if you don't get around to that then maybe I'll do something. But it's less likely that whatever I might come up with will fit what you need as well as what you might come up with. And maybe by experimenting a bit you'll find that bookmarks are really not the way you want to go... --- [Bookmark+ has "autofile" bookmarks, whose bookmark names are the nondirectory parts of the full file names. You can have multiple bookmarks with the same name, which is a relative file name in this case. But the target file recorded in the bookmark is an absolute name (so far).]