This is a follow-up to the prior "Storing pikchr src in the SVG metadata" thread.

What if, as an alternative to storing the source text inside the SVG as CDATA, we instead modify the pikchr_to_html() routine in Fossil so that it generates HTML according to the following template:

   <div class="pikchr">
      <div class="pikchr-svg"><svg> generated SVG here </svg></div>
      <pre class="pikchr-src" style="display:none"> pikchr source code </pre>
   </div>

Then we add a small amount of javascript to detect double-clicks on "pikchr-svg" elements and responds by setting display:none for the clicked-on element and display:block for the nearby "pikchr-src" element. And likewise, double-clicking on "pikchr-src" flips the display back over to use pikchr-svg.

Advantages:

1. Less javascript required. Perhaps much less.

2. No flags to the pikchr() interface needed. Pikchr can be simplified.

3. No icons appear that obscure part of the diagram or source text, and which then have to be clicked again to flip the display or to dismiss the icon.

4. The source text is just text, not something inside a edit box with scrollbars and a resize icon that must be dragged to see the whole text.

5. When the source text is displayed, it appears the same as if it were rendered on a system that does not support Pikchr, or if the "pikchr" language id had been omitted from the fenced code block.

Disadvantages:

1. There is no copy button. But, you can always just scrape the text that you want to copy, so I don't see this as a big problem.

we instead modify the pikchr_to_html() routine in Fossil so that it generates HTML according to the following template:

That... that... hmm... i can't find any holes in it except for the one you point out: no copy button. The one minor disadvantage of that would be the inability to copy the raw SVG to the clipboard. The intention of that particular feature was to allow prototyping in pik and then copying to inkscape for refinement, but whether or not that really even rates as high as a nice-to-have is arguable. It was added because it was low-lying fruit and pikchrshow already had the code for it.

