Nowy edytor w komentarzach – Plany i sugestie

Witam.

Jako że nowy edytor w postach i na mikroblogu jest już more or less wdrożony (zostały chyba tylko dwa bugi do poprawy); to należałoby się zastanowić nad następnym krokiem, czyli nowym edytorem w komentarzach. W komentarzach też istnieje pewne formatowanie, chociaż nie pełne, tzn są np pogrubienia, pochylenia, linki, ale nie ma np tabelek, i innych elementów. Widziałbym edytor w komentarzach jako pochodna edytora z postów.

Nie wiem więc czy można powiedzieć że w komentarzach jest Markdown? Być może okrojony Markdown?

Na razie nie mam czasu zabrać się za pisanie nowej wersji, i nie będę miał przez najbliśze tydzień-dwa, ale możemy zaplanować jak miałby wyglądać.

Rozmawialiśm z @cerrato nt tego jak to powinno być dobrze wszystko zrobione. Wspólnie ustaliliśmy, i z czym mam wrażenie wszyscy się zgodzą; że edytor powinien pokazywać "prawdziwe" formatowanie. Tzn jeśli coś jest pogrubione w edytorze, to powinno być też pogrubione w coyote; jeśłi coyote pokazuje coś jak link, to powinno to też być pokazane jako link w edytorze.

Myślę jednak też, że są rzeczy które są niepotrzebne w komentarzach, i być może takie rzeczy które powinny być, a ich nie ma.

Coś co mi osobiście przeszkadza w aktualnej edycji komentarzy:

• Możliwość dodania nowej linii, mimo że nie pojawi się ona w coyote. Edytor powinien być jednoliniowy (albo coyote powinien dopuszczać wielo-linjiowe komentarze).
• Autocomplete działa gorzej niż w edytorze postów. W edytorze postów jak wpiszemy np @Adam B, to pokaże się autocomplete które potem wsadzi @{Adam Boduch}. W edycji komentarza aktualnie po wpisaniu spacji autocomplete znika.

To byłyby takie dwie must-have, które dodałbym w edytorze komentarzy.

