[tw5] Introducing new text editor toolbar

[Jeremy Ruston]

I’m pleased to say that TiddlyWiki is finally getting an extensible rich text editor toolbar in the core. There’s a preview you can try out here:

http://rich-text-editor.tiddlyspot.com/

The breakthrough was (re)-discovering how to avoid losing the selection when clicking on one of the toolbar buttons. The solution turns out to be as simple as embedding the textarea in an iframe. There are some complexities stemming from the fact that the content of the iframe doesn’t inherit the prevailing CSS styles.

Anyhow, the code is complete enough to be usable. Besides the expected formatting operations there are a couple of interesting additions:

* An “excise” button that slices the selected text into a new tiddler and replaces it with a link or transclusion to the new tiddler

* A “stamp” button that brings up an extensible list of snippets that can be selected with a single click

It’s still a work in progress; the things left to are listed in the pull request:

https://github.com/Jermolene/TiddlyWiki5/pull/2315

I’m interested in feedback on how well it works on different browser/operating system combinations, but please feel free to post any thoughts or questions too,

Best wishes

Jeremy.

[Mark S.]

The little arrow buttons give an NS_ERROR_FAILURE message.

The problem with linking/transcluding via titles is that then you either have to stick with that title forever or be willing to go back and edit all the places it is referenced. I often find myself wanting to change a title -- sometimes the muse just isn't there when you're doing your first draft. As a consequence, I rarely use the linking feature.  It would be useful if there were a way to link via some ID field which would never have to change.

Mark

Pale Moon Version: 25.8.1 (x86)
Firefox 33
Windows 7

[Eric Shulman]

On Monday, March 7, 2016 at 10:16:51 AM UTC-8, Mark S. wrote:

The little arrow buttons give an NS_ERROR_FAILURE message.

The problem with linking/transcluding via titles is that then you either have to stick with that title forever or be willing to go back and edit all the places it is referenced. I often find myself wanting to change a title -- sometimes the muse just isn't there when you're doing your first draft. As a consequence, I rarely use the linking feature.  It would be useful if there were a way to link via some ID field which would never have to change.

Use of a special "unique tiddler ID" field has been suggested many times, for both TiddlyWiki Classic and TiddlyWiki5.  Typically, after much discussion of alternative architectures and backward compatibility, we generally come back to the fact that TiddlyWiki already has a field that holds a unique ID for each tiddler: the *title* field, and that what is really being discussed is a distinction between a tiddler's ID and the title that people see.

In TiddlyWiki5, the "caption" field can be used to provide that distinction.  For example, in the <<tabs>> or <<toc>> macros, if a tiddler has a caption field, then that text is displayed as the tab title or table toc link text, respectively.  Note that this is simply a TW core standard *convention*.  There is no requirement for a tiddler to have a caption field and, by default, only some of the core functions use the caption field.

For your purposes, you could extend this default usage to display the caption text in place of the title text, by modifying the $:/core/ui/ViewTemplate/title shadow definition, and replace

<$view field="title"/>

with

<$view field="caption"><$view field="title"/></$view>

For links, you could just use *pretty link syntax* to show the desired text, while using the title "ID" as the link target:

[[this is what the reader sees|TiddlerID]]

or, alternatively, you could use a "caption link" macro to assemble a link using the target tiddler's caption text, like this:

\define clink(tid)
<$link to="""$tid$"""><$view field="""$tid$!!caption"""><$view field="""$tid$!!title"""/></$view></$link>
\end

which you would invoke like this:

<<clink TiddlerID>>

There are probably some other places where you might want some customizations, but once you have tweaked things to suit your needs, you can just think to yourself "title = ID.... caption = display text".  Of course, if you don't provide a caption on a given tiddler, everything should fall back nicely to using the title text as the display text, just as before.

Hope this helps,

enjoy,

-e

Eric Shulman

TiddlyTools / ELS Design Studios

InsideTiddlyWiki: The Missing Manuals

[Sylvain Naudin]

I'm so happy :)
Thank you Jeremy for this nice feature which help many new users !!

Maybe can you add a title to detail with a label on mouse over ?


Cheers,
Sylvain

[Jeremy Ruston]

Hi Sylvain

> Maybe can you add a title to detail with a label on mouse over ?

That is the plan, as part of the internationalisation that I also need to do. I’ve updated the checklist:

https://github.com/Jermolene/TiddlyWiki5/pull/2315

Best wishes

Jeremy.

[andrew harrison]

This is so awesome. Not to take away anything because this is so awesome, but it would be nice if I could remove or add buttons like from a toolbar in the control panel.

 

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/31B2757E-F001-4B97-BEB5-0CFB1727FF4E%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Mark S.]

Suggestion for stamp: Add a 3rd possibility to do a transclusion AND a link. That way the user can quickly navigate back to the source snippet when changes are required.

Mark

On Monday, March 7, 2016 at 9:34:19 AM UTC-8, Jeremy Ruston wrote:

[Mark S.]

Hi Eric,

Thanks for your explainer. But there's something wrong with your macro definition. It seems to want the tiddler= attribute rather than the combined field=tiddler!!field.

Also, is the idea that only the caption OR the title shows up? I could fix it, but it would show both caption and title when both were available.

I don't suppose there's a simple way to make a macro that can do if/else choices?

It's a basic database design requirement that key linking fields be immutable. Title fields should float on top of the data independently so they can be freely altered as the use case is refined. I guess if I was going to depend on a macro solution I would want one that would create links based on a separate id field. But I suppose the link macro would have to do some sort of expensive field search so ... I don't know.

Thanks!
Mark

 



On Monday, March 7, 2016 at 11:30:00 AM UTC-8, Eric Shulman wrote:

On Monday, March 7, 2016 at 10:16:51 AM UTC-8, Mark S. wrote:

The little arrow buttons give an NS_ERROR_FAILURE message.

The problem with linking/transcluding via titles is that then you either have to stick with that title forever or be willing to go back and edit all the places it is referenced. I often find myself wanting to change a title -- sometimes the muse just isn't there when you're doing your first draft. As a consequence, I rarely use the linking feature.  It would be useful if there were a way to link via some ID field which would never have to change.