i will make this change later on today and, if there are no glaring unforeseen problem (can't imagine what they might be), then check that in. The pikchr command will need to be restructured because its current combinations of output/flags won't work as-is with this, but there are no backwards compatibility issues with that yet.

Disadvantages:

There's a hole there which i fought mightily with yesterday and haven't yet found a solution for: the current div's max-width is a good thing, IMO, but it breaks both the current JS-heavy approach and the new proposal, in that the max-width also applies to the source code view in both cases, which will keep a browser from permitting a resize on the source code. That's not important for most piks, but it very much is for small ones:

# This is an example of a pikchr where the source code
# view needs to be far larger than the SVG does.
# Mid- and large-sized piks aren't affected by this so much,
# but small pics are.
circle "see src"

The current JS impl works around that by unsetting the max-width when the source code is in view, and that works fine for left-aligned and indented picks, but it un-centers (temporarily left-aligns) centered piks because that max-width combined with "margin: auto" is how the centering is implemented. Unsetting the max width allows the user to resize the source code, but it also shifts centered piks to the left so long as the sources are in view.

So long as we have the max-width, we will need to unset it when the source view in enabled, which means that much of JS which we could ostensibly drop with the new HTML template still has to be in place for that. Because of that, other than the removal of the copy button (a total of 8 liberally-spaced lines which encapsulate a single function call), we won't save any JS with the new approach.

In any case, i'll reimplement it this way because i like the idea and want to see how it turns out, but we won't save much by doing it this way.

In any case, i'll reimplement it this way because i like the idea and want to see how it turns out, but we won't save much by doing it this way.

Eliminating the button to swap views introduces a new usability problem: tapping on the element to select the source code (with the intent of copying it) will flip it over, switching back to SVG view. It becomes impossible to select/copy the source code this way.

Suggestions on how to solve that are welcomed, noting that we cannot use double-click or long-press to switch views because those approaches introduce their own conflicts with default browser behaviours.

My current suggestion is to keep the mode-swap button, but we can eliminate the copy button (seems a bit superfluous and noisy). We can use the new output structure, though - that doesnt' introduce any inherent problems, and i've already consolidate the output impl for markdown/wiki/pikchrshow to use that form.

As to whether the source code element should be a TEXTAREA or PRE: a TEXTAREA has the advantage of including a "select-all" function built in, whereas a selecting a PRE for copying is much more effort for the user (in particular on mobile).

Use a double-click, not a single-click, to toggle between SVG and source text. (I'm assuming that's possible to do with JS - I don't really know.)

Use a double-click, not a single-click, to toggle between SVG and source text. (I'm assuming that's possible to do with JS - I don't really know.)

It is, but it screws up text selection on desktops and page-zoom on mobile. Many people use double-click to select text on pages (i got yelled at for the forum expansion mode, which initially used double-click to expand/collapse) and on mobile double-tap normally zooms in or out.

Double-click and long-press are features we can't use without interfering with default browser-side behaviours.

What if ...

Your suggestions are mostly implemented in:

https://fossil-scm.org/fossil/info/4f697731832a44b4

The exceptions, caveats, and notes:

• The newly-embedded PRE element is a TEXTAREA because it's much easier to select-all/copy from a textarea.
• The mode-switch button in the top/left is retained for the time because because there would seem to be no other approach which allows us to both freely switch between SVG/source views and allow the source code to be copied (the copy button is now gone, btw). If we switch views on click, selecting/copying the source code becomes impossible.
• The rendering impl was consolidated for wiki/markdown/pikchrshow/pikchr command, on the basis of the impl from pikchrshow.c, and the new alignment options were incorporated there.

pikchrshow no longer shows the mode-switch buttons because it's truly superfluous there (it was initially added there just for development/testing). The wiki and forum retain it, though.

Suggestions for improvement are welcomed, especially if they can eliminate the mode-swap button and yet make the source view copyable.

One option currently comes to mind: tapping on an SVG flips to source view, and the top/left button is only active in source view (and can still be toggled on/off in case it obscures anything). Thus tapping on an image immediately flips to source view but to flip back you'd need to tap the button which appears in that mode only. :-?

One option currently comes to mind: tapping on an SVG flips to source view, and the top/left button is only active in source view (and can still be toggled on/off in case it obscures anything). Thus tapping on an image immediately flips to source view but to flip back you'd need to tap the button which appears in that mode only. :-?

That was implemented in the follow-up commit:

Tapping on an SVG switches to source mode and shows the yellow button. That button can be toggled on and off by tapping within the source view, and toggled off by tapping anywhere else in the page body. Tapping the yellow button flips to SVG view and hides the button.

That seems like a good compromise to me, but suggestions are welcomed. With this approach, re-adding the copy button (which would only appear in source mode) is tempting.

That seems like a good compromise to me, but suggestions are welcomed. With this approach, re-adding the copy button (which would only appear in source mode) is tempting.

i've tentatively done so: the copy button now appears in source mode again, but after it copies the code it flips back to SVG mode:

https://fossil-scm.org/fossil/info/d369f4f389c6a447

We can certainly get rid of the copy button if it's undesired, but i don't currently see a way around having the other button if we want the source to be selectable/copyable.

Sorry, but I don't see what change. Could you please explain what should happen on the pikchrshow page now?

https://fossil-scm.org/fossil/pikchrshow

The fossil 3c786c6fc3603d82 checkin is more of what I had in mind. I have put this on the server for evaluation. I think it probably needs some CSS tweaks to make the source-code view look exactly right (for example to do away with the dashed border) but other than that, it seems to be what I'm looking for.

Please provide feedback.

Edit: Issue with safe_html() fixed by the follow-on check-in.

Modulo CSS refinement, the current trunk is doing what I want it to do. It works very well to double-click on diagrams in (for example) the user manual for Pikchr.

I worry, however, that source code display might surprise people who accidentally double-click on one of the diagrams in a document that is not about Pikchr. For example in the Fossil branching document. I wonder if the ability to double-click to toggle between SVG and source code should be an option that is disabled by default and is only enabled by an extra argument on the fenced code. Just as we now have "center" and "indent", perhaps an additional argument of "toggle-view". And without that argument, the display is permanently fixed on SVG and the source text is not even included in the generated HTML.

Ah, now I understand the change. I don't see a copy button when viewing the pikchr src. Is that intended?

An alternative to "toggle-view" could be a comment "double-click to see the graphic. For more info on these graphics, visit pikchr.org", etc.

Ah, now I understand the change. I don't see a copy button when viewing the pikchr src. Is that intended?

i tentatively re-enabled that but it might indeed be removed, based on y'all's feedback.

Note that the main site does not get updated for every trunk commit, so it may or may not correspond to anything i say here :).

An alternative to "toggle-view" could be a comment "double-click to see the graphic. For more info on these graphics, visit pikchr.org", etc.

We can't use double-click or long click without conflicting with browser-default behaviours. There was some degree of outrage when i tried to use double-click to expand/collapse forum posts, because double-click is used by desktop browsers to select text and mobile browsers to (normally) zoom in and out.

Note that the main site does not get updated for every trunk commit, so it may or may not correspond to anything i say here :).

FWIW, it looks like pikchr & fossil-scm run the same version.

We can't use double-click or long click without conflicting with browser-default behaviours.

I do see some text is temporarily highlighted as it switches from the graphic to the text, but it happens very quickly. I do understand double-click isn't desired, but if the floating buttons you previously had in place are bad form, I don't know what an alternative could be.

I like the dotted border and agree something should be around the pikchr code to help separate it from the text around it.

The fossil 3c786c6fc3603d82 checkin is more of what I had in mind.

Double-click conflicts with standard browser behaviours - we can't do that without upsetting people (including, at some point, ourselves).

I think it probably needs some CSS tweaks to make the source-code view look exactly right (for example to do away with the dashed border) but other than that, it seems to be what I'm looking for.

LOL -it initially had no border, but without the border the text looks truncated when the source view wraps around. That's the only reason for the border. Whether it's dashed or not is irrelevant, of course, but without a border the code looks weird when it wraps.

A PRE tag is, it turns out, a poor choice because selecting and copying text form a PRE is much more work than it is for a textarea. To select all of the source code within a PRE we have to mouse-select just the desired part of the page, but with a textarea we click it then tap ctrl-A. On mobile, it's even more work to select from a PRE vs textarea because cursor control is so much less precise.

And though it doesn't matter much in this specific case, here's a JS tip for future reference:

      "document.getElementById('svgid-%d').ondblclick=function(){\n"
      "  for(var c of this.children){"
      "    c.style.display = c.style.display=='none'?'block':'none';"
      "  }\n"
      "}\n"

Changing display that way is a bad habit to develop because the previous display value is not always known. If it was, e.g. "flex", or some such, code like that will hose its layout. Similarly, some skins do weird stuff with display, like setting label to block, and the above can break them because an explicitly-set style trumps one which is assigned via CSS.

That doesn't matter in this case because we know (or are fairly certain) that both of those elements are display:block, but a cleaner way to do hiding is simply start all hidden elements with the "hidden" CSS class (defined in default.css) and then change the body of the above loop to something like:

c.classList.toggle('hidden');

Good suggestions.

The latest code on https://pikchr.org/ (and on https://fossil-scm.org/) uses the "hidden" class to toggle the displays on and off. And it uses ctrl-click (clicking while holding down the Ctrl key) rather than double-click. The latter change means that you can no longer toggle the display from a tablet or phone - but you gotta conform to standards I suppose.

And it uses ctrl-click (clicking while holding down the Ctrl key) rather than double-click.

i hate to be a party-pooper, but the current implementation has more fallout: it can't work for wikiedit/fileedit previews: the nonce on the generated script tag is not the same for async requests like the previews.

Even if the nonce matched, i'm not 100% sure whether injecting that into the dom (which we have to do for the preview modes) would actually apply the JS bits (i'd have to try it and see).

