3 ms·

Waste of time. Better off to master JavaScript and extend VS Code / Codium / et. al. At least the JS knowledge will carry over to something employable.

G3rn0ti 4y ago
Well, that‘s a valid opinion and I am not telling anyone what tools to use. But as a senior I have seen many colleagues moving from one IDE du jour to the next and spending many hours of reconfiguring their tools while I just stuck to using Emacs all these years with a moderate shift of packages. I’ve been programming C, C++, Perl, JavaScript (and its various ECMA incarnations), React components, SQL and even Lua. Nowadays I am doing my terminal sessions from Emacs, too, and enjoy Tramp mode for tracing live bugs. Also, I started writing SQL change sets using org-mode which is really a killer for me now. Emacs is such a versatile programming tool and does not stop amazing me. VS Code looks so boring in comparison. Also my colleagues keep on whining about the CPU and memory consumption of their IDE that is quite large for, well, ultimately, text editing.
precompute 4y ago
Writing functions in elisp is much easier than having to write JS for electron-based editors, and the elisp you write will usually work for a long time without being modified. Emacs is geared towards people that use it regularly, and its defaults hardly ever change.
- ColonelPhantom 4y ago
  What makes it easier to write in ELisp compared to JS? Also, other text editors got on the 'real programming language' train too, like Neovim with its support for Lua. There's also Lite XL which is almost fully written in Lua itself. Does ELisp still have a big advantage there?
  - precompute 4y ago
    Sure. Elisp is very well-integrated with the editor itself, because that's what emacs is written in. There are some primitive functions that written in C that everything builds on top of. This makes writing functions an extension of the text editing process itself. This is why it's truly extensible. You don't get penalized for writing your own functions, they exist at the same rank as what emacs ships with. Writing functions in lua is fine, but nvim and the like still suffer from being just text editors, and most things that interact with the operating system / syscalls or change/traverse the UI require quite a lot of legwork. In Emacs, this is all very easy. Depending on what you need, you can be perfectly satisfied with vim and a couple of plugins. However, after realizing how easy it was to write functions in elisp, I more or less moved all my text / file editing to Emacs, along with most batch functions. For example, here's a function to insert a formatted date in the current buffer: (defun timestamp () "Insert string for the current time formatted like '2:34 PM' or 1507121460" (interactive) (insert (format-time-string "[%02y-%02m-%02d %02H:%02M:%02S] "))) You'd have to consult the docs for writing this trivial function in literally any other text editor. In emacs, you can `C-h` for everything, and this program will always run properly, because you're using functions that are used by emacs internally. Chaining functions: (defun org-id-create-copy () "org-id-get-create and then org-id-copy" (interactive) (org-id-get-create) (org-id-copy)) Utilizing inbuilt syntax for a major mode in your custom function: (defun org-delete-subtree () "Delete the current subtree" (interactive) (let ((org-heading-text (nth 4 (org-heading-components)))) (save-restriction (org-narrow-to-subtree) (kill-region (point-min) (point-max)) (widen) (kill-whole-line 1)) (message "Heading deleted : %s" org-heading-text))) Using recorded macros as functions: (fset 'throwtext-c "x\C-w\C-wGp") (fset 'kindle-clippings-to-org-macro (save-excursion (kmacro-lambda-form [?d ?d ?$ ?d ?% ?O ?\s-p escape ?d ?s ?b ?O ?* ? escape ?J ?o ?* ?* ? escape ?J ?j ?^ ?d ?w ?d ?w ?l ?v ?e ?~ ?I ?* ?* ?* ? escape ?w ?d ?w ?f ?| ?r return ?d ?w ?d ?w ?V ? ?\; ?c ?o ?n ?v ?e ?r ?t return ?j ?d ?d ?V ?\C-s ?f ?n] 0 "%d"))) Capturing (copying / appending to a certain location, depending on your config / provided template) highlighted text from a PDF file opened in Emacs: (defun org-capture-pdf-c (action) "Capture the active region of the pdf-view buffer." (let* ((pdf-buf-name (plist-get org-capture-plist :original-buffer)) (pdf-buf (get-buffer pdf-buf-name))) (if (buffer-live-p pdf-buf) (cond ((= action 1) (with-current-buffer pdf-buf (buffer-name))) ((= action 2) (with-current-buffer pdf-buf (buffer-file-name))) ((= action 3) (with-current-buffer pdf-buf (if (pdf-view-active-region-p) (car (pdf-view-active-region-text)) (ignore-errors (buffer-substring-no-properties (region-beginning) (region-end)))))) ((= action 4) (with-current-buffer pdf-buf (number-to-string (pdf-view-current-page))))) (user-error "Buffer %S not alive." pdf-buf-name)))) Traversing text programmatically: (defun comments-skip-c () "Skips to the line after the next comment ends" (interactive) (search-forward-regexp comment-start-skip) (while (string-match comment-start-skip (buffer-substring (line-beginning-position) (line-end-position))) (forward-line))) Making windows larger by a ratio: (defun make-window-larger-c (&optional ratio) "Makes the current window larger or smaller. RATIO is the ratio used, default is 0.618. It switches the width before the height." (interactive) (save-excursion (let\* ((postv (if olivetti-mode (progn (olivetti-mode -1) t) nil)) (wwidth (window-width)) (wheight (window-height)) (fwidth (frame-width)) (fheight (frame-height)) (ratio (if ratio ratio 0.618)) (fl/fheight (floor (\* ratio fheight))) (fl/fwidth (floor (\* ratio fwidth)))) (if (window-full-width-p) (if (window-full-height-p) (message "Nothing to resize.") (if (>= wheight fl/fheight) (if (>= wwidth fl/fwidth) (message "Nothing to resize.") (enlarge-window (- fl/fwidth wwidth) t)) (enlarge-window (- fl/fheight wheight)))) (if (>= wwidth fl/fwidth) (if (>= wheight fl/fheight) (message "Nothing to resize.") (enlarge-window (- fl/fheight wheight))) (enlarge-window (- fl/fwidth wwidth) t))) (if postv (olivetti-mode 1))))) Querying a SQLite DB for entries and showing them in a selectable list; selected entry is copied to clipboard. (require 'sqlite3) (defun kill-new-from-global-paste-c () (interactive) (let ((mylist '())) (let* ((dbh (sqlite3-open "/home/user/.local/share/zeitgeist/activity.sqlite" sqlite-open-readonly)) (stmt (sqlite3-prepare dbh "select * from text order by id desc limit 500"))) (while (= sqlite-row (sqlite3-step stmt)) (cl-destructuring-bind (id text) (sqlite3-fetch stmt) (setq mylist (nconc mylist (list text))))) (sqlite3-finalize stmt) (sqlite3-close dbh)) (kill-new (let* ((vertico-sort-function nil) (rlist (completing-read-multiple " " mylist)) (rstr "")) (while (length> rlist 0) (setq rstr (concat rstr (pop rlist) "\n"))) rstr)))) EDIT: Oh, and changing the "face" (appearance) of text is also very easy. It's easy to make your own syntax highlighting rules or even highlight stuff according to a regex temporarily.
