Finns det *någon* editor som faktitiskt fungerar förutsättningslöst?

Permalänk
Avstängd

Finns det *någon* editor som faktitiskt fungerar förutsättningslöst?

I gamla DOS och i Windows kan notepad och MS DOS-Edit öppna vilka filer som helst och visa vad de faktiskt innehåller, inte vad de representerar.

I synnerhet MS DOS-Edit är suverän på detta. Med parametern /NN där NN är en siffra kan vilken fil som helst öppnas och visas binärt med kolumnbredden NN. Editerbart såklart. Vilket ASCII-tecken som helst kan infogas med Ctrl-P.

Gnome Edit säger att den inte känner igen encodern. Jag tycker Gnome Edit ska ge fan i vilken encodning filen har.

Emacs visar filens representation, dvs öppnar jag en bildfil visas en bild. Jag behöver inte Emacs för det.

Midnight Commander visar oprintbara tecken som escapesekvenser. Idioti. Redigering är omöjligt och någon fast kolumnbredd finns inte. Det samma gäller Nano. Vi är som bekant helt retarderat i alla sammanhang.

Jag har också testat ett dussin eller så av GUI-editorer och de reagerar på samma idiotiska sätt som GEdit eller ibland Emacs.

Sökningar på google och forum ger ofelbart referenser till hexeditorer. Well, det är inte vad jag efterfrågar heller. Jag vill blixtsnabbt kunna titta i en fil, kanske ändra något, spara. Och jag vill kunna göra det helt förutsättningslöst, helt oberoende av vad det är för typ av fil. Den ska inte "avkodas", editorn ska inte visa sig "duktig" genom att tolka, den ska göra som den blir tillsagd. Inte fan öppnar man en bild i en texteditor för att se bilden. Det strider mot "Principle of Least Astonishment" och "Do What I Mean".

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Medlem

Geany verkar klara av det. Blev rätt långsam när jag drog in en 9MB ppm-fil, men de ints jag skrivit till filen syns som klartext där.

EDIT: Nevermind, får inga andra binärfiler att fungera...

Visa signatur
Permalänk

Vet inte om det är det du letar efter med kanske "vim -b" är det du söker?

Permalänk
Medlem

vim funkar väll till ALLT?

Permalänk
Avstängd

VIM ger samma resultat som Nano eller MC, dvs oanvändbart.

vim eller vim -b ger samma resultat. Öppnar jag en zipfil visas en fillista över innehållet. Ej godkänt.

Att visa vagnretur som BÅDE ^M och faktiskt vagnretur är givetvis också förvirrande. Jag vill se ASCII-tecken. Det ska inte tolkas. När markören står på en position ska ASCII-värdet stå i en statusbar.

Så här ser exempelvis en zipfil ut i VIM, Emacs och andra idiotiska program:

" zip.vim version v22 " Browsing zipfile /mnt/TV/wav2bin.zip " Select a file with cursor and press ENTER wav2bin.exe copying.txt wav2bin.c

I exempelvis MC ser det ut såhär:

PK^C^D^T^@....

^C, etc är ett tecken! Helt hopplöst att redigera eftersom man inte utan att parsa med ögat genom allt kan veta om ^M är "^" och "M" eller Ctrl-M.

I MS DOS-Edit ser motsvarande ut som PK[hjärta][ruter][paragraf][whitespace], etc, dvs ett tecken per tecken. I statusfältet syns koden för tecknet där markören står.

Det jag efterfrågar måste vara det absolut enklaste och självklaraste sättet att visa en fil. Tänk er att man i textläge sätter in ASCII-koderna direkt i grafikminnet. Så ska det se ut. En hexeditor kommer nära, men dels får man en kolumn med hexvärden, dels visas ofta specialtecken med "....". Detta gör det mycket svårt att erfaranhetsmässigt klassa filer genom att enbart titta i dem. Visas allting som det faktiskt ser ut får man en uppfattning om filens innehåll, om potentiell komprimerbarhet, etc.

