Názory k článku
Poznámkový blok ve Windows 10 dostává podporu unixového zalomení řádků
-
Rieger (neregistrovaný)
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.
-
Digi (neregistrovaný)
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/ -
Terorist (neregistrovaný)
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 WPRINTiPRINTnPRINTdPRINToPRINTwPRINTsPRINT... To má řešit driver tiskárny ;)
-
Mechanickej psaci stroj mel paku na posuv valce a jednim tahem se udelal jak CR tak LF.
Ano, ale stroj také umožňoval nastavit řádkování (1, 1,5 nebo 2). Mnohé stroje uměly i řádkování 0, tj. páka sloužila pouze jako CR, bez LF. Pokud jste chtěl CR jen mimořádně, tak se válec posunul ručně (bez užití páky). Pokud jste chtěl jen LF, užil se otočný ovladač (kolečko :)) na straně vozíku.
CR a LF byly tradičně oddělené příkazy. Maticové tiskárny uměly horizontální posun vpřed i zpět (CR), ale vertikální jen vpřed (LF).
Na tehdejší dobu byla volba CR LF od Microsoftu poměrně logická, ale docela brzy se přežila.
-
Karel (neregistrovaný)
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í.
-
SB (neregistrovaný)
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.
-
Karel (neregistrovaný)
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).
-
xxxxx (neregistrovaný)
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).
-
Ravise (neregistrovaný)
Ž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. -
xxxxx (neregistrovaný)
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.
-
Ravise (neregistrovaný)
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.
-
Pokud to uzivatele povazuji za chybu, pak nejde o ocekavatelne chovani.
Myslím, že tím se myslí rozdíl mezi přirozeným a striktním vnímáním. Např. ve výrazové logice má jiný význam dvojitý zápor, než v běžném vnímání. Poměrně často se stává, že někdo vyhotoví analýzu stavu - a tu popíše velmi exaktně. Pak ten samý text čte běžný smrtelní (manažer :)), ale pochopí z toho polovinu a z druhé poloviny si vyvodí dokonce opak. (A my to tu pak odborně rozebereme).
-
xxxxx (neregistrovaný)
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_CLASS/MSFTEDIT_CLASS )
-
xxxxx (neregistrovaný)
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).
-
xxxxx (neregistrovaný)
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.
-
eee (neregistrovaný)
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.
-
Ehm (neregistrovaný)
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.
-
Honza (neregistrovaný)
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.
