Yakov,
On Saturday, December 8, 2012 9:47:39 PM UTC+8, Yakov wrote:
>
> Hello.
>
> * [like I mentioned previously: moving list items up and down,
>>> copy/cut/paste, level-up/level-down options would be useful, especiall with
>>> regard to the issue above]
>>>
>>
>> Keyboard navigation on list items shall need to wait a bit, for the
>> current codes were written specifically for table cells, quite a few places
>> need modification to generalize.
>>
>>
> Just in case, here I didn't mean keyboard navigation between list items,
> but rather moving the items itself (up and down).
>
Ah, I see. Moving items is, I think, technically the same as
cut-and-pasting and if so should be easy to implement, since there are
already cut and past functions in TWted codes. This will be done in one of
the next few releases.
>
>
>> Clicking links or sliders inside lists doesn't open the editor, WOW! I'm
>>> curious if you've done extra things for this: I also tried
>>>
>>> <html><a href="javascript:;" onclick="displayMessage('this
>>> works!');">smth</a></html>
>>>
>>> and this also doesn't toggle edit mode.. what I mean is that the plugin
>>> could open the edit mode "when unnecessary" and while I tried only some
>>> things which can appear, can we be sure that it'll be ok with others?
>>> That's the only reason why I haven't suggested such "one click" approach
>>> without any edit button.
>>>
>>
>> The links are NOT DISABLED in edit mode by default so clicking them still
>> leads you wherever they point to. You can set the option
>> chkTWtedDisableLink to true if you want to disable them in the edit mode
>> (then clicking them will bring up the edit box). This option was introduced
>> a few versions ago and for now only links are done this way, sliders or
>> other things that can be toggled on and off are not, for I didn't expect a
>> slider panel in a list item or a table cell. I guess what you saw for
>> sliders inside a list was probably because the TWted couldn't find the
>> corresponding wiki text so it didn't do anything. I will think about this
>> in the later versions.
>>
>>
>
> Here we probably didn't understand each other. What suprised me wasn't the
> fact that links or sliders work; it was the fact that on clicking them, the
> editable element is not turned into a text field: what I expected was
> "click tiddlyLink -> open the corresponding tiddler AND open the element to
> edit". The last thing doesn't happen which is what is actually needed but,
> as I remember, such problem happened with PasteUpHelperPlugin (from
> TiddlyTools), so this doesn't seem to be a "default" behaviour. But anyway,
> this has something to do with the onclick event bubbling..
>
Well, during development I noticed that clicking a link can trigger two
actions: opening the link and the edit box, due to event bubbling. But I
didn't like it that way so I introduced the option to restrict it to one
action, either opening the link or opening the edit box. Now I know that
two actions can be expected in some cases, I will figure a way to put it
back.
>
> I'd also like to highlight some useful applications of such inline-editing:
>
> * first, editing pre elements (defined by the
>
> {{{
> ...
> }}}
>
>
I happened to have the above case done yesterday. Good timing! Those below
I didn't come up with, but I think they should share the same codes as the
one above, will do them soon.
> //{{{
> //}}}
>
> /*{{{*/
> /*}}}*/
>
> and may be
> <!--{{{-->
> <!--}}}-->
>
> wrappers) would ease editing code of long plugins if it is separated like
> in TWtable:
>
> //{{{
> some code
> //}}}
> // //heading of the next part of the code
> //{{{
> //}}}
>
> * it seems, for longer tiddlers it would be convenient to separate them
> logically (for instance with {{part{...}}} wrappers) and then edit one part
> at time (it is not always such division conisides with division by headers)
> * in some cases (for instance, when inline-editing formulae, if it is
> implemented) a wikified preview would be useful (preview block above the
> edit block). It is implemented for the whole tiddler in the PreviewPlugin
> [1]
>
A preview is a very good idea. Will definitely think about it.
>
> A side note: I've noticed that you use the SyntaxHighlighterPlugin3 by
> Mario. Some time ago he also made the CodeMirror plugin [2] which enables
> syntax highlightning when editing as well, may be it will be useful for
> you. Though, I must confess, I haven't succeeded in installing it [3] and
> plan to try again after some other things.
>
Well, I am not writing codes within the Tiddlywiki so most likely don't
need highlighting feature in edit mode. But certainly thanks a lot for the
information. I may need it for other purposes.
>
> Best regards,
> Yakov.
>
> [1] http://www.TiddlyTools.com/#PreviewPlugin
> [2] https://github.com/pmario/tw.CodeMirrorPlugin (note also the link to
> the tiddlyspace on the top)
> [3]
> https://groups.google.com/forum/?fromgroups=#!topic/tiddlywiki/iS0gvj5VTgw
>
I am preparing another alpha file (1.5.0 alpha 2) for people to play with,
in which the TWted no longer interfere with TW in the view mode, meaning no
editing in view mode any more. Instead it will take over the default edit
mode and change the behavior: you don't get the edit box and lose the
output, but remain visually in view mode and are able to edit the elements
(hopefully all elements but currently not yet). I will put it up in a
couple of days.
Have fun!
Vincent
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/tiddlywiki/-/Oj9RzHzFAkYJ.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/tiddlywiki?hl=en.