Edit: Hittade en bild på nätet som kan förklara bättre:

*Precis* så ska det se ut. Inget tjafs, helt plain, ingen djälva tolkning, ingen djälva encodning, ingen djävla duktighet. MS DOS Edit är nog ett av de absolut bästa program som MS lyckats med. De följer alla goda designprinciper, KISS, Least Astonishment, DWIM, lätt att använda, minimal kodstorlek, stabilt.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Medlem

Får man fråga till vilket ändåmål du vill kunna göra detta?

Edit: bvi(1): visual editor for binary files - Linux man page kanske, vet inte...

Visa signatur

Datorer - M1 MacBook Pro 14"
Hörlurssystem - Scarlett 4i4 / Objective2 / Beyerdynamic DT 770
Ljudsystem - NAD C356BEE > DALI Mentor 6
Bilpark - Porsche 718 Spyder

Permalänk
Avstängd

Titta i filer såklart! Så jag kan parsa den i min hjärna lite kvickt för att bedöma filtyp, potentiell komprimeringsgrad samt att kunna editera enstaka tecken. Hexeditorer finns, men problemet där är att det ska gå SNABBT. Jag vill inte ha en hexeditor som default öppningsprogram för generiska filer...

Edit: bvi/bview visar som en vanlig hexeditor. Det är inte GUI heller. Man vill ju helst slippa ändra "verktygsuppsättning" genom att köra CLI-program i terminal, även om det kan vara acceptabelt. Dessutom visas en hel radda tecken som "." i stället för ASCII-tecknet. Why?

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Medlem

UltraEdit borde fixa de du vill..

Permalänk
Medlem

Kan du inte köra MS-DOS Edit då? Finns dos-emulatorer man skulle kunna använda.

Permalänk
Medlem
Skrivet av MBY:

Att visa vagnretur som BÅDE ^M och faktiskt vagnretur är givetvis också förvirrande.

Är du säker på att det inte är vagnretur + nyrad? Det är ju så Windows markerar nya rader.

Skrivet av MBY:

Jag vill se ASCII-tecken. Det ska inte tolkas. När markören står på en position ska ASCII-värdet stå i en statusbar.

Problemet du har är att de första 32 ASCII-tecknen inte har någon visuell representation eftersom de är kontroll-tecken. De flesta editorer använder därför kontroll-koder för att visa dem. Det du vill göra är i så fall att tilldela tecknen godtyckliga symboler som du känner igen. Jag känner tyvärr inte till någon sådan editor, men det borde inte vara så svårt att koda ihop något sånt. Man kan också ändra typsnitt i t.ex. Ghex, så om man gör ett eget typsnitt eller hittar något lämpligt så kan det också fungera.

Permalänk
Avstängd
Skrivet av Ennuj:

UltraEdit borde fixa de du vill..

Det tror jag inte på! (Det verkar som alla editorer använder i stort sätt samma API, komponent eller vad det nu kan vara.)

(Men jag ska givetvis testa "UltraEdit" som jag trodde var ett winprogram)

Edit: Fail, UltraEdit är inte GNU. Ofri mjukvara går fetbort.

Skrivet av ronnylov:

Kan du inte köra MS-DOS Edit då? Finns dos-emulatorer man skulle kunna använda.

Nope, det är inte speciellt smidigt. Visst, måste jag titta i en fil på ett vettigt sätt så blir det edit.com i virtuell maskin. Wine har svårt att köra dos-program och att dra igång en VM är inget man gör i ett kick.

Skrivet av perost:

Är du säker på att det inte är vagnretur + nyrad? Det är ju så Windows markerar nya rader.

Det beror förstås vad man tittar i. Jag förväntar mig inte ASC 13, 10 i filer som inte kommer från DOS/Win, varpå jag misstänker att några editorer visar kaka på kaka. Men det spelar ingen roll, vagnretur är givetvis bättre än "^M".

Skrivet av perost:

