Hi Anoop, On 04/10/13 17:27, Anoop Nayak wrote:
Hi all,I just updated the repo now. Still I don't have much idea on integrating it to the tickets link and other areas where wiki editor will be required in future. Any suggestions?
I suspect that most wiki editable areas are likely to be TEXTAREA.wikitext - there are at least a few notable exceptions from this as the wikitext class is used to specify that the wiki toolbar should be added to the field but we have dropped the toolbar in some locations.
In particular: * TEXTAREA#comment field on ticket pages where the user has permission to comment * TEXTAREA#edit-comment field on ticket pages where the user has ability to edit the ticket and the Modify Ticket button has been pushed * TEXTAREA#field-description on all pages (the Create Ticket form) when a user has the ability to raise tickets.That last item shows that, at the moment at least, we shouldn't really need to worry about excessive inclusion of the javascript and we can consider ways to optimise this a bit later.
I would be tempted to add another class for the live syntax highlighting to target as that should make it fairly clear how to provide the ability for new controls if required.
Note that, on the assumption that live syntax highlighting is added to the create ticket form, the code will have to be able to deal with multiple controls on one page. It would probably also be worth allowing for no matching elements on a page as well.
Currently, it works only in the wiki editor. I have also updated some code so as to highlight CamelCase words(assuming that is wikiwords which Gary mentioned).
Yes, I will certainly find that hugely useful when I input something in CamelCase where I did not intend a link. Adding a '!' to the front is one of the ways to stop such text rendering as a link.
I am a bit wary of specifying syntax bit by bit that needs to be dealt with. It is almost certainly beyond the immediate aims of this project but a future enhancement might be to get bloodhound to publish syntax on a path so that frontend js code can request the set of patterns and interpret the form that is specified for how to display matches.
In the meanwhile I had a few questions which I had replied previously in the same thread. Seems like it went unnoticed :P. Hoping to receive replies soon.
Have I answered enough of them yet?
Thanks in advance, Anoop Nayak On Wed, Sep 18, 2013 at 11:55 PM, Anoop Nayak <[email protected]> wrote:Hi Gary, Thanks a lot for your feedback. 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. I too miss that very often. But I had got it working in Chrome. Regarding firefox it's still a work in progress according to https://groups.google.com/forum/#!topic/codemirror/SYk0tGcgUxU. 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. I'm also trying to find a pattern there. If you could set a standard, I may follow that. It is meaningless to include the script in all pages as it is quite heavy I guess. So could you suggest a mechanism to handle this. * 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. Updating javascript would mean putting the code in the javascript file which I guess can be done with the python code. But again I feel this is bit more complicated at this stage and I'm not sure whether I will complete this on time. And currently I have brought in the wikitoolbar functionality. It's again not perfect implementation though. And corrected the code without handling the KeyError exception. And firefox is having a lot of issues in codemirror. Even I'm not able to get the resizer in firefox. Well I had coded for the Adjust line height it should do the work I guess. The editor cannot be resized horizontally as lines are wrapped. I just tried with the previous editor and there also it is the same i.e resizing vertically only. I just updated the codemirror source files to the latest version as there are some patches regarding resizing i guess. Thanks & Regards, Anoop On Wed, Sep 18, 2013 at 10:51 PM, Gary Martin <[email protected]>wrote: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 licensetoo. 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/<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.cssIf 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 highlightingin 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 feelfree 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 NayakI 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-- Anoop
Cheers,
Gary
