RE: Friendlier dired experience [CODE INCLUDED]

[Drew Adams]

> > It does presume a 'segregationist' mind-set
> > that I clearly have and many on this list don't,
> > ie. it didn't occur to me that people find it
> > desirable to mix up bookmark types.

1. If there are no specific handlers, so the default
   handler is always used, then there are, generally
   speaking, no bookmark types.  The most-default
   default behavior is to treat all bookmarks the same.

2. Even when there are multiple bookmark types (and
   there are, even in `emacs -Q' - Info bookmarks,
   for instance), nothing _requires_ someone to "mix"
   bookmarks of different types in the same bookmark
   file.

   It's simple to have a bookmark file for Info
   bookmarks, another for EWW bookmarks, another for
   image bookmarks, another for man bookmarks, etc.

IOW, it's not either/or: one hard-coded camp of
"segregationists" vs another one of "integrationists".

Anyone can use bookmarks either way: mix or match.
___

And bookmarks can not only be "hard-code" separated
by type into different bookmark files.  If you use
Bookmark+ then you can mix them in a given bookmark
file but still separate them wrt access, display, etc.

A function can use bookmarks of any specific type, by
using the function that returns only bookmarks of that
type: `bmkp-<type-or-other-condition-name>-alist-only'. 

> > Now, if one can argue that it's *objectively* better to mix
> > bookmarks, then one can clearly reject the diredc system, but once
> > it becomes a subjective issue of expectation and personal
> > preference, the diredc system isn't so easy to reject.

>From my point of view, it's objectively better to be
able to mix _or_ keep separate.

And that, in different ways, only one of which
involves physical separation into different files.

Just one opinion.  The real point is that, even with
vanilla Emacs, nothing obliges anyone to mix bookmarks
of different types in the same file.

> That is why I am looking into those handlers Drew
> mentioned, but still did not find clear way to go.
> It is gluing two bookmark systems together. 

If you mean using bookmark handlers, in general,
then no, that has nothing particular to do with me
or Bookmark+.  That's basic to the vanilla-Emacs
design of bookmarks, and it has been so since Day
One.  There's a default behavior, AND you can add
bookmark types with their own behavior.

> Comments on Bookmark+: there are new things to learn, for example
> non-existent bookmarks for which I did not even now they are
> non-existent, "no such buffer now", bookmarkes to sequence or variable
> list, function, there are annotations which should be in every
> bookmark system. Browsers mostly have it, some of them still don't.
> 
> There are functions to export and import bookmarks,
> integrate. Thinking of knowledge management that is useful as one want
> whole set or groups or tagged bookmarks exported and to give such to
> other people. Bookmarks need not be only to location of files,
> directories, bookmarks are pointers and hyperlinks to information.
> 
> https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Hyperlink__;!!GqivP
> Va7Brio!Nb65Jllzho8BuyZWUu8ZyRmcMOVajbyIWqIMGvH8zDbSbrgROMDMgX2pwMSVvVSL$
> 
> In computing, a hyperlink, or simply a link, is a reference to data
> that the user can follow by clicking or tapping.[1] A hyperlink points
> to a whole document or to a specific element within a
> document. Hypertext is text with hyperlinks. The text that is linked
> from is called anchor text. A software system that is used for viewing
> and creating hypertext is a hypertext system, and to create a
> hyperlink is to hyperlink (or simply to link). A user following
> hyperlinks is said to navigate or browse the hypertext.
> 
> Emacs bookmarks, bookmarks+ or diredc bookmarks or any similar system
> fit into that definition of hypertext systems. Merging them together
> or having unified search and filtering interface is useful.

Yes, to all of that.  The main characteristics of
Emacs bookmarks are these, IMO:

 1. They're persistent.
    (They don't have to be, but they can be.)
 2. They can record nearly anything.
 3. The info they store can be used in any way.

In a nutshell, they're little, persistent bits of Lisp data.