From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: bookmark.el bug report Date: Wed, 30 Dec 2009 07:57:53 -0800 Message-ID: References: <5065e2900912272219y3734fc9fsdaee41167ef99ad7@mail.gmail.com><87aax361bd.fsf@red-bean.com> <87my13lf3v.fsf@tux.homenetwork><72EB214F963A4550B9F1B0EBBCFB48F4@us.oracle.com><87eimehkg1.fsf@red-bean.com> <87y6kkd1lu.fsf@tux.homenetwork> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1262188812 32332 80.91.229.12 (30 Dec 2009 16:00:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Dec 2009 16:00:12 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 30 17:00:05 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NQ0xo-0000gx-ID for ged-emacs-devel@m.gmane.org; Wed, 30 Dec 2009 16:59:56 +0100 Original-Received: from localhost ([127.0.0.1]:52042 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQ0xp-0002tM-5A for ged-emacs-devel@m.gmane.org; Wed, 30 Dec 2009 10:59:57 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQ0wC-0002Lw-O5 for emacs-devel@gnu.org; Wed, 30 Dec 2009 10:58:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQ0w7-0002KO-Uh for emacs-devel@gnu.org; Wed, 30 Dec 2009 10:58:16 -0500 Original-Received: from [199.232.76.173] (port=40813 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQ0w7-0002KL-SA for emacs-devel@gnu.org; Wed, 30 Dec 2009 10:58:11 -0500 Original-Received: from rcsinet11.oracle.com ([148.87.113.123]:61659) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NQ0w7-0007iQ-CW for emacs-devel@gnu.org; Wed, 30 Dec 2009 10:58:11 -0500 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id nBUFw1vr017630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Dec 2009 15:58:03 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id nBUFMuKm002829 for ; Wed, 30 Dec 2009 15:58:01 GMT Original-Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 1257899361262188665; Wed, 30 Dec 2009 07:57:45 -0800 Original-Received: from dradamslap1 (/141.144.160.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 Dec 2009 07:57:45 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcqJZNqOQg9LHMk7TeqCAtyu97Z93wAARQBQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt358.oracle.com [141.146.40.158] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4B3B7889.014D:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:119051 > > >>> (forward-char 3) > > > > > > Hardcoding 3 is ugly (I know it's done elsewhere, but it's > > > still ugly, elsewhere a well). > > > > That can be used instead:(skip-chars-forward " \\|\*\\|>\\|D") We are essentially moving to a different "field" here (even if not an Emacs field per se). The field at bol is a marks field; the field starting at char 3 is the bookmark-name field. IMO, it is worse to base the movement on syntax, skipping over the marks (and lack of marks) that are currently used in the design. That complicates changing the set of marks in the future, and it precludes bookmarks with names that start with any such marks (including SPC). Even if we never want either of those possibilities, such a search is more fragile, and it couples the two fields closely wrt code. The marks field should not be defined by its syntax (vs a bookmark-name syntax) but by its columns. It is a field of a fixed number of mark columns, regardless of which marks are used. It is better to skip over the width of the field. Either (1) comment the hard-coded field width (everywhere it is hard-coded, as Stefan suggested) or, better, (2) add a variable for that width. > >> Better would be to place the text property at BOL so > >> there's no need for any forward-char business. > > > > Yes, but remember you have to set properties on the bookmark name > > without "*"(annotation), ">"(mark), "D"(mark for deletion). > > That occur on third char and not before. > > Ah, that makes sense. > So maybe hardcoding 2 is not such a bad idea, but the important thing > is then that the same "hardcoding" be used both where the > property is used and where it's set. Yes. And to enforce that, either add comments to that effect or, preferably, use a variable.