또는 바이너리나 데이터파일 열 때 이맥스는 버벅거려서 못 쓰는 에디터임
진짜 엄마가 없도록 느림 ㅇㅇ
27버전부터 json 네이티브로 지원하고, 라지파일모드, gccemacs 버젼 컴파일해도 다 똑같다
이리슾 플러그인 때문에 느린 것도 맞지만 무엇보다 그냥 바닐라 자체가 느림
내 말이 사실인지 궁금하면 설정파일 잠깐 옮겨놓거나 모드 다 꺼놓고 당장 sublime이나 vscode 켜서 큰 파일 불러와서 비교해보면 알 수 있음
또는 qwewwwqwewqwww 대충 아무 문자나 써갈겨서 100만행 작성하고 그거 C-x h로 전체 선택 복사 붙여넣기 비교 해보면 됨. 드래그 하는데도 한세월임
이런 현실은 망각하고 해외에서 여전히 이맥스가 운영체제니 스스로 우월하다고 자위하면서 헛소리 하는 놈들 있는데 대가리 진짜 깨주고 싶음
애초에 이맥스 안에서 할 수 있는 것들 전부 유닉스 터미널에서도 가능함. 그것도 네이티브라서 훨씬 더 빠르고
이맥스는 덕지덕지 살만 붙여놓은 누더기 흉물임. 나도 이맥스 익숙해서 쓰는거지,
누가 이맥스로 에디터 입문하고 갈아탄다고 하면 vscode나 서브라임 쓰라고 권유함
모드에 따라 다르겠지만 만라인 정도 되는 버퍼는 지금까지 문제 없었다. 몇기가 되는 파일 굳이 열고 싶으면 VLFㄱㄱ. 그리고 이맥스가 OS라서 우월하다는 사람은 없음 오히려 조롱거리지... 유닉스 터미널 시스템과 차별화 되는 점이자 이맥스의 제일 큰 장점은 lisp machine (오래 전 피지컬 lisp machine처럼)이라는 거임. 싱글 쓰레드 monolith라서 생기는 문제들을 감안해도 lisp machine으로써 이맥스가 제공해주는 abstraction이 개발자들을 자유롭게 productive하게 만듬. Introspection같은 건 덤이고. 쉐로도 가능하지... 근데 lisp의 자유로움을 만끽 하는 순간 spoil 돼서 굳이 다른 걸로 내가 원하는 걸 implement할 이유가 없어짐.
기본 몇 만라인이 넘어가기 시작하면 단순하게 작성을 할 수가 있냐가 아니라. 텍스트를 바꾸거나 취급할 때 느려지는 거임. 니가 느리다고 못 느끼는 거는 다른 에디터를 써보고 직접 비교를 안 해서 그런 거지. 마치 지금 세대 비쥬얼 스튜디오로 입문한 사람들이 2000이나 vs6버젼이 얼마나 빠른지 모르고, 지금 비스 속도가 정상이라고 생각하는 것처럼. 이맥스의 커스터마이징과 그 추상화가 강점이라고 하고 나도 실제로 그것 떄문에 쓰지만 솔직히 까놓고 이야기하면 정작 이맥스로 모든 것을 작성하는 사람은 없음. melpa에서나 온라인에서 남들이 만들어놓은 걸 짜집기할 뿐이지
이맥스의 목표도 현재 진행형으로 최대한 C코드 베이스 줄이고 코어까지 lisp화 시키는 거다.
니 말대로면 lsp가 느리다는 이용자들 요구 때문에 json파서를 27버젼부터 c로 구현 안 했지
패키지들 개발자들이 그렇게 자유롭고 빠르게 implement 하고 창조적으로 생각 할 수 있는 이유도 lisp라서다. 내가 말 한는 이맥스의 힘은 단순 커스터마이징이 아니라 전체 시스템을 프로그래머 놀이터로 만든다는 거다.
여기서 emacs미래/목표에 대해서 토론 해봤자 무슨 의미겠냐ㅋ emacs-devel mailing list 가서 직접 물어봐라.
그리고 vscode랑 sublime랑 다르게 이맥스는 유닉스 철학까지 지킴ㅋ (do one thing) 단순히 리스프 인터프레터임. 니가 말한 것 처럼 쉘과 비슷한 포지션이지. 그래서 지금까지 생존 한 거임.
나도 이맥스 안에서 모든 것을 할 수 있다는 철학에 뽕에 취한 적 있지만, 그건 유닉스 철학이랑 다름. 조잡한 가상머신에서 열화된 모든 것을 취급한다는게 아님. 미니멀과 소프트웨어의 모듈화가 유닉스의 철학이지. 그걸 이맥스 안에서 무식하게 모든 것을 elisp으로 구현한다는 것은 오만임. 실제로 터미널 안에서 tmux를 켜서 윈도우 프레임 나누고 그 안에서 이맥스로 에디터 기능만 이용하고 다른 기능들은 성능이 좋은 네이티브로 이용하면 됨. 근데 그 에디터조차 느리고 무겁지. 간단하게 텍스트만 수정하는데는 vim보다도 못하고. 그래서 이맥스가 생존하고 있지만 실제 신생 에디터들한테 다 모가지 따이고 그들만의 리그가 됐지
오히려 최근 vi implementation들이 유닉스 철학에서 벗어남 (e.g. 터미널/내장 윈도우 관리/파일 관리) 이젠 "텍스트만" 수정 안함. 이맥스가 하려는 거 하려고 해보지만 결국 한계가 있음 VimL도 단순 glue이상으로 쓰면 문제 생기고. tmux도 마찬가지고 (copy-mode/session-management/window-management). 클립 보드도 다 자체 클립보드라 결국 플러그인 스크립트로 덕지덕지 해야하고. 유닉스뽕 맞았으면 vis랑 abduco랑 dvtm써라ㅋ. 이런 거 고민 할 시간에 이맥스 사용자(단순 엔드유저 아닌)들은 훨씬 productive한 삶을 살고 있다.
이맥스도 자체 모듈시스템으로 소프트웨어끼리 composition은 정점에 이름 (sexp의 우월함). 그래서 자체적으로 유닉스의 그런 좋은 디자인 패턴도 따름.
unix 철학과 딱 상반되는 위치에 있는게 lisp이라고 봄 unix 철학이라는게 절대선인지도 의문이고
ㅇㅇ 근본적으로 다른 세상임. 근데 공통적으로 추구하는 이상도 있고 상호간의 interoperability도 있음. - dc App
아니 위에 clev 쟤는 성능 느려서 못 써먹겠다 아무리 커스터마이징 돼 봐라 느려터져서 속 터지면 못 쓴다가 주제인데 혼자 엉뚱하게 UNIX 목표를 따라간다니 커스터마이징 짱짱이라니 다른 소리를 하고있네 누가 커스터마이징 부정함? 성능이 구리다는데 그건 부정할 수 없는 사실 아니냐고
"이런 현실은 망각하고 해외에서 여전히 이맥스가 운영체제니 스스로 우월하다고 자위하면서 헛소리 하는 놈들 있는데 대가리 진짜 깨주고 싶음 애초에 이맥스 안에서 할 수 있는 것들 전부 유닉스 터미널에서도 가능함. 그것도 네이티브라서 훨씬 더 빠르고" <- 이거 반박하는 거임. 속도 느린 거 vs 프로그래머 캔디랜드라면 닥후임. 애초에 누가 비교적인 성능 부정함? 그리고 왠만한 상황(90%)에서는 성능 저하는 문제가 전혀 안되서 반박할 가치도 없음. 쟤야말로 모듈화된 코드 운운하면서 어째 한 파일에 만라인씩 써 가는 시츄에이션을 들먹이냐? 개같은 회사 레거시 코드 작성 할 때도 이맥스 버벅거릴 만큼 느리게 만드는 건 많이 없음. 그만한 파일은 빔에서도 여러 모드 사용하면 버벅거림.
여전히 이맥스는 우월하고 (위에 제시한 이유 때문에) 대부분 모던 에디터들을 out-live할 거임. 물론 성능도 향상 되면서.
???? vim 써보고 하는 소리냐? strace 로그 파일 만들어서 보면 수백만줄도 가는데 버벅임이라곤 아예 찾아볼 수도 없는데 vim 이 렉 걸린다는 건 도대체 무슨 소리지?
단순로그는 이맥스도 빠름. Elasticsearch 로그 파일들 300~500메가 까지 한버퍼에 쓰고 그 이상 가면 vlf 써서 몇기가 까지 읽기 가능함. 빔으로 10기가 파일 열어봄? - dc App
이맥스 졸라 느려터진거 맞음
난 엄청 공감함
제목은 만 라인인데, 본문 예시는 왜 100만 라인이냐?
근로저 같은 거 쓰면 REPL에 몬가 출력하게 되는데 \\n 없이 길게 출력하면 존나 느려짐 개븅신임
유닉스 철학 지키고 이맥스 수준 커스터마이징 되면서 속도는 빠른 새 시대의 새로운 에디터가 필요하다고 생각함
그게 러스트 기반 xi 에디터임 텍스트 버퍼를 로프 구조로 짜서 logn으로 큰 파일들 핸들링 빠르게 하고 rpc로 서버/클라 디커플링해서(nvim 처럼) 커스터마이징도 자유롭게 함. 근데 요즘 개발 뜸하더라. Raph Levin이라고 기존 프로젝트 주인도 손 때고. - dc App
ㅇㅇ xi 좋아보였는데 아쉬움
아 아예 프로젝트 unmaintained 됐구나
이맥스 os 드립과 유닉스 철학이 공존하는게 아이러니 아닌가 싶다 난 솔직히 이해가 안가
이맥스는 단순히 elisp 인터프레터임. 그게 이맥스의 "one thing"임.
본인은 유닉스 철학이 꼭 지켜져야 되는 절대선같은 생각조차 의문이라 별 의미없는 얘기인데 perl도 유닉스 철학에 어긋난다고 까임(?) perl이나 ruby python javascript같은건 서로 '괄호없는 lisp'이라고 하지 유닉스 철학을 얘기하는 경우도 본적 없는듯 하고
https://docstore.mik.ua/orelly/linux/run/ch13_04.htm