i hate to be a party-pooper, but the current implementation has more fallout: it can't work for wikiedit/fileedit previews: the nonce on the generated script tag is not the same for async requests like the previews.

That will also affect forum preview as soon as that's ajaxified. Though it's not critical that pikchr mode swapping work in previews, it would seem strange to me, as a user, if it doesn't. The only way for it to work in those, though, is to install it post-load via JS. The code for that is in place, it just need to be adapted to the new structure emitted by pikchr_to_html(), and pikchr_process() (which we need for pikchrshow and the pikchr command, as they have different needs than pikchr_to_html()) needs to be adapted to use the same structure.

If we keep the script tags currently emitted inline via pikchr_to_html(), the mismatching nonces (best case) won't run in preview modes or (worst case) they'll try to run and complain loudly about security violations in the user's browser dev console.

A PRE tag is, it turns out, a poor choice because selecting and copying text form a PRE is much more work than it is for a textarea.

Another issue not addressed above or by your implementation is resizing of the source view. Ideally it "really should" be the same size as the SVG so that the page layout doesn't go haywire when the user clicks on it. However, that size is entirely too small for tiny picts. We can pin the size of a PRE to match the SVG but we can't make it resizable, whereas most browsers offer a drag-to-resize option on textareas (which we can initially size to match the SVG).

