Re: [ASF-ICFOSS MENTORING COMDEV-92] Regarding Live Syntax Highlighting

[Anoop Nayak <an...@gmail.com>]

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? 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). 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.

Thanks in advance,

Anoop Nayak


On Wed, Sep 18, 2013 at 11:55 PM, Anoop Nayak <an...@gmail.com> 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 <ga...@wandisco.com>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 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/<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
>>
>
>
>
> --
> Anoop
>



-- 
Anoop

Re: [ASF-ICFOSS MENTORING COMDEV-92] Regarding Live Syntax Highlighting

[Gary Martin <ga...@wandisco.com>]

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 <an...@gmail.com> 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 <ga...@wandisco.com>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 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/<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
>>>
>>
>>
>> --
>> Anoop
>>
>
>

Cheers,
     Gary