Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

not closing the editor textarea until I choose to do so #276

Open
rybesh opened this issue Oct 10, 2021 · 3 comments
Open

not closing the editor textarea until I choose to do so #276

rybesh opened this issue Oct 10, 2021 · 3 comments

Comments

@rybesh
Copy link

rybesh commented Oct 10, 2021

The disappear-on-focusout behavior of the fedwiki editor is quite unusual (I can't think of any other webapps that use it). I've always wished I could turn it off as it hinders the flow of editing when switching among windows (as I am almost always doing when editing fedwiki). Instead of just switching back to the browser window and pasting something in, I have to reopen the editor every time.

Furthermore, there are various browser extensions available for using an external editor to edit text in browser textareas, e.g. GhostText. But all of them rely on the textarea continuing to exist when focus switches away from the browser, which is not the case with fedwiki. That's unfortunate, since fedwiki is precisely the kind of application with which one might want to use a fully-featured editor to write text, rather than the impoverished textarea.

Could this design decision be revisited, I wonder?

@WardCunningham
Copy link
Member

precisely the kind of application with which one might want to use a fully-featured editor to write text, rather than the impoverished textarea.

I'm confused by this statement because it seems at odds with sharing within a community. We have made a number of decisions to lead folks to make simple pages written in a style that is easy to replicate and make contributions as an equal even when not acquainted with the same full-feature set that you are missing.

On another dimension, we are also strongly interested in ingesting wiki pages as part of workflow automation. Again, raising the bar at the textual level just makes more work reading that text within the automation. This argument is as old as unix where the designers were often criticized for not putting column headings in their output. Their reply was that the headings just get in the way when piping the output of one program into the input of another.

@WardCunningham
Copy link
Member

Having now read your CV I think that there are far more interesting things we could be discussing. We have had positive experience making federated wiki "outposts" where some specialized problem is paired with specialized editing that remains joined to the federation by agreeing to exchange compatible json pages. A sufficiently featured editor might stand as an outpost in its own right. Observable falls into this category for sure.

https://observablehq.com/

@rybesh
Copy link
Author

rybesh commented Oct 11, 2021

I fully agree with the decision to keep fedwiki content as simple as possible—that's one of the major reasons I use it. My desire to use an external editor has nothing to do with wanting to create complex markup. It just feels more comfortable to me to write text in an editor that is configured to my liking, rather than in a small textarea that I must keep resizing and that disappears when it loses focus.

But maybe I'm thinking of this the wrong way, and instead of changing how the wiki-client works I should be thinking in terms of turning my editor (emacs) into an alternative client for sending JSON to wiki-server?

3-w-c added a commit to 3-w-c/wiki-client that referenced this issue Oct 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants