emenel/doomemacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Fix typos in docs/getting_started.org

Browse source
This commit is contained in:
ejez 2020-12-20 11:58:48 +03:00
parent 0c9256411d
commit 3cae62cacf
1 changed files with 10 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

20
docs/getting_started.org
View file

@ -50,7 +50,7 @@ us know!
- [[#installing-packages-from-external-sources][Installing packages from external sources]] - [[#installing-packages-from-external-sources][Installing packages from external sources]]
- [[#pinning-packages-to-specific-commits][Pinning packages to specific commits]] - [[#pinning-packages-to-specific-commits][Pinning packages to specific commits]]
- [[#disabling-packages][Disabling packages]] - [[#disabling-packages][Disabling packages]]
- [[#changing-a-recipe-for-a-included-package][Changing a recipe for a included package]] - [[#changing-a-recipe-for-an-included-package][Changing a recipe for an included package]]
- [[#usingloading-local-packages][Using/loading local packages]] - [[#usingloading-local-packages][Using/loading local packages]]
- [[#configuring-doom][Configuring Doom]] - [[#configuring-doom][Configuring Doom]]
- [[#configuring-packages][Configuring packages]] - [[#configuring-packages][Configuring packages]]
@ -886,7 +886,7 @@ packages:
ensure your changes take effect. ensure your changes take effect.
#+end_quote #+end_quote
*** Changing a recipe for a included package *** Changing a recipe for an included package
If a Doom module installs package X from one place, but you'd like to install it If a Doom module installs package X from one place, but you'd like to install it
from another (say, a superior fork), add a ~package!~ declaration for it in your from another (say, a superior fork), add a ~package!~ declaration for it in your
=DOOMDIR/packages.el=. Your private declarations always have precedence over =DOOMDIR/packages.el=. Your private declarations always have precedence over
@ -1176,7 +1176,7 @@ Placing this on top of a lisp form will do one of two things:
=~/.emacs.d/.local/autoloads.el=, which is read very early in the startup =~/.emacs.d/.local/autoloads.el=, which is read very early in the startup
process). process).
2. Or copy that lisp form to Doom's autoload file verbatim (usually the case for 2. Or copy that lisp form to Doom's autoload file verbatim (usually the case for
anything other then ~def*~ forms, like ~defun~ or ~defmacro~). anything other than ~def*~ forms, like ~defun~ or ~defmacro~).
Doom's autoload file is generated by scanning these files when you execute ~doom Doom's autoload file is generated by scanning these files when you execute ~doom
sync~. sync~.
@ -1414,9 +1414,9 @@ org module documentation]] for details on how to add support for it.
#+END_SRC #+END_SRC
These two lines are a common sight in Emacs configs, but they are unnecessary These two lines are a common sight in Emacs configs, but they are unnecessary
for Doom Emacs. We already use the more sophisticated =wsbutler= to manage for Doom Emacs. We already use the more sophisticated =ws-butler= to manage
extraneous whitespace. However, you might have the impression that it isn't extraneous whitespace. However, you might have the impression that it isn't
working. That's because =wsbutler= works in two unusual ways, meant to be less working. That's because =ws-butler= works in two unusual ways, meant to be less
imposing than its alternatives: imposing than its alternatives:
1. It only cleans up trailing whitespace /on lines that you've touched/ (but 1. It only cleans up trailing whitespace /on lines that you've touched/ (but
@ -1431,7 +1431,7 @@ imposing than its alternatives:
However, if it's truly deliberate, ~M-x delete-trailing-whitespaces~ and ~M-x However, if it's truly deliberate, ~M-x delete-trailing-whitespaces~ and ~M-x
whitespace-cleanup~ are available to be called =deliberately=, instead. whitespace-cleanup~ are available to be called =deliberately=, instead.
2. =wsbutler= replaces trailing whitespace and newlines with *virtual* 2. =ws-butler= replaces trailing whitespace and newlines with *virtual*
whitespace. This is whitespace that only exists in the Emacs buffer, but whitespace. This is whitespace that only exists in the Emacs buffer, but
isn't actually written to the file. isn't actually written to the file.
@ -1470,7 +1470,7 @@ provide tools to make this easier. Here are a few things you can try, first:
issues that originate from upstream. issues that originate from upstream.
+ If you happen to know what module(s) are relevant to your issue, check their + If you happen to know what module(s) are relevant to your issue, check their
documentation (press =<leader> h m= to jump to a module's documentation). Your documentation (press =<leader> h d m= to jump to a module's documentation). Your
issue may be documented. issue may be documented.
+ If possible, see if the issue can be reproduced in vanilla Emacs (Emacs + If possible, see if the issue can be reproduced in vanilla Emacs (Emacs
@ -1559,9 +1559,9 @@ and before the subcommand. This will be fixed eventually.
Often, you may find it helpful for debugging to evaluate some Emacs Lisp. Here Often, you may find it helpful for debugging to evaluate some Emacs Lisp. Here
are couple things you can do: are couple things you can do:
+ Use =M-;= (bound to ~eval-expression~), + Use =M-:= (bound to ~eval-expression~),
+ =SPC x= will open a scratch buffer. ~M-x emacs-lisp-mode~ will change it to + =SPC x= will open a scratch buffer. ~M-x emacs-lisp-mode~ will change it to
the appropriate major mode, then use ~+eval:region~ (=gr=) and ~+eval:buffer~ the appropriate major mode, then use ~+eval:region~ (=gr=) and ~+eval/buffer~
(=gR=) to evaluate code, (=gR=) to evaluate code,
** How to determine the origin of a bug ** How to determine the origin of a bug
@ -1571,7 +1571,7 @@ in a fresh instance of Emacs with varying amounts of Doom loaded (none at all,
all of it, or somewhere in between). This can be helpful for isolating bugs to all of it, or somewhere in between). This can be helpful for isolating bugs to
determine who you should report a bug to. determine who you should report a bug to.
If you can recreate a bug in vanilla Emacs than it should be reported to the If you can recreate a bug in vanilla Emacs then it should be reported to the
developers of the relevant packages or, perhaps, the Emacs devs themselves. developers of the relevant packages or, perhaps, the Emacs devs themselves.
Otherwise, it is best to bring it up on the Doom Emacs issue list, rather than Otherwise, it is best to bring it up on the Doom Emacs issue list, rather than