Without some extra logic to make the sizes match, the UI layout "twitches" badly when switching.

Regarding ctrl-click:

https://fossil-scm.org/fossil/info/22ba9a41e4169887

That won't work on mobile. Plain old single-click is the only platform-portable option we have.

double-click works on my iPhone. But I can't do ctrl-click obviously. I can get triple-click to work in Firefox by checking for e.detail==3 on the single-click event, but that does not seem to work on the iPhone.

Pop-up icons on single click are not an acceptable solution.

So do y'all recommend:

1. double-click to toggle and endure the consequences (which to me are unclear at this point - why is it exactly that double-click is verboten?)

2. ctrl-click to toggle, and just tell mobile/tablet users that they can only look at the SVG and not the Pikchr source code.

Is there some other interaction that might work? Again - single click with pop-up icons is visually unacceptable to me so that is not a viable long-term option.

double-click to toggle and endure the consequences (which to me are unclear at this point - why is it exactly that double-click is verboten?)

Double-click on desktop Chrome/FF selects nearby text (the current word if the click is actually on text, otherwise something in the vicinity). Try double-clicking to the right of the Markup Style SELECT element in a forum reply. Firefox then selects the ":" from the "Markup style:" label.

Double-click on Android browsers typically zooms the page in our out: just verified that on my tablet with both Chrome and FF.

Triple-click on Chrome/FF desktop selects the current paragraph of text (try this to the right of the markup style SELECT in your next reply and note that it selects the text "Markup style:").

Caveat: "desktop" here means "on my Linux desktop." They might do other things on Windows or Mac.

We really have no business interfering with widely-used browser-installed defaults.

Is there some other interaction that might work? Again - single click with pop-up icons is visually unacceptable to me so that is not a viable long-term option.

i agree entirely that single-click isn't ideal, but it's the only platform-portable option we have unless we want to add something like what one of the forum-goers suggested: add a "tap zone" along the side of the image, and tapping it would toggle views. The tap zone would need to be along the top or left to avoid shifting its position out from other the user when switching modes, and it should probably be invisible, but it would also introduce an empty space to the left or top which might, in some contexts, look unsightly or inexplicable.

If mobile support for this feature is not a requirement, ctrl-click is as good as anything else. FWIW, mobile doesn't seem to me (as a strongly pro-mobile advocate) to be an important target for this specific feature, but consistency between platforms is always a plus. i can accept ctrl-click, but just needed to point out that it eliminates mobile use.