Oczywiscie trzeba by dodać też dekoracje linków, pogrubienia, pochylenia, `inline, @user oraz [[Delphi]]. Z jakiegoś powodu w komentarzu nie działa ~~strike~~ ani <u>underline<u/>, trzeba by się zastanowić czy tak ma być, czy trzeba je dodać?

Nie ma chyba sensu dodawać kontrolek do edycji komentarzy, ale nie widzę powodu żeby wyłączać komendy (np Ctrl+B do pogrubienia).

Dlatego też wrzucam ten post tutaj, żeby rozważyć jakie funkcje powinny zostać dodane do komentarzy, a jakie nie. Mając dokładną listę feater'ów w komentarzu moglibyśmy powoli zacząć developować edytor do komentarzy.

Ps: Można by się też zastanowić nad cytatami w komentarzu; można zauważyć że ludzie bardzo często odpowiadają w komentarzu na inny komentarz, zwłaszcza na mikroblogu i używają do tego `inline`. Może jakaś dedykowana składnia na to, być może > oraz \n, jak cytat w markdown, który też musiałby być jednolinijkowy?

Co do kontrolek - zgadzam się i też bym nie dawał ikonek, jedynie pokazywanie/parsowanie na bieżąco markdown i ewentualnie obsługa skrótów klawiaturowych (czy ktoś w ogóle tego używa?).

Co do cytowania znakiem > to raczej kiepski pomysł. Przy poście to wiadomo, że jak masz taki znak na poczatku linii to jest ona cytatem. Ale komentarze są jednoliniowe, więc nie da się tego jednocześnie stwierdzić. I moze dojsc do sytuacji w której będziemy rozmawiać o tym, co kogo kręci w płci przeciwnej, ja napiszę że piersi>pośladki, a edytor uzna, że to jest cytat ;)

cerrato napisał(a):

Co do kontrolek - zgadzam się i też bym nie dawał ikonek, jedynie pokazywanie/parsowanie na bieżąco markdown i ewentualnie obsługa skrótów klawiaturowych (czy ktoś w ogóle tego używa?).

Ja używam skrótów w sumie cały czas.

Co do cytowania znakiem > to raczej kiepski pomysł. Przy poście to wiadomo, że jak masz taki znak na poczatku linii to jest ona cytatem. Ale komentarze są jednoliniowe, więc nie da się tego jednocześnie stwierdzić. I moze dojsc do sytuacji w której będziemy rozmawiać o tym, co kogo kręci w płci przeciwnej, ja napiszę że piersi>pośladki, a edytor uzna, że to jest cytat ;)

No oczywiście to nie mogłoby być takie tępe :D i to nie musi być koniecznie >. Ale faktem jest ze ludzie chcą cytaty w komentarzu, i jak nie > to będą używać innego formatowania, teraz taką ofiarą jest `inline`.

TomRiddle napisał(a):

Jako że nowy edytor w postach i na mikroblogu jest już more or less wdrożony (zostały chyba tylko dwa bugi do poprawy); to należałoby się zastanowić nad następnym krokiem, czyli nowym edytorem w komentarzach. W komentarzach też istnieje pewne formatowanie, chociaż nie pełne, tzn są np pogrubienia, pochylenia, linki, ale nie ma np tabelek, i innych elementów. Widziałbym edytor w komentarzach jako pochodna edytora z postów.

oraz

Dlatego też wrzucam ten post tutaj, żeby rozważyć jakie funkcje powinny zostać dodane do komentarzy, a jakie nie. Mając dokładną listę feater'ów w komentarzu moglibyśmy powoli zacząć developować edytor do komentarzy.

Dla mnie powinien być ten sam edytor, jedynie nieudostępniający części możliwości (wyłączone skróty, niepojawiające się formatowanie). Jeśli nie da się w obecnym "ograniczyć możliwości", to OK, można kombinować z czymś customowym. Wtedy jednak dobrze będzie dążyć do takiej architektury edytora, żeby dało się go dostosowywać dowolnie do potrzeb ("budowa komponentowa" czy jak to nazwać) i ostatecznie zastosować zarówno w komentarzach, jak i wszędzie indziej.

Na razie nie mam czasu zabrać się za pisanie nowej wersji, i nie będę miał przez najbliśze tydzień-dwa, ale możemy zaplanować jak miałby wyglądać.

Plany są dobre. :)

Rozmawialiśm z @cerrato nt tego jak to powinno być dobrze wszystko zrobione. Wspólnie ustaliliśmy, i z czym mam wrażenie wszyscy się zgodzą; że edytor powinien pokazywać "prawdziwe" formatowanie. Tzn jeśli coś jest pogrubione w edytorze, to powinno być też pogrubione w coyote; jeśłi coyote pokazuje coś jak link, to powinno to też być pokazane jako link w edytorze.

No… czyli tak samo, jak w nowym edytorze obecnie?

Myślę jednak też, że są rzeczy które są niepotrzebne w komentarzach, i być może takie rzeczy które powinny być, a ich nie ma.

Coś co mi osobiście przeszkadza w aktualnej edycji komentarzy:

• Możliwość dodania nowej linii, mimo że nie pojawi się ona w coyote. Edytor powinien być jednoliniowy (albo coyote powinien dopuszczać wielo-linjiowe komentarze).

Dla mnie też nie powinno być możliwości dodania nowej linii, skoro nie jest ona pokazywana.

• Autocomplete działa gorzej niż w edytorze postów. W edytorze postów jak wpiszemy np @Adam B, to pokaże się autocomplete które potem wsadzi @{Adam Boduch}. W edycji komentarza aktualnie po wpisaniu spacji autocomplete znika.

Dla mnie powinien być ten sam autocomplete (ten sam kod).

Nie ma chyba sensu dodawać kontrolek do edycji komentarzy, ale nie widzę powodu żeby wyłączać komendy (np Ctrl+B do pogrubienia).

Zgadzam się.

TomRiddle napisał(a):

cerrato napisał(a):

Co do kontrolek - zgadzam się i też bym nie dawał ikonek, jedynie pokazywanie/parsowanie na bieżąco markdown i ewentualnie obsługa skrótów klawiaturowych (czy ktoś w ogóle tego używa?).

Ja używam skrótów w sumie cały czas.

Co do cytowania znakiem > to raczej kiepski pomysł. Przy poście to wiadomo, że jak masz taki znak na poczatku linii to jest ona cytatem. Ale komentarze są jednoliniowe, więc nie da się tego jednocześnie stwierdzić. I moze dojsc do sytuacji w której będziemy rozmawiać o tym, co kogo kręci w płci przeciwnej, ja napiszę że piersi>pośladki, a edytor uzna, że to jest cytat ;)

No oczywiście to nie mogłoby być takie tępe :D i to nie musi być koniecznie >. Ale faktem jest ze ludzie chcą cytaty w komentarzu, i jak nie > to będą używać innego formatowania, teraz taką ofiarą jest `inline`.

Dla mnie to też powinna być inna składnia niż >. No, albo nie umiem sobie wyobrazić innego wykorzystania >. Możesz pokazać przykład, jak Ty to widzisz? Co do ` – nie widzę problemu, że jest to wykorzystywane do dwóch rzeczy. Jeśli jednak musi być dedykowana składnia, to moim zdaniem najbardziej intuicyjna składnia cytatu w tekstach polskich to "cytat" (sam używam jej w komentarzach). W angielskich jest to chyba częściej 'cytat' (albo w ogóle?). Ponieważ gros na 4p to teksty polskie, byłbym za "cytat".

