Fejlettebb sorvége jel támogatást kapott a Notepad

Címkék
For many years, Windows Notepad only supported text documents containing Windows End of Line (EOL) characters - Carriage Return (CR) & Line Feed (LF). This means that Notepad was unable to correctly display the contents of text files created in Unix, Linux and macOS. [...] Starting with the current Windows 10 Insider build, Notepad will support Unix/Linux line endings (LF), Macintosh line endings (CR), and Windows Line endings (CRLF) as usual.

Részletek a bejelentésben.

Hozzászólások

Csak 20+ évet vártam rá... :D

--
trey @ gépház

Notepad++ a viragkotok hasznalnak; a nem tul nagy talentumok.

En meg normalis programozot nem lattam Notepad++-szal barmit is csinalni; olyan testidegen.

Kb. olyan ez, mint amikor valaki Dephiben programoz; affinitassal rendelkezo kollegak nem hasznalnak ilyen "cuccokat", es ha hasznaltak, akkor kiprobaltak mast, es valtottak.

Most johetnek a huszarok!

Hát nem tudom. Nyilván most már vannak más jók is ingyenesen Winre, de többeket ismerek, akik a Notepad++-ba szoktak bele és már az áll nekik kézre. Néha használom én is, szerintem semmi gond sincs vele.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Buta példa a többszörös vágólapra:
Van egy hibás XML file, amiben minden sor egy valamilyen tagg-el kezdődik, aztán tetszőleges szöveg, esetleg benne sub tagek, majd a sor végén hoppá, nincs ott a záró tag, mert valaki módszeresn elqrta.

Na, akkor Ctrl-F hogy kereső (find) módba lépjek
Bekattintom, hogy regexp keresés legyen
Beírom, hogy kalap nyitó kacsacsőr
Alt-Entert nyomva hirtelen lesz kétszáz kurzorom, mindegyik a megtalált szó végén, vagyis a tag nevének az elején.
Ctrl-Shift-Jobbra nyíl, és mindegyik keresett szó ki lesz jelölve, a záró kacsacsőrig.
Ctrl-C és mindegyik bekerül az adott kurzor saját vágólapjára.
End -el a sor végére ugrok
Begépelem, hogy nyitó kacsacsőr, perjel
Ctrl-V, és mindegyik kurzor beteszi az adott sorban előzőleg kijelölt és vágólapra tett taget
Begépelek még neki egy záró kacsacsőrt, és kész.

De mondok egy másik példát, még C# fejlesztő koromból:
Jött egy feladat, hogy kell csinálni egy bazi UI felületet, rajta egy raklap tök egyforma elemmel, nyílván mindegyikhez az adatkötéseket össze kellett rakni, különféle okok miatt nem szépen, hanem kézzel kellett rohadt sokat gépelni, értsd, minden egyes nyüves entitáshoz (változóhoz) egy-egy get set függvény, inicializálás, onchanged esemény, statikus és rendes, már nem is emlékszem még milyen cuccok kellettek, lényeg, hogy mindegyik cirka 10-15 teljesen egyforma sor, de a soron belül mindegyik másik változó névre hivatkozik.
Ekkor összeraktam egy text állományba a szükséges változókat, minden sor elejére "ráhúztam" a kurzorokat, majd Ctrl-Shift-End -el kijelöltem minden sort, de így az összes külön kijelölésnek számít, majd Ctrl-C.

Aztán nyomtam egy Del -t, hogy tűnjön el minden kijelölt szöveg, csak a rengeteg kurzor villogott szépen egymás alatt.
Na, akkor elkezdtem gépelni a litániát ami kellett és egyforma minden változónál, majd amikor a változó neve jött, akkor nyomtam egy Ctrl-V -t.
Így szépen kialakultak a csak a változó nevekben eltérő sorok.

Tudom, vannak erre más toolok is, meg osztály tervező cuccok, de igazából ezzel hamarabb meg lehetett lenni mint hogy az ember elkezdi beadagolni az adott toolba hogy mit akar, és milyen formában.

Na. Most, hogy ezt mind begépeltem, rájöttem, hogy egy kis google kereséssel és egy képpel sokkal egyszerűbben is megoldhattam volna... :-)

Íme:
http://thume.ca/assets/postassets/editors/sublime_vim.gif

