[Edbrowse-dev] wiki

[Edbrowse-dev] wiki

[Karl Dahlke]

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

Ok ... I have an account, I read the article on Hypatia, pretended to edit it,
compared the article with the raw input, reverse engineered their markup
language, and wrote an edbrowse article in their style, as shown below.
The 30 second explanation:
double brackets is a hyperlink within wiki,
single brackets is a hyperlink,
'' and ''' are italics or bold or some such,
<ref> builds a source style reference, hopefully demonstrating authority,
and finally each newline is a new paragraph, which I haven't implemented yet
because long lines are nearly impossible to manage in edbrowse,
so my last step would be to ,J each paragraph together.
And then of course my wife would have to get me past the captcha.
So, should I submit such a thing, and, do you have comments thereon?
Chris, one of my external links points to the philosophy article
on my website but should it be on yours alongside edbrowse for consistency?
I will tell you that they will be leary of approving an article
whose sources are other websites, not books or papers etc,
so they might just say no,
but you have to start somewhere and that's all we have.

'''Edbrowse'''
is a combination [[Text editor|editor]],
[[Web browser|browser]],
and [[mail client]] that runs in command line mode.
It does not display files or web pages in two dimensions across the screen;
instead it accepts commands and prints responses,
much like the [[Unix shell|shell]].
Edbrowse was modeled after ed, one of the earliest Unix editors,
though there are many more features, such as editing multiple files
simultaneously and rendering web pages as text.
It is a browser that acts like ed, thus the name edbrowse.
This program was originally written for
[[Blindness|blind]] users, but many sighted users have taken advantage of its
[[Script (computer programming)|scripting]] capabilities.
A [[batch job]] or [[cron job]] can access web pages on the [[internet]], submit forms,
and send [[email]], with no human intervention whatsoever.
Edbrowse can also tap into [[database]]s through [[odbc]].
A traditional substitute command updates the corresponding row in an [[sql]] table,
and similarly for insert and delete.
This [[open-source software|open source]] package is included in several [[Linux distribution]]s
<ref>[https://packages.debian.org/search?keywords=edbrowse ''Edbrowse'' distributed by Debian]</ref>
<ref>[http://packages.ubuntu.com/lucid/edbrowse ''Edbrowse'' on ubuntu]</ref>
<ref>[https://aur.archlinux.org/packages/edbrowse-git ''Edbrowse'' on arch linux]</ref>
and in [[free BSD]]
<ref>[http://comments.gmane.org/gmane.comp.web.edbrowse.devel/91 ''Edbrowse'' on free bsd]</ref>.

== Command Line Philosophy ==

Edbrowse is part of a larger philosophy,
wherein editors, browsers, mail clients, spreadsheets, and other critical [[computer application|applications]]
are rewritten from the ground up if necessary
to support various [[disability|disabilities]].
Once this is done,
Other programs
can leverage these tools,
and be immediately accessible to a wide range of computer users.
[[Web site]]s and [[web based]] utilities,
for example,
become accessible through customized browsers.
These include [[Internet Printing Protocol|printer management]] (port 631) and [[samba (software)|swat]] (port 901)
on some systems,
and most off-the-shelf [[network router|routers]].

This stands in contrast to the [[Front_and_back_ends|front end]] approach,
which modifies or enhances the input/output layer and leaves the applications alone.
[[Microsoft Explorer|Explorer]], [[Microsoft Outlook|Outlook]], and [[Microsoft Word|Word]]
all run without modification,
while a [[screen reader]] such as [[Window Eyes]] converts the words or [[computer icon|icons]] into speech or [[braille]].
The adapter is written once, and maintained as stand-alone software,
supporting almost any application that anyone could write.
This has obvious technical advantages,
and is the most practical path to accessibility,
but a small minority of disabled users find the experience suboptimal.
A sighted user quickly locates items on the screen by moving his eyes,
but the efficiency and speed of this visual interface is lost when those eye movements are replaced with a mouse and a screen reader.
A command line editor, in contrast, allows the user to jump to a particular location in a file or on a web page
by searching for a text fragment or [[regular expression]].
There is more typing, but less output,
which is desirable when that output is run through the linear channel of speech or braille.

Rewriting and maintaining these large and complicated programs,
such as a browser with all its [[Browser_plugin|plugins]],
is a daunting task that has received little support from government and industry to date.
Still, the core of [[Unix]] and [[Linux]] consists of command line utilities,
starting with the shell,
and a few intrepid volunteers continue to write and maintain higher level applications
such as browsers and database editors,
to keep the command line philosophy alive.

== History ==

In 2002, Karl Dahlke wrote the first version of edbrowse in [[perl language|perl]].
It lacks many important features, such as [[javascript]] support,
but it has one overarching advantage, it is 100% portable.
It can be run on [[Linux]], [[Unix]], [[OS X]], or [[windows operating system|Windows]],
provided perl is installed.
Thus edbrowse version 1.5.7 is still available today.
It is not maintained, but curious users can run the perl version as a test,
to see if they like the edbrowse interface,
or the command line philosophy in general.

Version 2 provided limited javascript support through a home-grown javascript interpreter,
but keeping up with the ever evolving standards of [[Client-side_scripting|client side javascript]] was impractical,
so in 2008 Karl wrote version 3,
which incorporates the open source
[[SpiderMonkey (JavaScript_engine)|Spider Monkey]]
javascript engine, also used by [[Firefox_browser|FireFox]].
This gives edbrowse a decent level of javascript support,
and provides access to more websites.

== User Impressions ==

Edbrowse is sometimes described as dense in its code and in its [[human interface]].
It contains many cryptic one and two letter commands,
and few interactive help facilities.
There is no menu, no dialog, and no screen of intuitive icons to click on.
Like [[bash shell|bash]], edbrowse greets the user with a blinking cursor,
waiting for input,
and if that input is syntactically incorrect, edbrowse prints a question mark.
Thus it is important to read the edbrowse user's guide before diving in.

For those who persevere, edbrowse can become an effective multi-purpose tool
that presents one common interface for an assortment of tasks
such as editing files, managing directories, receiving email, and surfing the net.
William McEwan,
of the
[[Puppy Linux]] forum,
describes edbrowse this way.

"The first few days I tried to use this program (based partly on the old UNIX
ed) I thought I was in a living nightmare.
But its so easy now.
I can literally do it with my eyes closed.
It has its limitations,
limited javascript support and so on,
but it also comes with much potent magic."

== External Links ==

[http://the-brannons.com/edbrowse Edbrowse home page], maintained by Chris Brannon

[http://www.eklhad.net/edbrowse/philosophy.html The command line philosophy], by Karl Dahlke

[https://github.com/eklhad/acsint.git The Jupiter speech adapter], a linear speech adapter that is optimized for command line programs

Re: [Edbrowse-dev] wiki

[Adam Thompson]

On Tue, Feb 18, 2014 at 03:34:42AM -0500, Karl Dahlke wrote:
> Ok ... I have an account, I read the article on Hypatia, pretended to edit it,
> compared the article with the raw input, reverse engineered their markup
> language, and wrote an edbrowse article in their style, as shown below.

First of all, well done for getting this far.

My comments on the article:
- The philosophy section is largely unsourced and will almost certainly be 
challenged as it is your personal opinion.
- for the same reasons, I'd also cut down on the accessibility stuff as,
even between the users on this list, we could have a long and no doubt interesting discussion
about why people use edbrowse, and the direction that accessibility should take.
- Also, probably remove the link to Jupiter as it's very obscure.
If you want to link to something like that I'd probably go for speakup (which
is in the Linux kernel module tree now), brltty or yasr,
as these are far more widely used.
- you probably want to focus more on the technical and feature aspects of
edbrowse and less on user opinions etc.
- should there be a reference to ed when talking about it?
- remember that, although putting an article on wikipedia may make some people
aware of the software, wikipedia's supposed to be primarily an information
source, not a promotional platform.

Cheers,
Adam.

Re: [Edbrowse-dev] wiki

[Chris Brannon]

Karl Dahlke <eklhad@comcast.net> writes:

> Chris, one of my external links points to the philosophy article
> on my website but should it be on yours alongside edbrowse for consistency?

I don't see a problem with linking to your site, but the most recent
version of the philosophy page is also available from mine as
http://the-brannons.com/edbrowse/philosophy.html.  I noticed that this
isn't linked from the main page; I need to fix that.

As far as article content goes, you may want to have a look at the
article for Emacspeak to find some possible adjustments to the Edbrowse
article.

-- Chris

Re: [Edbrowse-dev] wiki

[Adam Thompson]

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

On Wed, Mar 12, 2014 at 10:03:37AM -0400, Karl Dahlke wrote:
> I submitted my edbrowse article to wikipedia,
> with my wife's help getting past the captcha.

That's good to hear.

> I then pulled it down to view, and there at the top was a big note saying
> "This article has been marked for speedy deletion by our automatic filter."
> Really?
> I clicked a few links, fortunately wiki is a very edbrowse-friendly site,
> and found out why.
> In 2010 someone posted an article about edbrowse.
> I had no knowledge of this.

I have to say, it's the first I've heard of any previous article as well.

> The assumption, by their software,
> is that the conditions are as they were in 2010,
> and I'm just reposting it to be stubborn,
> and so it is marked for speedy deletion by the administrators.

That's understandable.

> I found the place where I could make a comment and request that it
> not be deleted, speedily or otherwise.
> I pointed out that during those 4 years it had gone beyond a personal project
> and was now part of many distributions, including the references
> that would validate my claim.
> Soon thereafter the notice of deletion disappeared, leaving only the article,
> looking just like the one I last posted on this list,
> that we all agreed to.
> In other words, I think we were successful.
> It is there.

Good work. Thanks for doing this.

> Course it could be deleted next week for some other reason,
> but for now it is there.

Yeah, or edited beyond recognition, but that's the nature of a wiki.

> 1. Should I reference it in my users guide?

Yes.

> 2. Should I include some of its paragraphs in my users guide?
> It is perhaps a better introduction than anything I have in usersguide.html.
Hmmm, I'd assume that anyone whos got as far as the user's guide
probably only needs a brief intro to edbrowse, so probably not.

> 3. Should I include the raw markup of the article in the doc directory?
> That would show people how to write wiki articles, if they wish,
> but it also runs the risk of becoming out of date
> as anyone on the planet can edit and change my edbrowse article on wikipedia.

It would almost certainly become out of date, so I wouldn't.

> 4. At the end of the users guide, talking about various command line utilities,
> should I add a section about my experience posting the article,
> and how to interact with wikipedia, and it's markup language etc?
> Or is that such a rare thing to do that it's not worth talking about.

I suspect it's probably not worth it,
as they may also change the submission process, markup etc.
May be worth a post to the command-line list though.

Cheers,
Adam.

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

[Edbrowse-dev] wiki

[Karl Dahlke]

I submitted my edbrowse article to wikipedia,
with my wife's help getting past the captcha.
I then pulled it down to view, and there at the top was a big note saying
"This article has been marked for speedy deletion by our automatic filter."
Really?
I clicked a few links, fortunately wiki is a very edbrowse-friendly site,
and found out why.
In 2010 someone posted an article about edbrowse.
I had no knowledge of this.
I could not find the article, or even who posted it.
Any idea who it was?
I did however find the discussion log of why it was deleted.
The article itself was fine, but edbrowse was consider
a personal project, and not "noteworthy".
And they were right.
It existed only on sourcefoge and was not being distributed by anybody.

The assumption, by their software,
is that the conditions are as they were in 2010,
and I'm just reposting it to be stubborn,
and so it is marked for speedy deletion by the administrators.

I found the place where I could make a comment and request that it
not be deleted, speedily or otherwise.
I pointed out that during those 4 years it had gone beyond a personal project
and was now part of many distributions, including the references
that would validate my claim.
Soon thereafter the notice of deletion disappeared, leaving only the article,
looking just like the one I last posted on this list,
that we all agreed to.
In other words, I think we were successful.
It is there.
Course it could be deleted next week for some other reason,
but for now it is there.

1. Should I reference it in my users guide?

2. Should I include some of its paragraphs in my users guide?
It is perhaps a better introduction than anything I have in usersguide.html.

3. Should I include the raw markup of the article in the doc directory?
That would show people how to write wiki articles, if they wish,
but it also runs the risk of becoming out of date
as anyone on the planet can edit and change my edbrowse article on wikipedia.

4. At the end of the users guide, talking about various command line utilities,
should I add a section about my experience posting the article,
and how to interact with wikipedia, and it's markup language etc?
Or is that such a rare thing to do that it's not worth talking about.


Karl Dahlke

Re: [Edbrowse-dev] wiki

[Adam Thompson]

On Tue, Feb 18, 2014 at 10:21:22AM -0500, Karl Dahlke wrote:
> Thanks Adam for your feedback.

That's ok, anything I can do to help.

> I will make a couple responses, then should we take this discussion off line -
> as this list is more for development and all
> the technical issues that still confront us??

I don't know, I think it's important to have user input on this.

> > should there be a reference to ed when talking about it?
> 
> Yes. Missed that one. Done.
> 
> > The philosophy section is largely unsourced.
> 
> Yes that was and is one of my concerns.
> But it seems (to me) to important to omit.
> It is the very reason for writing edbrowse in the first place.
> It has to start somewhere, and I don't see ACM or I triple E publishing
> a paper on it, so not sure how to get the ball rolling.
> Worst case I suppose they could contest that particular section.

Yeah, I see what you mean, I wonder if it could be condensed with a reference to the relevant web page?

> > describing the direction that accessibility should take.
> 
> Well I tried hard not to say where it *should* go, only pointing out
> that there are different approaches.
> Their writing guidelines say that's ok.
> It's all right to say there are approaches A and B out there,
> and even quote some people who support A and some people who support B,
> as long as you quote both sides.
> Like the Broken Windows theory of policing,
> which I read about, where they quote people who like it and people who don't,
> and that's ok; though I didn't want to work that hard,
> or write that much, and I still don't want to,
> but I think it would help to say approaches A and B exist,
> because right now only about 100 people in the world know about approach B.

Perhaps, but I wonder if this article is the right place to put it.

> 
> > Also, probably remove the link to Jupiter as it's very obscure.
> 
> I initially wanted to put it in, as opposed to speakup and the others
> that you mention, because it uniquely isn't a screen reader.
> It captures and reads a linear log of output, consistent with linear programs.
> In that sense it is part of approach B.
> But if you didn't get that subtle distinction then I'm not making the point
> well enough, and it's too obscure and too tangential,
> and you're right I just shouldn't go there.
> This is about the editor browser, not various kinds of adapters.
> So I have removed that link.

Ok.

> > you probably want to focus more on the technical and feature aspects
> 
> I hadn't thought of this.
> A section called == Features ==
> But as I write it in my mind, a b command to browse, a g command to go
> to a hyperlink, etc, I wonder if it wouldn't be incomprehensible,
> unless you were fluent in ed, which damn few people are.
> I'll have to think about that one.

I was more thinking in terms of:
Perl compatible regular expressions
http, https etc support for web browsing
email support (not sure exactly what as I personally don't use this)
database support (again not sure on the details)
Multi-buffer support
Configuration file with macro language
Scriptability via popen and friends
Possible examples for the above two
etc

> 
> > and less on user opinions
> 
> Again, their writing guidelines say it is fine to quote peoples reactions
> to a theory or idea or product,
> they say it is even helpful to the reader,
> as long as you are somewhat even handed.
> And I do find these third party quotes in a lot of their articles.
> John says String Theory does indeed explain the fabrik of the universe,
> but Tim says it is a silly mathematical exercise.

Ok, I didn't know that was the case.

Cheers,
Adam.

[Edbrowse-dev] wiki

[Karl Dahlke]

Thanks Adam for your feedback.
I will make a couple responses, then should we take this discussion off line -
as this list is more for development and all
the technical issues that still confront us??

> should there be a reference to ed when talking about it?

Yes. Missed that one. Done.

> The philosophy section is largely unsourced.

Yes that was and is one of my concerns.
But it seems (to me) to important to omit.
It is the very reason for writing edbrowse in the first place.
It has to start somewhere, and I don't see ACM or I triple E publishing
a paper on it, so not sure how to get the ball rolling.
Worst case I suppose they could contest that particular section.

> describing the direction that accessibility should take.

Well I tried hard not to say where it *should* go, only pointing out
that there are different approaches.
Their writing guidelines say that's ok.
It's all right to say there are approaches A and B out there,
and even quote some people who support A and some people who support B,
as long as you quote both sides.
Like the Broken Windows theory of policing,
which I read about, where they quote people who like it and people who don't,
and that's ok; though I didn't want to work that hard,
or write that much, and I still don't want to,
but I think it would help to say approaches A and B exist,
because right now only about 100 people in the world know about approach B.

> Also, probably remove the link to Jupiter as it's very obscure.

I initially wanted to put it in, as opposed to speakup and the others
that you mention, because it uniquely isn't a screen reader.
It captures and reads a linear log of output, consistent with linear programs.
In that sense it is part of approach B.
But if you didn't get that subtle distinction then I'm not making the point
well enough, and it's too obscure and too tangential,
and you're right I just shouldn't go there.
This is about the editor browser, not various kinds of adapters.
So I have removed that link.

> you probably want to focus more on the technical and feature aspects

I hadn't thought of this.
A section called == Features ==
But as I write it in my mind, a b command to browse, a g command to go
to a hyperlink, etc, I wonder if it wouldn't be incomprehensible,
unless you were fluent in ed, which damn few people are.
I'll have to think about that one.

> and less on user opinions

Again, their writing guidelines say it is fine to quote peoples reactions
to a theory or idea or product,
they say it is even helpful to the reader,
as long as you are somewhat even handed.
And I do find these third party quotes in a lot of their articles.
John says String Theory does indeed explain the fabrik of the universe,
but Tim says it is a silly mathematical exercise.

Well no hurry on this, so I'll look through it again with your thoughts
in mind, and meantime we can continue to make the software better,
which is really what we're all about.

Thank you.

Karl Dahlke