Use of a special "unique tiddler ID" field has been suggested many times, for both TiddlyWiki Classic and TiddlyWiki5.  Typically, after much discussion of alternative architectures and backward compatibility, we generally come back to the fact that TiddlyWiki already has a field that holds a unique ID for each tiddler: the *title* field, and that what is really being discussed is a distinction between a tiddler's ID and the title that people see.

...

[Eric Shulman]

On Monday, March 7, 2016 at 9:13:22 PM UTC-8, Mark S. wrote:

Hi Eric,

Thanks for your explainer. But there's something wrong with your macro definition. It seems to want the tiddler= attribute rather than the combined field=tiddler!!field.

oops... yes.  tiddler="""$tid$""" field="!!caption"

 

Also, is the idea that only the caption OR the title shows up? I could fix it, but it would show both caption and title when both were available.

The way the <$view> is *nested*, it will show the caption field if it exists, OR the title field if no caption field exists.... but not both.

It's a basic database design requirement that key linking fields be immutable. Title fields should float on top of the data independently so they can be freely altered as the use case is refined. I guess if I was going to depend on a macro solution I would want one that would create links based on a separate id field. But I suppose the link macro would have to do some sort of expensive field search so ... I don't know.

If the "title" field was named "ID", and the "caption" field was named "title", you would have what you want, without having to implement completely separate handling for a custom ID field.

-e

[Mat]

Excellent!!!  We can finally answer "Of course!" to the many people wondering "Is there a text toolbar?"


I thought I could report on undo not working in FF but it was already noted in the pull request so here are only some general reflections:

An idea for responsiveness for smaller screens might be to merge e.g the H buttons into a cycling button (ex).

I absolutely love the Incision and Stamp features!!! (Ironically I've fiddled with my own solutions for these over the past weeks e.g the select feature in my just released QuickTid is somewhat like a Stamp... but it's built in wikitext so a bit rough and based on lot's of shufflings to get it to work. I wish I had seen this first.)

Stamp has a LOT of potential IMO and deserves separate attention somehow. It could save a lot of work and simplify for people to use code and solutions that they could not create themselves. There could be a library of snips, e.g ready made filters and macros.

 
<:-)

[Scott Simmons (Secret-HQ)]

* An “excise” button that slices the selected text into a new tiddler and replaces it with a link or transclusion to the new tiddler
* A “stamp” button that brings up an extensible list of snippets that can be selected with a single click

!!!

And not in the "<H3>" sense but rather the "Oh, my goodness; that's capital!" sense.

UI-wise, I suggest the toolbar be positioned full-width horizontally across both the editing pane and the preview pane in order to preserve the more-or-less scroll-syncing of the two panes (and for aesthetics).  This may be included under the heading of "integrating the preview pane."

The bold and italic buttons' text graphics appear notably larger than the other buttons'.

The code buttons' graphics could perhaps be clearer, especially for triple backticks/code block.  How about something like <> and </n> instead?

A third button that would fit well with the code buttons would be one to wrap text in """ and """ (with line breaks, of course) for literal-line-spacing blocks of text.

For the stamp tool, "add your own" would be more elegant if it triggered a modal with the explanatory text and fields you could fill in to create the stamp text tiddler.  Perhaps pre-fill the "title" field there with "$:/" as a gentle reminder/nudge to create stamp text tiddlers as a system tiddlers.  (Or would that be too pushy?)

Perhaps the excise text popup would work more elegantly as a standard TW5 modal, as well.  More room for additional options, some of which might be added by plugin developers.  ;)  [Personally, I'd love to have the ability to tag the excised-text tiddler to the current tiddler.]

[Andy Pastuszak]

You have just made Tiddlywiki far more accessible to the masses!  This is going to be awesome.  Thanks for making such a great tool.

Andy

[Jeremy Ruston]

Thanks for the feedback everyone. I’ve made some improvements:

1. Added tooltips to the text editor toolbar buttons

2. Made text editor toolbar buttons selectable via Control Panel. (H4,

H5 and H6 are hidden by default)

3. Added support for tagging an excised tiddler with the name of the

donor tiddler, as suggested by Scott

4. Improved styling

5. Improved “Add your own” item for snippets that now kicks off a new

tiddler with the required tag and fields, also suggested by Scott

6. Added the ability to excise as a custom macro call, providing a way for Mark to excise as both a link and a transclusion

I’ve uploaded a new preview:

http://rich-text-editor.tiddlyspot.com/

You can see the code in the pull request:

https://github.com/Jermolene/TiddlyWiki5/pull/2315

Best wishes

Jeremy.

-- 
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/5710db60-33f8-4b9e-8292-f1c3e3b4cde8%40googlegroups.com.

[Jeremy Ruston]

I forgot to add that there is also now a picture chooser. I’ve added some screenshots below.

Best wishes

Jeremy.

[Mark S.]

Is it possible to move the toolbar to a tab on the sidebar?

The problem with a toolbar connected with the tiddler is that the tools quickly get scrolled away as the text gets longer.  If the toolbar was in the sidebar, then the tools would be still available as one writes.

Or maybe if there was a way for a scrollbar to appear in the tiddler when it exceeds some length. That is what happens in this google groups comment box.  After a certain number of lines, a scrollbar appears so that you never have to be more than 2 text inches away from the tools.


Mark

[Mat]

Jeremy Ruston wrote:

I forgot to add that there is also now a picture chooser.

Wonderful! I don't want to be greedy but I think most such picture choosers let the user import pics too.

Detail; could it be that the excision button has the icon tilted 90 degrees?

BTW the Preview button is IMO now be better suited in the toolbar, appearing as one of those buttons, perhaps at extreme right.

<:-)

[Jon]

Hi Jeremy,

I was wondering if it might be better to alter the action of the buttons slightly so the inserted items are not highlighted.

