edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev] Directory Sort
Date: Sat, 13 Jan 2018 12:31:20 -0500	[thread overview]
Message-ID: <20180013123120.eklhad@comcast.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]

I implemented this because I wanted it, but I didn't document it, because I'm not sure if you like this interface, or if we might change it.
Pull the latest and play around.
This is a way to sort your entries in directory mode in ways other than alphabetical.
It's only meaningful when reading in a directory.
I hardly ever need it, but when I need it, I need it!

Remember the various ls commands?
lsl shows you the length of the file on the current line.
lst time lss size lsy symbolic link lsp permissions lsi inode lsk link count lsm major minor numbers.
To put this on all the files in the scan, enter ls=lt, or some such, then read in the directory.
The equals sign puts it on all files in the directory listing.
All this was there before.
I'm trying to keep a similar syntax with the new stuff.

dsrt=a  sort alphabetical.
dsrt=t sort by time.
dsrt=s sort by size.

With help messages on you'll see the sort mode as you set it.

You can also use + as in dsrt+a.
This is intuitive, with dsrt-a for reverse sort alphabetical.
dsrt-t reverse sort time, dsrt-s reverse sort size.

They can be effective together.
If you care about the times of your files, and you want them sorted that way,

dsrt-t
ls=t
e some_directory

If you are already in a directory and want to change the sort or display,
make the changes and then refresh with rf.

so: did I break anything? Does the new sort work as expected?
Would you change anything as to how it works, or the user interface?
I use qsort so it should be fast even for huge directories,
though it does have to stat each inode.
Finally, when sorting by time or size, should I move all the directories and special files to the end?
They don't really have any meaning in terms of mod time or file size.
I don't do that now but thinking maybe I should, what do you think?

Karl Dahlke

             reply	other threads:[~2018-01-13 17:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-13 17:31 Karl Dahlke [this message]
2018-01-13 17:42 ` Dominique Martinet
2018-01-13 17:56   ` Karl Dahlke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180013123120.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).