PS Może inaczej – w wykorzystywaniu składni ` do dwóch semantycznie różnych rzeczy widzę pewien problem. Jest on jednak mały w porównaniu z kwestią nauczenia użytkowników innej składni. Ale być może przesadzam i w zasadzie można nową składnię bez przeszkód wprowadzić?

Silv napisał(a):

Dla mnie powinien być ten sam edytor, jedynie nieudostępniający części możliwości (wyłączone skróty, niepojawiające się formatowanie). Jeśli nie da się w obecnym "ograniczyć możliwości", to OK, można kombinować z czymś customowym. Wtedy jednak dobrze będzie dążyć do takiej architektury edytora, żeby dało się go dostosowywać dowolnie do potrzeb ("budowa komponentowa" czy jak to nazwać) i ostatecznie zastosować zarówno w komentarzach, jak i wszędzie indziej.

No ten sam na pewno nie może być chociażby z tego powodu że komentarze mają być jednolinijkowe.

Rozmawialiśm z @cerrato nt tego jak to powinno być dobrze wszystko zrobione. Wspólnie ustaliliśmy, i z czym mam wrażenie wszyscy się zgodzą; że edytor powinien pokazywać "prawdziwe" formatowanie. Tzn jeśli coś jest pogrubione w edytorze, to powinno być też pogrubione w coyote; jeśłi coyote pokazuje coś jak link, to powinno to też być pokazane jako link w edytorze.

No… czyli tak samo, jak w nowym edytorze obecnie?

Tak.

• Autocomplete działa gorzej niż w edytorze postów. W edytorze postów jak wpiszemy np @Adam B, to pokaże się autocomplete które potem wsadzi @{Adam Boduch}. W edycji komentarza aktualnie po wpisaniu spacji autocomplete znika.

Dla mnie powinien być ten sam autocomplete (ten sam kod).

Tak będzie.

Dla mnie to też powinna być inna składnia niż >. No, albo nie umiem sobie wyobrazić innego wykorzystania >. Możesz pokazać przykład, jak Ty to widzisz? Co do ` – nie widzę problemu, że jest to wykorzystywane do dwóch rzeczy. Jeśli jednak musi być dedykowana składnia, to moim zdaniem najbardziej intuicyjna składnia cytatu w tekstach polskich to "cytat" (sam używam jej w komentarzach). W angielskich jest to chyba częściej 'cytat' (albo w ogóle?). Ponieważ gros na 4p to teksty polskie, byłbym za "cytat".

Pomysł dobry ale nie zadziała, bo gdybym chciał napisać jak się robi interpolację stringów w PHP to chciałbym użyć `"foo:$bar"` i nie chciałbym żeby to było interpretowane jako cytat. Ten sam problem z `'foo:$bar'`. To musi być coś co nie ma związku z `inline` moim zdaniem.

@Adam Boduch: Na razie ~~strike~~ i <u>underline</u> nie działają w komentarzu.

Tak ma być?

Swoją drogą; to może pora się zastanowić czy komentarze pod wpisami na mikroblogu powinny się rządzić dokładnie tymi samymi zasadmi co komentarze pod postami? Czy może to jednak inne bestie.

PS: Uważam też że fajnie by było gdyby <kbd> działało w komentarzu, kilka razy już chciałem użyć. @furious programming co myślisz?

Wszystkie style nie łamiące linii i nie wymagające tekstu wieloliniowego powinny być dostępne w komentarzach, razem z edytorem, paskiem przycisków do formatowania oraz obsługą spechalnych skrótów klawiszowych.

furious programming napisał(a):

[...] paskiem przycisków do formatowania oraz obsługą spechalnych skrótów klawiszowych.

Ciężej może być pisać na telefonie, jak pokażemy kontrolki w komentarzu.

Chociaż nie wiem. Może niech więcej osób się wypowie.

furious programming napisał(a):

Wszystkie style nie łamiące linii i nie wymagające tekstu wieloliniowego powinny być dostępne w komentarzach [...]

