On Thu, Aug 16 2012, Eric Schulte wrote:
> Eric Abrahamsen <e...@ericabrahamsen.net> writes:
>
>> On Thu, Aug 16 2012, Eric Schulte wrote:
>>
>>> Eric Abrahamsen <e...@ericabrahamsen.net> writes:
>>>
>>>> On Thu, Aug 16 2012, Eric Schulte wrote:
>>>>
>>>>>>> Every time I edited a block and clicked "save", it just deleted the
>>>>>>> whole block. I got these errors in ~/.elnodelogs/elnode-error:
>>>>>>>
>>>>>>
>>>>>> I'm not sure what could be causing this problem. Did the test suite run
>>>>>> successfully for you?
>>>>>
>>>>> I've now added a POST test to the test suite. So if your problem
>>>>> persists you should now see a failing test, and conversely if you are
>>>>> now passing the test suite this problem should be eliminated.
>>>>
>>>> So yes, I did run the tests the first time, and you're right that,
>>>> without the "post" test, they went just fine. The documents were also
>>>> altered on-disk (ie, the chunks really were deleted).
>>>
>>> Interesting.
>>
>> [...]
>>
>>> Even thought this test is failing, it does show that your elnode server
>>> is returning the HTML in response to your POST requests. It looks like
>>> it only fails because your Emacs exports *foo* as <em>foo</em> instead
>>> of as <i>foo</i>.
>>>
>>>>
>>>> Then I restarted emacs -Q and used your batch.el file. I'm still getting
>>>> the same problem, unfortunately: the editable blocks disappear when I
>>>> hit "save". I realized I don't actually know whether this is supposed to
>>>> edit the simple.org or simple.html files:
>>>
>>
>> [...]
>>
>>> I've just pushed up some changes to the git repository which add new
>>> require statements. Hopefully the errors above were caused by some
>>> required functions not being loaded at run time. If the newest from git
>>> doesn't work fix these problems, please try running
>>>
>>> emacs -Q -l batch.el
>>>
>>> with this updated version of batch.el, and let me know what is printed
>>> in the *Messages* buffer in the line which starts as "params:".
>>
>> The same test failed in the same way,
>
> Fair enough, this must be a legitimate difference in our HTML export,
> I'll make the test appropriately more permissive.
>
>> so I loaded up the new batch.el file, and here's the "params" line:
>>
>> params:(("path" . "/simple.org") ("end" . "577") ("beg" . "156") ("org"
>> . ""))
>>
>> Hope that's enlightening!
>>
>
> Yes, very enlightening. It means that the server-side and Emacs Lisp
> side are working as expected. However, for some reason, when you hit
> [SAVE] the information submitted by your browser includes an empty text
> field (this is the "org" pair above).
>
> This must be a JavaScript issue related to some difference between
> browsers. Can I ask, what browser you are using? I've done all of my
> testing with browsers in the Firefox family (Firefox and conkeror).
I'm using the version of Chrome provided by Arch linux, it tells me
Version 21.0.1180.79 (151411). I just tried the test server in Firefox,
and it worked perfectly.
Much as I like Chrome, I've occasionally seen it make websites fail in
ways you wouldn't think a browser should be capable of.
--
GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.11) of
2012-08-14 on pellet 7.8.11
