Roaster
RU / EN
A WYSIWYG word processor in Python

A WYSIWYG word processor in Python

Hi all, Finding a good data structure for a word processor is a difficult problem. My notebook diaries on the problem go back 25 years when I was frustrated with using Word for my diploma thesis - it was slow and unstable at that time. I ended up getting pretty hooked on the problem. Right now I’m taking a professional break and decided to finally use the time to push these ideas further, and build MiniWord — a WYSIWYG word processor in Python. My goal is to have a native, non-HTML-based editor that stays simple, fast, and is hackable. So far I am focusing on getting the fundamentals right. What is working yet is: - Real WYSIWYG editing (no HTML layer, no embedded browser) with styles, images and tables. - Clean, simple file format (human-readable, diff-friendly, git-friendly, AI-friendly) - Markdown support - Support for Python-plugins Things that I found: - B-tree structures are perfect for holding rich text data - A simple text-based file format is incredibly useful — you can diff documents, version them, and even process them with AI tools quite naturally What I’d love feedback on: - Where do you see real use cases for something like this? - What would be missing for you to take it seriously as a tool or platform? - What kinds of plugins or extensions would actually be worth building? Happy about any thoughts — positive or critical. Greetings

SaaS BOTH · chrisecker
N/A
Данные о доходе недоступны

AI-анализ

Анализ скоро появится.

Похожие продукты

SaaS
Angel Match

Angel Match

База данных из 110 000+ бизнес-ангелов и венчурных инвесторов. Экономьте время на поиске инвесторов — находите подходящих по отрасли, стадии и локации.

$38.8K /мес
SaaS
Calendesk

Calendesk

Софт для онлайн-записи. Не тратьте время на согласование встреч — автоматизируйте запись, оплату и управление клиентами. Для терапевтов, коучей, юристов и сферы услуг.

$21.5K /мес
SaaS
Changelogfy

Changelogfy

Принимайте лучшие решения и создавайте продукты на основе обратной связи. Единая платформа для сбора фидбека, приоритизации roadmap и публикации обновлений.

$4.3K /мес
SaaS
Superlog (YC P26)

Superlog (YC P26)

Hey HN, we’re Nico and Arseniy, co-founders of Superlog (https://superlog.sh). We're building a self-installing, self healing observability tool meant not to be opened. It has a wizard that daily sets up proper logging and an agent that investigates errors and opens PRs. Super short demo: https://www.youtube.com/watch?v=xFhU9Mk247M. In our earlier startups, we tried Sentry, Datadog, Grafana, Dash0, and nothing was good enough. Proper telemetry and alerting still requires a ton of manual setup. We struggled with adding good logs, so debugging was tough, especially as codebases grow at a faster pace. Meanwhile, the Datadog/Dash0 bill kept climbing, and we still spent engineering hours to learn, configure, and maintain our observability tooling. With Sentry, we found ourselves flooded by a stream of alerts into our Slack channel, most were duplicates or lacked context, so alert fatigue/constant interrupts were a real pain. The #ops notification is consistently the worst feeling on a Saturday morning We’ve seen too many times servers run out of memory and disk, and three AWS metrics giving us three different values. Half of the graphs on dashboards are normally empty or outdated, and manually clicking through UIs, especially when the team is small, seems like a huge waste of time. At some point we realized that solving this problem would be more valuable than the things we had been working on, and we had the expertise to do it, since Arseniy had spent years at Datadog, getting paged during the night to debug production incidents. So we decided to build a platform that would just work: agent-first, MCP-native, zero-setup. Here’s how Superlog works: we have a wizard that scans your repo, and automatically instruments it with well-structured logs, traces and metrics via OpenTelemetry. We make sure to highlight main failure modes, endpoint performance, usage per tenant, and LLM/upstream cost (by callsite, tenant and model). Errors get fingerprinted and grouped into incidents, so you see one issue, not a thousand duplicates. When you get a notification from Superlog, you see a clear failure summary, its inferred severity and impact upfront. Then the agent investigates and tries to solve the issue. If it has enough context, it produces a concise and tested PR. If it doesn't, it posts its findings for the investigating team, and automatically pulls in the engineers that could contribute more context based on documentation, previous investigations and Slack threads. Either way the output is one clean PR per incident, posted in Slack, that you can merge, ignore, or open as a Claude Code session and modify. Three things we think are different from other observability vendors: (1) We solve the setup pain. The wizard will instrument everything with native OTel SDKs, respecting the semantic conventions, with proper service and environment tagging. We’re also working on native automatic dashboards and alerts, so that you can see what’s going on in a glance and don’t miss subtle failure modes. (2) Our telemetry doesn’t decay. The wizard runs daily, and keeps adding logs, alerts and dashboards where it’s needed. You don't have to remember to instrument new features. The next time something breaks, the data you need to debug it is already there. (3) Our goal is to solve alert fatigue. We use agents to merge similar errors and refine the summaries, giving you relevant information upfront. We have a custom evaluation setup that makes sure that our summaries are dense and correct, and severity and impact is on point. We also give you confidence scores for every LLM-enhanced metric so that wrong guesses don’t get boosted. Important: superlog telemetry is vendor-neutral, so you keep all the logs/metrics/traces we install. Pricing is on the site. We're early, so expect rough edges and please tell us when you find them. You can try it at https://superlog.sh. We'd love to hear what you're using today, what's broken about it, and whether the "one mergeable PR per incident" model sounds useful or terrifying. Especially keen to hear from folks running integration-heavy products, anyone who's rolled their own observability, and anyone who has tried Sentry / Datadog MCPs and given up. Comments and feedback welcome!

Доход N/A
SaaS
Vibe Coding a $20k /Year Enterprise Logistics Platform

Vibe Coding a $20k /Year Enterprise Logistics Platform

Show HN: Vibe Coding a $20k /Year Enterprise Logistics Platform

Доход N/A

Ключевые факты

Категория
SaaS
Аудитория
BOTH
Основатель
chrisecker
Данные о доходе
Неизвестно

Поделиться

Twitter LinkedIn