For example to bold text, you would need to first select the text and then press B.
But if the '''' is inserted with the cursor flashing in the middle, you could press B and then continue typing in bold - it just means you don't need the additional action of selecting the text first. (This is the current behaviour of Danielo's keyboard shortcuts).

Great addition - thanks.

Regards
Jon

[Scott Simmons (Secret-HQ)]

On Wednesday, March 9, 2016 at 6:17:49 PM UTC-5, Mark S. wrote:

The problem with a toolbar connected with the tiddler is that the tools quickly get scrolled away as the text gets longer.  If the toolbar was in the sidebar, then the tools would be still available as one writes.

There's a still-experimental feature in TW5 to make the titles of tiddlers "stick" to the top of the screen as you scroll down. Unfortunately, it only works in some browsers — but if this could ever become a universal feature, I think it would be handy to make it available for the formatting bar, too — so that, as you scroll down the page, the bar always remains visible on the screen.

An alternative might be to wrap the bar in a CSS class and make it user-configurable for the bar to have a fixed position (position:fixed; margin-top:0; or position:fixed; margin-bottom:0;).

[Mark S.]

Hi Scott,

How do you activate this feature?

Thanks,
Mark

On Thursday, March 10, 2016 at 10:42:52 AM UTC-8, Scott Simmons (Secret-HQ) wrote:

On Wednesday, March 9, 2016 at 6:17:49 PM UTC-5, Mark S. wrote:

The problem with a toolbar connected with the tiddler is that the tools quickly get scrolled away as the text gets longer.  If the toolbar was in the sidebar, then the tools would be still available as one writes.

There's a still-experimental feature in TW5 to make the titles of tiddlers "stick" to the top of the screen as you scroll down. Unfortunately, it only works in some browsers — but if this could ever become a universal feature, I think it would be handy to make it available for the formatting bar, too — so that, as you scroll down the page, the bar always remains visible on the screen.

An alternative might be to wrap the bar in a CSS class and make is user-configurable for the bar to have a fixed position (position:fixed; margin-top:0; or position:fixed; margin-bottom:0;).

[Mat]

@Mark - note caniuse sticky

@Mark & @Scott - an idea would be to have the toolbar show at bottom of the textfield. You are more likely to write at the end of your text, i.e close to frame bottom. But the ideal might be some kind of popup at cursor position so it appears exactly where you are.

<:-)

[tony]

>extensible rich text editor toolbar in the core http://rich-text-editor.tiddlyspot.com/

Congratulations on the new editor, Jeremy!

This will really help increase user adoption getting over the tw markup learning curve.

Probably too much to ask but can the RichTextEditor be offered as an optional plugin instead of permanent Core?

The tiddler body embedding the textarea in an iframe disables these handy bookmarklets from Skeeve (StephanHradek) [1]

If the toolbar stays in the Core, I think a lot of these bookmarklets can be reformatted as snippets, but I wonder about side effects of the new textarea/iframe on other tools/services that interact with tiddler bodies?

I'm excited to learn how to make macro snippets. The snippets reminds me of Eric's great QuickEditPackage [2]

On that note, has anyone made a snippet to insert the value of the macro call into the tiddler body, ie hard coded value?

Basically, the <<now>> macro would make a handy hard coded date timestamp if the timestamp value can be inserted which goes toward future proofing tiddler data sans html.

As for testing, i can report the ItsAllText addon for FireFox still works so one can still edit with vim :-) [3]

Best,
tony

[1] http://tw5magick.tiddlyspot.com/
[2] http://tiddlytools.com/#QuickEditPackage
[3] https://github.com/docwhat/itsalltext

On Monday, March 7, 2016 at 9:34:19 AM UTC-8, Jeremy Ruston wrote:

[Scott Simmons (Secret-HQ)]

On Thursday, March 10, 2016 at 1:58:29 PM UTC-5, Mark S. wrote:

How do you activate this feature?

Hi, Mark —

Look for Sticky titles in $:/ControlPanel » Appearance » Theme Tweaks » Options.

Or look for the tiddler $:/themes/tiddlywiki/vanilla/options/stickytitles.

It works in Firefox but not in TiddlyDesktop or Chrome.  Your mileage may vary in other browsers.  If something like that could work cross-platform, it strikes me as ideal for the text editor toolbar.

[Scott Simmons (Secret-HQ)]

On Thursday, March 10, 2016 at 3:25:48 PM UTC-5, Mat wrote:

note caniuse sticky

Bookmarked!

(That site is awesome, Mat.  Thanks!)

 

an idea would be to have the toolbar show at bottom of the textfield. You are more likely to write at the end of your text, i.e close to frame bottom.

Well-observed!  And certainly easier to implement than some of the other visions offered up in this thread.

 

But the ideal might be some kind of popup at cursor position so it appears exactly where you are.

Fixed at the top or bottom of the screen (user-configurable!) seems pretty ideal to me — although you might run into problems if two or more tiddlers were open in edit view at once.  (Which toolbar would see?  You would have to save/close the tiddler matching the current toolbar before you could use the toolbar to edit another tiddler.)

Maybe if the toolbar were moved into its own tiddler and summoned whenever one or more tiddlers were in edit view, so that it could execute changes anywhere the cursor was at the time — ?  (Or maybe I'm just tired and overcomplicating things.)

[Scott Simmons (Secret-HQ)]

On Thursday, March 10, 2016 at 3:54:38 PM UTC-5, tony wrote:

 

Probably too much to ask but can the RichTextEditor be offered as an optional plugin instead of permanent Core?

Hmmm.

It does seem the text editor should come out of $:/core/ui/EditTemplate/body and into its own tiddler that could be listed (or not) in the list field of $:/tags/EditTemplate.

That would allow easy removal for those who don't want it and more modularity for those who want to create their own custom EditTemplates for different purposes.  A user (like, oh, say, Mat) could also use list-before/list-after to decide whether to display the rich edit bar above or below the story body textarea.  ;)

[Jeremy Ruston]

Once again, many thanks to everyone for the feedback.

I’ve uploaded a new preview that properly integrates the preview pane:

http://rich-text-editor.tiddlyspot.com/

Probably too much to ask but can the RichTextEditor be offered as an optional plugin instead of permanent Core?

Hmmm.

I’ve also been wondering about making the entire thing into an optional plugin. The trouble is that it is, I think, an essential end-user feature, and I’m keen to ensure that the vanilla TiddlyWiki experience is as good as we can make it.

It does seem the text editor should come out of $:/core/ui/EditTemplate/body and into its own tiddler that could be listed (or not) in the list field of $:/tags/EditTemplate.

Right now, the rich text editor is separate from the ordinary editor, and is enabled via editor type mappings; users can change the mapping back to use the ordinary editor.

But I intend to integrate the new functionality into the existing edit-text widget, and to do so in a fully backwards compatible manner.

That would allow easy removal for those who don't want it and more modularity for those who want to create their own custom EditTemplates for different purposes.  A user (like, oh, say, Mat) could also use list-before/list-after to decide whether to display the rich edit bar above or below the story body textarea.  ;)

Ah, it’s not possible to separate the slices containing the toolbar and the editor; they are switched in as a single unit. That is necessary for the message routing to work: the toolbar is actually embedded in the editor in the widget tree, but arranged adjacently in the DOM tree.

So, we could enhance things to optionally repeat the toolbar after the editor as well or instead of before it, but we can’t separate the two things. That actually rules out a lot of the floating ideas that have been mooted.

My preferred option is to add a toolbar button that fixes the height of the textarea (using scrollbars if needed) so that it fits on screen with the toolbar.

The tiddler body embedding the textarea in an iframe disables these handy bookmarklets from Skeeve (StephanHradek) [1] 

Yes, I don’t think we can retain compatibility with those bookmarklets, but there’s nothing to stop them being adopted and updated.

If the toolbar stays in the Core, I think a lot of these bookmarklets can be reformatted as snippets, but I wonder about side effects of the new textarea/iframe on other tools/services that interact with tiddler bodies?

It’s a good point, and of course TiddlyWiki code or extensions that relies on the old arrangement is going to break. But the textarea-within-an-iframe technique is pretty common, and so I’d expect browser extensions to cope with it.

I'm excited to learn how to make macro snippets. The snippets reminds me of Eric's great QuickEditPackage [2]

Yes, Eric has already explored a lot of this territory!

On that note, has anyone made a snippet to insert the value of the macro call into the tiddler body, ie hard coded value? 

That is an option I intend to add. In particular, I’d like make it possible to create a toolbar button with a dropdown containing a form and a submit button that passes the form values to the macro and inserts the wikified output. Pretty much like the functionality of the excise button, but without needing JavaScript.

Basically, the <<now>> macro would make a handy hard coded date timestamp if the timestamp value can be inserted

Yes, that would work.

which goes toward future proofing tiddler data sans html.

I’m not sure what you mean here, Mat?

Best wishes

Jeremy.

As for testing, i can report the ItsAllText addon for FireFox still works so one can still edit with vim :-) [3] 

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/5def3a53-1eee-4b6f-b8ec-f236bf152a86%40googlegroups.com.

[Mat]

Jeremy Ruston wrote:

which goes toward future proofing tiddler data sans html.

I’m not sure what you mean here, Mat?

Just; that was Tony writing, not me :-)

The new preview pane integration - wow!

 

My preferred option is to add a toolbar button that fixes the height of the textarea (using scrollbars if needed) so that it fits on screen with the toolbar.

That's a really interesting idea! If set to fixed height, would it still be resposive to different screen heights?
 
It would be very cool to be able to page scroll (i.e jump full pages) and have one tiddler show at a time instead of the current "whizz by" of tiddlers during scroll. I'm reminded of the Article Storyview concept.


Iframes; only now did I register that note about textareas in iframes! I'm drifting from topic but integrated iframes should make it very easy to set the content src to anywhere... as in TWederatoin... and we might locally even be able to use srcdoc to sandbox e.g imported tiddler content. (And then just maybe even apply a subset of wikitext rules to the content then! Code highlighting, functional tiddlerlinks etc in displayed codetext...)

<:-)

[tony]

On Friday, March 11, 2016 at 4:35:45 AM UTC-8, Jeremy Ruston wrote:

make it possible to create a toolbar button with a dropdown containing a form and a submit button that passes the form values to the macro and inserts the wikified output. Pretty much like the functionality of the excise button, but without needing JavaScript.

Exciting and useful development to insert the wikified result :-O
 

which goes toward future proofing tiddler data sans html.

on FutureProofing

After years of legacy tools, open and proprietary, parsers and all manner of versions, conversions, transitions, transconfusions
 
The line is my tiddler and all tokens therein are the elements. Wiki CamelCase is the hyperlink. [1]

I have found TiddlyWiki fiddling proportional to the distance separating me from content :-)

In fact, early on, TiddlyWiki was actually TinkeringWiki with no end in joy of tweaking, optimizing, etc

We thrive on novelty, but Goldilocks said she won't remember transclusion or want to parse out list filter definitions

So I opted for AnalogWikiWeb that FutureSelf will still understand.


It's giving up a lot staying AntiMetaData, fields barren, tags unfed.

But experience tells a different story. Categorzation/classification is a hard problem.

Search wins. It's smarter at harvesting than my fumbling with names, labels, classes, tags.

All we have is time so my convention stays all line based ISO 8601 strftime("%Y-%m-%d %H:%M:%S %a")

Pretty much a LifeLog with all its human inefficiency and redundancy, slow and bloated, organic analoginess

But still read like a book. Context is always in the past, lines back, down the "river".

When Windows break, apps forgotten, the web vectorized, SkyNet reigns, long live lines of plain text!

Since TiddlyWiki for me is a non-linear PersonalWebNotebook, this wouldn't fly in Federated collaborative space.

YMMV

Best,
tony

[1] the gamble is on the old tools that last because they endure: regexp, vim, emacs, sed, awk, unix
however cool newness is, nothing seems to last without the BDFL, community and/or infrastructure to support it?
gotta find middle ground between AnalogDigital world

[Stephen Kimmel]

I'm having a problem with the preview window in the new text editor. In some cases the preview falls below the editing area. I assume that I've done something to create this but the system should be robust enough to withstand whatever it was I did.

[Andrew]

Your image is fuzzy just like mine but I think it is because of the type of tiddler. I think mines because I'm missing something:

[Mark S.]

You seem to have a half dozen more buttons than in the pre-release. Did you add some of your own, and could that be causing the dislocation?

Mark

[Knut Franke]

On Monday, March 7, 2016 at 6:34:19 PM UTC+1, Jeremy Ruston wrote:

I’m pleased to say that TiddlyWiki is finally getting an extensible rich text editor toolbar in the core. There’s a preview you can try out here:

Neat!
 

I’m interested in feedback on how well it works on different browser/operating system combinations, but please feel free to post any thoughts or questions too,

Works on Firefox 44 (Linux), except for the issues mentioned in the pull request, and the fact that the items in the spacer button menu don't seem to have any effect (not sure what they're supposed to do). Some usability nitpicks:

I think pushing the inline markup buttons with no text selected should insert start/end markers (which they do) and then position the cursor in a suitable position for immediately entering bold/strikethrough/... text (instead of selecting the inserted markup). Same for ordered/unordered lists and headings when the cursor is on an empty line.

When the cursor is at the end of a line (with no selection), block markup buttons behave differently than when the cursor is anywhere else on the same line. This may be confusing.

If some text in the middle of a paragraph is selected, the block markup (code/quote/list/numbered list/headings) buttons fail to insert the empty leading line needed for correct rendering.

For excising text, I believe linking would be a better default than transclusion. Splitting up a tiddler that has grown too large is probably a more common use case than including a snippet somewhere else; though this may be my personal preference.

Anyway, a big thumbs-up on this; it substantially improves the already considerable discoverabilty-factor for new users. :)


Cheers,
Knut

[andrew harrison]

To show Jeremy how much I appreciate the coming toolbar, I creating a plugin to add a button to it. 

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/2a82ad0b-6347-4e15-9aa9-f7e84157e576%40googlegroups.com.

[Mat]

@Jeremy

Another valuable tool type would be a kind of fold/unfold, possibly using the revealwidget and similar to Erics old NestedSliders plugin (an absolute favourite of mine in TWC); I.e select a text portion and click a text editor tool to have the selection surrounded with the necessary reveal mechanism. The resulting view mode button and the content text could be of different kinds:

* region type fold/unfold like in VisualStudio, i.e equivalent to the ⊞ and ⊟ there (squared plus and squared minus characters).
* if label provided then something like [label >]
* inline reveals (example)
* popup reveals

Some(!) of these might even be suitable as an option in the Excision tool rather than as a separate tool.

IMO to hide/reveal parts in content is very powerful concept for text (hypertext?) - i.e for conveying a message with text in the most efficient way. It lets you design a text that turns to readers of different levels in a much(!) more elegant way than common hyperlinking does; instead of jumping away from the text for more in-depth, it lets you access depth in place. (One could even imagine a text where a reader fills in at what level he wants the text - "summary", "overview", "in-depth but with highlighted basic concepts"... - and this sets the depth for the reveals. Or the system stores depth level from previous use and uses this as default.)

Hide/reveal is IMO also generally underused in hypertext, probably because there is no standard html construct for it. In TW we do have the revealwidget but this is IMO much to complex to apply - compare it to the simplicity in adding a link, or a transclusion.


@Jeremy
I might have missed it before or there is a new tool to the right of the Redo button; it seems to be something to insert/control the vertical distance between two sections (great idea). I don't get it to work though (FF nor Chrome, win10) and the popup looks a bit rough with very airy squares stating a pixel number.

On the matter of including the Rich text editor in core; I think it should be in standard distro (as expected by newcomers!) but maybe now is a good time to introduce a more advanced edition without pretty stuff.

Thank you for all the wonderful stuff!

<:-)
<:-)

[Mat]

Ya know... I'm beginning to realize that a edit mode text toolbar could really be a general platform for manipulating edit mode content, something that we have not really had thus far.

For example the katex people could have their own set of buttons. Or when we put on the locomotive hats and want a railroad diagram. For the occasional user I'd think richtext tools should be superior to having to learn the notation. Actually - I strongly suspect that many who would really benefit from such special notations just don't bother with it because it is too cumbersome to learn the wikitext for it. I even suspect this is the case with the existing bitmap editing feature - so I just added an idea to the github thread elaborating on Jeremys note about later adding bitmap widget toolbars.

But overall, it'd be great if people can easily create toolbuttons to add to the new toolbar. Andrews contribution indicates that this might already be the case!!

<:-)

[Jeremy Ruston]

Thanks to everyone for the feedback - and particular congratulations to Andrew Harrison for the “reduce” button. I’ve answered comments from Mat, Knut and Stephen below.

I’ve uploaded a bunch of new changes to GitHub and to the preview:

* Improved bitmap editing functionality, including:

** selectable colours with a new reusable colour picker

** selectable painting width

** selectable opacity

** clear image to colour

** resize the image

* New button for switching the text editor between automatic resizing and a fixed height

https://github.com/Jermolene/TiddlyWiki5/pull/2315

http://rich-text-editor.tiddlyspot.com/

> edit mode text toolbar could really be a general platform for manipulating edit mode content, something that we have not really had thus far.

That is correct. The mechanism isn’t specific to wikitext. I plan to add suitable buttons to the Markdown plugin, for example, and as you suggest, the KaTeX and Railroad plugin could ship with it’s own toolbar buttons too.

> Another valuable tool type would be a kind of fold/unfold, possibly using the revealwidget and similar to Erics old NestedSlidersplugin (an absolute favourite of mine in TWC); I.e select a text portion and click a text editor tool to have the selection surrounded with the necessary reveal mechanism. The resulting view mode button and the content text could be of different kinds:

You could build that button based on the existing “bold” button.

> IMO to hide/reveal parts in content is very powerful concept for text (hypertext?) - i.e for conveying a message with text in the most efficient way. It lets you design a text that turns to readers of different levels in a much(!) more elegant way than common hyperlinking does; instead of jumping away from the text for more in-depth, it lets you access depth in place. (One could even imagine a text where a reader fills in at what level he wants the text - "summary", "overview", "in-depth but with highlighted basic concepts"... - and this sets the depth for the reveals. Or the system stores depth level from previous use and uses this as default.)

The concept of “stretchtext” in classical hypertext is pretty close to what you’re getting at:

https://en.wikipedia.org/wiki/StretchText

> Hide/reveal is IMO also generally underused in hypertext, probably because there is no standard html construct for it. In TW we do have the revealwidget but this is IMO much to complex to apply - compare it to the simplicity in adding a link, or a transclusion.

We have discussed before adding wikitext syntax for a hide/reveal pair, it’s an interesting idea.

> I might have missed it before or there is a new tool to the right of the Redo button; it seems to be something to insert/control the vertical distance between two sections (great idea). I don't get it to work though (FF nor Chrome, win10) and the popup looks a bit rough with very airy squares stating a pixel number.

It was actually the embryonic control for setting the text editor height. It’s fixed now.

> On the matter of including the Rich text editor in core; I think it should be in standard distro (as expected by newcomers!) but maybe now is a good time to introduce a more advanced edition without pretty stuff.

It would be quite surprising if the “advanced” edition had less stuff in it than the “standard” one! But I get what you mean.
<:-)

> I think pushing the inline markup buttons with no text selected should insert start/end markers (which they do) and then position the cursor in a suitable position for immediately entering bold/strikethrough/... text (instead of selecting the inserted markup). Same for ordered/unordered lists and headings when the cursor is on an empty line.

I agree, and plan to do just that.

> When the cursor is at the end of a line (with no selection), block markup buttons behave differently than when the cursor is anywhere else on the same line. This may be confusing.

> If some text in the middle of a paragraph is selected, the block markup (code/quote/list/numbered list/headings) buttons fail to insert the empty leading line needed for correct rendering.

Thanks, I’ll look at both those..

> For excising text, I believe linking would be a better default than transclusion. Splitting up a tiddler that has grown too large is probably a more common use case than including a snippet somewhere else; though this may be my personal preference.

Makes sense, I’ll change the default and let’s see how others feel.

> Anyway, a big thumbs-up on this; it substantially improves the already considerable discoverabilty-factor for new users. :)

Many thanks!

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/3d869e10-ca71-4260-89d8-c4e0cf9b2ee3%40googlegroups.com.

[Stephen Kimmel]

I'm obviously missing something but I can't make any of the new icons appear on the editor toolbar. They, and indeed everything besides H4, H5 and H6, appear to be selected on the Control Panel Text Editor Toolbar section, but nothing I've tried makes them appear.

What am I missing?

[Jeremy Ruston]

It could be that you're missing a "condition" field, which holds a filter indicating when the button should be displayed. Have a look at the built-in buttons,

Best wishes

Jeremy

--

Jeremy Ruston

jer...@jermolene.com

http://jermolene.com

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/b213657b-3a90-4404-a464-969283e378d7%40googlegroups.com.

[Stephen Kimmel]

I caught that one and was able to make all my new buttons re-appear.

If you go to http://rich-text-editor.tiddlyspot.com/ and open the TiddlyWiki Pre-release tiddler, you'll see the basic icons but not the new ones. Go to the Control Panel, Text Editor Toolbar you'll see that Paint Colour, Opacity, Line Width, etc, are all checked. If you go to $:/core/ui/TextEditorToolbar/paint you'll see that is has a condition field which, as close as I can tell, is identical to the one for $:/core/ui/TextEditorToolbar/bold.

I'm missing something.

Cheers

[Stephen Kimmel]

Andrew,

Does your reduce plugin also end up creating words that a search would find that weren't actually in the original text? Your demo has "some text one one three three one two one 12345 12345" with the resulting string becoming "twothreetextsomeone12345". I see the words "texts" and "someone" in there. Though it would lessen the impact of your function, leaving in some spaces as separators would prevent false positives when the result is searched.

Stephen

[infurnoape]

Good point. But that could be alot of spaces.

Happy Connecting. Sent from my Sprint Samsung Galaxy S® 5

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/0105db29-9cc5-466c-9378-d9a2b5ab57db%40googlegroups.com.

[Jeremy Ruston]

Hi Stephen

On 15 Mar 2016, at 11:55, 'Stephen Kimmel' via TiddlyWiki <tiddl...@googlegroups.com> wrote:

If you go to http://rich-text-editor.tiddlyspot.com/ and open the TiddlyWiki Pre-release tiddler, you'll see the basic icons but not the new ones. Go to the Control Panel, Text Editor Toolbar you'll see that Paint Colour, Opacity, Line Width, etc, are all checked. If you go to $:/core/ui/TextEditorToolbar/paint you'll see that is has a condition field which, as close as I can tell, is identical to the one for $:/core/ui/TextEditorToolbar/bold. 

Did you mean to include a different URL?

Best wishes

Jeremy

[Stephen Kimmel]

I don't think so. I've attached screen captures to illustrate.

Is this, perhaps, a Firefox issue?

[Alex Hough]

Jeremy,

Here's an idea to help with coding in grounded theory. A post a while ago [1] discusses the use of TW in grounded theory research. The method basically involves "coding"  (or tagging) hypertext with categories. [2]

I have cut and pasted a paragraph into my TW. I've added my own line breaks and spaces in edit mode. The paragraph contains a list of tags which I want to use to catagorise and mark up a text.

Here is the paragraph

Engagement is a category of user experience characterized by attributes of 

challenge, 

positive affect, 

endurability, 

aesthetic and sensory appeal, 

attention, 

feedback, 

variety/novelty, 

interactivity, and 

perceived user control.

I would like to convert the list into this

<<tag challenge>>

<<positive affect>>

<<tag endurability>>

<<tag aesthetic>>

etc etc

I could see a text editor option where you select the list, press a button and the selected text has "<<tag" and ">>" added as a prefix and suffix

best wishes

Alex

[1] https://groups.google.com/d/msg/tiddlywiki/BcH7tz2BFj8/YFJ-eHsedZ8J

[2] https://en.wikipedia.org/wiki/Grounded_theory#Philosophical_underpinnings_of_grounded_theory

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/1d37f2bc-0363-44cb-9c16-a36320b43e47%40googlegroups.com.

[Mark S.]

I'm trying to figure out which new icons you are referring to. The paint icons only show up if your tiddler is an image type. Is that what you mean, or are some other even newer icons?

Have fun,
Mark

[Stephen Kimmel]

Then that's what I missed. It does neatly address the issue of different toolbars for different tiddler types.

[Stephen Kimmel]

While I find the bitmap editor amusing, I don't see myself using it very much beyond possibly annotating pictures. Rather than being part of the standard core, I think that functionality would be better as a plugin so the folks who would use these capabilities can have them while others can skip them.

However in the context of Tiddlywiki, I think I would find a graphics editor that handled SVGs could be very useful. I know SVGs are a completely different beast than most other graphic forms so using the current functions probably wouldn't help much.

Sort of along those lines, I would be interested in knowing what SVG editors people are using as I haven't found one that a) I like very much and b) produces an SVG in a form as simple as the ones Jeremy uses for his buttons.

[Ste Wilson]

Ive tried quite a few and am currently settled on Method Draw http://editor.method.ac/ as my editor of choice.
Simple but recognises ortho lines with a press of the shift key and allows easy editing of start and end points.  Perfect for the simple line diagrams i need.

Stephen

http://stephenteacher.tiddlyspot.com/#

[Mat]

Stephen Kimmel wrote:

Sort of along those lines, I would be interested in knowing what SVG editors people are using

Found this great article: The ultimate guide to svg.
My personal attempts at vector graphics always end in failure.

<:-)

[Jeremy Ruston]

I’m still working away on the text editor toolbar. I’ve uploaded a new preview that includes keyboard shortcuts for most toolbar text editor operations; the shortcut is shown in the tooltip.

Try the preview out here:

http://rich-text-editor.tiddlyspot.com/

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7f215b57-e32f-4486-9ae8-9f3572bb8850%40googlegroups.com.

[Jon]

Hi Jeremy,

Looks fabulous.

Thanks
Jon

[Knut Franke]

On Monday, March 21, 2016 at 4:02:11 PM UTC+1, Jeremy Ruston wrote:

I’m still working away on the text editor toolbar. I’ve uploaded a new preview that includes keyboard shortcuts for most toolbar text editor operations; the shortcut is shown in the tooltip.

Just a quick heads-up that these two (very minor) issues are still present:

1. If some text in the middle of a paragraph is selected, the block markup (code/quote/list/numbered list/headings) buttons fail to insert the empty leading line needed for correct rendering

1. For excising text, I believe linking would be a better default than transclusion. (unless you've changed your mind about this)
   

Otherwise, works very smoothly on Firefox.

Bad news: Most buttons don't work on Microsoft Edge (somewhat ironically, undo/redo do work). Looks like a problem with scripting changes to the editor widget; no error messages on the JS console. Not an issue for me personally, I just happened to test with Firefox on Windows 10 so I gave it a quick shot with Edge as well; just letting you know.


Cheers,
Knut

[Jeremy Ruston]

Hi Knut

Just a quick heads-up that these two (very minor) issues are still present:

1. If some text in the middle of a paragraph is selected, the block markup (code/quote/list/numbered list/headings) buttons fail to insert the empty leading line needed for correct rendering

mono-block and quote are easy, and I’ve made the necessary changes here:

https://github.com/Jermolene/TiddlyWiki5/pull/2315/commits/3264499764d425a6949c9787fa316ee505b68458

The others are harder. The trouble is that there are cases where one wouldn’t want the extra line inserted, particularly if the preceding line were another heading or list item. I’m not sure the best way to address it; anyhow, the operation is implemented here:

https://github.com/Jermolene/TiddlyWiki5/blob/text-editor/core/modules/editor-operations/text/prefix-lines.js

2. For excising text, I believe linking would be a better default than transclusion. (unless you've changed your mind about this)

I am thinking of sticking with transclusion as the default, not so much because it is the most useful as that it is the most vivid first experience.

Bad news: Most buttons don't work on Microsoft Edge (somewhat ironically, undo/redo do work). Looks like a problem with scripting changes to the editor widget; no error messages on the JS console. Not an issue for me personally, I just happened to test with Firefox on Windows 10 so I gave it a quick shot with Edge as well; just letting you know.

I just downloaded a VM of Windows 10 with Edge for testing, and interestingly, it seems that the toolbar buttons do work (including the shortcuts), but the textarea updating is buggy - try using the toolbar with the preview pane open to see what I mean. I’ll investigate further; perhaps there’s some magic that will trigger the textarea to redisplay itself correctly.

Many thanks,

Jeremy.

Cheers,
Knut

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/29b875b0-e8b0-4935-ae36-20b7e7dd54e1%40googlegroups.com.

[Tryign It]

The formating bar is a great addition - especially the Excise button!
I think it would also be a good idea to include a tag bar below the 'tag with current tiddler' to the excise button.

Also - is there a way to modify the current Headings (change the colors, size, etc)? Add more heading presets (H7, H8, H9, H10, etc.)?

A feature that is tremendously useful in any text editing software is the ability to 'fold' texts and also to move the folded text up/down. LibreOffiice for example has a feature of Ctrl+(arrow keys) - and you can move a bullet up or down, indent it, etc - very easily.

While I dont think that is within the scope of this release, would you ever consider it in near future?

Another great addition to the editor would be auto detection of all HEADINGS, and creating a mini hierarchal outline of them on the side. This help the user navigate the tiddler easily when editing.

I also do not think that is within the scope of this particular release - but maybe a consideration for future release? For reference, LibreOffice also has such a feature. Tremendously useful

Tables are a extreme hassle in any markdown/wiki language -
so currently I think transcluding an html tiddler with the table into the main tiddler - edited via an external editor is the best option. But I can not find such a solution to the text folding/moving...

[Alain Dutech]

Hello,

while I'm not a great fan of toolbars (I usually unview them), I must say that Jeremy did a great and nice work. And this will greatly enhance people usablility of TW5.

Nevertheless, I even tried to add "my" completion popup window in this new text-iframe widget. (see http://snowgoon88.github.io/TW5-extendedit). In the "module" branch I modified the module so that it can be easily included to any textarea and I tried to add it to the text-iframe. But this poses problem within the iframe element...

1) if I create my "popup" div element alongside the this.iframeTextArea of the widget, the CSS rules are messed up because of the "new" document of the iframe.
2) if I create my "popup" div element outside of the iframe, as a sibling of the this.dummyTextArea  of the widget, the popup looks fine but then the computation of the position of the popup is rather hard to compute (up to now).

Well... Anyone knows how I could somehow transfer the CSS definition of my popup elements so that they apply and are reconised inside the "#document" of the iframe ?? That would help me a lot.
Is this the purpose of the following lines in the widget ? No other way around ?

        // Copy the styles from the dummy textarea
	var textAreaStyles = window.getComputedStyle(this.dummyTextArea,null),
		styleText = [];
	$tw.utils.each(textAreaStyles,function(name,index) {
		styleText.push(name + ": " + textAreaStyles[name] + ";");
	});
	this.iframeTextArea.style.cssText = styleText.join("");
	this.iframeTextArea.style.display = "block";
	this.iframeTextArea.style.width = "100%";

Again, "bravo" and nice job.
Alain
PS : my plan would be to be able to also "stamp" by using a slight deviation of the completion popup...

[Jeremy Ruston]

Hi Tryign It

The Formating Bar is a great addition - especially the Excise button!

Thanks, glad you’re enjoying it.

I think it would also be a good idea to include a tag bar below the 'tag with current tiddler' to the excise button.

That’s an interesting idea, and would perhaps make a good experiment for someone learning how these buttons work.

Also - is there a way to modify the current Headings (change the colors, size, etc)? Add more heading presets (H7, H8, H9, H10, etc.)?

To change the colours/size of the headings you’d need to change the theme or customise the CSS. HTML tags only go up to H6, although nowadays you could use custom elements and custom CSS to create additional headings if you needed to.

A feature that is tremendously useful in any text editing software is the ability to 'fold' texts and also to move the folded text up/down.

The text editor in TW5 is still a basic HTML textarea, which doesn’t support things like folding. However, it is supported by CodeMirror, an open source library that provides an enhanced editor. CodeMirror is integrated with TW5 as a plugin, but I have yet to update the integration to work with the new toolbar buttons. Anyhow, you could certainly experiment with code folding once all of that was done.

LibreOffiice for example has a feature of Ctrl+(arrow keys) - and you can move a bullet up or down, indent it, etc - very easily.

That could be done via a plugin, but I’d be cautious about overriding the underlying platform cursor handling.

While I dont think that is within the scope of this release, would you ever consider it in near future?

I’d certainly like to add features for easier manipulation of lists.

Another great addition to the editor would be auto detection of all HEADINGS, and creating a mini hierarchal outline of them on the side. This help the user navigate the tiddler easily when editing.

I also do not think that is within the scope of this particular release - but maybe a consideration for future release? For reference, LibreOffice also has such a feature. Tremendously useful

Again, that’s probably CodeMirror territory.

Tables are a extreme hassle in any markdown/wiki language -

so currently I think transcluding an html tiddler with the table into the main tiddler - edited via an external editor is the best option. But I can not find such a solution to the text folding/moving…

One could imagine an “edit table” toolbar button that detected being within a table, and then displayed the table content in a grid of separate text boxes, like a spreadsheet, that one could tab between.

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/cc2988f8-a5f9-4d76-8c8d-ddff40930b6e%40googlegroups.com.

[Jeremy Ruston]

Hi Alain

while I'm not a great fan of toolbars (I usually unview them), I must say that Jeremy did a great and nice work. And this will greatly enhance people usablility of TW5.

Thanks!

Nevertheless, I even tried to add "my" completion popup window in this new text-iframe widget. (see http://snowgoon88.github.io/TW5-extendedit). In the "module" branch I modified the module so that it can be easily included to any textarea and I tried to add it to the text-iframe. But this poses problem within the iframe element...

1) if I create my "popup" div element alongside the this.iframeTextArea of the widget, the CSS rules are messed up because of the "new" document of the iframe.
2) if I create my "popup" div element outside of the iframe, as a sibling of the this.dummyTextArea  of the widget, the popup looks fine but then the computation of the position of the popup is rather hard to compute (up to now).

I’d recommend option (2), mainly because I intend to refactor things so that the edit-text widget optionally wraps the textarea in an iframe, so your code will need to cope with both cases.

Well... Anyone knows how I could somehow transfer the CSS definition of my popup elements so that they apply and are reconised inside the "#document" of the iframe ?? That would help me a lot.
Is this the purpose of the following lines in the widget ? No other way around ?

Sadly, yes, this is the only working approach beyond replicating all the style definitions within the iframe. It’s not perfect though; for example, hover effects won’t get transferred. Anyhow, we maybe should refactor it into the dom utility module.

Again, "bravo" and nice job.

Thanks, and likewise with the autocompletion functionality, it’s great to have, and I hope I can help get it working well with the new toolbar stuff.

Best wishes

Jeremy

Alain
PS : my plan would be to be able to also "stamp" by using a slight deviation of the completion popup...

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7c9db70f-65ca-44f3-b324-d9065ca3e749%40googlegroups.com.

[Knut Franke]

On Monday, March 21, 2016 at 10:28:49 PM UTC+1, Jeremy Ruston wrote:

The others are harder. The trouble is that there are cases where one wouldn’t want the extra line inserted, particularly if the preceding line were another heading or list item. I’m not sure the best way to address it; anyhow, the operation is implemented here:

https://github.com/Jermolene/TiddlyWiki5/blob/text-editor/core/modules/editor-operations/text/prefix-lines.js

I see. At the moment, I don't have a good idea for how to solve this either.

I just downloaded a VM of Windows 10 with Edge for testing, and interestingly, it seems that the toolbar buttons do work (including the shortcuts), but the textarea updating is buggy - try using the toolbar with the preview pane open to see what I mean. I’ll investigate further; perhaps there’s some magic that will trigger the textarea to redisplay itself correctly.

Ah, okay. Looks like another tricky issue. ;-)


Cheers,
Knut

[Alain Dutech]

About completion : Thank you for taking the time to answer me. I'll play with both cases and see what comes out of the "stable" 5.12 release to, then, finalize my approach.

Alain

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/6yUkcDzp7ko/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CEC08DA3-47F7-46FC-9254-AF0638BBF36D%40gmail.com.

[Jon]

Hi Jeremy,

Noticed that a couple of the buttons have a different behaviour to the rest.

Pressing each of the buttons a 2nd time removes the formatting apart from those for monospaced and quotes.

Regards
Jon