[Edbrowse-dev] various new commands

[Edbrowse-dev] various new commands

[Karl Dahlke]

As per discussions with users, and some of my own thoughts,
I'm asking if it's worth adding a few commands,
with the tradeoff that it's always nice to have more commands,
and it's damn confusing to have so many cryptic commands.

g$
go to the last link on the line.
A line can have many links and you don't have to count.
Example to send a tweet would be 3g$ instead of 3g5.
maybe i$* instead of i5*,
if you see that the last input on the line is the button you want to push.
I've seen surveys with ten checkboxes on a line,
more or less, for how satisfied you are, and you just want to check the last one.

>From within the file manager, also known as directory mode:

lsl  file length
lst  file mod time in short numeric form, for braille displays etc.
lsp  file owner group permission, in octal of course,
  again saving time to read or space on a braille display.
lsi inode, link count, and major minor numbers if any

These would be nice but can to some degree be handled
as functions in config file.

function lsl {
!wc -c "'_/'."
}

Or /bin/ls -ld run through sed etc,
but these are a bit awkward, reformatting mod time and permissions the way we want,
and of course you have to type <lsp instead of lsp,
and you have the ok prompt afterwards which you don't need.
So not quite so convenient.

this brings me to another question.
Should I continue to use <func to run an edbrowse function,
or should I, like the shell,
compare the first word (alpha string followed by whitespace)
of your entered line agains the functions you have
and if there is a match then run that function.
No need for the < symbol.
Course you dare not have a function named e,
or you couldn't type "e foo" any more.
If I removed the necessity for < I'd probably have to keep it around
optionally for backward compatibility.

Just wondering what folks think on these matters.

Karl Dahlke

Re: [Edbrowse-dev] various new commands

[Chris Brannon]

Karl Dahlke <eklhad@comcast.net> writes:

> g$
> go to the last link on the line.

Yep, it seems to follow the principle of least astonishment.  I like it.
I frequently encounter pages with 12 links on a line, so this would be useful!
i$* belongs, if for no other reason than regularity of
the command set.

> > lsl  file length

How would these work?  Would they just operate on the current file?
Another alternative would be to have a single lsf command that operates
kind of like a toggle.  Initially, you just see filenames in the buffer,
like the situation today.  But when lsf is invoked, the buffer is rebuilt
to display stat info alongside each filename.
Executing lsf again would hide the extra info.
This one isn't all that important to me either way.

> Should I continue to use <func to run an edbrowse function,

You should keep it.  Yes, it's ugly, but it means that we never ever ever
have to worry about colliding with user functions when extending the
edbrowse command set.  Sometimes there's a lot to be said for
conventions, even ugly ones.

-- Chris

Re: [Edbrowse-dev] various new commands

[Adam Thompson]

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

On Sun, Sep 20, 2015 at 01:44:56AM -0700, Chris Brannon wrote:
> Karl Dahlke <eklhad@comcast.net> writes:
> 
> > g$
> > go to the last link on the line.
> 
> Yep, it seems to follow the principle of least astonishment.  I like it.
> I frequently encounter pages with 12 links on a line, so this would be useful!
> i$* belongs, if for no other reason than regularity of
> the command set.

Agreed.

> > > lsl  file length
> 
> How would these work?  Would they just operate on the current file?
> Another alternative would be to have a single lsf command that operates
> kind of like a toggle.  Initially, you just see filenames in the buffer,
> like the situation today.  But when lsf is invoked, the buffer is rebuilt
> to display stat info alongside each filename.
> Executing lsf again would hide the extra info.
> This one isn't all that important to me either way.

The lsf idea sounds sensible to me.

> > Should I continue to use <func to run an edbrowse function,
> 
> You should keep it.  Yes, it's ugly, but it means that we never ever ever
> have to worry about colliding with user functions when extending the
> edbrowse command set.  Sometimes there's a lot to be said for
> conventions, even ugly ones.

Agreed. Tbh I've never had an issue with that.
What I would like though is some sort of variable support in edbrowse functions.
It'd also be nice if the ok prompt could alter if a command being ran returns
non-zero, and perhaps allow this to be checked in edbrowse functions.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]