Another completely reasonable option is to drop this feature until/unless we can find some nicer way of activating it.

single-click [is] the only platform-portable option we have

It seems to me that viewing Pikchr source code is a developer-level activity, akin to right-click→ShowPageSource or right-click→InspectElement in firefox, neither of which you can do from mobile, as far as I know. So I don't have any problems using ctrl-click to toggle.

Another idea it to leave toggle turned off by default. (The user only gets to see the SVG, not the Pikchr source code.) But enable it in cases where it is important (such as the Pikchr user manual) using an extra tag that follows "pikchr" at the start of the fenced code block. And if enabled by a fenced-code-block tag, I'm ok with using a single-click (without floating icons) to toggle.

Or it can be hybrid:

• Single-click toggle only when enabled by a fence-code-block tag

• Ctrl-shift-click works regardless of how the fenced-code-block is tagged, and is intended for use only be experts on workstations, akin to "Inspect Element" or "View Page Source".

I propose that the fenced-code-tag for single-click be just the word "toggle". In documents like the Pikchr user manual, where being able to view the Pikchr source is important, we can go through and tag all the pikchr code with "toggle" and then single-click will work. Otherwise, you have to be on a workstation with a keyboard so that you can hold down the Ctrl key (or Shift key, or Alt key, or some combination thereof) to toggle.

I'm not sure I want casual readers of ordinary documentation to be able to see the Pikchr source code while browsing with their phone. They can't see the HTML sources. Why should the Pikchr sources be any different? If you want to reverse-engineer a document, use a workstation.

Another idea it to leave toggle turned off by default. (The user only gets to see the SVG, not the Pikchr source code.) But enable it in cases where it is important (such as the Pikchr user manual) using an extra tag that follows "pikchr" at the start of the fenced code block. And if enabled by a fenced-code-block tag, I'm ok with using a single-click (without floating icons) to toggle.

Also perfectly reasonable, and that could also be toggled on/off globally via JS, based on any number of criteria (perhaps even a button/hyperlnk at the top of affected pages). Imagine a button or button-like link at the top of /doc which says "toggle pikchr interaction mode" or some such.

Or it can be hybrid:

i like that approach. JS can handle either way with ease: "do this if CSS class (tag) X is set, else do that other thing." (Or don't do that other thing, as the case may be.)

I propose that the fenced-code-tag for single-click be just the word "toggle".

Sounds good to me.

They can't see the HTML sources. Why should the Pikchr sources be any different?

Weeeeell, just playing Devil's Advocate: they can edit wiki pages online and might want to see how a remote pikchr works, or simply to quickly copy/paste the source from a pikchr into another page. However, that's not an important use case for mobile: we can punt on that without me losing any sleep over it :).

As per my previous response, if you're okay with it i'll rip out the inlined script tags and adapt the current toggle code for the behaviour you just described.

Hybrid is now on trunk and on the server.

Diagram 1:

box "Toggle with" "just a" "click"

Diagram 2:

box "Must use" "ctrl-click"

Hybrid is now on trunk and on the server.

i like that... but i still need to move it to non-inlined JS code for the sake of page previews (which will "soon" include forum post previews). If you have any objections to that, please voice them, otherwise i'll start hoisting sometime in the next hour or so.

In case you're near your webcam, i'll hang out in jitsi for the next while in case you'd like to reprimand me for that off-list :).

This is a very good compromise with double-clicking and Stephan's previous impl.

Now...something to think about. What about impl this same logic to collapse forum posts in a thread.

Richard's first post announcing a PIC formatter for Fossil has well over 100 replies. It would be nice to click some of those and collapse them out of view.

I'm sorry, I don't mean to keep Richard, Stephan, Warren busy improving Fossil without contributing to it, so please don't feel like I'm requesting these without having the gratitude for the work done by you three and hundreds of others. Thank you for continuing to work on Fossil.

I'm sorry, I don't mean to keep Richard, Stephan, Warren busy improving Fossil without contributing to it,

