[tw] [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.' via TiddlyWiki]

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

Post by Jeremy Ruston
I’m pleased to say that TiddlyWiki is finally getting an extensible rich
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
* 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
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.

[Eric Shulman]

Post by 'Mark S.' via TiddlyWiki
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

['Mark S.' via TiddlyWiki]

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

Post by Eric Shulman

Post by 'Mark S.' via TiddlyWiki
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
[[this is what the reader sees|TiddlerID]]
or, alternatively, you could use a "caption link" macro to assemble a link
\define clink(tid)
<$link to="""$tid$"""><$view field="""$tid$!!caption"""><$view field=
"""$tid$!!title"""/></$view></$link>
\end
<<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

[Eric Shulman]

Post by 'Mark S.' via TiddlyWiki
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"

Post by 'Mark S.' via TiddlyWiki
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

Post by 'Mark S.' via TiddlyWiki
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

[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

Post by Jeremy Ruston
I’m pleased to say that TiddlyWiki is finally getting an extensible rich
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
* 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
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.

[Jeremy Ruston]

Hi Sylvain

Post by Sylvain Naudin
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.

Post by Jeremy Ruston
Hi Sylvain

Post by Sylvain Naudin
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
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
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.' via TiddlyWiki]

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

Post by Jeremy Ruston
I’m pleased to say that TiddlyWiki is finally getting an extensible rich
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
* 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
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.

[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
<https://groups.google.com/forum/#%21topic/tiddlywiki/HQD6c-bf7ls>).

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 <http://quicktid.tiddlyspot.com/> 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)]

Post by Jeremy Ruston
* 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

Post by Jeremy Ruston
I’m pleased to say that TiddlyWiki is finally getting an extensible rich
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
* 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
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.

[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 have just made Tiddlywiki far more accessible to the masses! This is going to be awesome. Thanks for making such a great tool.
Andy
http://rich-text-editor.tiddlyspot.com/ <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.
* 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
https://github.com/Jermolene/TiddlyWiki5/pull/2315 <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.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
Visit this group at https://groups.google.com/group/tiddlywiki <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 <https://groups.google.com/d/msgid/tiddlywiki/5710db60-33f8-4b9e-8292-f1c3e3b4cde8%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Jeremy Ruston]

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

Best wishes

Jeremy.

Post by Jeremy Ruston
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
http://rich-text-editor.tiddlyspot.com/ <http://rich-text-editor.tiddlyspot.com/>
https://github.com/Jermolene/TiddlyWiki5/pull/2315 <https://github.com/Jermolene/TiddlyWiki5/pull/2315>
Best wishes
Jeremy.

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
http://rich-text-editor.tiddlyspot.com/ <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.
* 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
https://github.com/Jermolene/TiddlyWiki5/pull/2315 <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.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
Visit this group at https://groups.google.com/group/tiddlywiki <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 <https://groups.google.com/d/msgid/tiddlywiki/5710db60-33f8-4b9e-8292-f1c3e3b4cde8%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Mat]

Post by Jeremy Ruston
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).

Regards
Jon

Post by Mat

Post by Jeremy Ruston
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.
<:-)

['Mark S.' via TiddlyWiki]

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

[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

Post by 'Mark S.' via TiddlyWiki
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;*).

['Mark S.' via TiddlyWiki]

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)

Post by 'Mark S.' via TiddlyWiki
The problem with a toolbar connected with the tiddler is that the tools

Post by 'Mark S.' via TiddlyWiki
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 <http://caniuse.com/#feat=css-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.

<:-)

[Scott Simmons (Secret-HQ)]

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

note caniuse sticky <http://caniuse.com/#feat=css-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 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.

[tony]

Post by Jeremy Ruston
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

Post by Jeremy Ruston
I’m pleased to say that TiddlyWiki is finally getting an extensible rich
http://rich-text-editor.tiddlyspot.com/

[Scott Simmons (Secret-HQ)]

Post by tony
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.
Visit this group at https://groups.google.com/group/tiddlywiki <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 <https://groups.google.com/d/msgid/tiddlywiki/5def3a53-1eee-4b6f-b8ec-f236bf152a86%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[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!

Post by Jeremy Ruston
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
<http://twaddle.tiddlyspot.com/#Article%20Storyview> 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]

Post by Jeremy Ruston
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

Post by Jeremy Ruston
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' via TiddlyWiki]

<Loading Image...>
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:

<Loading Image...>