@Adam Boduch: wykonalne?

TomRiddle napisał(a):

Silv napisał(a):

Dla mnie powinien być ten sam edytor, jedynie nieudostępniający części możliwości (wyłączone skróty, niepojawiające się formatowanie). Jeśli nie da się w obecnym "ograniczyć możliwości", to OK, można kombinować z czymś customowym. Wtedy jednak dobrze będzie dążyć do takiej architektury edytora, żeby dało się go dostosowywać dowolnie do potrzeb ("budowa komponentowa" czy jak to nazwać) i ostatecznie zastosować zarówno w komentarzach, jak i wszędzie indziej.

No ten sam na pewno nie może być chociażby z tego powodu że komentarze mają być jednolinijkowe.

OK, fair enough. Inaczej powiem: chodzi mi o to, żeby w sensie logicznym, w sensie człowieka (programisty), nie tworzyć bytów nad potrzebę. Żeby nie tworzyć dwóch podobnych zmiennych, funkcji, pól, metod, klas, interfejsów, skryptów, edytorów i tym podobnych, różniących się jedynie tym, że jedno będzie wykorzystywane w postach, a drugie w komentarzach. W miarę możliowości żeby kod był ten sam. Oczywiście nie w każdej linijce kodu się da. W miarę możliwości.

Dla mnie to też powinna być inna składnia niż >. No, albo nie umiem sobie wyobrazić innego wykorzystania >. Możesz pokazać przykład, jak Ty to widzisz? Co do ` – nie widzę problemu, że jest to wykorzystywane do dwóch rzeczy. Jeśli jednak musi być dedykowana składnia, to moim zdaniem najbardziej intuicyjna składnia cytatu w tekstach polskich to "cytat" (sam używam jej w komentarzach). W angielskich jest to chyba częściej 'cytat' (albo w ogóle?). Ponieważ gros na 4p to teksty polskie, byłbym za "cytat".

Pomysł dobry ale nie zadziała, bo gdybym chciał napisać jak się robi interpolację stringów w PHP to chciałbym użyć `"foo:$bar"` i nie chciałbym żeby to było interpretowane jako cytat. Ten sam problem z `'foo:$bar'`. To musi być coś co nie ma związku z `inline` moim zdaniem.

Nie rozumiem, co ma Twój przykład do mojej propozycji. Przecież w składni ` składnia " nie byłaby interpretowana jako cytat, tylko dosłownie – tak, jak każda inna składnia w składni `.

TomRiddle napisał(a):

furious programming napisał(a):

Wszystkie style nie łamiące linii i nie wymagające tekstu wieloliniowego powinny być dostępne w komentarzach [...]

@Adam Boduch: wykonalne?

A niby dlaczego nie? Zamiast pisać wszystko od nowa i implementować w innej kontrolce, wystarczy w komentarzu również zastosować instancję edytora postów, tyle że bez wsparcia niektórych funkcji (np. znaczników kodu źródłowego, list itd.) oraz dodać kontrolę nad nowymi liniami.

<u> jak najbardziej. Wystarczy tutaj dodać do listy obsługiwanych tagów: https://github.com/adam-boduch/coyote/blob/master/app/Services/Parser/Factories/CommentFactory.php#L22

Co do przekreślenia to nie wiem czemu nie działa w tej bibliotece CommonMark. Dodany jest parser InlinesOnlyExtension: https://github.com/adam-boduch/coyote/blob/master/app/Services/Parser/Parsers/SimpleMarkdown.php#L24

Silv napisał(a):

No ten sam na pewno nie może być chociażby z tego powodu że komentarze mają być jednolinijkowe.

OK, fair enough. Inaczej powiem: chodzi mi o to, żeby w sensie logicznym, w sensie człowieka (programisty), nie tworzyć bytów nad potrzebę. Żeby nie tworzyć dwóch podobnych zmiennych, funkcji, pól, metod, klas, interfejsów, skryptów, edytorów i tym podobnych, różniących się jedynie tym, że jedno będzie wykorzystywane w postach, a drugie w komentarzach. W miarę możliowości żeby kod był ten sam. Oczywiście nie w każdej linijce kodu się da. W miarę możliwości.

No przecież wiadomo że go nie napisze od nowa i się zrobi re-use wszystkiego co się da.

Tamten edytor powstawał 3 miesiące, nie chce tyle samo poświęcić na komentarze :D

Ale muszę zrobić dwa edytory siłą rzeczy. Jaką mam alternatywę, dodać parametr isSingleLine do edytora? Na pewno nie.

TomRiddle napisał(a):