Constructive feedback is contribution, and you have no shortage of it! Without you asking about it, we wouldn't have Ctrl-Enter in 3 of our apps (and it's a huge improvement when editing a wiki page).

Thank you, Stephan! It's been real nice working with you.

Per our off-list discussion, the updated implementation is now in the trunk, stripped of oodles of the previous code (note all the red of the left of the diff).

Summary:

• By default, ctrl-click switches modes.
• If the block has the "toggle" tag, it also responds to single-click.
• If the block has the "source" tag, it starts off¹ in source code view.
• Both source and toggle may be combined.

And here is a series of pikchrs which demonstrate this, but of course won't work until the server is running the new code:

Normal: ctrl-click to toggle

C: circle fill yellow
dot rad 0.05 at C.n - (0.1,0.15)
dot rad 0.05 at C.n + (0.1,-0.15)
dot rad 0.05 at C.n + (0.1,-0.15)

ellipseht=0.15
ellipsewid=0.1
ellipse at C.n + (0,-0.35) fill black

"toggle": single-click to toggle

C: circle fill yellow
dot rad 0.05 at C.n - (0.1,0.15)
dot rad 0.05 at C.n + (0.1,-0.15)
dot rad 0.05 at C.n + (0.1,-0.15)

ellipseht=0.15
ellipsewid=0.1
ellipse at C.n + (0,-0.35) fill black

"source": show source by default, ctrl-click to toggle

C: circle fill yellow
dot rad 0.05 at C.n - (0.1,0.15)
dot rad 0.05 at C.n + (0.1,-0.15)
dot rad 0.05 at C.n + (0.1,-0.15)

ellipseht=0.15
ellipsewid=0.1
ellipse at C.n + (0,-0.35) fill black

"source toggle": show source by default, single-click to toggle

C: circle fill yellow
dot rad 0.05 at C.n - (0.1,0.15)
dot rad 0.05 at C.n + (0.1,-0.15)
dot rad 0.05 at C.n + (0.1,-0.15)

ellipseht=0.15
ellipsewid=0.1
ellipse at C.n + (0,-0.35) fill black

1. ^{^} trivia: we unfortunately, for the "source" case, have to delay the switch from SVG- to source-view until JS runs, which means the user might see a brief flicker as the element changes views. We cannot currently set up that block to show the source and hide the SVG in C because the code which renders the DOM elements does not run until after pikchr() succeeds, and that call to pikchr() is the only place we could add the required CSS class to the SVG element. Changing that order would complicate the error handling, requiring discarding of partial output on error, but if this flickering ends up bugging me enough then that might just happen.

Turns out that ctrl-click does not work on my iMac. We might need to convert to alt-click. (Shift-click is also used for some kind of text selection.)

Ctrl-click on mac is the same as right-click on linux and windows. Mac's don't have a right mouse button.

Turns out that ctrl-click does not work on my iMac.

LOL!!!

That makes my night. Try changing this line:

https://fossil-scm.org/fossil/file?ci=tip&name=src%2Ffossil.pikchr.js&ln=46

To use altKey instead of ctrlKey. And/or metaKey:

https://www.w3.org/TR/2014/WD-DOM-Level-3-Events-20140925/#widl-KeyboardEvent-metaKey

which is Mac-specific.

Try changing this line:

More correctly, both of these:

https://fossil-scm.org/fossil/file?ci=tip&name=src%2Ffossil.pikchr.js&ln=46+84

Something to think about when trying to select all the code...

I haven't read all the details on this yet, but the two single click mode makes selecting the source pretty difficult. Sometimes you'll be able to select the text, copy it, click to show the pikcrh, click again and see the text is highlighted. Other times You might release the mouse a little too quickly and not copy everything.

Something to think about when trying to select all the code...

That's definitely a minus for which i've got no current workaround other than start and end the drag-selection outside of the source area.