Problemet du har är att de första 32 ASCII-tecknen inte har någon visuell representation eftersom de är kontroll-tecken. De flesta editorer använder därför kontroll-koder för att visa dem. Det du vill göra är i så fall att tilldela tecknen godtyckliga symboler som du känner igen. Jag känner tyvärr inte till någon sådan editor, men det borde inte vara så svårt att koda ihop något sånt. Man kan också ändra typsnitt i t.ex. Ghex, så om man gör ett eget typsnitt eller hittar något lämpligt så kan det också fungera.

Det är naturligtvis utomordentligt fånigt att kontrollkoderna inte har någon visuell representation i Windows eller *nix när det gått alldeles utmärkt tidigare. Det spelar ingen roll vilken typ av symbol man använder, bara man följer regeln ett tecken, en position. Sedan må det vara PETASCII om det så vill! Men rimligast är förstås att de glyfer visas som skulle visas om du lade byten i bildminnet direkt i textläge. Då har alla icke-whitespace-tecken en glyf.

Men återigen, det är ett sidospår det här med tecken. Frågeställningen är om det finns någon GUI-editor som kan visa filer i råformat utan att vara så jävla duktigt. Öppnar man en textfil ska den visas precis som vanligt. Alltså kan vagnretur/nyrad få tolkas, bara den inte visar en jäkla bild om du öppnar en bildfil, fillista när du öppnar en zip-fil, etc. Poängen är att det ska gå snabbt, vara självklart och användbart. Att man kan lösa allt med virtuella maskiner eller egendomliga parametrar till obskyra program må vara hänt. Det jag irriterar mig mest på är att kontrolltecken ska visas på två positioner. Bättre då att visa ett tecken (notepad visar en fyrkant). Fast bäst är förstås om man använder de standardglyfer som faktiskt finns sedan 30 år för dessa (som dock kan variera med teckenuppsättningen). Att höga tecken visas som whitespace är också väldigt oförklarligt. Om det inte finns tecken nog att fylla upp 256 koder, vad ska man då med unicode till? Det är nästan mer irriterande och en sjuka som finns både i windows och *nix. Att koder under 32 (kontrollkoderna) inte har självklara glyfer kan man förstå, men 128-255?

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk

Googla på "easy text editor c++" och anpassa den helt efter dina behov så får du en som beter sig precis som du vill. Det finns säkerligen redan någon sådan färdig som någon har lagt ut bara att kompilera och använda. (kan t.o.m. vara färdig-kompilerad om man har tur)

Problemet med ditt önskemål är att efterfrågan är liten och då är det svårt att hitta ett stort populärt program med stor hemsida och allt.
*edit*
Eller jag kanske missuppfattade något, men som jag tolkade det så skulle du ha enklast möjliga utan några finesser. Sedan hur man tolkar tecken är ju lite knepigt, då du vill ha någon teckenkodning. (inte bara ettor och nollor på en rad)

*edit2*
Att öppna stora filer via sådana enkla är kanske inte bra och där ligger väl problemet?

Visa signatur

[Core i7-3930K med 32GB ram, 2*256GB SSD] & [Core i7 3770K med 16 GB RAM, 256GB SSD] som tillsammans har ett [HD 5850 1GB] och 3st 24".

Permalänk
Medlem
Skrivet av MBY:

Det tror jag inte på! (Det verkar som alla editorer använder i stort sätt samma API, komponent eller vad det nu kan vara.)

I princip alla editorer använder väl ASCII eller UTF-8 för att visa binärfiler. Det du förmodligen vill ha är nog Code page 437 som är vad MS-DOS edit använder. Editorer som t.ex. vim kan visa cp437 (set encoding=cp437 i vim), men i alla fall vim väljer att visa kontroll-koder för de 32 första symbolerna istället för den grafiska representationen i cp437 (förmodligen för att moderna typsnitt inte använder cp437). Det löser ju inte ditt problem, men kanske kan det hjälpa att veta att det du letar efter förmodligen är en modern texteditor som kan visa de grafiska symbolerna i cp437. Möjligtvis så går det kanske att få vim att automatiskt konvertera ASCII till cp437-kompatibel UTF-8 med något smart script.

