Re: One vs many directories

[Jean Louis <bugs@gnu.support>]

* Texas Cyberthal <texas.cyberthal@gmail.com> [2020-11-21 21:02]:
> Hi Jean,
> 
> > That is good and isn't it general way of sorting things? I guess
> > that general computer users may not be aware that they could make
> > nice hierarchical tree of directories.
> 
> It's not that they're unaware.  Everybody with a mouse and Windows
> Explorer tries to make good directories.

People try and people fail. I know hackers only on distance, I do not
know them personally face to face. Often computer users that I see in
offices like stationary, even sometimes legal office, have their
desktops overloaded of files on top of files on top of files where
majority of them are named something like unknown or whatever new-file
and similar nonsense. All sorting is taking place under Desktop on
Desktop space and it becomes mess.

> It's just that Dired+Treefactor's order of magnitude improvement in
> speed and fluency means that the directory tree can be mind-synced

Good term, mind synced. That is how it should be. In my opinion
various paradigms of file sorting should be sorted in a list similar
to those Awesome lists. Sorting files how mind thinks is how it should
be. Computer should help user to complement the mind and help in
execution of actions and not bother the mind or make mind confused
what is really the case with majority of users.

Side note: I was always sorting files, people, stuff from the command
line or from web browser into their places. And I mostly used readline
in bash for completion or finding of the selection candidate.

In Emacs I am using `ivy-mode` or `helm`, `selectrum` and similar,
Emacs offers quite good interface for completions.

And often I am completing file locations, maybe I wish to file into
this or the other subject. So the list of subjects has to be brought
up.

In X and outside of Emacs there is dmenu and I could use it even from
Emacs inside out. 

(defun dmenu-completing-read (prompt collection)
  ;; &optional predicate require-match initial-input history def inherit-input-method)
  "Uses external `dmenu' command for Emacs completions."
  (let* ((collection (concat (string-join collection "\n") "\n"))
	 (file (string-to-file-force collection "/dev/shm/collection"))
	 (dmenu "dmenu"))
    (with-temp-buffer
      (call-process dmenu file (current-buffer) nil "-fn" "DejaVu:pixelsize=30" "-l" "10" "-i" "-b" "-p" prompt "-nb" "dark goldenrod" "-nb" "black")
      (string-trim (buffer-string)))))

(dmenu-completing-read "Subject: " '("People" "Work" "Group"))

I find dmenu as excellent tool to provide it for functions that are used within Emacs and that may be used outside of Emacs to complement Emacs filing of files.

For example Rox filer file manager or Nautilus can invoke external command that files the file into specific directory by using dmenu. Choose the directory by few words, and if directory is semnatically written, file may be filed easily.

Three interfaces for selection among large line-based items were needed:

- [X] Emacs
- [X] X interface: Dmenu
- [ ] Console. I was using readline with TAB, it is not visual enough

Now I found finally `fzf`.

$ mv courier-crm114 `find Work/Computer -type d | fzf`

Then in the next step I can type "mail" or "spam" subdirectories and file it there.

fzf is great tool for console and terminal emulators. It similar
things on console what helm does on Emacs and dmenu on X.

- [X] Console: fzf

fzf is great tool that may be used for finding stuff, filing, retrieval of stuff, launching or opening files. Example:

$ mimeopen `locate *.org | fzf`

and similar with dmenu:

$ mimeopen `locate -d .locate.database  -A Documents .org | dmenu -fn DejaVu:pixelsize=20 -l 10 -i -b -p "Org: " -nb "dark goldenrod" -nb black `

As my files are in ~/Documents/Org/ I would find at least 185
files ending with .org there by its name and quickly open it with
emacs. Instead of "mimeopen" I could as well use emacsclient.

If you have set your mimeopen to open it by Emacs, you will
quickly locate the file and open it. Provided that Org file names
have some built-in semantics.