Projektowanie·16 czerwca 2026·5 min czytania

Dlaczego stworzyliśmy kolejny edytor Markdown

Edytorów Markdown jest już wiele, więc po co tworzyć następny? Nie dlatego, że brakuje im funkcji, lecz dlatego, że wartości, na które pozwalają, ślady pozostawiane przez zapis i odczucia podczas pisania nigdy nie współgrały ze sobą w jednym produkcie.

mote

Informacje o wydaniu otwarte w trybie podglądu na żywo. Znaczniki Markdown są ukryte i pojawiają się dyskretnie tylko w wierszu nagłówka, w którym znajduje się karetka.

Za każdym razem, gdy wybierałem edytor Markdown, musiałem z czegoś zrezygnować.

Aplikacje oferujące wygodną edycję bezpośrednią zmieniały plik podczas zapisywania. Aplikacje zachowujące plik w niezmienionej postaci miały niedopracowane środowisko edycji. Aplikacje z rozbudowanymi funkcjami notatek były zbyt ciężkie nawet do otwarcia jednego dokumentu.

W końcu trzymałem otwarte po dwa edytory naraz.

Dlatego zacząłem tworzyć mote. To edytor, który spełnia wszystkie trzy warunki.

Ukrywa znaczniki Markdown i pozwala edytować tekst bezpośrednio
Zapisuje utworzony przeze mnie plik w niezmienionej postaci
Działa lekko, bez silnika przeglądarkowego

Istnieje już wiele produktów, które spełniają każdy z tych warunków z osobna. Nie udało mi się jednak znaleźć produktu, który spełniałby wszystkie trzy jednocześnie.

O lekkości opowiem za pomocą liczb

Większość edytorów Markdown obsługujących edycję bezpośrednią korzysta z silników przeglądarkowych takich jak WebKitGTK czy Chromium. Działają one poprzez przekształcanie Markdown w HTML i wyświetlanie go w przeglądarce.

Ułatwia to implementację, ale ma swoją cenę. To tak, jakby razem z dokumentem działała jeszcze cała przeglądarka. Przybywa procesów, rośnie zużycie pamięci, a każde naciśnięcie klawisza przechodzi przez kilka dodatkowych etapów.

Niewiele produktów ujawnia jednak te koszty. Na stronach produktów zamiast informacji o użyciu procesora w stanie bezczynności czy opóźnieniu podczas pisania pozostaje tylko słowo „lekki”.

mote działa inaczej.

Użycie procesora w stanie bezczynności, zużycie pamięci, opóźnienie podczas pisania i czas uruchamiania mierzymy na tym samym komputerze i w ten sam sposób. Skrypty pomiarowe i surowe dane są również dostępne w repozytorium. Nie wydajemy kompilacji, które przekraczają ustalony budżet wydajności.

Do porównań używamy wyłącznie wartości zmierzonych w tym samym czasie. Wartości, których nie udało się zmierzyć, nie zapisujemy jako 0, lecz oznaczamy je jako niezmierzone.

Bo lekkość powinna być wartością pomiarową, a nie odczuciem.

Nie poprawiamy pliku podczas zapisywania

Gdy zarządza się dokumentami za pomocą git, czasem można natrafić na dziwny diff.

Poprawiasz tylko jedną komórkę tabeli, a w następnym commicie pojawia się mnóstwo wierszy, których wcale nie zmieniałeś. Dzieje się tak, ponieważ podczas zapisywania edytor ponownie dostosował odstępy lub wyrównanie tabeli. Jeden poprawiony przez ciebie wiersz miesza się z dwudziestoma wierszami poprawionymi przez edytor.

Nie oznacza to, że zawsze zmienia się cała zawartość. Są też edytory, które dobrze zachowują podziały wierszy czy kolejne spacje. Różnice pojawiają się głównie w tabelach i wyrównaniu. Funkcja zapisywania pliku w niezmienionej postaci również nie jest dostępna wyłącznie w mote.

Mimo to uznałem ją za warunek, którego trzeba bezwzględnie przestrzegać.

W mote podstawą jest tekst. Bajty pliku trafiają bez zmian do bufora, a pogrubiony tekst, tabele i wzory matematyczne są renderowane nad nim. Podczas zapisywania bufor trafia na dysk w niezmienionej postaci.

Wygląd ekranu może się zmienić na lepsze, ale plik nie jest potajemnie modyfikowany.

Diff w git po zmianie wartości jednej komórki tabeli z „review” na „approval” i zapisaniu pliku — zmieniły się tylko wiersz zawierający tę komórkę oraz ostatni akapit, a wyrównanie pionowych kresek i wypunktowanie za pomocą gwiazdek pozostały bez zmian. Na pasku stanu widnieje +8 −6 B.

