Poznámkový blok ve Windows 10 dostává podporu unixového zalomení řádků

Fakt jo? Dvacet pet let na to cekam a dockal jsem se...... Budu muset do Redmontu poslat nejaky dekovny dopis. Nebo rovnou darek.

I na poštách v US mají svoje "kolbaby". Takže by to došlo. A nedělejte si iluze o tom že občas sami nevědí jak se něco pise.

https://www.youtube.com/watch?v=sPv8PPl7ANU

https://www.youtube.com/watch?v=0Mk_qzvLLXM

https://youtu.be/d_AP3SGMxxM

Ty brďo! Čo bude ďalšie? Telnet server? ... akej vzrušujúcej modernej doby sme sa dožili!

Jak další přidají podporu samotného CR ze světa Applu.

Teď jsem se jinde dočetl, že implementovali i to. Tak to už jim nezůstalo nic k inovacím a mohou tým okolo Notpadu rozpustit.

Jako další bude přidáno odesílání veškerého editovaného obsahu do microsoftu, kde bude (samozřejmě s respektem k ochraně soukromí) pečlivě analyzován za účelem zlepšení uživatelské zkušenosti, která je ale i teď naprosto dokonale úžasná. To vše po tom, co to uživatel po restartu celého počítače odsouhlasí kliknutím na jednu z odpovědí na 50 otázek.

Anekdota ze života uživatele: uprostřed práce BSOD a nucený automatický reboot. To se nějak sešlo s připravenou aktualizací, takže opětovné spuštění stroje trvalo asi 20 minut. Když se zase konečně ukázala plocha, nejenže byla část práce v kopru, ale navíc všechny ikony byly sesypané na jednu stranu. A pak vyskočilo okénko a v něm bylo něco jako "windows jsou stále lepší, podívejte se jaké skvělé vlastnosti jsme přidali". Tohle za ty prachy nikde jinde nedostanete.

Telnet je na Windowsoch uz davno :)

To teda neni, byl vyhozen :(

Krásne, len kdyby samotný Win10 bol aspoň štvrťofunkčný... neschopný Mrkvosoft.

Konecne muzu vyhodit dos2unix & unix2dos!

Vždycky je možnost přejít na dosový EDIT z W98, ten to umí načíst a zobrazit správně. Akorát po uložení tam bude CRLF. A v binárním režimu dovedl teprve zajímavé věci!

O čtvrtstoletí pozdě. Jinak ok.

IT má docela velkou setrvačnost.

Linux ve zkratce:
"Windows, Unix, and "classic" MacOS all use different conventions for indicating the end of a line of text. Windows does things correctly: it uses a pair of characters, the carriage return (CR), followed by the line feed (LF). Two characters are needed because they do different things: the CR moves the print head to the start of a line; the LF advances the paper by one line. Separating these is valuable, as it allows for effects such as underlining to be emulated: first print the text to be underlined, then issue a CR, and then print underscore characters.

Unix, however, uses a bare line feed to denote that a new line should be started. Classic MacOS (though not modern macOS) uses a bare carriage return for the same purpose. Given the meaning behind the CR and LF characters, these operating systems are both obviously wrong, but sometimes wrongness is allowed to prevail and persist."
ZDROJ: https://arstechnica.com/gadgets/2018/05/notepad-gets-a-major-upgrade-now-does-unix-line-endings/

Hmm... Super, ale to že něco vyžaduje tiskárna neznamená, že kvuli tomu musím doplňovat nějaké znaky do textu. To je skoro to samé, jako kdyby tiskárna vyžadovala za každým tisknutelným znakem napsáno PRINT, jen si představte implementaci poznámkového bloku ve WPRINTiPRINTnPRIN­TdPRINToPRINTwPRIN­TsPRINT... To má řešit driver tiskárny ;)

Mechanický stroj to naopak vyžadoval. Pokud jste jen stiskl páku, tak jste udělal "line feed" a jen se vám posunul papír nahoru. Pokud jste chtěl jen "carriage return" tak jste zatlačil na kolečko ručního posuvu papíru a celý vozík odtlačil zpět doleva. Pokud jste chtěl udělat oboje najednou, tak jste zatlačil na páku - ta nejprve posunula papír a když byla na doraz, tak jste začal tlačit vozík. Pro člověka sice jeden pohyb, ale pro psací stroj to byly pohyby dva, byť navazující.

Zde je třeba se lemplů z Microsoftu zastat - řešení Microsoftu považuju za správné, protože dělá přesně to, co ony 2 řídicí znaky popisují, přičemž dodržuje kontinuitu z minula. Zda je či není zaimplementováno použití pouze např. CR s přepisem řádku nebo LF, je nepodstatné. Klidně by bylo možno přidat řídicí znak „begin of new line“, ale nic by se tím nezískalo.
Takže z mého pohledu to má Microsoft čistě technicky v pořádku, Unix a Apple chybně.

Dejte prosím mínus, a to i v případě, že s názorem nesouhlasíte. Děkuji.

