[Conkeror] flailing about on upgrade

[Jeremy Maitin-Shepard]

"Mark Eichin" <eichin at gmail.com> writes:

[snip]

> I think I was getting bit by the usual "X paste doesn't actually work
> half the time" bugs; c-y does get a value to paste from *somewhere*
> but it isn't what I select in emacs or xterm, at least most of the
> time; whatever m-space does was more reliable, I think.

I don't remember what M-space used to do, but I'll look into it and see
if that is a command to add back again.  There isn't so much an "x paste
doesn't actually work half the time" bug but there are several different
notions of a clipboard in X, which can create confusion and
inconsistency.  Most commonly used are the PRIMARY selection, which is
generally used by terminal emulators, and by emacs by default, and by
other programs (i.e. gtk programs) when you simply select text with the
mouse, and the CLIPBOARD selection, which is used when you explicitly
choose e.g. a cut or copy command or paste command in most programs
(whereas middle click uses the PRIMARY selection typically.)

>> >   * "ReferenceError: XMLHttpRequest is not defined"  anyone know off
>> > hand how I get at that from the rcfile now?
>> 
>> var req = Cc["@mozilla.org/xmlextras/xmlhttprequest;1"].createInstance();
>> 
>> See:
>> 
>> http://developer.mozilla.org/en/docs/nsIXMLHttpRequest

> Ah, the example at the end, yeah, that works.

>> The RC file no longer loads in the context of a particular window.
>> Instead it loads when conkeror first starts, before any windows are
>> open, in a global conkeror context.  Due to oddities in JavaScript, a
>> fair number of names like XMLHttpRequest are actually just bound as
>> properties of the top-level window object, and thus are not available,
>> but you can always access them by the normal XPCOM mechanisms.

> Ah, got it.  (That also explains why a lot of my other hacks don't work. :-)

>> >   * how do I get passthrough so that I can use gmail?
>> 
>> C-M-q  switches to pass through mode, escape  switches back.

> Oh, and it's even mentioned in the new c-h t output :-)

>> C-q quotes a single key.

> Hmm.  Unfortunately neither of these work as well as "letting anything
> unbound leak through" did; in particular, having to switch out of pass
> through just to get M-n/M-p and C-x C-f to work is tedious, and
> switching back in isn't going to be easy to learn either.  Maybe that
> means I should look at prism-google-mail instead... though it does
> suggest that for passthrough there's a difference between "buffer"
> commands and "windowmanger" commands.

You can set the keymap to pass through unbound keys, but as more
functionality is added to Conkeror, more keys will likely be bound in
the default keymaps, and so your Google Mail will gradually become less
functional.  You could also bind keys like M-n and M-p and C-x C-f even
in the key binding that is used for C-M-q.

>> > (My apologies if it sounds like I'm complaining - it's just that my
>> > command bindings are in my fingers, not my head, so when they don't
>> > work it gets really frustrating, and when I go back to classic
>> > firefox, basic editting keys like c-n and c-p pop up windows which is
>> > kind of painful :-)
>> 
>> If you come to #conkeror on irc.freenode.net, I and others will probably
>> also be there to help, if you have any additional questions.  Feedback
>> is always helpful.

> Hmm, second excuse in a week to get back on irc :-)

>> > On a related note - anyone using pyxpcom with conkeror?  It was a
>> > plenary session topic at Pycon (mozilla team apparently considers
>> > python "the first second-class language" :-) but I don't quite grok
>> > the level at which it operates...
>> 
>> As far as I understand, with some work it might be possible to produce
>> XPCOM components in Python, but because Conkeror doesn't actually expose
>> any XPCOM interfaces related to its internals, you wouldn't be able to
>> do anything very interesting with Conkeror from Python.  Possibly
>> pyxpcom could allow Conkeror to be rewritten mostly from scratch in
>> python, but that would be a lot of work and probably provide little
>> gain.  Possibly the only advantage it would provide is speed ---
>> JavaScript is actually quite a powerful language, but it is quite slow.
>> I think a lot of the noticeable slowness, though, is due to rendering
>> rather than JavaScript.

> My main interest is actually in whether some of the things I run as
> external daemons (and use XMLHttpRequest to communicate with) could be
> done as in-browser objects instead - ie. write bits of python and then
> call them from javascript code in rcfile (which could pass in any
> relevant values, as it does now, without having to expose any new
> APIs.)  That's an area in which my own code is painfully slow because
> it has to quote unicode in buffers down to something 8-bit that it can
> send over XMLHttpRequest, which would work better from the python
> side.

You could probably get that to work easily enough.  JavaScript may also
be able to do what you need directly, though.

-- 
Jeremy Maitin-Shepard