Permalänk
Avstängd

Ja, precis! Men det är inte nödvändigtvis så att det måste vara CP437 så länge det är ekvivalent. Fast jag förstår verkligen inte varför man skulle ha något _annat_ än CP437, eller varför man inte fyller code pagen med tecken hela vägen. CP437 hade om jag minns rätt problem med italienska och saknar dansk/norskt Ö, men vad fan, vi har ju unicode och inget hindrar andra code pages. Just kontrolltecknen är ju av denna art att de är fullständigt ointressanta att "internationalisera", så de kan vara CP437-lika för alla system.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Medlem

Om du snabbt vill kolla vad en fil är för slags fil så finns kommandot "file <filnamn>" som känner igen en massa olika format.

Permalänk
Skrivet av MBY:

Edit: Fail, UltraEdit är inte GNU. Ofri mjukvara går fetbort.

Är det inte bara att ladda hem valfri GNU-licensierad editor och implementera det själv?

Permalänk
Glömsk

Emacs har en hexeditor.

M-x hexl-mode

Visa signatur

...man is not free unless government is limited. There's a clear cause and effect here that is as neat and predictable as a law of physics: As government expands, liberty contracts.

Permalänk
Avstängd
Skrivet av iXam:

Om du snabbt vill kolla vad en fil är för slags fil så finns kommandot "file <filnamn>" som känner igen en massa olika format.

Nejnejnej!

Skrivet av Psionicist:

Emacs har en hexeditor.

M-x hexl-mode

Nejnejnej!

Hexeditor och att ta reda på filtyp är INTE vad jag söker.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Medlem

Om jag öppnar en zip-fil (antar att det gäller alla andra filer med) med

vim -u NONE <filnamn>

så får jag alla bytes utanför printable ASCII markerade i en avvikande färg och hanteras av editorn som ett tecken.
Vad jag kan se av mina snabba tester hanterar den även UTF-8 korrekt (förutsatt att typsnittet innehåller en komplett glyph-uppsättning).

Testat med vim 7.2 på OS X och Linux.

Permalänk
Avstängd
Skrivet av NakedApe:

Om jag öppnar en zip-fil (antar att det gäller alla andra filer med) med

vim -u NONE <filnamn>

så får jag alla bytes utanför printable ASCII markerade i en avvikande färg och hanteras av editorn som ett tecken.
Vad jag kan se av mina snabba tester hanterar den även UTF-8 korrekt (förutsatt att typsnittet innehåller en komplett glyph-uppsättning).

Testat med vim 7.2 på OS X och Linux.

Verkar lovande! Ska pröva vid tillfälle!

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Medlem

Ovanstående skall givetvis gå att ordna för GUI-versionen (gvim) också, men du får skapa en egen genväg/.desktop-fil med rätt argument. Men det har du säkert redan koll på…

Permalänk
Medlem
Skrivet av NakedApe:

Om jag öppnar en zip-fil (antar att det gäller alla andra filer med) med

vim -u NONE <filnamn>

så får jag alla bytes utanför printable ASCII markerade i en avvikande färg och hanteras av editorn som ett tecken.
Vad jag kan se av mina snabba tester hanterar den även UTF-8 korrekt (förutsatt att typsnittet innehåller en komplett glyph-uppsättning).

Testat med vim 7.2 på OS X och Linux.

Detta gör väl hela vim obrukbar? Jag kan inte ens manuvrera mig i textfilen. Och många tecken visas som ^B etc. vilket gör att kolumnbredd ej bevaras.

Edit: Ett annat problem är så klart att i princip inget typsnitt implementerar ens något tecken för kontrollsekvenserna (i.e. <= 0x20) eller 0x7f till 0xa0
Du måste nog få tag i något cp437 typsnitt innan du kan få det att fungera.

Permalänk
Medlem
Skrivet av Micket:

