CodiMD 1.6.0 announced that it’s the last version of 1.x.
We want to go forward and develop a version which introduces some breaking changes. Version 2.0.
I already provided some thoughts to it in the community chat, but would love to have a bit more discussion about it over here.
Plans:
Remove the not so great embeddings and replace them with with URL-based replacements (i.e. instead of writing {youtube <some id>} just paste the link in a single line)
Rework configs as it’s done in a currently open PR (probably replace config.json with a config.yaml and getting rid of the split between dev, test and prod environments within the same file)
possibly rename if we come up with a good name on time
Add basic user profiles
Relocate notes to an own sub directory (from https://demo.codimd.org/<some uuid> to https://demo.codimd.org/n/<some uuid> or similar) but with backwards compatibility
Working towards having an actual, standardized API
Reworking internals towards TypeScript
To be clear, I can’t do all of this on my own, and it’s not a made decision, I want your input on it, but that’s at least my vision for 2020. I would love when there would be people who also want to work on the front-end and make some improvements towards UI/UX there as well. I really invite you to share your ideas with me in this perspective and I would like to setup some tasks on Github soon, so people who want to help, can easily find a spot to get their hands dirty
It looks like a good plan! Out of curiosity, what is the reasoning for “Relocate notes to an own sub directory”, I have no objection to it, just wondering if there an open issue with more context that I can read to catch up.
Main reason for the relocation is the conflict in free URL mode which causes things like documents existing at https://codimd.example.com/robot.txt which is rather bad. For now we fight this by having forbidden NoteIDs, but I think the better solution would be to move things into a sub-directory and define an API for it.
Although this thread is more than a month old and I didn’t contribute for about a year now I followed the story quite a bit and collected some thoughts.
First of all, though off-topic, I want to express my support for this project and honour @sheogorath’s fair attitude and open mind throughout the difficulties with HackMD.
Secondly, though I never compiled and thus seen @amenthes’s profile page I’m excited.
Note sub directory: Although this makes things clearer and easier I’m not a huge fan of this.
I like short URLs
Maybe we should think about namespaces for users or even groups in this context
Maybe we could relocate UUIDs but leave the opportunity for even newly created freely chosen IDs (if they are activated)
Idea: Hooks
I think we are missing a hook system for the API/CLI, so we could hook Listeners on events to export the notes, do some stuff like a git commit or add support for WebDAV.
Taking inspiration from Android sensors, which accept sampling rates, we could define some approximately frequencies the listener could request, like:
live: every change (may cause heavy load)
minutely: every minute, if changed
revision: every saved revision
offline: when no user views the document (may never occur)
I guess this is a quite important feature for interoperability.
Further Ideas
Groups
Some way to structure and organise notes
File system-compatibility (WebDAV?) although no inotify
Full text search
Extensive tagging
Cross-document references
Frequently visited notes (quite related to the history data model)
Well, many ideas might be boo big or even unnecessary but I want to share them anyway, hoping that I get some feedback. I can elaborate on those in separate threads or issues, if somebody is interested. Do we have an ability to run some permanent ranking of the most wanted features by the way?
Tools like MS Word enable users without expertise to write whole books, while such as Evernote empower them to organise themselves. Although my personal preference is stability over functionality the extensive functionality was a strength of HackMD.
For me such tendencies are a good inspiration, how about you?
Maybe it would be a good idea to change the CodiMD Icon?
Together with a renaming this could yield a whole rebranding of the software. Currently the CodiMD Logo is the same as HackMD and HackMDs CodiMD, which does not really help to differntiate the projects. Maybe we could use a File Icon with the markdown mark instead?
Like so:
(I’ve made a svg version, but this can’t be uploaded here)
It’s simple and not to much of a difference. Also it’s custom build from some font-awesome icons (which we would need to credit, but I think that’s done already?) so other projects can’t simply use the same icon via font awesome.
We could also ask for icon drafts like gitea did a few years ago. Maybe someone more creative than me has a better idea…
What is necessary for exporting with Pandoc? Is the CodiMD api able to be used with something like this restful api version or even the hosted demo instance at pandoc.org/try
I’m interested in using Codi to draft out mediawiki pages.
The API looks quite… abandoned, although it would be intriguing. My approach would probably be to include Pandoc via Docker and build the stuff that is necessary for CodiMD to convert and send the document as a HTTP response.
Make it possible to easily disable functionality. In my CodiMD instance, I feel like there is a lot of functionality that is unused, and also unneeded. A lot of these things feel in some way like “plugins”. If it’s possible to slowly move to an architecture where it’s possible to disable or add new custom plugins, that would be super-cool. This obviously is also related to the “hooks”-idea proposed earlier.
Who, when, and where are the decided features for version 2.0 going to be set in stone?
When is the expected/anticipated/hopeful release date for version 2.0?
I am not a JavaScript guy, but if there is a decided list of features ready for development I will take a look and see if there is anything I can try out.
When it comes to the who, generally speaking it’s the community and their interest in features. Technically speaking it’ll probably be me who presses the merge button but will definitely happen in exchange with people in the community.
When is one of those questions in software that is close to impossible to answer. We expect 2.0 around August, earliest. The general perspective is: Whenever things are ready and/or required.
And the where: On GitHub and the community chat. Currently the change set for 2.0 is already rather big. Therefore the goal is getting towards reasonable stability and going towards release. Especially in the back end there is still a lot to do. But we are getting there.
As a new comer, these are the first noticed features that Codimd/Hedgedoc is missing.
New suggestions:
Support for auto language directions (include dir=“auto” in the HTML markup of each element like paragraph, heading, list, to-do list, …).
This is so much important for RTL languages like Arabic, Hebrew and others.
Import all existing .md notes at once from local storage, instead of: one by one.
Not sure if this already exist (because it’s crucial for new comers), but have no idea how to do it.
Already suggested:
Folder/directory structure for notes organisation (like Notebooks).
Contextual search (Search for notes content also).
Should we close this topic and open a new one? The last two posts could be moved over to that new topic. This is a very old thread that does not really belong to the recently released 2.0 Alpha 1.
I’m unsure if we can configure the ligatures this finely. But it’s probably best to request such a feature in the issue tracker and if it’s not possible we can close this and it’s documented for the next person.
(thx 