['Mark S.' via TiddlyWiki]

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

Post by 'Stephen Kimmel' via TiddlyWiki
<https://lh3.googleusercontent.com/-TOx7OwLchgo/VuOTgTGmsEI/AAAAAAAAA2w/6cOvaBma5a8gh0YZ4VmJE_clNoIQn_YIQ/s1600/Screenshot%2B2016-03-11%2B21.54.19.png>
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.

[Knut Franke]

Post by Jeremy Ruston
I’m pleased to say that TiddlyWiki is finally getting an extensible rich

Neat!

Post by Jeremy Ruston
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
<http://reduce.tiddlyspot.com/> to add a button to it.

Post by Knut Franke

Post by Jeremy Ruston
I’m pleased to say that TiddlyWiki is finally getting an extensible rich

Neat!

Post by Jeremy Ruston
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
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
--
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
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
<https://groups.google.com/d/msgid/tiddlywiki/2a82ad0b-6347-4e15-9aa9-f7e84157e576%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Mat]

@Jeremy

Another valuable tool type would be a kind of fold/unfold, possibly using
the revealwidget and similar to Erics old NestedSliders
<http://tiddlytools.com/#NestedSlidersPluginInfo> 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
<http://twaddle.tiddlyspot.com/#Subtle%20buttons%20and%20inline%20revealed%20content>
)
* 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 <http://tiddlywiki.com/plugins/tiddlywiki/katex/>people
could have their own set of buttons. Or when we put on the locomotive hats
and want a railroad <http://tiddlywiki.com/#Railroad%20Diagrams>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
<https://github.com/Jermolene/TiddlyWiki5/pull/2315>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.
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

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 <http://tiddlywiki.com/plugins/tiddlywiki/katex/>people could have their own set of buttons. Or when we put on the locomotive hats and want a railroad <http://tiddlywiki.com/#Railroad%20Diagrams>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 <https://github.com/Jermolene/TiddlyWiki5/pull/2315>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!!
<:-)
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
Visit this group at https://groups.google.com/group/tiddlywiki <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 <https://groups.google.com/d/msgid/tiddlywiki/3d869e10-ca71-4260-89d8-c4e0cf9b2ee3%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

['Stephen Kimmel' via TiddlyWiki]

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?

Post by 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.
** 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
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
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
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 <http://tiddlywiki.com/plugins/tiddlywiki/katex/>people
could have their own set of buttons. Or when we put on the locomotive hats
and want a railroad <http://tiddlywiki.com/#Railroad%20Diagrams>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
<https://github.com/Jermolene/TiddlyWiki5/pull/2315>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!!
<:-)
--
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
<javascript:>.
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
<https://groups.google.com/d/msgid/tiddlywiki/3d869e10-ca71-4260-89d8-c4e0cf9b2ee3%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[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
***@jermolene.com
http://jermolene.com

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?

Post by 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.
** 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.
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.)

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

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!!
<:-)
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
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.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
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/b213657b-3a90-4404-a464-969283e378d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

['Stephen Kimmel' via TiddlyWiki]

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

Post by 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
http://jermolene.com
On 15 Mar 2016, at 02:41, 'Stephen Kimmel' via TiddlyWiki <
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]

Hi Stephen

If you go to http://rich-text-editor.tiddlyspot.com/ <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' via TiddlyWiki]

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

Is this, perhaps, a Firefox issue?

Post by Jeremy Ruston
Hi Stephen
On 15 Mar 2016, at 11:55, 'Stephen Kimmel' via TiddlyWiki <
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