deafpolygon 4y ago
I'm going to post it as a reply to my comment, so it's not a mistake that this is here. I notice my comment being downvoted, and that's fine. I don't really care- but my statement stands; it's a far better use of your time to learn JavaScript and write extensions in VS Code to accomplish what you want. I realize this might get flagged and someone might be offended. I don't have patience today. My JavaScript advice is multi-fold: - You'll learn a language that's in active use and development, and the lingua franca of the web. - You'll learn how extensions are created for VS Code, one of the most popular text editor and the greatest reach for sharing your work if you desire that. - JavaScript is *fast*, Emacs is slow ; there are many other language problems that, shockingly, JavaScript is just better with. - Waste less time debugging your text editor; not all of us (especially myself) have time to sink into becoming experts at Emacs. Emacs documentation is a bit esoteric and not that easy to grok, unless you already know ELisp. - Need an off-the-shelf solution? VS Code most likely has that, and it's probably going to work - Don't waste your time with dogma. EMacsers get in a tizzy fit over this and that, the right way to do things, to RTFM, etc. It's a community that has almost the same level of toxicity as Linux users. I am someone who went all-in with Emacs for around 6 months. It is really an interesting piece of software and no one will deny that it can ostensibly do alot. One of the biggest issues I had was writing any form of prose - which made it lag so badly, it was nearly impossible to scroll. The collective solution, after posting on Reddit and searching via Google, was simply to use search - rather than scrolling to find what you're looking for. I find manipulating buffers in Emacs fairly tedious, and I still believe that the mouse is a great invaluable tool not to be shunned. Some things are just easier and faster to manipulate with a pointer. I don't have a problem reaching for my mouse and returning to the keyboard without looking. I tried to use it for journalling, and learning the ins-and-outs of Org-mode was fun. I liked org-capture. Then I realized, Obsidian was a better piece of tool. It handles prose just fine, and Markdown is much easier to remember (due to its ubiquitiness) than org-mode. And guess what languages extensions are written in? JavaScript. Other comments: > Writing functions in elisp is much easier than having to write JS for electron-based editors, and the elisp you write will usually work for a long time without being modified. Old JS code still work. JS has a reputation for being backwards compatible and taking a very long time to break any type of ABI. In the case of Electron, you are informed when things break - and you have time to update it. It's not like code changes happen under your feet, and things are breaking all of the time. [0] On top of that, Electron-based applications are almost guaranteed to work similarly on Windows, Mac and Linux. The same can't be said for Emacs, which suffer some fairly extreme performance issues on Windows. > VS Code looks so boring in comparison. It's just a tool. I can use themes, and syntax highlighting is great. > but nvim and the like still suffer from being just text editors And this is what makes it perfectly suited for its task. > In Emacs, this is all very easy. What makes emacs very easy? Every time I see anyone say Emacs is easy - they gush about writing code in ELisp, it's almost dogmatic. It's not about Emacs, it's about *ELisp*. I do believe the majority of Emacsers suffer from the IKEA effect[1] because the learning curve is so high that by the time they're able to build something in ELisp - they're also hit over the head with the Stockholm Syndrome[2]. My preferred solution would be to use an SQLite plugin in VS Code because that allows me to browse and query any code, rather than a fixed string. I don't need to write a new function, or try to manipulate Emacs buffers. > Alternately, spend a weekend learning VS.Code and get on with doing real work. Exactly my perspective. [0] https://www.electronjs.org/docs/latest/breaking-changes https://www.electronjs.org/docs/latest/breaking-changes [0] https://en.wikipedia.org/wiki/IKEA_effect https://en.wikipedia.org/wiki/IKEA_effect [1] https://en.wikipedia.org/wiki/Stockholm_syndrome https://en.wikipedia.org/wiki/Stockholm_syndrome

