Markdown is great for simple notes, journaling, and such, but if you need _advanced_ formatting then Markdown quickly starts to become too basic and limiting. Even something as simple as text alignment, you just can’t do in Markdown, unless you break the simplicity of Markdown and start introducing CSS.
This is why I think, besides supporting Markdown in my notes app, having another format would be a good idea. Something more advanced.
It needs to be non-proprietary, so it must be an open standard like #Markdown - perhaps #Asciidoc or #Pandoc Markdown.
There are mainly two downsides to having support for multiple different formats in the app. Firstly, it takes longer to develop, and secondly, it makes it more confusing to non-technical people.
The first downside is not so much of a problem imo. I’ll start with Markdown (which I’m already working on and have most of the essential formatting working), and then later, I can start implementing support for another format.
I see the second downside as more of a problem. If users need to choose between two formats such as Markdown or Asciidoc, they are going to be like _“wtf is this?!”_
I probably need a little helper explaining the two formats…
Today I’ll get headings working in my #Markdown editor. I should also build some kind of dropdown menu with options to search the document, show word counter, and so on.
Besides that, it would be nice to get shortcuts working to add/remove bold and italic styling by clicking `CMD + B` for bold and `CMD + I` for italic. I suppose text formatting should also be added as buttons in the menu bar.
I have decided to continue with building my own parser instead of using a package like `swift-markdown`. I might switch to a package eventually, but it’s a good learning experience. #dev
Pro tip: if you have guinea pigs, don’t leave any cables near them…
I learned that the hard way 😂
It might be a good idea to simply start by making a #WYSIWYG editor that writes and reads #Markdown files, but without the show/hide functionality of the Markdown syntax in 'live-preview' mode. Instead, I have now made an editor that only shows the rendered Markdown using `swift-markdown` package. I will also have a 'source mode' (this mode should show the raw Markdown without any formatting).
Building an #Obsidian-style live-preview editor is so damn difficult. My current hack is to render the Markdown syntax at a font size of 0.01, which makes it look invisible. That works visually, but it breaks keyboard navigation, because the cursor still has to step through those hidden characters. For example, if I have **bold**, the two invisible asterisks (**) on each side are still in the text buffer, so arrow-key movement feels awkward as the caret gets stuck on them.
This project is frustrating but I can't give up! I want this to work out 😂 #dev
View quoted note →I moved away from building my own #Markdown parser. Now I am trying to use the package called `swift-markdown`.
It's certainly more convenient because it takes care of all the edge-cases.
Now I just need to think about how I am going to hide and show the Markdown syntax when selecting some text with styling applied.
I tried cheating a bit by making the syntax a size of 1, so that the characters are so small they become invisible. This worked, but if having double or triple asterisks (** or ***), then it will obviously create more spacing when hidden, because they are still there, just a very small size.
I can definitely understand why there are so few editors that support live-preview the way #Obsidian does it... #dev
Working on complex problems is fun (like the #Markdown parser I’m building), but I feel like it’s so difficult to fall asleep because I can’t stop thinking about how I can solve whatever problem I’m working on 😂
I have the nested styling working with both **bold** and _italic_ styling applied.
But the parsing logic seems to have trouble finding correct opening and closing asterisks. If I have something like "this ***text is* bold and** italic.", then the third asterisk in the beginning will always be visible - it doesn't hide like it's supposed to... I assume this is because, it has trouble scanning for opening and closing asterisks, otherwise, I don't know what it could be.
But idk... maybe it's a simpler problem than I think. Will have to look into it tomorrow.
Also, doing something like "this _text is italic **but some of the_ text is also** bold" doesn't work yet.
There are quite a few edge cases to test and solve, and it's getting increasingly more complex.
I am building my own parsing logic, which really isn't ideal considering how complex this stuff is getting. Had this been a JavaScript project, I would have just used a package for the parsing, but I haven't found a really nice one for #Swift... #dev #Markdown
View quoted note →Arc Browser has been a bit annoying lately for me. My tabs have been going dark. Like, literally just a dark page and refreshing didn't help...
So now I'm back to using Brave Browser again.
Having some trouble with nested styles in my native #Markdown editor app that I'm working on for #macOS.
In the example below _(see image)_, the parent element is bold styling and the nested child is italic.
The child element is correctly italic as it should be, but for some reason, the bold styling does not apply to the child element as well. #dev #Swift
The reason why I am building an alternative to #Obsidian is simple:
I want a native notes app for #macOS that supports #Markdown with live-preview.
The **native** part is what’s important. I want something natively built for the macOS platform.
I know there are native Markdown editors for macOS, but none of them support REAL live-preview. At least not that I could find. And believe me, I’ve been looking…
They all have this side-by-side feature with the raw Markdown syntax on the left and the rendered Markdown on the right.
I also have many more ideas, like building a moodboard with an infinite canvas for notes, links, images, and videos.
**Basically, the perfect app for brainstorming new ideas!**
View quoted note →I’ve mentioned before on #Nostr that I want to build a #Markdown notes app with live-preview, exactly like how it works in #Obsidian (my favorite notes app).
Today I finally had a few hours free to develop a little prototype, just to see if I could get the live-preview part working.
Good news: **it actually _mostly_ works!**
Basically, if you haven’t tried Obsidian, here’s how it works:
- It supports Markdown, but so do a lot of other apps.
- What makes Obsidian so good (imo at least) is the live-preview. By default, it hides the Markdown syntax, but when you put the cursor inside some styled text, the syntax shows up again.
My prototype isn’t perfect yet… Notice how if there’s italic text inside bold, only the outer styling shows up.
#dev #macOS #Swift #AppKit
There’s a thunderstorm right now with heavy rain.
I saw all the flashes of lightning and thought it would be cool to get on video.
Nothing happened, so I stopped recording and went back to bed.
Then of course the lightning started again… ⛈️⚡️
My first post from Nosotros!
btw. there’s some overflow in the dialog when writing a post. At least it happens when quoting another post.
View quoted note →Wow. The UI looks awesome 🤩
View quoted note →I had underestimated how much SVG code it takes for a QR code.
It was simply not practical to inject the SVG code directly into the `<script>` tag like `data-qr-code="data:image/svg+xml;base64,…”`.
Especially because the `<script>` tag is something clients will be using, it looks rather unprofessional to have a ton of lines of code just for a QR code.
Instead, I opted to use an API called `QRServer` to show QR codes on clients’ websites.
When clients use the widget creator, I don’t use the API. Instead, I generate the QR codes locally using an NPM package called `qrcode-generator`. The QR code updates in real time as the user types their URL, which would put unnecessary strain on the API - that’s why I generate the QR codes locally. #dev
View quoted note →It’s crazy that #ActivityPub still doesn’t have a solution for letting users switch instances while transferring their posts and comments.
At least #ATProto has solved that problem.
And then we have #Nostr where you never need to worry about that. Just run a private relay, and then you have a backup of all your events, allowing you to broadcast them to new relays.
Injecting SVG code into the script tag was a mistake. I hadn’t thought it through… Turns out it takes a lot more SVG code to build a QR code than I imagined 😅 #dev
View quoted note →I'm doing an internship for my Software Engineering degree this fall semester.
One of my tasks is to develop a widget that clients can embed on their websites using a simple `<script>` tag. That tag should fetch a JavaScript file from our server that contains all the logic.
Yesterday I worked on coding the widget's UI. Today I need to figure out how to handle QR code generation. Ideally, I'd like to do it on the client side so we can avoid building API routes or storing anything in a database.
I’m looking at the npm package `qrcode-generator`.
With it, I could probably just generate the QR as SVG and inject it directly into the page from the script. #dev
In my opinion, there’s no reason at all to have these kinds of metrics on a decentralized protocol like Nostr.
Metrics like follower counts, like counts, total views, etc. are never going to be accurate anyways.
*By accurate I also mean by humans.*
They aren’t even accurate on centralized platforms like Facebook and Instagram because of all the bot accounts.
The only to get accurate metrics is to have a centralized platform that requires ID verification to create an account. And, one ID can only be associated with one account. Then creating bot accounts become an impossible task.
We should obviously not want this. It’s dystopian…
I’m just saying to explain that these kinds of metrics are irrelevant on Nostr.
View quoted note →
