RE: [External] : Re: A feature to go to last edit locations

[Drew Adams]

Your msg is very long, and is getting (or is)
off-topic.  I replied to some of what you wrote
here.

> https://urldefense.com/v3/__https://www.dougengelbart.org/content/view/110
> /460/*2a1a__;Iw!!ACWV5N9M2RV99hQ!K4ZMzQdLs-
> jMoDjFBEzqIHwTyvrkh3Lnkzh51eINtJK2sVxrkpv-h1NODDZd0Yuem0trawHNFVtYnTOo$

Thanks for the link.

> My objects can be for example Org
> objects, it would be non-file database entry. I do not think that
> Bookmark+ has been designed to hold for example LaTeX.

Bookmark+ uses the vanilla Emacs design for
bookmarks.  It defines some new types of bookmarks,
and changes some of the plumbing.

Emacs bookmarks can "hold" anything you like.  For
bookmarks that you want to persist, the "anything"
needs to be persistable and readable.

But typically bookmarks don't "hold" much data.
Instead, they point to data that's available
somewhere else (whether it's persisted or not at
that "somewhere else").

There should be no inherent problem bookmarking a
"non-file database entry".  You just have to
decide what you need to put in the bookmark, to
later get to it (e.g. restore it).

Bookmark targets need not be things you can open
in Emacs - a bookmark, like any Emacs function,
can invoke actions/commands outside Emacs.

Even vanilla bookmarks can jump to nonfile things.
Bookmark+ adds some such, and enhances others.
Dired bookmarks are a good example of bookmarking
a nonfile "location"/thing.  Jumping to one restores
the Dired state of the time of bookmarking (markings,
hidden files, omitted files, ls switches, inserted
subdirs, etc.).

You can even bookmark things for which there's no
way to "jump" to - no way to invoke the bookmark.
Or for which you never want/need/bother to invoke
the bookmark.  

You can sort, edit, tag – whatever non-invokable
bookmarks, i.e., you can use bookmarks just to
organize things.  (And you have bookmarks that
are invokable only in certain contexts.)

> I have it same, I can combine, or find interesection of elementary
> objects, I can mark what I need or take all list of visible ones and
> make new object contaning all those.

Bookmark tags are a good way to categorize things
and access them by combinations of such categories.

https://www.emacswiki.org/emacs/BookmarkPlus#BookmarkTags

> What is to be done with the object is decided by it's type and
> subtype.
> I understand that ideas spring up in my mind which you read and then
> say "Hey, that already exists in Bookmark+", but I did not know.

There are no doubt other Emacs features (both
vanilla and from other libraries) that let you do
similar/overlapping things.  And of course any
time two things are different (which is what makes
them two things, not one), there are pros and cons
for each.

Org mode, for example, lets you embed different
kinds of things in an Org buffer/file.  You can
tag them, link them, annotate them, and act on
them in any number of ways.  A big difference here
is that the info/data of the things, and the tags
and links and annotations... are in the Org file,
along with the other things and any "main" text.

That has some advantages, no doubt.  But storing
annotations, links, tags, actions, other metadata,
... separately (e.g. in a bookmark file) also has
(different) advantages.

The implementation of bookmarks, as text files of
Lisp code, is fine for many use cases.  It fits
the use of any number of bookmark files, each of
which is not gigantic.

But yes, Someone (TM), sometime, will hopefully
do things such as:

1. Allow (also) for binary ("compiled") bookmark
   formats (and thus files).

2. Allow storing and accessing bookmarks using
   (multiple) databases.

3. ... (?)

Think of JSON, for example.  As a standard, it's
defined only textually.  But there are multiple
binary JSON formats as well, and without them
many uses of JSON wouldn't be feasible.  Same
with XML.

> Even then, objects are saved in the database, and related to planning,
> and represent themselves notes, tasks, not just bookmarks pointing to
> notes and tasks, they are related to people, can be shared and so I
> canot reuse your library, apart from reusing ideas, food for thought.

Not clear to me.  Why would notes, etc., whether
related to people or not, be something you can't
leverage bookmarks for?  I don't doubt you're
saying something true, but it's not clear to me
what it is.

(No need to follow up with an explanation.  This
is already likely off-topic etc.)

> > Bookmark+ adds over 70 types of bookmark. (You
> > can see what they all are by invoking function
> > ‘bmkp-types-alist’.)
> 
> But that does not seem to be the function, it is
> alist, but I do not see 70 types.

No, it's a function, not a variable.  The function
returns an alist of known types (their names) and
the associated history list (for completion).  It's
a function because which predefined types exist
depends on your environment, e.g., on whether you
have this or that other library, and on what Emacs
release you have.

It's not very important what predefined types exist.
The predefined types, and the functions etc. that
leverage them, are conveniences.  You can say they
belong to the top-level cruft of Bookmark+, not to
the basic design/features.

What's important is that it's easy for you to define
new types.  The predefined types are usable OOTB,
for things like jumping to a bookmark of a given
type, or choosing a navigation list of bookmarks of
a given type.

FWIW, (bmkp-types-alist) shows this, for me:

(("non-invokable" . bmkp-non-invokable-history)
 ("some-tags" . bmkp-some-tags-history)
 ("bookmark-list" . bmkp-bookmark-list-history)
 ("file-this-dir-all-tags"
  . bmkp-file-this-dir-all-tags-history)
 ("desktop" . bmkp-desktop-history)
 ("untagged" . bmkp-untagged-history)
 ("specific-files" . bmkp-specific-files-history)
 ("sequence" . bmkp-sequence-history)
 ("all-tags" . bmkp-all-tags-history)
 ("image" . bmkp-image-history)
 ("specific-buffers" . bmkp-specific-buffers-history)
 ("file" . bmkp-file-history)
 ("last-specific-buffer"
  . bmkp-last-specific-buffer-history)
 ("local-file" . bmkp-local-file-history)
 ("autonamed-this-buffer"
  . bmkp-autonamed-this-buffer-history)
 ("regexp-filtered-tags"
  . bmkp-regexp-filtered-tags-history)
 ("temporary" . bmkp-temporary-history)
 ("file-this-dir-all-tags-regexp"
  . bmkp-file-this-dir-all-tags-regexp-history)
 ("non-dir-file" . bmkp-non-dir-file-history)
 ("dired-wildcards" . bmkp-dired-wildcards-history)
 ("regexp-filtered-file-name"
  . bmkp-regexp-filtered-file-name-history)
 ("this-buffer" . bmkp-this-buffer-history)
 ("eww" . bmkp-eww-history)
 ("omitted" . bmkp-omitted-history)
 ("regexp-filtered-annotation"
  . bmkp-regexp-filtered-annotation-history)
 ("this-file" . bmkp-this-file-history)
 ("region" . bmkp-region-history)
 ("info" . bmkp-info-history)
 ("tagged" . bmkp-tagged-history)
 ("remote-non-dir-file"
  . bmkp-remote-non-dir-file-history)
 ("file-some-tags-regexp"
  . bmkp-file-some-tags-regexp-history)
 ("autofile-some-tags"
  . bmkp-autofile-some-tags-history)
 ("bookmark-file" . bmkp-bookmark-file-history)
 ("url-browse" . bmkp-url-browse-history)
 ("non-file" . bmkp-non-file-history)
 ("orphaned-remote-file"
  . bmkp-orphaned-remote-file-history)
 ("man" . bmkp-man-history)
 ("file-this-dir" . bmkp-file-this-dir-history)
 ("file-all-tags-regexp"
  . bmkp-file-all-tags-regexp-history)
 ("orphaned-local-file"
  . bmkp-orphaned-local-file-history)
 ("autofile-all-tags"
  . bmkp-autofile-all-tags-history)
 ("some-tags-regexp" . bmkp-some-tags-regexp-history)
 ("file-some-tags" . bmkp-file-some-tags-history)
 ("url" . bmkp-url-history)
 ("variable-list" . bmkp-variable-list-history)
 ("file-this-dir-some-tags-regexp"
  . bmkp-file-this-dir-some-tags-regexp-history)
 ("dired" . bmkp-dired-history)
 ("icicles-search-hits"
  . bmkp-icicles-search-hits-history)
 ("annotated" . bmkp-annotated-history)
 ("autofile-all-tags-regexp"
  . bmkp-autofile-all-tags-regexp-history)
 ("local-non-dir-file"
  . bmkp-local-non-dir-file-history)
 ("file-all-tags" . bmkp-file-all-tags-history)
 ("all-tags-regexp" . bmkp-all-tags-regexp-history)
 ("autonamed" . bmkp-autonamed-history)
 ("orphaned-file" . bmkp-orphaned-file-history)
 ("non-autonamed" . bmkp-non-autonamed-history)
 ("buffer" . bmkp-buffer-history)
 ("remote-file" . bmkp-remote-file-history)
 ("gnus" . bmkp-gnus-history)
 ("lighted" . bmkp-lighted-history)
 ("function" . bmkp-function-history)
 ("this-file/buffer" . bmkp-this-file/buffer-history)
 ("snippet" . bmkp-snippet-history)
 ("this-buffer-lighted"
  . bmkp-this-buffer-lighted-history)
 ("file-this-dir-some-tags"
  . bmkp-file-this-dir-some-tags-history)
 ("w3m" . bmkp-w3m-history)
 ("dired-this-dir" . bmkp-dired-this-dir-history)
 ("regexp-filtered-bookmark-name"
  . bmkp-regexp-filtered-bookmark-name-history)
 ("autofile-some-tags-regexp"
  . bmkp-autofile-some-tags-regexp-history)
 ("autofile" . bmkp-autofile-history)
 ("last-specific-file"
  . bmkp-last-specific-file-history))

> Can you save window configuration over session? I would like to do
> that. That is not same as desktop which is slow and cannot narrow to
> window configuration.

That's one of my wishes too.

Last time I checked, window configs are not Lisp
readable.  I tried to get Emacs (Juanma, who did
the desktop restore stuff) to raise window and
frame configs to the level of Lisp-readable
thingies (so persistable) - but to no avail.

See, e.g., bug #14964 (also #10348).

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14964#11

  I would also like to see functions that accept
  or produce window and frame configurations
  optionally accept and produce also Lisp-readable
  equivalents.

  IOW, today, such configurations always use actual
  window and frame objects, which are not Lisp-readable.
  I would like to see them optionally (e.g. via optional
  arguments) use Lisp-readable frame and window states.
  IOW, make it simple to persist such configurations.
  ...

  [Juanma's] work with desktop.el will apparently use
  Lisp-readable representations of sets of frames.
  I hope this will be applied/extended to the
  frame-configuration functions, so we can optionally
  get Lisp-readable frame configurations (with the same
  properties and interfaces as we have now).
  E.g., a frame config would continue to look like this,
  even when Lisp-readable:

  (frame-configuration FRAME+WINDOW-CONFIG...)

  where FRAME+WINDOW-CONFIG would be a Lisp-readable
  representation of a frame (a set of frame parameters,
  preferably at least the same ones recorded now) plus
  the frame's window configuration.

  And likewise for window configurations.  We have
  `window-state-(get|put)', but I would also like to
  see Lisp-readable window configurations.  IOW, wrap
  with (window-configuration...) what `window-state-get'
  with non-nil WRITABLE arg returns.

That suggestion was rejected.  I don't think, but
dunno for sure, that this is still the case: no
persistable, Lisp-readable frame and window configs.

HTH.