G3rn0ti 4y ago

Well, that‘s a valid opinion and I am not telling anyone what tools to use. But as a senior I have seen many colleagues moving from one IDE du jour to the next and spending many hours of reconfiguring their tools while I just stuck to using Emacs all these years with a moderate shift of packages. I’ve been programming C, C++, Perl, JavaScript (and its various ECMA incarnations), React components, SQL and even Lua. Nowadays I am doing my terminal sessions from Emacs, too, and enjoy Tramp mode for tracing live bugs. Also, I started writing SQL change sets using org-mode which is really a killer for me now. Emacs is such a versatile programming tool and does not stop amazing me. VS Code looks so boring in comparison. Also my colleagues keep on whining about the CPU and memory consumption of their IDE that is quite large for, well, ultimately, text editing.

precompute 4y ago

Writing functions in elisp is much easier than having to write JS for electron-based editors, and the elisp you write will usually work for a long time without being modified. Emacs is geared towards people that use it regularly, and its defaults hardly ever change.

ColonelPhantom 4y ago
What makes it easier to write in ELisp compared to JS? Also, other text editors got on the 'real programming language' train too, like Neovim with its support for Lua. There's also Lite XL which is almost fully written in Lua itself. Does ELisp still have a big advantage there?
- precompute 4y ago
  Sure. Elisp is very well-integrated with the editor itself, because that's what emacs is written in. There are some primitive functions that written in C that everything builds on top of. This makes writing functions an extension of the text editing process itself. This is why it's truly extensible. You don't get penalized for writing your own functions, they exist at the same rank as what emacs ships with. Writing functions in lua is fine, but nvim and the like still suffer from being just text editors, and most things that interact with the operating system / syscalls or change/traverse the UI require quite a lot of legwork. In Emacs, this is all very easy. Depending on what you need, you can be perfectly satisfied with vim and a couple of plugins. However, after realizing how easy it was to write functions in elisp, I more or less moved all my text / file editing to Emacs, along with most batch functions. For example, here's a function to insert a formatted date in the current buffer: (defun timestamp () "Insert string for the current time formatted like '2:34 PM' or 1507121460" (interactive) (insert (format-time-string "[%02y-%02m-%02d %02H:%02M:%02S] "))) You'd have to consult the docs for writing this trivial function in literally any other text editor. In emacs, you can `C-h` for everything, and this program will always run properly, because you're using functions that are used by emacs internally. Chaining functions: (defun org-id-create-copy () "org-id-get-create and then org-id-copy" (interactive) (org-id-get-create) (org-id-copy)) Utilizing inbuilt syntax for a major mode in your custom function: (defun org-delete-subtree () "Delete the current subtree" (interactive) (let ((org-heading-text (nth 4 (org-heading-components)))) (save-restriction (org-narrow-to-subtree) (kill-region (point-min) (point-max)) (widen) (kill-whole-line 1)) (message "Heading deleted : %s" org-heading-text))) Using recorded macros as functions: (fset 'throwtext-c "x\C-w\C-wGp") (fset 'kindle-clippings-to-org-macro (save-excursion (kmacro-lambda-form [?d ?d ?$ ?d ?% ?O ?\s-p escape ?d ?s ?b ?O ?* ? escape ?J ?o ?* ?* ? escape ?J ?j ?^ ?d ?w ?d ?w ?l ?v ?e ?~ ?I ?* ?* ?* ? escape ?w ?d ?w ?f ?| ?r return ?d ?w ?d ?w ?V ? ?\; ?c ?o ?n ?v ?e ?r ?t return ?j ?d ?d ?V ?\C-s ?f ?n] 0 "%d"))) Capturing (copying / appending to a certain location, depending on your config / provided template) highlighted text from a PDF file opened in Emacs: (defun org-capture-pdf-c (action) "Capture the active region of the pdf-view buffer." (let* ((pdf-buf-name (plist-get org-capture-plist :original-buffer)) (pdf-buf (get-buffer pdf-buf-name))) (if (buffer-live-p pdf-buf) (cond ((= action 1) (with-current-buffer pdf-buf (buffer-name))) ((= action 2) (with-current-buffer pdf-buf (buffer-file-name))) ((= action 3) (with-current-buffer pdf-buf (if (pdf-view-active-region-p) (car (pdf-view-active-region-text)) (ignore-errors (buffer-substring-no-properties (region-beginning) (region-end)))))) ((= action 4) (with-current-buffer pdf-buf (number-to-string (pdf-view-current-page))))) (user-error "Buffer %S not alive." pdf-buf-name)))) Traversing text programmatically: (defun comments-skip-c () "Skips to the line after the next comment ends" (interactive) (search-forward-regexp comment-start-skip) (while (string-match comment-start-skip (buffer-substring (line-beginning-position) (line-end-position))) (forward-line))) Making windows larger by a ratio: (defun make-window-larger-c (&optional ratio) "Makes the current window larger or smaller. RATIO is the ratio used, default is 0.618. It switches the width before the height." (interactive) (save-excursion (let\* ((postv (if olivetti-mode (progn (olivetti-mode -1) t) nil)) (wwidth (window-width)) (wheight (window-height)) (fwidth (frame-width)) (fheight (frame-height)) (ratio (if ratio ratio 0.618)) (fl/fheight (floor (\* ratio fheight))) (fl/fwidth (floor (\* ratio fwidth)))) (if (window-full-width-p) (if (window-full-height-p) (message "Nothing to resize.") (if (>= wheight fl/fheight) (if (>= wwidth fl/fwidth) (message "Nothing to resize.") (enlarge-window (- fl/fwidth wwidth) t)) (enlarge-window (- fl/fheight wheight)))) (if (>= wwidth fl/fwidth) (if (>= wheight fl/fheight) (message "Nothing to resize.") (enlarge-window (- fl/fheight wheight))) (enlarge-window (- fl/fwidth wwidth) t))) (if postv (olivetti-mode 1))))) Querying a SQLite DB for entries and showing them in a selectable list; selected entry is copied to clipboard. (require 'sqlite3) (defun kill-new-from-global-paste-c () (interactive) (let ((mylist '())) (let* ((dbh (sqlite3-open "/home/user/.local/share/zeitgeist/activity.sqlite" sqlite-open-readonly)) (stmt (sqlite3-prepare dbh "select * from text order by id desc limit 500"))) (while (= sqlite-row (sqlite3-step stmt)) (cl-destructuring-bind (id text) (sqlite3-fetch stmt) (setq mylist (nconc mylist (list text))))) (sqlite3-finalize stmt) (sqlite3-close dbh)) (kill-new (let* ((vertico-sort-function nil) (rlist (completing-read-multiple " " mylist)) (rstr "")) (while (length> rlist 0) (setq rstr (concat rstr (pop rlist) "\n"))) rstr)))) EDIT: Oh, and changing the "face" (appearance) of text is also very easy. It's easy to make your own syntax highlighting rules or even highlight stuff according to a regex temporarily.