Nem a 7zip fejlesztője volt az, aki nyafogott, hogy a Windows 8-ban megváltoztatták egy valamelyik API hívás viselkedését, amelyiknek a doksijában világ életében ott volt, hogy csak egyszer hívd meg az alkalmazás futása során és igazából csak véletlenül működött Windows 7-ig? Meg, hogy nagyjából mostanság jutott el odáig, hogy ne VC++6-al fordítson, hanem haladjon egy picit a fordítók terén? És más hasonló retardságok?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A Notepad++ részével egyetértek. Egy ideje Linuxon is azt használom Sci-Te formájában, mióta a KDE-s Kate editort elcseszték végleg az 5-ös verziótól kezdődően.

A 7-zip-et viszont Windows alá sem szoktam feltenni, a Double és a Total Commander pluginnel kezeli a 7z-állományokat, ki-betömörítés, tesztelés, titkosítás, stb..

No keyboard detected... Press F1 to run the SETUP

Ez annyira így van, hogy én pölö üzemszerűen Powershellből generálok egy Bash állományt, amit aztán a linux gépeken jól be source -olok.
( Mindenféle AD -ból kibányászott adatokat gyömöszölök bele egy bash asszociatív array -ba, mert ez nekem így jó.)
Csakhogy a Bash háklis arra, hogy a text állomány lehetőleg ne kezdődjön hexa szeméttel, (érthető módon) így a mindent helyére másoló scriptem a helyére rakás előtt még jól kiszedi belőle ezt a hülyeséget.
Tudom, lehetne ANSI is, de akkor meg valami más volt a nyűg, asszem akkor meg a Windows egy másik részével akadt össze, a Windows önmagával való kompatibilitásának fényes bizonyítékaként.

Disclaimer: Persze nem kizárt, hogy a Windows így jó, és csak én "fogom rosszul", - ha lophatok egy elhíresült mondatot.

A bash nem hiszem, hogy háklis rá.
Próbáltad már indítani úgy, hogy bash scriptneve.sh ?

Amire gyanítom te gondolsz, csak nem tudtad adekvátan megfogalmazni, az az, hogy ha raksz rá X bitet, akkor nem fog elindulni, mert a kernel ami a shabang alapján interpreternek átpasszolná az indítását (kivéve persze, ha pl. egy elf-el van dolga) fogja ráncolni rá a szemét és nem fogja elindítani. De az egy másik probléma. Ha ez a jelenség és a bash script_bom_mal_kezdve.sh lefut, akkor nem a bash a háklis rá. Persze ettől még lehet a bash is háklis rá. De ebből a pongyola leírásból nekem még nem jött át, hogy el tudtad különíteni a két dolgot.

A szabvány engedni ugyan engedi, de nagyon nem ajánlja, általában véve marha rossz gyakorlat BOM-ot rakni UTF-8 fájlba. Ez a de facto standard encoding már minimum 10-15 éve lényegében MINDENHOL, nem kell előre jelezni, hogy helló, ez tényleg UTF-8 fájl lesz.

Nem igaz, hogy ennek a cégnek ez a feladat ekkora megugorhatatlan problémát jelent.

Idemásolok egy részt a wikipédiáról, ahol azért egy hangyányival részletesebben kifejtik ezt:

"""
The IETF recommends that if a protocol either (a) always uses UTF-8, or (b) has some other way to indicate what encoding is being used, then it "SHOULD forbid use of U+FEFF as a signature."[8]
"""

De mivel rendes szövegszerkesztő (legalábbis itt többek szerint) többféle kódolásban tud menteni, ezért az első nem áll fenn, a második meg pont ennyire lenne gagyi megoldás, cserében a BOM legalább ismert lehetőség. Szóval nem értelmetlen, csak fölösleges.

