Make README more AsciiDoc-compatible
It seems to almost work, except for callouts without blocks.
This commit is contained in:
parent
d04c140a69
commit
f99615c850
GPG Key ID:
A0420B94F92B9493
35
README
35
README
|
|
@ -90,8 +90,8 @@ project that makes do with a single Makefile, even for cross-compilation on
|
|||
Windows. Let us avoid CMake and the likes of it.
|
||||
|
||||
It seems that Go can link dynamically, therefore I could build libhaven.so
|
||||
https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ
|
||||
https://stackoverflow.com/questions/1757090/shared-library-in-go
|
||||
(https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ
|
||||
and https://stackoverflow.com/questions/1757090/shared-library-in-go)
|
||||
and have the rest of the package as rather small binaries linking to it.
|
||||
The "cannot implicitly include runtime/cgo in a shared library" error is solved
|
||||
by "go install", which again requires "-pkgdir" because of privileges.
|
||||
|
|
@ -102,6 +102,7 @@ GUI
|
|||
Probably build on top of X11/Xlib or xgb<1>. Wayland can wait until it
|
||||
stabilizes--it should not be a major issue switching the backends.
|
||||
Vector graphics can be handled by draw2d<2>.
|
||||
|
||||
<1> https://rosettacode.org/wiki/Window_creation/X11#Go
|
||||
<2> https://github.com/llgcode/draw2d
|
||||
|
||||
|
|
@ -118,7 +119,7 @@ for FreeType fonts and it's more of a choice between vectors and bitmaps.
|
|||
The looks will be heavily inspired by Haiku and Windows 2000 and the user will
|
||||
have no say in this, for simplicity.
|
||||
|
||||
Resources:
|
||||
.Resources:
|
||||
- https://github.com/golang/exp/tree/master/shiny is a GUI library
|
||||
- https://github.com/as/shiny is a fork of it
|
||||
- http://man.cat-v.org/plan_9/1/rio has a particular, unusual model
|
||||
|
|
@ -187,8 +188,8 @@ Only UTF8_STRING-convertible selections are synchronized.
|
|||
|
||||
hasp -- (lib)asciidoc syntax preprocessor
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Provisional tool to make libasciidoc understand more syntax, namely two-line/
|
||||
underlined titles for my Gitea projects.
|
||||
Provisional tool to make libasciidoc understand more syntax, namely
|
||||
two-line/underlined titles for my Gitea projects.
|
||||
|
||||
ht -- terminal emulator
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -211,10 +212,10 @@ smooth integration with non-IRC "backends" such as Slack or Mattermost.
|
|||
|
||||
he -- text editor
|
||||
~~~~~~~~~~~~~~~~~
|
||||
VIM controls, no scripting, no syntax highlight, single-file, made for variable-
|
||||
-width/proportional fonts. Initially done primarily to produce a text editing
|
||||
widget, which is going to be an interesting challenge, arguably better solved by
|
||||
whole program composition. Scintilla may provide some inspiration.
|
||||
VIM controls, no scripting, no syntax highlight, single-file, made for
|
||||
variable-width/proportional fonts. Initially done primarily to produce a text
|
||||
editing widget, which is going to be an interesting challenge, arguably better
|
||||
solved by whole program composition. Scintilla may provide some inspiration.
|
||||
|
||||
In the second stage, support for the Language Server Protocol will be added so
|
||||
that the project can be edited using its own tools. Some scripting, perhaps
|
||||
|
|
@ -226,7 +227,7 @@ The real model for the editor is Qt Creator with FakeVIM, though this is not to
|
|||
be a clone of it, e.g. the various "Output" lists could be just special buffers,
|
||||
which may be have names starting on "// ".
|
||||
|
||||
Resources:
|
||||
.Resources:
|
||||
- http://doc.cat-v.org/plan_9/4th_edition/papers/sam/
|
||||
|
||||
ho -- all-powerful organizer
|
||||
|
|
@ -235,8 +236,9 @@ Zettelkasten with fulltext search, arbitrary reciprocal links, arbitrary tags.
|
|||
Flat storage. Should be able to use translation dictionaries for search hints.
|
||||
|
||||
Indexing and search may be based on a common database, no need to get all fancy:
|
||||
http://rachbelaid.com/postgres-full-text-search-is-good-enough/
|
||||
https://www.sqlite.org/fts3.html#full_text_index_queries (FTS4 seems better)
|
||||
|
||||
- http://rachbelaid.com/postgres-full-text-search-is-good-enough/
|
||||
- https://www.sqlite.org/fts3.html#full_text_index_queries (FTS4 seems better)
|
||||
|
||||
htd -- translation dictionary
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -267,8 +269,8 @@ using cursor keys. Possibly a dialog with image metadata.
|
|||
hfm -- file manager
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
All we need to achieve here is replace Midnight Commander, which besides the
|
||||
most basic features includes a VFS for archives. The editing widget in read-
|
||||
-only mode could be used for F3. The shell is going to work very simply,
|
||||
most basic features includes a VFS for archives. The editing widget in
|
||||
read-only mode could be used for F3. The shell is going to work very simply,
|
||||
creating a PTY device and running things under TERM=dumb while decoding SGR,
|
||||
or one could decide to run a new terminal emulator with a different shortcut.
|
||||
ht could probably also be integrated.
|
||||
|
|
@ -283,8 +285,9 @@ The first version doesn't need to be able to reference other cells, and can more
|
|||
or less be a CSV editor.
|
||||
|
||||
We can take inspiration from Excel:
|
||||
https://docs.microsoft.com/en-us/office/client-developer/excel/excel-recalculation
|
||||
https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems.pdf
|
||||
|
||||
- https://docs.microsoft.com/en-us/office/client-developer/excel/excel-recalculation
|
||||
- https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems.pdf
|
||||
|
||||
The rest
|
||||
~~~~~~~~
|
||||
|
|
|
|||
Loading…
Reference in New Issue