deafpolygon 4y ago

I'm going to post it as a reply to my comment, so it's not a mistake that this is here. I notice my comment being downvoted, and that's fine. I don't really care- but my statement stands; it's a far better use of your time to learn JavaScript and write extensions in VS Code to accomplish what you want. I realize this might get flagged and someone might be offended. I don't have patience today. My JavaScript advice is multi-fold: - You'll learn a language that's in active use and development, and the lingua franca of the web. - You'll learn how extensions are created for VS Code, one of the most popular text editor and the greatest reach for sharing your work if you desire that. - JavaScript is *fast*, Emacs is slow ; there are many other language problems that, shockingly, JavaScript is just better with. - Waste less time debugging your text editor; not all of us (especially myself) have time to sink into becoming experts at Emacs. Emacs documentation is a bit esoteric and not that easy to grok, unless you already know ELisp. - Need an off-the-shelf solution? VS Code most likely has that, and it's probably going to work - Don't waste your time with dogma. EMacsers get in a tizzy fit over this and that, the right way to do things, to RTFM, etc. It's a community that has almost the same level of toxicity as Linux users. I am someone who went all-in with Emacs for around 6 months. It is really an interesting piece of software and no one will deny that it can ostensibly do alot. One of the biggest issues I had was writing any form of prose - which made it lag so badly, it was nearly impossible to scroll. The collective solution, after posting on Reddit and searching via Google, was simply to use search - rather than scrolling to find what you're looking for. I find manipulating buffers in Emacs fairly tedious, and I still believe that the mouse is a great invaluable tool not to be shunned. Some things are just easier and faster to manipulate with a pointer. I don't have a problem reaching for my mouse and returning to the keyboard without looking. I tried to use it for journalling, and learning the ins-and-outs of Org-mode was fun. I liked org-capture. Then I realized, Obsidian was a better piece of tool. It handles prose just fine, and Markdown is much easier to remember (due to its ubiquitiness) than org-mode. And guess what languages extensions are written in? JavaScript. Other comments: > Writing functions in elisp is much easier than having to write JS for electron-based editors, and the elisp you write will usually work for a long time without being modified. Old JS code still work. JS has a reputation for being backwards compatible and taking a very long time to break any type of ABI. In the case of Electron, you are informed when things break - and you have time to update it. It's not like code changes happen under your feet, and things are breaking all of the time. [0] On top of that, Electron-based applications are almost guaranteed to work similarly on Windows, Mac and Linux. The same can't be said for Emacs, which suffer some fairly extreme performance issues on Windows. > VS Code looks so boring in comparison. It's just a tool. I can use themes, and syntax highlighting is great. > but nvim and the like still suffer from being just text editors And this is what makes it perfectly suited for its task. > In Emacs, this is all very easy. What makes emacs very easy? Every time I see anyone say Emacs is easy - they gush about writing code in ELisp, it's almost dogmatic. It's not about Emacs, it's about *ELisp*. I do believe the majority of Emacsers suffer from the IKEA effect[1] because the learning curve is so high that by the time they're able to build something in ELisp - they're also hit over the head with the Stockholm Syndrome[2]. My preferred solution would be to use an SQLite plugin in VS Code because that allows me to browse and query any code, rather than a fixed string. I don't need to write a new function, or try to manipulate Emacs buffers. > Alternately, spend a weekend learning VS.Code and get on with doing real work. Exactly my perspective. [0] https://www.electronjs.org/docs/latest/breaking-changes https://www.electronjs.org/docs/latest/breaking-changes [0] https://en.wikipedia.org/wiki/IKEA_effect https://en.wikipedia.org/wiki/IKEA_effect [1] https://en.wikipedia.org/wiki/Stockholm_syndrome https://en.wikipedia.org/wiki/Stockholm_syndrome