On my tablet, interestingly, if you hold down long enough for the text selection to start, then that mouse-up (or "finger-up") doesn't toggle it.

That's definitely a minus for which i've got no current workaround other than start and end the drag-selection outside of the source area.

Could your copy button be added to this once the src is exposed?

Could your copy button be added to this once the src is exposed?

That one is up to Richard. It's essentially impossible to place the button so that it doesn't hide something or get blocked by something else, though, so adding it would require re-adding parts of the hide/show button bits.

Moving the <pre> outside of the pikchr-svg <div> will also clear all the complication about remembering the max-width when hiding the SVG.

Doh, that would solve that.

i'll get this done momentarily.

We should restore the outer

Here you go:

https://fossil-scm.org/fossil/info/cd22f0f07d452bcc

And there's a funny story about alt-click: many Linux window managers intercept alt-click for window movement (try alt-LMB and dragging a window to move it or alt-RMB to resize by dragging), so i went with the most conservative approach and now listen for any of ctrl/alt/meta, and the user will simply have to find one (if any) which works on their environment.

Much much better. I agree with the ctrl/alt/meta approach.

Two more minor issues I see:

1. The clicking does not work for markdown rendered on the timeline. example. I don't think the fossil.pikchr.js is being included.

2. If the Pikchr code contains "print" statements (used for debugging) those generated HTML that is outside of the <svg> and so they do not get turned off when clicking over to source mode. Example below. I think it is the the <svg> and not the container <div> that is being switched on and off.

print "This text persists"
print "even when clicking over"
print "to source mode."
box "Click here"

The clicking does not work for markdown rendered on the timeline. example. I don't think the fossil.pikchr.js is being included.

It's only included in "a few select places" so far, but i will work that one in later today - it's 6am, so about time for the daily nap. Are there any other "weird" places it might need to be? Currently, IIRC, it's in:

• /wiki
• /doc
• /forumpost
• forum post editor
• /wikiedit and /fileedit apply it to previews

i'll just track down wherever wiki content is rendered and add it there. /file and /info now come to mind.

If the Pikchr code contains "print" statements (used for debugging) those generated HTML that is outside of the <svg>...

Fixed!

Unrelated: i really like what you did with the script tags:

https://fossil-scm.org/fossil/info/6854244949f33472

It's only included in "a few select places" so far,

The current trunk should about cover it.

As part of that task the routines which output fossil.XYZ.js now understand the deps between each of those modules, emit them in proper dependency order (recursively), and only emits any given one of them a single time even if multiple callers request them or multiple deps lead back to them. Thus it no longer matters whether a caller emits ("dom","copybutton") or just "copybutton", as the latter depends on the former and its deps will be emitted along with it. That will also simplify future maintenance if the cross-module deps change, as only the central-most emit function needs to be adjusted.

The clicking does not work for markdown rendered on the timeline. example. I don't think the fossil.pikchr.js is being included.

While adding that to the timeline, /info, and friends (not checked in yet - still finding all of the places), this kind of stuck out at me while testing:

https://fossil.wanderinghorse.net/screenshots/pikchr-happy-readme.png

In hindsight it's obvious, but i wasn't expecting to see that while browsing /tree.

Seeing that actually reminds me: i'd like to see "folder" (as in filesystem) added as one of the pikchr object types.

The clicking does not work for markdown rendered on the timeline. example. I don't think the fossil.pikchr.js is being included.

Almost done, but for later reference and potential discussion: files/pages intentionally not touched by this change, though they invoke wiki_convert() or markdown_to_html():

• fuzz.c: doesn't seem necessary here
• report.c (ticket reports): clickability seems unnecessary here.
• search.c: ditto
• th_main.c: "wiki" and "markdown" TH1 commands: loading the JS from here would potentially conflict with page-level JS loads, as each individual module should only be loaded once. If/when people really start producing pikchrs in wiki output from th1 we can revisit this, but 7:45am is not the right time for it ;).

The new code is not working. We should restore the outer <div>. What we need is:

