RE: bookmark.el bug report

[Drew Adams]

> > >>> (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.