Zaczynamy od poprawnej obsługi języka koreańskiego

Subtelne niedogodności edytorów internetowych czuje się pod palcami. Choć przewijanie, rozmycie i ruch mogą wyglądać podobnie, nieco różnią się od tych w natywnych aplikacjach systemu operacyjnego.

Podczas wpisywania tekstu po koreańsku różnica staje się jeszcze większa.

Znaki w trakcie komponowania mogą się rozpadać, kursor może przeskakiwać, a tekst wpisywany na końcu wiersza może znikać. Są to problemy pojawiające się podczas obsługi przez edytor internetowy zdarzeń związanych z komponowaniem znaków koreańskich.

W mote znaki i efekty są renderowane bezpośrednio przez system operacyjny. Komponowany tekst koreański również trafia bezpośrednio z systemowej metody wprowadzania. W zamian trzeba osobno zaimplementować obsługę wprowadzania tekstu dla każdego systemu operacyjnego i sprawdzić ją na rzeczywistych urządzeniach. Obecnie obsługiwany jest Linux, a wersje dla macOS i Windows są w trakcie tworzenia.

To trudniejsza droga, ale dla osób piszących długie teksty ta różnica jest istotna.

Dokument w języku koreańskim otwarty w trybie podglądu na żywo — poprzedzający znak # pojawia się dyskretnie tylko w wierszu nagłówka, w którym znajduje się karetka, a znajdujące się wyżej pogrubienie, kursywa i kod wbudowany są wyświetlane bez znaczników. — Dokument w języku koreańskim otwarty w trybie podglądu na żywo — poprzedzający znak `#` pojawia się dyskretnie tylko w wierszu nagłówka, w którym znajduje się karetka, a znajdujące się wyżej pogrubienie, kursywa i kod wbudowany są wyświetlane bez znaczników.

Osób potrzebujących mote może nie być wiele.

Programiści zarządzający plikami README i dokumentami projektowymi za pomocą git. Osoby piszące długie teksty po koreańsku. Osoby, które przez cały dzień trzymają edytor otwarty na laptopie.

Powody, dla których porzucają edytory, są jednak oczywiste.

Zaśmiecony diff. Przerywane wprowadzanie tekstu po koreańsku. Wentylator, który nie przestaje pracować.

Ustaliliśmy również, czego nie będziemy robić

mote nie oferuje synchronizacji, wtyczek, linków zwrotnych, AI ani funkcji współpracy.

Nie tworzymy własnego systemu synchronizacji. Nie wymagamy też kont ani serwerów. W folderze dokumentów nie tworzymy nawet osobnego pliku konfiguracyjnego. Nie dodaliśmy funkcji, które wymagałyby przechowywania stanu niemożliwego do zapisania w Markdown.

Dzięki temu w folderze pozostają wyłącznie pliki .md. iCloud, Syncthing i git działają bez zmian, nawet nie wiedząc o istnieniu mote.

Nie udostępniamy również API wtyczek. Nawet uruchomienie jednego timera przez wtyczkę mogłoby złamać naszą obietnicę dotyczącą wydajności. Udostępniamy natomiast motywy, fragmenty kodu i szablony eksportu. Pozwalają one zmieniać wygląd rezultatów bez wpływania na wydajność podczas edycji.

Nie tworzymy również linków zwrotnych ani widoku grafu. Nie jest to produkt, który ma konkurować z bazami danych notatek. Obsługujemy jedynie drzewo folderów i standardowe łącza względne.

Nie dodajemy też AI. Nie streszczamy ani nie dopisujemy dalszej części tekstu, nie odczytujemy też folderu dokumentów, by wysyłać jego zawartość na zewnątrz. Uważamy, że fakt, iż edytor nigdzie nie wysyła moich dokumentów, również jest ważną funkcją.

Nie obsługujemy również współpracy w czasie rzeczywistym. Wspólna edycja wymagałaby przyjęcia modelu dokumentu na serwerze za źródło prawdy. Byłoby to sprzeczne z zasadą zachowywania pliku na dysku w niezmienionej postaci.

Spośród tych dwóch możliwości mote wybrał plik.

Jeśli potrzebujesz ekosystemu Obsidian, lepszym wyborem będzie Obsidian. Jeśli ważna jest dla ciebie wieloletnia stabilność Typory, właściwym wyborem będzie Typora. Typografia iA Writer również pozostaje dla nas celem, do którego musimy dążyć.

mote nie ma zastąpić wszystkich edytorów Markdown.

Nie chodziło też o to, że potrzebny był jeszcze jeden edytor Markdown.

Potrzebny był jeden edytor, który szanuje zarówno pliki, jak i laptopa.

Nowsze →To nie Markdown był źródłem ociężałości, lecz silnik przeglądarkowy

Bądź na bieżąco przez RSS.