Detta gör väl hela vim obrukbar? Jag kan inte ens manuvrera mig i textfilen. Och många tecken visas som ^B etc. vilket gör att kolumnbredd ej bevaras.

Givetvis inkräktar det på konfigurationen av vim men oanvändbar blir den inte, inte hos mig i alla fall. Sedan lämnade jag som en övning åt läsaren (om än outtalat så) att räkna vilka "finesser" i vim som bör utelämnas för att slippa beteendet med att den visar filstrukturer etc. Poängen var att visa att vim i grund och botten gör det TS efterfrågade.

Skrivet av Micket:

Edit: Ett annat problem är så klart att i princip inget typsnitt implementerar ens något tecken för kontrollsekvenserna (i.e. <= 0x20) eller 0x7f till 0xa0
Du måste nog få tag i något cp437 typsnitt innan du kan få det att fungera.

Kontrollsekvenser representeras av sin ASCII-kod eller den CTRL-tangentkombination som genererar dem. Jag kan inte riktigt förstå varför detta skulle vara svårare att förstå än en glyph som inte säger något om koden. Jag skulle lite gubbgrinigt påpeka att om man vill ha allt precis som förr i världen så får man stanna "förr i världen" och köra DOS/Win16 eller så får man implementera det själv.

EDIT: missade visst en quote-tag.

Permalänk
Avstängd

Men "^M" är knappast "mer modernt", och för det andra så kan man ju hävda att en försämring inte är en förbättring, så så mycket för "modernt". Problemen med "^M" (etc) är många. Det mest uppenbara är att det är svårt (eller omöjligt) att skilja CTRL-M från "^" + "M". Ett annat problem är att cursorposition inte stämmer överens med position i fil. Att visa icke skrivbara tecken med en annan färg är rätt smart, men då behöver man ju _BARA_ "M" för CTRL-M, osv. Jag har ännu inte hunnit testa, men enligt Micket så verkar det ju inte fungera?

(Att visa som "^M" _och_ ha en annan färg verkar ju snudd på idioti, varför visa "^" alls då?)

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk

Om du har tex:

set statusline=%<%f%h%m%r\ \ Buffer:%n%=[%b][0x%B]\ %-11(Line:%l%)%-10(Col:%c%V%)\ %P

Som statusline så kan du se vad för tecken du har under pekaren och också vilken kolumn du är på igentligen. Därmed kan du se skillnad på ctrl-M och "^"+"M"

Permalänk
Medlem
Skrivet av MBY:

Men "^M" är knappast "mer modernt", och för det andra så kan man ju hävda att en försämring inte är en förbättring, så så mycket för "modernt". Problemen med "^M" (etc) är många. Det mest uppenbara är att det är svårt (eller omöjligt) att skilja CTRL-M från "^" + "M". Ett annat problem är att cursorposition inte stämmer överens med position i fil. Att visa icke skrivbara tecken med en annan färg är rätt smart, men då behöver man ju _BARA_ "M" för CTRL-M, osv. Jag har ännu inte hunnit testa, men enligt Micket så verkar det ju inte fungera?

(Att visa som "^M" _och_ ha en annan färg verkar ju snudd på idioti, varför visa "^" alls då?)

Allt det du räknar upp här är såvitt jag kan se argument mot vims metod för att du är van din gamla editor. Inget av det du nämner bereder mig några problem överhuvudtaget: ^M är en vedertagen (åtminstone i min värld) förkortning för CTRL-M som genererar koden på tangentbordet. Fullkomligt logiskt till skillnad från ett hjärta eller en 90° vinkel i valfri orientering. Jag kan heller aldrig minnas att jag tagit fel på ^+M och representationen för ASCII 13 då de som sagt presenteras med olika färg. Varför man har valt att använda både avvikande färg och en flerteckensrepresentation är antagligen att det finns massor med funktionalitet som påverkar färgen hos tecken (syntax highlight, outline mode, etc) i vim.

Du har givetvis all rätt att tycka att vims metod är idiotisk, men prova gärna och se om det är så hemskt som du tror.

