On 30/08/2021 13:20, Mateusz Viste wrote:
>>>>> Pokrótce obejrzałem. Pierwszy szok: rpm o rozmiarze 194 MiB.
>>>> To słaby argument. Atom wstaje szybko i tylko to się liczy.
>>> To nie był żaden argument :)
>> Wobec tego, skoro to nie argument, to co Ci przeszkadza?
> Rozmiar nie jest argumentem. Argumentem jest ból brzucha, który rozmiar
> u mnie powoduje. I on mi przeszkadza. Naprawdę.

Rozumiem. Czyli dyskusja bez sensu, nie masz argumentacji racjonalnej.

> Przecież podałem: widząc edytor tekstowy o rozmiarze 400 MiB ściska mnie
> pod żołądkiem. A ja wolę żyć bez bólu, niż z bólem. Czy to
> wystarczająco racjonalne?

Nie, to ani troche racjonalne. Rozmiar współczesnego software jest
wiekszy niż w czasach Atari. Bo i mozliwości większe. Dam przykład: do
pythona jest autouzupełnianie wspomagane AI. Ile GB poświęcisz na
ficzer, któy kilkukrotnie przyspiesza pisanie kodu? Gdzie jest granica
za którą boli brzuszek? Może to ból fantomowy?

Dlaczego śladowy rozmiar na dysku jest argumentem? Rozmawiamy o
rozmiarze będacym promilem obecnej pojemnosci komputera z hipermerketu
do oglądania pono. To dużo?

> Podświetlanie składni jest.
> Auto-indentacja jest (brak "napierniczania spacji"!).
> Search i search & replace są.
> Konfigurowalna szerokość tabulacji jest.
> Auto-save jest.

Wniosek: to nie notatnik.

> Nic więcej mi nie potrzeba.

Wydaje Ci się. Najzywczajniej nie miałeś kontaktu z narzędziami takimi
jak Atom, dlatego nie widzisz przestrzeni do rowijania się.

Pocieszę Cię: ja tez nie używam Atmoma. Ale używam np. Visual Studio.

> Jest nawet kilka dodatkowych, potencjalnie
> fajnych rzeczy, choć z nich nie korzystam: zawijanie kodu, tworzenie
> zakładek w kodzie czy też podpowiadanie nazw zmiennych.

Więc to nie jest notatnik. Skąd tu się wziął notatnik w tej dyskusji?

>> I widzisz czytelne diffy? Czy masz już w mózgu parser united diffa?
>> Widziałeś jak się pracuje z Tortoise/Rabbit lub ze zintegrowanym VCS
>> w edytor?
> Tak, widziałem. Gdybym całe dnie spędzał na oglądaniu diffów to może
> używałbym jakiegoś upiękczacza, ale analiza diffów to może z 5% mojego
> czasu. svn diff jest dla mnie jak najbardziej czytelny, i zupełnie
> wystarczający. A wygląda tak:
>
> svn diff unchtest.c
> Index: unchtest.c
> ====================================================
===============
> --- unchtest.c (revision 339)
> +++ unchtest.c (working copy)
> @@ -80,7 +80,8 @@
> int decodedbytes;
> unsigned char buffer[4096];
>
> - bytes = min((rand() % 256) + 1, file_chunk_len - bytesprocessed);
> + bytes = (rand() % 256) + 1;
> + if (bytes > file_chunk_len - bytesprocessed) {
> + bytes = file_chunk_len - bytesprocessed;
> + }
> printf("processing %4zu bytes of chunked data", bytes);
> memcpy(buffer, file_chunked + bytesprocessed, bytes);
>
> Ja to czytam bez problemu, nie potrzeba mi żadnych fikuśnych kolorków.

Bo oto trywialny diff. Dodałeś w nim linijki.

Teraz zrób to samo dla difa w którym zmieniłeś 1 znak w 100 znakowej
linijce.

Jak wiem, że grunt w dyskusji to dobierać przykłady podpierajace własne
tezy, wiec sie nie dziwie, że wybrałeś przykład diffa czytelnego dla
ksiegowej.

> A gdybym *naprawdę* potrzebował zastanowić się głęboko nad jakimś
> diffem, to po prostu wrzuciłbym go do pliku i otworzył domyślną,
> systemową diff-wyświetlarką (kompare).

Co porządy edytor IDE może zrobić automatycznie, bez *dodatkowej*
czynności. I dużo, dużo więcej.