Creating an _in place_ editor, wiki app using Asciidoctor

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Creating an _in place_ editor, wiki app using Asciidoctor

Fernando-Basso
I have been using Asciidoctor for for some years now, for taking notes, making
summaries of programming, ideas, insights, etc. and I love it. I love the TOC
with links, the default HTML/CSS theme, etc. Too many things I like about
Asciidoctor to list here, actually. (I am even attempting to write a vim plugin
do some handling of todo lists more or less following the way Org-mode works
when handling "checkboxes".)

It so happens that I recently started using Zim Desktop Wiki. Two things I most
like about Zim is the "searchability" and the tree structure of the files in
the wiki as well as the table of contents for each file that happen to be
viewing/editing. Those features make Zim extremely navigable (and easily navigable).

zim wiki example

https://i.imgur.com/wQPIOhV.png

I don't like its Dokuwiki syntax though for a few reasons that I don't think
would matter matter here.

And with that, came the idea of making a Zim Wiki clone using Asciidoctor as
the underlying markup. That means files would not only be useful for this Wiki
of mine, but would also be ready to use in external places, like README files
in Github or Gitlab, for blogging with Jekyll and whatnot and perhaps other
things.

One goal would be to implement the _in place_, wysiwyg style of editing like
Zim does.

Easier said than done :)

For me at least, editing text in such a manner (and resorting to the source only
on some specific cases) lessens cognitive burden during the writing. Also, I tried
live previews, epiphany's automatic reload, etc. and although they help, it is
a bit of a nuisance having to switch back and forth between windows or even
finding what I just wrote in source code on the split pane of Atom, for instance.
It is still a bit burdensome to me.

And then, why did nobody (to my knowledge) have done something like this
_in place_ editing for Asciidoctor yet? Perhaps it is next to impossible?

If I even attempted such a thing, I would perhaps use Electron and Asciidoctor.js.

I don't believe I would succeed, but would like to hear some commentary about
this.

Thanks in advance.


Reply | Threaded
Open this post in threaded view
|

Re: Creating an _in place_ editor, wiki app using Asciidoctor

ciampix
> [...]
> And then, why did nobody (to my knowledge) have done something like this
> _in place_ editing for Asciidoctor yet? Perhaps it is next to impossible?

Not online but ...

https://www.asciidocfx.com/

--


Marco Ciampa

I know a joke about UDP, but you might not get it.

------------------------

 GNU/Linux User #78271
 FSFE fellow #364

------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Creating an _in place_ editor, wiki app using Asciidoctor

Fernando-Basso
This post was updated on .
Looks like a nice project and looks really good for writing in Asciidoctor.
Still, it isn't wysiwyg. That is the part I fear to be almost, if not
completely, impossible.

AsciidocFX uses a second pane to preview the rendered content, and that I can
do with Atom, or Vim + Epihany already.

So my main doubt/question is about ideas regarding writing such a thing
(wysiwyg) and using Asciidoctor as the underlying markup. Zim uses a very
simple markup, and perhaps that makes it a bit easier for a wysiwyg.

I think it is very possible to write a very searchable and navigable, no matter
the underlying markup format, but again, I would like comments abut this in
place
 editing mode I speak of.
Ted
Reply | Threaded
Open this post in threaded view
|

Re: Creating an _in place_ editor, wiki app using Asciidoctor

Ted
My thought is that you could start with a basic WYSIWYG editor. It has very few buttons but handles most of what people want to do.

* There is this floating Medium Editor that allows for basic markdown.
* The same idea English Editor hooked up to your GitHub repo.

Adapt these editors to write Asciidoc.

Then when you need more, you open to a text on the left | preview on the right.

Later expand the editor to handle more Asciidoctor markup. Perhaps use CKEditor 



For more back ground, see thread: Asciidoctor CMS publisher
- Ted @TedAtCIS
Reply | Threaded
Open this post in threaded view
|