Micket har en poäng i att kolumnbredd är ett problem, jag har inte försökt lösa det och tänker inte lägga någon energi på det om du anser hela projektet förfelat. Men att han inte kan manövrera i filen låter hemskt konstigt. Jag kan manövrera alldeles utmärkt och alla grundläggande funktioner jag testat fungerar, även om de allra flesta blir fullkomligt meningslösa när texten man manövrerar i inte följer "normala" syntaktiska regler.

Permalänk

Vim är open-source, du kan ladda ned källkoden här...
Vim source archives : vim online

Permalänk
Avstängd
Skrivet av NakedApe:

Allt det du räknar upp här är såvitt jag kan se argument mot vims metod för att du är van din gamla editor. Inget av det du nämner bereder mig några problem överhuvudtaget: ^M är en vedertagen (åtminstone i min värld) förkortning för CTRL-M som genererar koden på tangentbordet. Fullkomligt logiskt till skillnad från ett hjärta eller en 90° vinkel i valfri orientering. Jag kan heller aldrig minnas att jag tagit fel på ^+M och representationen för ASCII 13 då de som sagt presenteras med olika färg. Varför man har valt att använda både avvikande färg och en flerteckensrepresentation är antagligen att det finns massor med funktionalitet som påverkar färgen hos tecken (syntax highlight, outline mode, etc) i vim.

Du har givetvis all rätt att tycka att vims metod är idiotisk, men prova gärna och se om det är så hemskt som du tror.

Micket har en poäng i att kolumnbredd är ett problem, jag har inte försökt lösa det och tänker inte lägga någon energi på det om du anser hela projektet förfelat. Men att han inte kan manövrera i filen låter hemskt konstigt. Jag kan manövrera alldeles utmärkt och alla grundläggande funktioner jag testat fungerar, även om de allra flesta blir fullkomligt meningslösa när texten man manövrerar i inte följer "normala" syntaktiska regler.

Jag har inte påstått annat än att ^M är vanligast. Det är vanligt på alla plattformar jag sysslat med, men det gör det inte mindre korkat. Kan man dessutom färgkoda behövs ju inte "^" alls. Men färgkodningen är däremot lite mer ovanlig och beroende på hur cursorn rör sig är det bara otympligt, till svårt, till omöjligt att skilja på ^M och ^+M. I vissa fall rör sig curson så att det är två steg för ^ och M, så det är möjligt att sudda ut ^. Vet inte hur det är med vim. Jag tycks aldrig få tid att laborera.

Men det är just kolumnbredden samt förutsättningslös visning som är poängen med tråden. Alltså, inte visa en bildfil som en bild (etc), öppna binärfiler (men visa textfiler som text), ange vilken kolumnbredd man vill ha (förutsättningslöst), osv.

Man kan "vänja" sig vid precis vad som helst. Jag har använt ^M precis lika länge som glyf för 13. Det är bara det att glyf är lättare att använda, smartare och mer logiskt.

Det absolut vanligaste sättet är nog det som brukar användas av hexeditorer (och notepad) är att indikera kontrolltecken med ".", blanksteg eller "■" (254). Alla dessa är idiotiska. Ett 7 är ett 7, ingen punkt (46), inget blanksteg (32 eller 255), inget 254.

Det är inte MS DOS Editor som är så jäkla bra (även om det troligtvis är ett av MS bättre program), det är linux som inte verkar ha någon som helst möjlighet för detta. I DOS/Win kan man åtminstone falla tillbaka på Edit. NC kunde också visa på ett förnuftigt sätt, men MC klarar det inte (^M).

fqvarfort: Ja, det är GNU. Och? Om jag skulle modifiera en editor skulle jag inte utgå från något som bygger på något från 1976 och påstås vara "modernt". MS DOS-Edit är inte heller "modernt", men följer goda designprinciper. Jag har faktiskt lekt med tanken att skapa en egen editor för *nix. Arbetsnamnet är "no fucking nonsense edit".

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."