To je slušný level doublethinku, když v jedné větě chválíte Microsoft jak řešení "dělá přesně to, co ony 2 řídicí znaky popisují" a hned ve druhé tvrdíte, že je jedno, že vlastně nedělá, co ty znaky popisují...

CR a LF jsou řídíci znaky pro tiskárnu, už na obrazovce nedávají smysl, natož v datovém formátu souboru, kde zbytečně plýtvají místem.

To sice jo, ale proč to má Unix špatně? Vždyť už ZX Spectrum to mělo správně a konec řádky byl znak 13!

A teď bez ironie: oni si to autoři OS i terminálů dělali dost po svém. CR/LF jsou ještě fajn, ale podívejte se, jak si třebas konec řádku vymysleli pánové ve VMS. To bylo teprve žůžo!

Navíc tohle není vynález Microsoftu. CR+LF je tam proto, že DOS vycházel z CP/M, které to takhle mělo odjakživa (tedy od roku 1974).

https://en.wikipedia.org/wiki/Newline

CR a LF jsou především jakýmsi zavedeným standardem. To především. Nevyhovují-li pro zobrazení (opravdu?), mají být nahrazeny - recyklace významu obecně není následováníhodnou praxí.
To plýtvání místem jste nemyslel vážně, že ne?

To by snad šlo obhájit, kdyby Windows aplikace opravdu interpretovaly CR a LF korektně, tedy při CR tiskly znaky přes sebe a při LF šly na další řádek bez návratu vozíku. Ale to nedělají. Takže smolík.

Ach jo. "Řekněte WOW!: A řekněme, zase subjektivní rýpnutí do jinak informativní zprávičky. Navíc mi připadá, že ta zprávička je tu celkem zbytečná - čekat na rootu tak low-level věc pro win 10 jako změny v jeho notepad, fakt už nějak nevím.

K věci:

Notepad na win vždy byl low-level. To, že čistý notepad pracoval pouze s CR LF, mi nepřijde divné, stejně jako se nepodivuji že *nix cat > foo.txt při přepisu z konzole generuje jen LF a ne CR LF. Pochopitelně.

Jakmile bylo třeba více, i na čistý txt, člověk už od dob w95 buď použil wordpad (pokud stačilo čtení či nepotřeboval zachovat pouhé LF na výstupu a nevadila konverze do CR LF po save), nebo si doinstaloval notapad++ (či podobné), stejně jako na *nix použil vi (pokud chtěl lépe interaktivní než ed, navíc linux distribuce často mají vi klony v základu, bez nutnosti doinstalace).

Že notepad ukládá CR LF bych překousl (resp. jak to ukládá je mi šumák), ale že bez CR nezalomí řádek na obrazovce mě dlouhé roky parádně vysíralo. Proč notepad samostatné LF prostě ignoruje?

I kdyby text se samotným LF
                         měl být zalomený takhle LF
                                                 protože nikdo nevrátil hlavu LF
                                                                              na začátek řádku.

Mmt, já měl za to, že pokud to jen jde, tak prostě ukazuje znaky tak, jak je má definované ve fontu zvoleného písma. Případně prázdný čtvereček, není-li ve zvoleném fontu definice znaku.

Takže třeba v případě zvoleného písma "Terminal" mi tam pro 0xA ukazoval takovou tu inverzní kuličku, nebo třeba pro 0x6 zobrazil list. Tedy co si pamatuji. Prostě, co jsem si nadefinoval v mém fontu písma, to zobrazil. Použitelné a dost používané tam tehdy u IBM byly tuším takové šipky stylu trojúhelníčky.

Už ani nevím jak tabelátor, což byla tuším jediná další výjimka po konci řádky, zda jej nějak rozdělal na mezery (předpokládám) či u písma terminal ukázal ten znak 'kolečko", ale neinverzní (tak, jak byl u IBM PC definován v code page 437). Už si nepamatuji.

> pokud to jen jde, tak prostě ukazuje znaky tak, jak je má definované ve fontu zvoleného písma

To ale nedělá - když tam dáte sekvenci CR LF, tak odřádkuje. I když by je určitě šlo zobrazit jako znaky z fontu.

"Proč notepad samostatné LF prostě ignoruje?"

Protoze notepad neni typograficky program a uzivatele by to pri otevreni neznameho souboru povazovali za chybu?

Takže namísto očekávaného chování, které by uživatelé považovali za chybu uděláme krok stranou a při otevření souboru, který je řádkovaný samotným LF ukážeme jediný dlouhý dlouhý dlouhý řádek, protože to rozhodně není chybné chování.ASCII 10 (line feed, LF, \n, ^J), moves the print head down one line, or to the left edge and down. Used as the end of line marker in most UNIX systems and variants. Zdroj: https://en.wikipedia.org/wiki/Control_character.Mimochodem, jak se ti čte jediná dlouhá nezalomená řádka?Chybějící mezera za interpunkcí je schválně, protože nemlich to samý dělal notepad při ignorování LF.

"Takže namísto očekávaného chování, které by uživatelé považovali za chybu"

Pokud to uzivatele povazuji za chybu, pak nejde o ocekavatelne chovani.

