From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: [PATCH] Add user option to disable location in bookmarks Date: Sun, 21 Jun 2020 18:44:29 +0000 (UTC) Message-ID: <2ee3b657-fefb-4ced-8f98-967e6c353e1e@default> References: <87sgep35cb.fsf@gmail.com> <87blld2x5h.fsf@gmail.com> <062414c6-41f4-4803-9a62-28274825b8e0@default> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="1982"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jamie Beardslee , Emacs developers To: Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 21 20:47:38 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jn50D-0000NP-L5 for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Jun 2020 20:47:37 +0200 Original-Received: from localhost ([::1]:58804 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jn50C-0003C1-M4 for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Jun 2020 14:47:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jn4zF-0002l6-C2 for emacs-devel@gnu.org; Sun, 21 Jun 2020 14:46:37 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:48470) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jn4zC-0002Vl-Tl for emacs-devel@gnu.org; Sun, 21 Jun 2020 14:46:36 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05LIi3Tj166905; Sun, 21 Jun 2020 18:46:31 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-2020-01-29; bh=Iah8mk17wksyk0uSzzT67oCwHxzfmqWTUMeznqR7M5M=; b=nYARK2345CXslXiymtdWuW0iX67OqrSZXUhhuepmxcQCq/UJGyAiNIXX5sVf8HWCr4af faNROFgz5YIBaAzSsNuY+BqyQUJk4hbjscganv06GeJD+IrRwdItFE347HNFwIj8F/I/ Iwcb9LPWa27PJw52ta6xrJgbcMActW/zYCAADa0t3/1P62kJU56qWl2QkZ34LSEvE/om MpH5unuSvPQ/Ipr8HAGhCQzNMmxAUbkwb54xga3u1ZXcJ8oDfT8X/4naAbC33uZpXEZ/ 7Y0eE/+/vsMFavv5HmT3kLA/2Bg/TWHfCP875k1boBTnkaLsxZt+msLehaUmuXMORFG2 Zw== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 31sebbbc1f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 21 Jun 2020 18:46:31 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05LIi1HZ074980; Sun, 21 Jun 2020 18:44:31 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 31sv7nx8xs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 21 Jun 2020 18:44:31 +0000 Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 05LIiThX026200; Sun, 21 Jun 2020 18:44:30 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5017.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9659 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 suspectscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006210147 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9659 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 phishscore=0 adultscore=0 impostorscore=0 cotscore=-2147483648 mlxscore=0 suspectscore=0 mlxlogscore=999 bulkscore=0 lowpriorityscore=0 clxscore=1015 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006210146 Received-SPF: pass client-ip=156.151.31.85; envelope-from=drew.adams@oracle.com; helo=userp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/21 14:46:33 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -63 X-Spam_score: -6.4 X-Spam_bar: ------ X-Spam_report: (-6.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:252497 Archived-At: > > If this is about save-place then save-place should > > do the right thing. See above. If there's an option > > to be added in that regard, it's a save-place option: > > `save-place-ignore-bookmark-position'. The hook > > function (see above) can move to the save-place place > > if the option is non-nil, and just do nothing if it's > > nil. >=20 > I think you are too quick in punting the change to =E2=80=98save-place=E2= =80=99. > > I think it=E2=80=99s a matter of user expectations. Of course it is. User expectations, common use cases, and individual preferences. The _general_ expectation is realized in the default make-record function. And in the default jump-to behavior. That's why they are defaults. But they're only defaults. > You expect that a bookmark targets a particular location in the file. No. I don't expect anything particular from a given bookmark, other than what it advertises. Emacs users, in general, expect, by default, what the default behavior provides. That's why it's the default. > (There are bookmarks that do not target a file; > let=E2=80=99s ignore them for now.) First, not targeting a file is not the same thing as not targeting a particular location in a file. But if you really mean not targeting a position in a file, why ignore the case of bookmarks that don't target such locations, if that's just what this user's looking for? If you as a particular user, or a particular mode or library author, want all bookmarks used in some context - or even all bookmarks - to not go to a specific file position then why create bookmarks that do that? Why use the _default_ make-record function to create bookmarks for that use case? That's the first point. There's no requirement to use the default make-record function, if you want a custom behavior. > Activating the bookmark visits that file (if not already > visited), displays that file=E2=80=99s buffer, and jumps to the bookmarke= d > location (adjusting it by searching for context if necessary). By default, yes. That's the default behavior for jumping to a bookmark, including a file-visiting bookmark.=20 > Jamie expects that a bookmark targets the file in its entirety. > Activating the bookmark then should visit the file (if not already > visited) and display the file=E2=80=99s buffer. I understand that. (Visiting a file does put the cursor at _some_ position - bob by default.) > If the file had to be > re-visited, save-place kicks in and restores the point and scroll > position to the values saved when the file=E2=80=99s buffer was killed. I= f > save-place is not active, the point and scroll position should remain > whatever they end up by default (top of buffer?). Yes, bob, by default, when first visiting a file. > I dare say both expectations are valid for files. All kinds of expectations are valid. Whatever a user wants and is realizable is valid. No one's suggested that Jamie's preferred behavior is invalid. > Therefore, the fix should allow the user to avoid > saving a location in bookmarks targeting files, That doesn't follow. A user should be able to jump to a file bookmark and end up at the last save-place location in that file. That says nothing about what gets saved in a bookmark record. Is the need to avoid saving a location in bookmarks? Or is the need to always visit a file bookmark at bob (position 1)? Or is the need to always (or only sometimes perhaps) let a hook function adjust the position upon visiting? I think the need described is just to have jumping to a file bookmark go to save-place's recorded location within the file. > perhaps by introducing a setting like > =E2=80=98bookmark-set-save-location=E2=80=99, boolean, default t. saveplace.el affects only file (and Dired) visits, right? So only file (and possibly Dired) bookmarks present the user with this need. > Other bookmark types would then decide if it makes > sense to honor that setting, and how. You mean they would _have_ to do that - decide. Or else they would just get their `location' settings ignored whenever someone wanted save-place to ignore `location' for file bookmarks. So _every_ kind of bookmark would now need to add logic to deal with this blanket, all-bookmarks option. Unless, that is, for some reason some particular kind of bookmark really wanted to make its `location' be ignored whenever the option is enabled. In which case, it probably would have just not included a `location' setting, or it too would have already felt the need for such an option. > E.g. an Info buffer technically contains a whole Info manual but, > through narrowing, makes an appearance of displaying only a single > Info page; it would make sense to bookmark the page but not the exact > line and context. Would it? If necessarily so, then Info bookmarks wouldn't have a `location' setting, would they? Now, you can say that we could add such a blanket user option, which makes all bookmarks, of all kinds, have their `location' setting ignored. And we could compensate for that blanket treatment by providing a separate option that lists bookmark types (or buffers or files or whatever) to exclude from the option behavior. Or we could incorporate that into the same option, by making it (1) a list of type, buffer, files, or whatever to exclude; (2) t or `all', meaning include all; or (3) nil, meaning always respect `location'. _____ Or we can just satisfy the need, which is for save-place, by having save-place do what it does for visiting files generally: invoke its hook, already defined, for visiting a file, `save-place-find-file-hook'. That hook function (which shouldn't be named `*-hook', BTW) does just what's wanted. (And perhaps Jamie will want to do similarly for Dired bookmarks, using `save-place-dired-hook'.) And the place to use such a save-place hook function for bookmark jumping, is `bookmark-after-jump-hook', just as the place to use the same function for `find-file' visiting is `find-file-hook'. Completely comparable, IMO.