4 ms·

Getting Started with Emacs 24

75 points by bozhidar 15y ago

agumonkey 15y ago
Additional note, the traditional starter kit configuration files, now in version 2 (tailored for emacs 24) https://github.com/technomancy/emacs-starter-kit https://github.com/technomancy/emacs-starter-kit
- WalterGR 15y ago
  the traditional starter kit configuration files Traditional in what sense? Is emacs-starter-kit considered a must-have?
  - agumonkey 15y ago
    I didn't meant it literally, but in case newcomers are tempted to try this new release, they might want some dotemacs files to play along.
    - bozhidar 15y ago
      That's why I've created the "non-traditional" Emacs Prelude https://github.com/bbatsov/emacs-prelude https://github.com/bbatsov/emacs-prelude ;-)
  - bozhidar 15y ago
    It's been around for about 3 years and is the most widely known Emacs setup out there. I guess this is what "traditional" means...
nyellin 15y ago
Does anyone know the status of multithreading and concurrency in Emacs 24? As far as I can tell, multithreading didn't make it in. Why not?
- hollerith 15y ago
  None of the Unix shells (csh, bash, etc) are multithreaded either. Like Emacs, what concurrency they have comes from fork, exec and setting "listeners" (terminology?) for signals from child processes. If I were to write a web server in Emacs Lisp (or bash) I would probably want multithreading in Emacs or (bash) but I have never felt the desire to write a web server or anything else that needs multiple threads all running in Emacs Lisp, and I've written many 10s of 1000s of lines of Emacs Lisp. Although my web browser (Firefox) is multithreaded, I spend orders of magnitude more time waiting for my web browser's UI to stop being unresponsive than I do waiting for Emacs or any of the Unix shells I have used to stop being unresponsive.
  - nyellin 15y ago
    Here are some features that to the best of my knowledge are currently impossible: * Non-blocking save on network drives * Non-blocking autosave * Rebuilding tag tables in the background * Loading and fontifying large files in the background (i.e. concurrent fontification, not just jit-lock) * Concurrent url fetching and downloads (e.g. updating el-get without blocking) [1] * Concurrent spellcheck * Fast scrolling in large buffers (especially complex XML files opened in nxml-mode) without annoying hacks like http://stackoverflow.com/q/4160949 http://stackoverflow.com/q/4160949 There are plenty more improvements that wouldn't affect me personally. I imagine erc and other networked packages would also benefit from true concurrency. [1] I just started using el-get on my laptop and I haven't checked this yet. Maybe it somehow works.
    - hollerith 15y ago
      So it did not bother you that I claimed that Emacs is just as concurrent as any of the Unix shells are and that you can do most of those things (I do not know enough to say whether you can do nonblocking saves on network drives) in any Unix shell :) :) Look, concurrency is complicated, and here is not the place for a long exposition about it, but the Emacs of 1995 (and again almost any Unix shell) can do most of what you listed. Often, it forks a program written in C and listens for a signal informing it of the result. M-x man is probably the best example: it forks a program written in C (or a bunch of them connected with Unix pipes) and waits for the C program to fill a buffer with the rendered man page. On modern hardware, the rendering is snappy, but M-x man was written in the early 1990s, when it took many seconds to render some man pages, so it is written such that the user can continue editing (can switch buffers, etc) and when the man page is ready, emacs switches to the buffer containing the new man page.

75 points by bozhidar 15y ago

Additional note, the traditional starter kit configuration files, now in version 2 (tailored for emacs 24) https://github.com/technomancy/emacs-starter-kit https://github.com/technomancy/emacs-starter-kit

WalterGR 15y ago
the traditional starter kit configuration files Traditional in what sense? Is emacs-starter-kit considered a must-have?
- agumonkey 15y ago
  I didn't meant it literally, but in case newcomers are tempted to try this new release, they might want some dotemacs files to play along.
  - bozhidar 15y ago
    That's why I've created the "non-traditional" Emacs Prelude https://github.com/bbatsov/emacs-prelude https://github.com/bbatsov/emacs-prelude ;-)
- bozhidar 15y ago
  It's been around for about 3 years and is the most widely known Emacs setup out there. I guess this is what "traditional" means...

nyellin 15y ago

Does anyone know the status of multithreading and concurrency in Emacs 24? As far as I can tell, multithreading didn't make it in. Why not?

hollerith 15y ago
None of the Unix shells (csh, bash, etc) are multithreaded either. Like Emacs, what concurrency they have comes from fork, exec and setting "listeners" (terminology?) for signals from child processes. If I were to write a web server in Emacs Lisp (or bash) I would probably want multithreading in Emacs or (bash) but I have never felt the desire to write a web server or anything else that needs multiple threads all running in Emacs Lisp, and I've written many 10s of 1000s of lines of Emacs Lisp. Although my web browser (Firefox) is multithreaded, I spend orders of magnitude more time waiting for my web browser's UI to stop being unresponsive than I do waiting for Emacs or any of the Unix shells I have used to stop being unresponsive.
- nyellin 15y ago
  Here are some features that to the best of my knowledge are currently impossible: * Non-blocking save on network drives * Non-blocking autosave * Rebuilding tag tables in the background * Loading and fontifying large files in the background (i.e. concurrent fontification, not just jit-lock) * Concurrent url fetching and downloads (e.g. updating el-get without blocking) [1] * Concurrent spellcheck * Fast scrolling in large buffers (especially complex XML files opened in nxml-mode) without annoying hacks like http://stackoverflow.com/q/4160949 http://stackoverflow.com/q/4160949 There are plenty more improvements that wouldn't affect me personally. I imagine erc and other networked packages would also benefit from true concurrency. [1] I just started using el-get on my laptop and I haven't checked this yet. Maybe it somehow works.
  - hollerith 15y ago
    So it did not bother you that I claimed that Emacs is just as concurrent as any of the Unix shells are and that you can do most of those things (I do not know enough to say whether you can do nonblocking saves on network drives) in any Unix shell :) :) Look, concurrency is complicated, and here is not the place for a long exposition about it, but the Emacs of 1995 (and again almost any Unix shell) can do most of what you listed. Often, it forks a program written in C and listens for a signal informing it of the result. M-x man is probably the best example: it forks a program written in C (or a bunch of them connected with Unix pipes) and waits for the C program to fill a buffer with the rendered man page. On modern hardware, the rendering is snappy, but M-x man was written in the early 1990s, when it took many seconds to render some man pages, so it is written such that the user can continue editing (can switch buffers, etc) and when the man page is ready, emacs switches to the buffer containing the new man page.