[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





On 15 March 2016 at 15:35, 'Stephen Kimmel' via TiddlyWiki <

Post by 'Stephen Kimmel' via TiddlyWiki
I don't think so. I've attached screen captures to illustrate.
Is this, perhaps, a Firefox issue?

Post by Jeremy Ruston
Hi Stephen
On 15 Mar 2016, at 11:55, 'Stephen Kimmel' via TiddlyWiki <
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

--
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
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
<https://groups.google.com/d/msgid/tiddlywiki/1d37f2bc-0363-44cb-9c16-a36320b43e47%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

['Mark S.' via TiddlyWiki]

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

Post by 'Stephen Kimmel' via TiddlyWiki
I don't think so. I've attached screen captures to illustrate.
Is this, perhaps, a Firefox issue?

Post by Jeremy Ruston
Hi Stephen
On 15 Mar 2016, at 11:55, 'Stephen Kimmel' via TiddlyWiki <
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' via TiddlyWiki]

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

Post by 'Mark S.' via TiddlyWiki
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

Post by 'Stephen Kimmel' via TiddlyWiki
I don't think so. I've attached screen captures to illustrate.
Is this, perhaps, a Firefox issue?

Post by Jeremy Ruston
Hi Stephen
On 15 Mar 2016, at 11:55, 'Stephen Kimmel' via TiddlyWiki <
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' via TiddlyWiki]

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/#

Post by 'Stephen Kimmel' via TiddlyWiki
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.

[Mat]

Post by 'Stephen Kimmel' via TiddlyWiki
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
<http://www.webdesignerdepot.com/2015/01/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.

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 <http://www.webdesignerdepot.com/2015/01/the-ultimate-guide-to-svg/>.
My personal attempts at vector graphics always end in failure.
<:-)
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
Visit this group at https://groups.google.com/group/tiddlywiki <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 <https://groups.google.com/d/msgid/tiddlywiki/7f215b57-e32f-4486-9ae8-9f3572bb8850%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Jon]

Hi Jeremy,

Looks fabulous.

Thanks
Jon

Post by 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.
http://rich-text-editor.tiddlyspot.com/
Best wishes
Jeremy.

Post by 'Stephen Kimmel' via TiddlyWiki
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
<http://www.webdesignerdepot.com/2015/01/the-ultimate-guide-to-svg/>.
My personal attempts at vector graphics always end in failure.
<:-)
--
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
<javascript:>.
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
<https://groups.google.com/d/msgid/tiddlywiki/7f215b57-e32f-4486-9ae8-9f3572bb8850%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Knut Franke]

Post by 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.

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
2. 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

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

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.
Visit this group at https://groups.google.com/group/tiddlywiki <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 <https://groups.google.com/d/msgid/tiddlywiki/29b875b0-e8b0-4935-ae36-20b7e7dd54e1%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Knut Franke]

Post by Jeremy Ruston
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;
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

Post by Jeremy Ruston
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

['Stephen Kimmel' via TiddlyWiki]

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

Post by andrew harrison
To show Jeremy how much I appreciate the coming toolbar, I creating a
plugin <http://reduce.tiddlyspot.com/> to add a button to it.

[infurnoape]

Good point. But that could be alot of spaces.


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

-------- Original message --------
From: 'Stephen Kimmel' via TiddlyWiki <***@googlegroups.com>
Date: 03/15/2016 5:43 AM (GMT-07:00)
To: TiddlyWiki <***@googlegroups.com>
Subject: Re: [tw] Re: [tw5] Introducing new text editor toolbar

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

On Saturday, March 12, 2016 at 11:40:10 PM UTC-6, Andrew wrote: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 ***@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.

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

[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 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 <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.
Visit this group at https://groups.google.com/group/tiddlywiki <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 <https://groups.google.com/d/msgid/tiddlywiki/7c9db70f-65ca-44f3-b324-d9065ca3e749%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[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

Post by 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
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
<https://groups.google.com/d/msgid/tiddlywiki/7c9db70f-65ca-44f3-b324-d9065ca3e749%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
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
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
<https://groups.google.com/d/msgid/tiddlywiki/CEC08DA3-47F7-46FC-9254-AF0638BBF36D%40gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[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

Post by 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

Post by 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
<javascript:>.
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
<https://groups.google.com/d/msgid/tiddlywiki/7c9db70f-65ca-44f3-b324-d9065ca3e749%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
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
<javascript:>.
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
<https://groups.google.com/d/msgid/tiddlywiki/CEC08DA3-47F7-46FC-9254-AF0638BBF36D%40gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[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.
Visit this group at https://groups.google.com/group/tiddlywiki <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 <https://groups.google.com/d/msgid/tiddlywiki/cc2988f8-a5f9-4d76-8c8d-ddff40930b6e%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Paul Boughner]

Whats the process for adding a button to apply a highlight?

I am currently using the stamp button to insert "@@ hl.ToDo" at the head,
and "@@" to close it.

@@ hl.ToDo -text- @@

I use this to tag things in journals and then use a list to search for that
particular highlight. Which automagically gives me lists of ToDo, research,
add to quiz, etc.

I would like to add a highlight button like the stamp button to choose the
highlight.

Post by Jeremy Ruston
I’m pleased to say that TiddlyWiki is finally getting an extensible rich
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
* 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
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.