Re: Creating an _in place_ editor, wiki app using Asciidoctor

mojavelinux
Administrator
In reply to this post by Fernando-Basso
Fernando,

While this doesn't directly answer your question, I wanted to share that I also started out using DokuWiki. That's what got the gears turning in my head that eventually allowed me to discover AsciiDoc. I stopped using DokuWiki once I was introduced to GitHub because I felt it was better to store files in git than on the local filesystem.

-Dan

On Tue, May 22, 2018 at 4:59 PM Fernando-Basso [via Asciidoctor :: Discussion] <[hidden email]> wrote:
I have been using Asciidoctor for for some years now, for taking notes, making
summaries of programming, ideas, insights, etc. and I love it. I love the TOC
with links, the default HTML/CSS theme, etc. Too many things I like about
Asciidoctor to list here, actually. (I am even attempting to write a vim plugin
do some handling of todo lists more or less following the way Org-mode works
when handling "checkboxes".)

It so happens that I recently started using Zim Desktop Wiki. Two things I most
like about Zim is the "searchability" and the tree structure of the files in
the wiki as well as the table of contents for each file that happen to be
viewing/editing. Those features make Zim extremely navigable (and easily navigable).

zim wiki example

I don't like its Dokuwiki syntax though for a few reasons that I don't think
would matter matter here.

And with that, came the idea of making a Zim Wiki clone using Asciidoctor as
the underlying markup. That means files would not only be useful for this Wiki
of mine, but would also be ready to use in external places, like README files
in Github or Gitlab, for blogging with Jekyll and whatnot and perhaps other
things.

One goal would be to implement the _in place_, wysiwyg style of editing like
Zim does.

Easier said than done :)

For me at least, editing text in such a manner (and resorting to the source only
on some specific cases) lessens cognitive burden during the writing. Also, I tried
live previews, epiphany's automatic reload, etc. and although they help, it is
a bit of a nuisance having to switch back and forth between windows or even
finding what I just wrote in source code on the split pane of Atom, for instance.
It is still a bit burdensome to me.

And then, why did nobody (to my knowledge) have done something like this
_in place_ editing for Asciidoctor yet? Perhaps it is next to impossible?

If I even attempted such a thing, I would perhaps use Electron and Asciidoctor.js.

I don't believe I would succeed, but would like to hear some commentary about
this.

Thanks in advance.





If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Re-Creating-an-in-place-editor-wiki-app-using-Asciidoctor-tp6350.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML


--
Dan Allen | @mojavelinux | https://twitter.com/mojavelinux
Reply | Threaded
Open this post in threaded view
|

Re: Creating an _in place_ editor, wiki app using Asciidoctor

mojavelinux
Administrator
In reply to this post by Fernando-Basso
Fernando,

My feeling about why there's no WYSIWYG for AsciiDoc (and why you see preview windows being developed instead) is that WYSIWYG goes against the philosophy of AsciiDoc. The whole point of AsciiDoc is to be able to see the markup you're creating, but for it to be minimal enough not to get in your way. It's a fundamentally different approach than editing rich text directly.

I recognize this is not for everyone. Our focus is not on satisfying everyone. It's on satisfying the writers who embrace AsciiDoc and find it to be the most efficient way to write.

An idea I would support is being able to edit directly in the preview window (at least within a block) and have the content be updated in the source window (perhaps in the Atom plugin). There are definitely times when that would be the most efficient way to edit. But I would never personally support hiding the source view. That introduces a disconnect with the underlying markup and allows poor formatting to take root. Have you ever looked at the HTML source after a WYSIWYG has its way with it? It's a mess. That's what we're trying to get away from with AsciiDoc.

Cheers,

-Dan

On Tue, May 22, 2018 at 4:59 PM Fernando-Basso [via Asciidoctor :: Discussion] <[hidden email]> wrote:
I have been using Asciidoctor for for some years now, for taking notes, making
summaries of programming, ideas, insights, etc. and I love it. I love the TOC
with links, the default HTML/CSS theme, etc. Too many things I like about
Asciidoctor to list here, actually. (I am even attempting to write a vim plugin
do some handling of todo lists more or less following the way Org-mode works
when handling "checkboxes".)

