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 23:00:53 -0800 (PST) Message-ID: <53f1bb2f-c049-4e81-97cb-b63a4438b85e@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> <87mub573g5.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="162098"; 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 Fri Jan 03 08:01:27 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 1inGxb-000g0n-2j for geh-help-gnu-emacs@m.gmane.org; Fri, 03 Jan 2020 08:01:27 +0100 Original-Received: from localhost ([::1]:49340 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1inGxZ-0007E6-V1 for geh-help-gnu-emacs@m.gmane.org; Fri, 03 Jan 2020 02:01:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52780) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1inGxE-0007Cf-J8 for help-gnu-emacs@gnu.org; Fri, 03 Jan 2020 02:01:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1inGxD-0005KR-22 for help-gnu-emacs@gnu.org; Fri, 03 Jan 2020 02:01:04 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:37394) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1inGxC-0005HM-Kt for help-gnu-emacs@gnu.org; Fri, 03 Jan 2020 02:01:02 -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 0036sLFw043958; Fri, 3 Jan 2020 07:00:57 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=Rm7+Sub4hN54B876vTe1c2p+AU87iQ9E6szQLX8TjIY=; b=PdED4KHnAbiNxVDxTdAAAxAzSoyU9bErz8lNrkeKCfMqMqj659Et7v8IoVAILTyuOWFe 7XHVZ4PvtzYQLfC1EsZGIWKB7lJ+5+aRbXehD9u+i+APDrEwTiSBfMt2hVWB0DBEKJZO MK4LLrd26WeXSkkKyckCkTHoUL9E0Rc7E+uhnDSThpv0cuLQPvKdslyEMUrKUBz2Ohgy REB7nOIS5xQDNLezO2rKWbgo/bgAnUH3LmsjP8rPYbh+AhT4PZoYd4d/1wzqWwWybKJq Vl4DgfGl3y12OJJ1kH/s0AktQ0nCYFEgD5zEOfWlXDm8i28hu8EhYH662qFc9DZvhv+D Pw== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2x5ypqtvnv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 Jan 2020 07:00:57 +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 0036sHwT013665; Fri, 3 Jan 2020 07:00:57 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 2xa06t93gg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 Jan 2020 07:00:56 +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 00370sLL023688; Fri, 3 Jan 2020 07:00:54 GMT In-Reply-To: <87mub573g5.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=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-2001030065 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-2001030065 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:122143 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. > > > > 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 [...] >=20 > Can't I just use a file or directory local variable > for that part? That would be a trivial solution > for the problem. You can. I think I mentioned that. You can put the new location of the file anywhere you like, for a bookmark to pick up and use. Is it trivial for you to update a variable value whenever you move the target file? If so, then Bob's your uncle - just use a bookmark handler that uses the variable value to provide the dir. The point is that the code that handles a bookmark has to get that info from somewhere. Currently it gets it from the bookmark (as an absolute file name), but it could get it anywhere. If you're sure to be in the same dir as the target file when you use a bookmark to it, then you can have the handler just use `default-directory' - no need for any variable or whatever. If not, but if some other rule applies for knowing the location of the file relative to the place where you invoke the bookmark, then you can code that in the handler. If not - e.g., if you put the new location in a var or whatever, then the handler can get it there. There's no miracle. The bookmark is separate from the target file. As a consequence, you need to provide some connection between the two, which will remain valid when you move the file - a rule, a lookup,... - something. > The problem is that the bookmark file can't know > where I may have moved a file to Bookmark, not bookmark file. It's not about the bookmark file. (I may have misspoken and given the wrong impression about that.) If the bookmark you invoke can assume that the target file will always be in some location relative to where it's invoked (e.g. same dir), or if the file location can be obtained somehow, then there's no problem - how to obtain it just needs to be coded in the bookmark's handler. If the handler can assume that the file's dir will always be in some variable, or obtainable by some function, then it can use that info. > -- but I'm very unlikely to move the bookmark > file very often. It's not about where the bookmark file is. It's about how the bookmark is accessed (from where), and how it gets the target location. > So I would prefer a solution where the file > knows where to ask for its bookmarks and > annotations, and the bookmark mechanism has > the data and the mean to deliver it. See above. It's up to you to define that mechanism - how "the file knows" and "asks". Various means are available for linking the bookmark and its target file logically. But they do need to be linked, in some way. How you do that depends on your use case. I can only say that, because the bookmark and its target file are separate, some linkage is needed. --- I suggest that the general discussion of your and Marcin's questions be continued in this thread, and that if there's a more detailed discussion to be had about how to do what you want using bookmarks we do that off-list, as it might be a distraction. Just a suggestion.