RE: [External] : [emacs bookmark.el] Sorting by last set

[Drew Adams <drew.adams@oracle.com>]

> > But there are other ways to "modify" bookmarks: for example, 
> > you could edit a bookmark's annotation without updating its 
> > target.  One could make a reasonably good argument as to why an 
> > annotation change should count as a "modification" for the 
> > purposes of sorting... and, one could make a reasonably good 
> > argument why it shouldn't.
> >
> > My purpose here is just to ask: is the name "last-modified" 
> > really the most appropriate one for the behavior currently 
> > implemented?

I can't speak to whatever behavior you've
currently implemented.

But why would _setting_ a bookmark be the only
modification that you want reflected in such a
property?

And does this "setting" include RE-setting or
just initial setting (which I guess is about
the same as creating)?

If resetting's included then which kinds of
resetting?  Does relocating count?  Just
repositioning (manually or automatically)?
Renaming?  Changing properties manually (e.g.
editing), or by code?

Just what is "setting" for your "behavior
currently implemented?  And why is that the
most useful/appropriate behavior for such a
time/date bookmark field?

You're not implementing something offhand.
You're changing the basic bookmark data
structure.  It's worth thinking about.

Other ways to modify (beyond "setting") are
not at all limited to adding, removing, or
modifying an annotation.  That seems like a
straw man, to make it seem like all that's
important wrt modifying is setting.

But even just an annotation edit is a change,
and it might well be significant for a user.
Let's not belittle modification other than
setting.

If you're going to introduce a last-modified
time property of some sort, I'd suggest that,
by default at least, it be updated for any
change to the bookmark - maybe even automatic
repositioning.

But including automatic repositioning could
be a user decision (e.g., a user option, off
by default.  Better is to have a (list value)
option that can cover all predefined kinds of
modification.

> > The simple solution would be to just change the symbol to
> > `last-set-date'.  I think that would be my choice.  It would
> > reduce the potential for confusion and misunderstanding.
> 
> Yes, I forgot about annotations so I think `last-set-date' would be
> better. I could prepare this simple patch.

See above.  What does "set" mean, and why is it
(whatever it means) important to the exclusion
of all other kinds of modification?

> > * Now that we're using a symbol for *one* possible value of
> >   `bookmark-sort-flag', should we use symbols for *all* possible
> >   values?  (And leave the treatments of `t' and nil as legacy
> >   compatibility behaviors, documented as such but deprecated in
> >   favor of using the corresponding new symbols instead when   writing
> >  new configurations.)
> 
> Why not... but we have to settle for good symbol names. I propose
> 'last-created (as nil) and 'alphabetical (as t).

Would you please use `created', the same field
name that Bookmark+ uses?  Occam's razor says
not to complicate things gratuitously.  Why
not use the same name, for the same thing?

There's only one creation of a given bookmark.
It makes no sense to talk of a "last" creation
time.

And time is about all that a `created' field
could usefully record - it's understood.

> I prefer `bookmark-sort'.

Please see what I wrote in my previous message,
if for no reason other than it provides useful
food for thought.

You (plural) are just starting to see the value
(usefulness) of different ways to sort bookmarks.

There are as many ways of usefully sorting as
there are kinds of bookmarks.  No, - as there
are _combinations_ of kinds.

No - there are many more useful ways to sort
than even that.  You've already noticed at least
two kinds of time (created, modified) and one
kind of syntax (alphabetical).

You cannot know what ways to sort will be useful
for this or that user in this or that context.
Users should be given an easy way to define
their own sort orders (sorting commands). 

As experience grows you'll see that a general
and flexible approach to sorting is called for.
Again, I invite you to look at what Bookmark+
offers here - and again, at least as food for
thought.