(De tény, ha aktívan kellene Win-t használnom, és is prüszkölnék attól, hogy ez az egyszerű funkció - akár a sorvégjelről, akár a kódolás beállításáról van szó - hiányzik.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

mostmár csak azt a 20 évet kell kivárni, amíg a vezetőség engedélyezi, hogy rendszeresítsék a windows 2028-ban, és bekerüljön a rá következő pöcs kedden.

A több évtizedes megfeszített munka kezd beérni, végre egyszerre lesz használható a status bar és a word wrap is.

Aztabetyár.... 2018-ban micsoda fejlesztés ez már....
Akkor innentől notepadban fogok szerkeszteni linux alatt..... jah mégse.... :D

A Wine-s notepad már régóta tudja ezt :D Sőt, Unicodeban is lehet menteni vele.

Nálam mindig a legújabb Wine van fent Archon, de most megnéztem, és nálam nincs benne ilyen feautre. Bár nem lehetetlen, hogy ennek ellenére lekezeli a linuxos sorvégeket, és kapásból UTF-8-ba ment, de beállítási lehetőséget ilyenre nem látok benne.

No keyboard detected... Press F1 to run the SETUP

Szerintetek ez használja a BUILD-en bemutatott AI szolgáltatásokat a UNIX line-end felismerésére, vagy rájöttek a nagy OSS őrületben, hogy a file utility 20 éve tudja a funkcionalitást és belenéztek a forrásába?

Birom a hup-kozosseget.

A Microsoft ha elkezdene kinyalni a seggeteket, azt sem elveznetek; mondanatok szar ez!

Azzal nyalja ki a seggem az MS, hogy osszerak egy majdnem mukodo notepad-ot? Komolyan?

Szoval ha en most adok neked egy felig kesz szart, amibe ugyan tudsz irni szoveget, de nem menti el jol az allaomyant, akkor Te meg fogsz dicserni? Es megvedesz azoktol, akik azt mondjak hogy ez szar, mert mar 40 evvel ezelott is tudtak menteni editor programok file-ba?

Vagy fel kell vennem az MS nevet, hogy rajongj ertem? :D

... legközelebb meg már lehet, hogy 64kByte-nál nagyobb txt fájlt is be fog olvasni :D

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

A macOS sortörés megtévesztő lehet, esetleg a Mac OS-re gondoltak, a Mac OS X / OSX / macOS elődjére. Míg az előbbi valóban CR-t használt, a macOS, mint UNIX származék, az LF-et tol. És most ne vegyük ide azokat a dinoszaurusz programokat, amelyek túlélték a Mac OS -> Mac OS X váltást.

--
Kinek nem inge, ne vegye gatyára

:) Hurrá! [irreleváns] NEM használok nótpadot eonok óta.
ha win alatt kell szerkesztenem akkor notepad++ azzal meg nincs baj
és ott is van gvim , emacs, sublime, atom, stb
--
Avoid hangovers, Stay Drunk!

Amugy azon gondolkodtam, hogy MacOS <= 9-en ahol a CR volt az uj sor, vajon hany curses/curses-szeru programnak lenne baja? Vagy egy "jobb ncurses hivas" CR helyett maskepp tolja sor elejere a kurzort ujrarajzolashoz? Anno C++-ban irtam olyat, ahol CR-rel oldottam meg, hogy hany % a progress es ugrottam a bash-es sor elejere, abbol indultam ki. Az a regi MacOS-en kb szazalekpontonkent uj sor lett volna, ha jol ertem. Meg ha a program legvege jol is ment volna az std::endl miatt.

Kb 20 éve nem programoztam cursesben, de mintha ott nem printf-fel hanem valami wprint-tel kellett volna írogatni - márpedig akkor nyilván rendesen le kellett kezelje az ilyesmit. Legalábbis általam írt curses-es kód ment UNIX-on, meg Windows-on is PDcurses-sel.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Unix es Windows ok

CR = CR mindketton
newline kulonbseget meg (CRLF vs LF) konnyu implementalni

Keddesem: a Unix elotti Mac OS-eket (<= Mac OS 9) tamogatta-e a curses? Mert azokban a CR (szabvanytalan modon) uj sort jelentett. Masik, hogy Unix elotti Mac OS-en volt-e valami, ami "visszarakta a kurzort az elejere ujsor nelkul" (ami a tobbi rendszeren CR)

Nem ertem a problemadat. Curses-t hasznalo kodot jellemzoen C-ben irt az ember, ott meg \n -nel jelezted a mit is? Azt, hogy a kovetkezo sor elejere akarsz kerulni. A hasznalt OS-tol fuggetlenul. Ezt pl. a UNIX vilagban a tty alrendszer ugy oldja meg, hogy van egy halom (input es output) flag, amelyet parancssorbol pl. az stty paranccsal piszkalhatsz, es ezek a jelzok hatarozzak meg, hogy CR vetele / kuldese eseten legyen-e belole / mellett LF (is). Vagy epp hanyagoljuk el azt (lasd: igncr, inlcr, icrnl, onocr, onlcr, ocrnl stty parametereket). Es azert kerul az Enter hatasara a kurzor oda, ahova, mert ugy van a tty reteg beallitva - nem pedig azert, mert a \n kocsivissza-soremelest jelent. A \r kocsivisszat jelent, a \n pedig soremelest - mar technikailag.

Ja a kerdesre a valasz: ha valaki portolta a UNIXokra irt cursest macOS-re, akkor igen :-) - egyebkent nem.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?