It so happens that I recently started using Zim Desktop Wiki. Two things I most
like about Zim is the "searchability" and the tree structure of the files in
the wiki as well as the table of contents for each file that happen to be
viewing/editing. Those features make Zim extremely navigable (and easily navigable).

zim wiki example

I don't like its Dokuwiki syntax though for a few reasons that I don't think
would matter matter here.

And with that, came the idea of making a Zim Wiki clone using Asciidoctor as
the underlying markup. That means files would not only be useful for this Wiki
of mine, but would also be ready to use in external places, like README files
in Github or Gitlab, for blogging with Jekyll and whatnot and perhaps other
things.

One goal would be to implement the _in place_, wysiwyg style of editing like
Zim does.

Easier said than done :)

For me at least, editing text in such a manner (and resorting to the source only
on some specific cases) lessens cognitive burden during the writing. Also, I tried
live previews, epiphany's automatic reload, etc. and although they help, it is
a bit of a nuisance having to switch back and forth between windows or even
finding what I just wrote in source code on the split pane of Atom, for instance.
It is still a bit burdensome to me.

And then, why did nobody (to my knowledge) have done something like this
_in place_ editing for Asciidoctor yet? Perhaps it is next to impossible?

If I even attempted such a thing, I would perhaps use Electron and Asciidoctor.js.

I don't believe I would succeed, but would like to hear some commentary about
this.

Thanks in advance.





If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Re-Creating-an-in-place-editor-wiki-app-using-Asciidoctor-tp6350.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML


--
Dan Allen | @mojavelinux | https://twitter.com/mojavelinux
Reply | Threaded
Open this post in threaded view
|

Re: Creating an _in place_ editor, wiki app using Asciidoctor

Fernando-Basso
Hey Dan,

I also don't think hiding the source code is a good idea. What I “advocate” is having an “inline preview” which allows one to have less cognitive dissonance because one does not need to keep looking back and forth from source do preview pane and vice-versa (and having to find the precise spot where the content was changed in the preview pane), but always making it possible to see the underlying markup whenever one wants, similar to what happens in org-mode, which hides a link markup, but shows it again when there is a missing "[" or "]", and hides it again when the syntax for that link is "finished/concluded".

In Typora, when you place the cursor inside an inline `piece of code`, the backticks are displayed, and when the cursor leaves that piece of text, the preview is displayed instead. The same for links and other markup.

In Zim, we have to _edit_ the links in a popup dialog. That is not what I think should happen (for links or any other type of markup). On the contrary, the user should have to properly type the markup, and when it is done, then the preview hides the markup and displays the preview. When the user enters a piece of text which contains markup, there should be a way to edit the markup in-place.

What I like the most in Zim is the *navigability*. The tree view for the files on a given wiki, and the TOC that can be floating or placed on the left or right, the @tags!. It is very _navigable_ and very _searchable_. OK, I realize this is a wiki software. Yet, I can only imagine how freaking cool it would be to have Zim/wiki-like features with the AWESOME Asciidoctor as the underlying markup language.

I was probably not very precise and clear as I would like to be, but I think it gives a better idea of what I have in mind.

Best,
Fernando
jos
Reply | Threaded
Open this post in threaded view
|

Re: Creating an _in place_ editor, wiki app using Asciidoctor

jos
Hi,

I am also using Typora for Markdown documents and like to share my experience. Having one windows which combines the markup view and the editable preview work very well.  There is no cognitive overhead of having to look at two views, which you need to sync for yourself. Also, the use of screen estate is much more efficient.
 
In addition to what Fernando describes, Typora can also switch between the preview and markup mode (for the whole document, not just the current line) by typing Ctrl-/.

Jos