Ale muszę zrobić dwa edytory siłą rzeczy. Jaką mam alternatywę, dodać parametr isSingleLine do edytora? Na pewno nie.

A to czemu nie?

Adam Boduch napisał(a):

<u> jak najbardziej. Wystarczy tutaj dodać do listy obsługiwanych tagów: https://github.com/adam-boduch/coyote/blob/master/app/Services/Parser/Factories/CommentFactory.php#L22

Co do przekreślenia to nie wiem czemu nie działa w tej bibliotece CommonMark. Dodany jest parser InlinesOnlyExtension: https://github.com/adam-boduch/coyote/blob/master/app/Services/Parser/Parsers/SimpleMarkdown.php#L24

Dodałem te dwie rzeczy na repo.

Silv napisał(a):

TomRiddle napisał(a):

Ale muszę zrobić dwa edytory siłą rzeczy. Jaką mam alternatywę, dodać parametr isSingleLine do edytora? Na pewno nie.

A to czemu nie?

Bo nie tak się wytwarza oprogramowanie.

Nie dowala się ukrytych powiązań pomiędzy podułami. Wydziela się części wspólne i komponuje z nich większe moduły. Nie zrobię spaghettii z tego edytora żeby za pół roku nie dało się go utrzymać.

I tak zrobimy w przypadku edytora postów i komentarzy. To co będzie wspólne, dekoracje, kombinacje klawiszy, autocomplete, to się zrobi re-use, a reszta to będzie kompozycja. Wyeksportujemy dwie klasy, np MultilineEditor i SinglelineEditor (albo jakoś inaczej je nazwiemy), jedna będzie pochodzną drugiej, i użyjemy ich odpowiednio.

Nie wiem, jaką budowę ma edytor. Jeśli ma budowę modułową, X modułów, i do komentarzy wybierzesz np. X-1 modułów, to to jest właśnie to, o co mi ogólnie chodzi, jeśli chodzi o architekturę. Reusability. :)

Niektórzy teraz mogą być przyzwyczajeni do wstawiania Enter w komentarzu, zastanawiam się co się powinno stać jak ktoś kliknie Enter właśnie. Niby dodać komentarz, to chyba ma sens.

A co jeśli ktoś kliknie Shift+Enter? Na większości edytorów jeśli Enter submituje formularz, to Shift+Enter wstawia znak nowej linii, ale my tego nie chcemy. Może edytor mógłby mignąć animacją w CSS na 100ms, dając feedback że "tak, przyjąłem klawisz, ale nie dodajemy nowej linii tutaj", żeby user nie pomyślał że to bug?

Hmm, czy ja wiem? Może pozostawmy tak jak jest obecnie? Enter tworzy nową linie (bo być może wygodniej piszącemu dzielić na paragrafy? nie wiem) ale parser i tak ją zignoruje. I pozostawić Ctrl+Enter tak jak dotychczas.

Adam Boduch napisał(a):

Hmm, czy ja wiem? Może pozostawmy tak jak jest obecnie? Enter tworzy nową linie (bo być może wygodniej piszącemu dzielić na paragrafy? nie wiem) ale parser i tak ją zignoruje.

Tak, też tak myślałem, ale to daje takie poczucie że te nowe linie się pokażą, a potem zawód bo się nie pokażą :/

I pozostawić Ctrl+Enter tak jak dotychczas.

Okej.

TomRiddle napisał(a):

Niektórzy teraz mogą być przyzwyczajeni do wstawiania Enter w komentarzu, zastanawiam się co się powinno stać jak ktoś kliknie Enter właśnie. Niby dodać komentarz, to chyba ma sens.

Nic się nie powinno dziać, ani w przypadku Enter, ani w Shift+Enter. Natomiast skrót Ctrl+Enter powinnien służyć do publikowania komentarza, tak jak jest to obecnie w przypadku komentarzy, postów, wiadomości prywatnych, artykułów itd.

@Adam Boduch: Można wrzucić prototyp edytora komentarzy na 4programmers.dev? Bo jeszcze nie działa totalnie, zbugowany na maxa, ale coś już jest. Mogę też wrzucić na https://4playeditor.net/

Można, można tylko muszę przepiąć bo tam jest branch master podpięty. Wrzuciłeś na staging ?

Adam Boduch napisał(a):

Można, można tylko muszę przepiąć bo tam jest branch master podpięty. Wrzuciłeś na dev ?

Jeszcze nie wrzucałem nic. Tak pytam.

Z tego co pamiętam to na staging jeszcze jest ten commit z poprawionym Pattern::mask() performacen'owo.