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

 ( trey | 2018. május 9., szerda - 8:34 )
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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

--
trey @ gépház

Türelmes vagy. :D
Egyébként nem az volt a mondás, hogy notepad -> kuka, van helyette wordpad?

wordpad? :D pff.

inkább a Notepad++

Nem mindenki ezt teszi fel windows-ra másodikként a 7zip után? :)

--
zrubi.hu

A wordpad benne van (volt?) a windows-ban, mint tartozék. :)
Mondjuk én cygwin+vim-re szavaztam, ha már... notepad+-t talán nem is láttam.

Jó Ég!
Már rég elfelejtettem, hogy van wordpad is, de jelentem a Win10-ben még megvan.

Nem.

Amióta van Sublime Text ( https://www.sublimetext.com/ ) azóta a Notepad++ nálam nyugdíjba ment.

A többszörös kurzor, többszörös vágólap feature zseniális, ráadásul platformfüggetlen, így Windows és Linux alatt is pont ugyan olyan kedves velem.

+1

Köszi az ötletet! Megnéztem, tetszik, marad!

Akkor a VSCode-ot és az Atom-ot nézd meg esetleg :)

+1


alias killall='echo "Wenn ist das Nunstück git und Slotermeyer? Ja. Beiherhund das Oder die Flipperwaldt gersput." | espeak -vde' #That's not funny.

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!

Nekem bejön a Delphi. És a notepad++-t is használom konfigfájl heggesztésre Windowson - mert a nodepad.exe bénán kezeli a fájlvégeket :-).

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…

LOL

A béna fos, elavult, gagyi, gyárilag szállított notepad.exe HELYETT használt alkalmazásról beszélünk. Nem programozóknak, meg designereknek, meg IT guruknak való cuccról.

Nem mellesleg a npotepad++ ingyenes és open-source. ;)

--
zrubi.hu

Ar / ertekben 0:infinity modban veri a Sublime-t ;)

"En meg normalis programozot nem lattam Notepad++-szal barmit is csinalni; "

Makró képessége viszont hasznos, amit meg nem nagyon láttam másban. De egyébként miért programozna bárki is bármit Notepad++-ban?

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

A többszörös vágólap alatt nem tudom mit értesz (clipboard manager? az nem az editor dolga), de többszörös kurzort tud.

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

Ja hogy erre gondoltál, ezt tudja. Lehet, hogy nem pont úgy, ahogy sublime-ban, most nem vagyok gép közelben, hogy megnéztem. (Illetve én SciTE-t használok, de mindkettő scintilla alapú editor).

+1

Mégnemvót: Emacs, nekem az a második a 7zip után.

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

omg, azért a kettő nem ugyanazt tudja, nem is váltja ki egymást.
A notepad text editor, a wordpad pedig rich tect editor.

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

Amikor megjelent a wordpad (XP-ben?) akkor voltak ilyen elképzelések, csak azt nem tudom, hogy a MS részéről vagy inkább a felhasználókéról.

Wordpad szerintem már a win98-ban is volt és akkor RTE volt.

Szerk.: tévedtem, Win95. https://en.wikipedia.org/wiki/WordPad

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

Microsoft Write forever, Windows 1.0 óta :)

+1 :D

Bizony, ez már a fényes 21. század. ;)

20 év múlva lehet még az is belekerül, hogy default UTF-8-ba mentsen, ne ősrégen elavult (saját) kódlapos retek encodingokat használjon. Ez sokkal alattomosabb tud lenni.

Ne hasznalj ekezetet es problema megoldva :D

Amúgy is ha jól rémlik, a Windows (legalább is notepad-ban) furán kezeli az UTF-8-at, mintha valami plusz bájtot biggyesztene a szöveg elejére.

> furán kezeli az UTF-8-at, mintha valami plusz bájtot biggyesztene a szöveg elejére

Az a BOM lesz, nem? Ha igen, azt engedi a szabvány.

Lehet engedi, csak akkor meg egy másik program nem volt felkészítve a szabványra, aminek be kellett volna olvasnia.

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.

Ez már szinte unix! ;) Hiszen a szabványos .TXT kiterjesztéshez bármilyen tartalom tartozhat.
Tehát csak ezért akad össze önmagával.

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.

Itt a kulcs:

"amit aztán a linux gépeken jól be source -olok."

Valóban, efölött elsiklottam.

Viszont így számomra érthetetlen, hogy a bash ezen miért akad fönn.
Nem látok rá értelmes, racionális indokot, hogy source-oláskor egy bom-mal kezdődő fájlra picsogjon.

Érdekes!
Mi a pontos jelenség?

sztem akkor ott a BOM-ot egy parancsként értelmezi.
sőt, mivel a '#' előtt nincs whitespace az egész első sort egy parancsként akarja futtatni.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

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.

A legszebb, amit eddig láttam: C# ojjektumból hexdump (ez egy fícsör).
A végeredmény BOM+ASCII. :-D

meg a php fájlok elején kacsacsőr-kérdőjel előtt a BOM... "headers are already sent on line..."

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

BOM (byte order marker) UTF-8 kódolásnál értelmetlen.
--
ulysses.co.hu

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.

igen.
még csak 20 éve avult el, és máris itt vannak a 25 éve minden text editorban természetes fícsörök-ök!

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.

de az egy vacak koppintás!

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!

Ez nem ilyen egyszerű! Évtizedekig szemétkedtek, most hirtelen jó fiúk lettek, ez azért gyanús. Majd ha legalább 5 éve nyalja a seggemet kitartóan és közben nem harap bele semmibe, akkor majd elkezdek megbízni benne!

És ha fűbe...? ;)

Akkor majd megsiratom. Vagy nem ;-)

Ott is ki kell várni az 5 évet. Csak azért mert nem mozog, nem lélegzik, még nem hiszem el nekik azt sem hogy halottak! ;-)

+1 :D :D :D :D

-42-

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

Kaparnak. Elkestek vele.
____________________
echo crash > /dev/kmem

... 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

… már évek óta tudja :)

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

lol
Ezt hányan vették észre vajon?
Volt itt valahol oldalt történelem link.

Tukon ulve vartuk ezt a feature-t :)

Lenyűgöző, mire képes a tudomány a XXI. században! :)

https://hup.hu/cikkek/20161205/fejlettebb_symlink_tamogatas_a_windows_10-ben#comment-2044370


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Köszönöm, erre gondoltam. ;)

Üdv,
Marci

:) 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?

Hát oda kb terminállal együtt kellett portolni, azon kevés OS egyike, aminek nincs TUI konzolja.