5 ms·
I've fixed that. I only wanted something simple for new users to try out the new feature (Macro). This manual is only about stock Emacs features, not adding co
by tuhdo 12y ago
I've fixed that. I only wanted something simple for new users to try out the new feature (Macro).
This manual is only about stock Emacs features, not adding complexity with 3rd party packages. When I first introduced on Reddit, someone advised me to stick to stock Emacs (which I did) because they see this section using an external package (ggtags) for browsing kernel source code: http://tuhdo.github.io/emacs-tutor.html#sec-8 http://tuhdo.github.io/emacs-tutor.html#sec-8. When people are good with the basics, they understand what they need and find appropriate packages.
If you want advance techniques, the primary resource should be Emacs Lisp Manual, Emacs docstrings, and learn code written by package maintainers.
EDIT: Even before working with Emacs Lisp, using 3rd party packages already makes Emacs much more advanced.
- klibertp 12y ago> If you want advance[d] techniques, the primary resource should be Emacs Lisp Manual, Emacs docstrings, and learn[ing] code written by package maintainers. (I'm also learning English, so I know that having your mistakes pointed out helps - that's what the [] are for in the quote) Yeah, been there, done that. :) Docstrings and easy access to source code (find-function, find-library) are a great strength of Emacs - not only the documentation is of great quality, but it's mostly up-to-date. But going through packages' sources is not always pleasant: some authors are not very good with English (like me, for example), others have a dislike for writing comments, yet others are biased against cl-lib or too much in favour of eieio and so on. It's still a great learning experience, but it takes more time than it could take if the content was presented more systematically and in a more readable manner. Like in a book. Or a series of articles, or something. Note: I am thinking about writing something like this myself, but I don't feel confident enough just yet. > someone advised me to stick to stock Emacs I think it's stupid advice - bad for both programmers and non-programmers. If you're a programmer, using Emacs is (should be) about endless customization, tweaking and - you guessed it - programming your editor to do your work for you. In this case learning to use C-f instead of right arrow is so stupid it hurts - you should learn about define-key, make-sparse-keymap, global-set-key, describe-keymap (and generally describe-...) and of course apropos instead. I guarantee it will take you less time than making C-f a habit! That's the way I learned Emacs: I started learning with Emacs Lisp Manual, not a tutorial or Emacs Manual and it got me up to speed in no time at all. Instead of learning what keys to press to do something it's better - again, for programmers - to just learn the name of a function which does what you want. It's true that I don't use many standard keybindings and I remapped most of them, but this is ok, because this is my editor and nobody else is going to use it anyway. And when I started fiddling with packages I already knew how to hack them into shape and dig through their code, which is infinitely better than just knowing where to find them and praying they have any docs at all :) And for non-programmers, sticking with vanilla Emacs makes it unnecessarily painful experience, with 2/3 of useful features disabled by default and without access to the functionality available via packages, which I'd call really essential. For non-programmers vanilla Emacs is not that much better than Notepad++ or Gedit (if at all, considering weird key bindings!) and it's pointless to stick to it just to "learn about Emacs philosophy" - non-programmers won't benefit from "the Emacs way" (which is: being an infinitely programmable editor!) at all. It's much better for them to grab some Emacs starter kit, like Prelude or any other starter kit out there and then use customize-... interface to tweak what they need.
- tuhdo 12y agoI did write about customizing and extending Emacs here, and made a clear point about extending and customizing: " Because the nature of Emacs is an extensible system, people write extensions to improve Emacs and share with others. The extensions improve various aspects of Emacs: Improve existing and add new editing features, integrate 3rd party tools, add programming languages supports, change Emacs appearance… Without the ability to extend, Emacs will just be another obscure editor with some useful features but cannot meet the demands of people, because different people have different needs, and Emacs maintainers cannot provide them all and integrate all into Emacs. With the ability to extend, people can bend Emacs the way they want, much like Lisp. Unlike other editors which encourage users to stay with the default as much as they can, Emacs encourages users to customize and extend Emacs as much as they can." http://tuhdo.github.io/emacs-tutor3.html http://tuhdo.github.io/emacs-tutor3.html I just don't want to mix the two things: Emacs basics and Emacs extending together in a guide. It should be separate. I used to use packages a lot, until I realize that many built-in features which I didn't know serve me well. Learning stock Emacs is beneficial because users get the features that are always available. > I started learning with Emacs Lisp Manual, not a tutorial or Emacs Manual and it got me up to speed in no time at all I guess you method could work for, but I think it would be intimidating for most new users when they first read that to be able to use Emacs, they will have to learn Emacs Lisp. This is contrasting to everything else, even Vim. Vanilla Emacs is definitely better than Notepad++ or Gedit: - Emacs is an implementation of Emacs Lisp with an editor on top of it. The other editors are just... editors. - Emacs has many useful features such as: + how to use mark and point and region. A useful feature is exchange-point-and-mark; other editors do not have this. + Dired + ibuffers, that can manage hundreds of buffers + a window management system (so you don't have to use things like tmux, screen) + registers, you can save anything, like window configuration, text, position + the help system + Bookmark (to quickly access things later) + Calc (a scientific calculator) + CEDET a language framework for building IDE features (like context-sensitive completion, jump, find references...). The best language it is supporting is C/C++, as demonstrated in the guide. ...more features that typical editors won't have... Learning all these things should not require customization and external packages to further add burden to learners. After people learned something like Dired, if they want more, they can look it up for packages like Dired+. Finally, Prelude disables arrow keys and encourage users to use key bindings like C-f, C-b... I think most of the key bindings for editing in Emacs are fine and make editing faster. Of course, the bindings are not as ergonomics as Vim, but it is still much better than other editors. Since you don't like C-f, C-b... I guess you don't like key bindings with prefix C-x and C-c as well?
- klibertp 12y agoAlso, I have a suggestion (completely unrelated to my ramblings): could you maybe re-record the animations with some program showing what keys you press enabled? It would make them even better resource, I think. I only used this: https://launchpad.net/screenkey https://launchpad.net/screenkey but it seems it's unmaintained; still, it could be still working. I know it would be a lot of work, but it would turn the gifs into self-contained mini-howtos, which I think would benefit everyone :)