Hi Anoop,
Comments inline..
On 18/09/13 15:43, Anoop Nayak wrote:
Hi Gary,
The fix was easy but again a dirty one. I'm looking forward to close the
bug soon. Currently I have used the KeyError exception handling. I hope to
find an alternative solution soon.
Given that you are just setting a flag to true, I would probably have used
flag = req.args.get('action') == "edit"
And I have doubts regarding the license
too. Actually I forked(modified) the mode wikimarkup.js and wikimarkup.css
(still incomplete and a long way to get it perfected) from
https://github.com/marijnh/CodeMirror/blob/master/mode/tiki/. So should I
put the codemirror license in it or the apache license. I'm currently
updating the repo now. Please do check the license in each of the external
files i.e the following:
1.
bloodhound_livesyntaxhighlighting/bhlivesyntaxhighlight/htdocs/js/codemirror.js
2.
bloodhound_livesyntaxhighlighting/bhlivesyntaxhighlight/htdocs/css/codemirror.css
If the code is modified then arguably there should be something to point
out that this is the case as well. For the css you could probably be
keeping the original and overriding anything you needed to in another
css file.
Without looking closer at the code and your changes, I couldn't say how
easy it would be to separate your changes to the original code and still
achieve the desired result. It may well be worth the effort at some
point though.
I haven't coded for the wikitoolbar yet. I was planning to remove it. But I
need your opinion here. And the code folding is implemented now i guess.
While I rarely use the wikitoolbar, it may well be missed by others. I
don't think we were considering removing it but I could be wrong.
Further I would like to know whether are we having syntax highlighting in a
nested manner. Or in other words, if we are writing the code in wikimarkup
processor tags({{{ }}}), is it required to highlight in that language too.
I'm trying for it actually.
That is interesting. It would probably be particularly useful for html
code that is expected to be rendered in place.
Beyond that, it shouldn't really hurt but it might be something to
consider for a later point in the project, if there is still time.
And devs please do check out the branch livesyntaxhighlighting and feel
free to put in your suggestions to improve it.
The textarea resize still acts a bit strangely. There is resize thing
just visible in the lower right hand corner in chrome but it only
resizes the vertical scrollbar. There is no resizer when using firefox
though. I think it is useful to be able to resize the textarea if the
user wishes.
Thanks & Regards,
Anoop Nayak
I like it that you are highlighting the links in [link link text]
syntax. It would be nice to see this extended to WikiWords as well.
One thing I don't like about it so far is that it seems to stop the
x-windows highlight copy buffer from working (neither putting the text
in the buffer when selecting text from the editor with the mouse, nor
middle-click pasting the contents of the buffer). I would definitely
miss this, even if there are other OSs that lack this feature.
There are still two other aspects to this kind of plugin that I would be
interested in.
* The first is that we have some number of wikiformatting textareas
(and more may be added in the future - external plugins also exist
as well), so would it be appropriate and possible to automatically
provide this feature without having to check that we are on a
specific page.
* The second is a question of whether we can provide the frontend
javascript with information about patterns that should be
highlighted so that we don't have to update the plugin for
additional syntax if it is added by another plugin.
This all looks a bit too much given your original schedule but at worst
it is possible future directions for the plugin.
Anyway, Anoop, I would also like to hear more ideas from you, how you
think it looks and what you think you still have time to achieve.
Cheers,
Gary
