You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Is there a way to make clickable noweb references <<link>> in
source blocks in order to jump to its block definition?
- How are speed keys different from/better than evil-mode? Does speed
keys can be use along with evil-mode?
- Is there a good reason for the entry point to be a variable switch,
and for the bindings to be managed by a list, instead of having a
minor mode layering its keymap onto standard org-mode bindings?
- How do you count 5000 examples?
@@ -3902,3 +3905,306 @@ prints out the following into the message buffer:
3902
3905
:type-of-f lambda
3903
3906
:env-of-f nil)
3904
3907
#+END_SRC
3908
+
3909
+
* Questions and Answers
3910
+
:PROPERTIES:
3911
+
:CUSTOM_ID: /questions-and-answers/
3912
+
:END:
3913
+
** [[#/2022-04-04-search-options-link-abbreviations-and-org-open-at-point/][Search options in file links | link abbreviations | COME WITH ME on this JOURNEY into the heart of the command org-open-at-point]]
** [[#/2022-03-22-org-speed-keys-and-self-insert-command/][Org Speed Keys! BOOM! Great org-mode's feature! And a good OPPORTUNITY to talk about self-insert-command]]
*** How are speed keys different from/better than ~evil-mode~? Does speed keys can be use along with ~evil-mode~?
4093
+
**** Quick answer
4094
+
4095
+
1) If we are in evil normal state ~<N>~, Org speed keys won't work
4096
+
(because most of the printing keys are used for something else,
4097
+
specifically they are bound in ~evil-normal-state-map~),
4098
+
2) if we are in evil insert state ~<I>~ or in evil emacs state ~<E>~, Org
4099
+
speed keys works (because the printing keys are not bound by
4100
+
~evil-mode~ in ~evil-insert-state-map~ nor in ~evil-emacs-state-map~).
4101
+
4102
+
**** Answer with more details
4103
+
4104
+
Org speed keys are not better than ~evil-mode~ nor the other way, they
4105
+
are really differents.
4106
+
4107
+
***** Org speed keys
4108
+
4109
+
Org speed keys are a kind of a "hack" that hijack the "inserting emacs
4110
+
process".
4111
+
4112
+
It can be seen as: when we try to insert a character, do not use
4113
+
the standard command for inserting, use another one that checks for the
4114
+
position of the cursor in the buffer, if it is at a specific location,
4115
+
performs a lookup for the command to call, if we find one, call it, if
4116
+
none, insert the character. It is all about one command
4117
+
~self-insert-command~ and one remapping ~self-insert-command~ to
4118
+
~org-self-insert-command~.
4119
+
4120
+
***** ~evil-mode~
4121
+
4122
+
~evil-mode~ manipulates the hierarchy of all the keymaps that are
4123
+
active, making the current evil "state" map to win over the others.
4124
+
4125
+
We can check this by inspecting the list of the current active
4126
+
keymaps with the function ~current-active-maps~. If the same key
4127
+
sequence is bound several times to different commands in the list
4128
+
returned by ~current-active-maps~, the first binding in the list wins
4129
+
over the others.
4130
+
4131
+
For instance, when we are in evil normal state ~<N>~, the bindings in
4132
+
the keymap ~evil-normal-state-map~ takes precedence (over almost all)
4133
+
the other binding in the current active maps, and will appear at the
4134
+
beginning of the list returned by ~current-active-maps~.
4135
+
4136
+
Assuming we are in evil normal state ~<N>~, to check this previous
4137
+
assertion, we can run:
4138
+
4139
+
: M-x pp-eval-expression RET (current-active-maps)
4140
+
4141
+
Now, if we switch to the evil insert state ~<I>~, the bindings in
4142
+
the keymap ~evil-insert-state-map~ takes precedence (over almost all)
4143
+
the other binding in the current active maps, and will appear at the
4144
+
beginning of the list returned by ~current-active-maps~.
4145
+
4146
+
Assuming we are in evil normal state ~<I>~, to check this previous
4147
+
assertion, we can run:
4148
+
4149
+
: M-x pp-eval-expression RET (current-active-maps)
4150
+
4151
+
Now, what's interesting, is that evil insert state ~<I>~ doesn't bind the
4152
+
printing keys nor remap the command ~self-insert-command~. So, when
4153
+
we are in evil insert state ~<I>~, and we press the key ~n~ for
4154
+
instance, the "command loop editor", when perfoming the key lookup in
4155
+
the current active maps, won't find the binding coming from the
4156
+
keymaps ~evil-insert-state-map~ but the binding coming form the current
4157
+
global map which resolves (by default) to the command
4158
+
~self-insert-command~. And, if we've remapped ~self-insert-command~ to
4159
+
~org-self-insert-command~, (which is the case in org-mode with
4160
+
~org-use-speed-commands~ set to ~t~), the "command loop editor" will call
4161
+
~org-self-insert-command~.
4162
+
4163
+
*** Is there a good reason for the entry point to be a variable switch, and for the bindings to be managed by a list, instead of having a minor mode layering its keymap onto standard org-mode bindings?
4164
+
4165
+
I think that the benefit of this approach (remapping
4166
+
~self-insert-command~ to ~org-self-insert-command~) over having a minor
4167
+
mode layering its keymap onto standard ~org-mode~ is that we don't have
4168
+
to switch between keymaps or minor modes to get the feature.
4169
+
4170
+
Let's say we define a minor mode ~X-mode~ with the keymap ~X-mode-map~
4171
+
that binds the key ~n~ to ~org-next-visible-heading~.
4172
+
4173
+
Now, when ~X-mode~ is turned on, ~X-mode-map~ "wins" over ~org-mode-map~ and
4174
+
typing ~n~ will get us (from anywhere in the buffer) to the next
4175
+
heading.
4176
+
4177
+
Now, what should we do to insert the character ~n~ in the buffer? We
4178
+
should turn off ~X-mode~ to remove the binding from ~X-mode-map~.
4179
+
4180
+
With the remapping method we don't have to switch between minor modes
4181
+
before moving to the next heading by typing ~n~. The only restriction
4182
+
is to be at the beginning of a heading. There is always a trade off.
4183
+
4184
+
I don't know if it is a good reason but this the only one that I see.
4185
+
4186
+
** [[#/2022-03-11-org-mode-source-code-5000-examples/][Did you know that org-mode's source code contains more than 5000 examples?]]
0 commit comments