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]  [patch] [experimental] JS console patch
Date: Mon, 28 Sep 2015 05:47:58 -0400	[thread overview]
Message-ID: <20150828054758.eklhad@comcast.net> (raw)
In-Reply-To: <20150827230052.kevin@carhart.net >

> Here is my JS console code.

Wow! First of all, I don't undderstand that javascript at all,
but I see that it works, so on we go.
It is now included in startwindow.js as per the latest push.
You don't have to type an extra command; the ok (object keys) function is there.

Type jex (javascript executions) from a running web page
to enter this mode.
I very much didn't want to type jex each and every time, so it's a mode,
like a in the editor.
Type . by itself to exit this mode.
So now you can look at and change variables, and use the ok function for
the members of any object.
alert(ok(document.body));
But there are two major things to fix.

1. All the gc variables under document are damn annoying.
These are artificial placeholders in edbrowse to protect
certain things from garbage collection.
They could all be members of the object document.gc$,
instead of variables under document.
That's not hard to do but not trivial, and must be done in both decorate.c
and jseng-moz.cpp.

2. The real nuisance is having to type alert all the time.
When you run a js shell, from mozilla or v8 or whomever,
the result of your entered command is  displayed if there is a result.
You don't have to type alert all the time.
This is obviously what we want.
So javaParseExecute should return a string if the
executed script has a result,
a string we can print if not null,
or perhaps a new function javaParseExecuteResult for this purpose.
Then this feature won't be quite so painful to use.

If you set db3 before you enter then you will see syntax errors etc,
instead of just silence, assuming your entered command worked
when maybe it didn't.

this is not documented yet, because I don't think we have
the final interface or all the details worked out.
But we all wanted it, and it was so damn easy to do,
especially since Kevin handed me the ok() function,
so why not move forward on it.
If someone wants to address either of the shortcomings above,
or suggest improvements, let me know.

Karl Dahlke

  reply	other threads:[~2015-09-28  9:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-28  6:00 Kevin Carhart
2015-09-28  9:47 ` Karl Dahlke [this message]
     [not found] <5608d799.c539440a.54033.3b99SMTPIN_ADDED_BROKEN@mx.google.com>
2015-09-29  7:03 ` Adam Thompson
2015-09-29  9:04   ` Kevin Carhart

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=20150828054758.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).