A typo in my re-impl of that (margin-auto instead of margin:auto) broke the centering and led me to an alternate impl which i like better but you might not (in which case i'll revert it). The visible difference is that when toggling to source mode, the source code is centered right where the image was, without needing any trickery involving re-setting max-width or some such (no JS changes at all, only DOM and CSS). That feels much more intuitive to me than having the text fly to the left of the screen.

The DOM structure effectively looks like:

<div style="text-align: center">
  <div class="pikchr-svg" style="max-width:XYZ; display: inline-block">
    <svg...>...</svg>
  </div>
  <pre class='pikchr-src' style='display:inner-block'>...</pre>
</div>

The outer DIV's text-align cannot align display:block elements, but it can align display:inline-block elements, so both the inner div and source view are now inline-block, allowing them to be centered without the non-intuitive margin:auto funkiness.

Here's a page which currently demonstrates that impl (ctrl-click it):

https://fossil.wanderinghorse.net/r/cwal/wiki/s2

:-?

(oh, man, i thought i posted this nearly 10 hours ago, and yet i awake to find it still here in my browser.)

The new code is not working. We should restore the outer <div>. What we need is:

A typo in my re-impl of that (margin-auto instead of margin:auto) broke the centering and led me to an alternate impl which i like better but you might not (in which case i'll revert it). The visible difference is that when toggling to source mode, the source code is centered right where the image was, without needing any trickery involving re-setting max-width or some such (no JS changes at all, only DOM and CSS). That feels much more intuitive to me than having the text fly to the left of the screen.

The DOM structure effectively looks like:

<div style="text-align: center">
  <div class="pikchr-svg" style="max-width:XYZ; display: inline-block">
    <svg...>...</svg>
  </div>
  <pre class='pikchr-src' style='display:inner-block'>...</pre>
</div>

The outer DIV's text-align cannot align display:block elements, but it can align display:inline-block elements, so both the inner div and is now inline-block, allowing them to be centered without the margin:auto kludgery.

:-?

Edit: here's a page which currently uses that impl - just ctrl/alt/meta-click the image:

https://fossil.wanderinghorse.net/r/cwal/wiki/s2

So I don't have any problems using ctrl-click to toggle.

Sounds good to me. i think of this feature of more as a document-editing feature, but that's also overwhelmingly a desktop-side activity. No harm done if it can't currently work on a phone or tablet.

That leaves the problem of the script tags embedded by pikchr_to_html(). Those won't work in wiki/doc preview modes (anything served async) because (1) of the nonce mismatch in such calls an (2), though i am not at all certain of this yes, the way the preview's HTML gets parsed and injected into the DOM. The first point kills it, in any case.

My proposal is to...

1. Let me remove those inlined scripts and add that behaviour via JS code. In the case of "directly-rendered" pages (/wiki, /forumpost, etc.), the JS will trigger via an onPageLoad callback, and in the case of previews it will be invoked after the preview is injected into the DOM. That code is all in place and working, it just need to be adapted to the new structure.

2. Re-restructure pikchr_to_html() to again be implemented in terms of the more flexible pikchr_process(), simply for maintenance's sake later on. Both pikchrshow and the pikchr command require rendering options not available via pikchr_to_html().

single-click is the only platform-portable option we have.

Double-click works fine on almost every platform I have at hand:

• iPhone
• Android tablet
• Chrome
• Safari
• Firefox
• Edge

Double-click does not work on an iPod - it zooms the display instead. I'm willing to live with the fact that you cannot toggle between SVG and Pikchr source on an iPod.

Are there any other reasons why we can't use double-click, other than iPod compatibility?

Double-click works fine on almost every platform I have at han

It may well be that FF/Chrome mobile only zoom in when there's no event handler on the given area. That's a definite possibility. On desktop, though, it's known (via feedback from earlier versions of the expand/collapse feature in the forum) to do both: select text and fire the event handler.