Jak říkám, notepad není "program pro editaci textu". Je to přímé zpřístupnění jednoho z nejnižších řídicích prvků windows (class EDIT), který by měl hlavě z fontů (definic fontů) zobrazit pro upravení co se dá, včetně znaků menších než 32 (z historických důvodů). Prostě jen rozšíření základního static conrtrol (class STATIC) o možnost editace.

Proto i ta ( na první pohled nesmyslná) omezení na 48K, 64K (kdysi u reálného režimu a 16 bit), pomalé načítání větších textů (v nových verzích) a podobně.

Nic více, nic méně.

Už i úlitba ES_MULTILINE (možnost víceřádková při CR LF) a rozbalení tabelátorů v rámci EDIT je něco navíc - někdy nepříjemné, nechtěné. Čím méně bude zasahovat do toku písmenek řídicími prvky, tím lépe. Ideálně jako cat (navíc s editační možností při vstupu - rozšíření STATIC)

Pro úpravu základních textu (s použitím řídicích znaků) slouží/sloužil programy wordpad/write. (a pro programátory class RICHEDIT_CLAS­S/MSFTEDIT_CLASS )

To je Jezek. Nedokaze odlisit subjektivni nazor od objektivnich faktu. A furt nedokaze pochopit, ze nekam subjektivni nazor patri, a nekam ne. S touhle poruchou se potyka uz dlouho.

Tak, a na rade je drag and drop textu, a potom možno pamätanie si viac ako 1 krok späť

Přiznám se, mně se ty změny moc nelíbí.

Notepad kdysi býval vždy prostě jen windows class EDIT. Čili editační "objekt", určený v normálním případě pro pár řádek, bez většího formátování, atd. Na vše další byl (pod win) write/wordpad.

... také jsem tak někdy nepřímo notepad využíval, např. při kontrole, zda při programování, jako horní limit, zda už to není na RICHEDIT_CLASS ...

Pokud nějaké změny, tak proč to sakra cpou do low-level notepadu? Buď to znamená zneužití jména notepad na něco jiného (nového, jinak fungujícího) anebo udělají změny přímo v EDIT class, což považuji za ještě horší (pro zpětnou kompatibilitu).

Abych to přirovnal do *nix světa. Když už jsme na root.

Po cat > foo.txt nebudu chtít menu či automatické přepnutí do okenního prostředí "že když přece chci napsat text tak pokud běží i grafické prostředí, tak ať to kouká být nějaké hezčí". Od toho ať si uživatel spustí plnohodnotný editor.

Stejně tak po (notepadovském) windows control EDIT nechci žádné další formátovací specialitky či změny v chování a zasahování do fontů. Stačí už to, co tam je. Od toho ať si spustí plnohodnotný word editor (wordpad).

Případně, jinak, ani nechci obdobu alias (nepřesné) "cat>" aby namísto toho automaticky zapnul vi(like). Pokud potřebuji, tak si vim pustím ručně, stejně jako si ručně pustím wordpad/notepad++. A když chci low-level windows notepad, spustím si notepad. Pokud chci low-level cat, spustím si cat.

Notepad je textový editor, write wordprocessor, jsouto uplne jine kategorie aplikaci. Windows desitky ket slýsny textovy editor chybi a cim vic svet prechazi z binarnich datovych formatu na textove, tim je to palcivejsi. Linuxový gedit je proti notepadu úplná kosmická tenologie.

Ať to implementují přes WSL!

"Windows desitky ket slýsny textovy editor chybi"

Tak urcite, stamiliony uzivatelu win nedelaji nic jineho nez edituji text ;-)))

Takze tie subory budu mensie? Parada :-)

WOW!

A stále zatuhne, když v něm člověk otevře soubor, co má pár MB nebo víc? Nebo už i tohle po 25 letech opravili?

Není šance. Nevím, kde je tedy ta hranice, ale v práci logy notepadem otvírat nemůžu. Klidně to šrotuje celou přestávku na oběd a pak to spadne. Notepad++ to otevře okamžitě. Velikost, při které to nastává, z hlavy nevím, ale nic extrémního to není, jsou to v 99% případů aplikační logy vytvořené během několika minut.

Jo přesně. Taky tohle řeším u logů. PSPad je o něco lepší, ale taky tuhne. Pěkně se chová prohlížeč textových souborů v Total Commanderu po F3. Je to jen prohlížeč a ne editor, ale to zrovna u logů nevadí. Je celkem takové trapné, když firma, co vydělává miliardy není schopná napsat jednoduchý textový editor dobře. Stejně tak třeba Oraclu celkem běžně při větších akcích tuhne SQL Developer. Taky s firma s miliardama v kapse a není schopná pochopit, že v GUI vlákně se nedělají potenciálně dlouhé operace, že potenciálně dlouhé operace musí jít přerušit, že soubor, co se otvírá, může být opravdu velký atd. Jasně že notepad ani gui k databázi není na těch produktech to hlavní. Ale i kdyby to byl jen reklamní prostor (jako že není - logy se reálně čtou, sql se v něčem vyvíjí), tak by ten reklamní prostor nemuseli mít pokakanej.