People transitioning from Vim could be surprised if we set these
variable to t by default, so setting them to nil respects better
the POLA principle.
Impacted variables:
dotspacemacs-ex-substitute-global
dotspacemacs-remap-Y-to-y$
Background: `C-i` and `TAB` are the same keycode for historic reasons.
With the current settings, evil [1] and evil-jumper [2] associate
`jump-forward` to `C-i` (==`TAB`), what overrides bindings set to
`TAB` (==`C-i`) in terminal mode, like `orc-cycle`. To fix this,
this commit:
- Set `evil-want-C-i-jump` to `nil`, to prevent `evil` and `evil-jumper`
to use the `C-i` (==`TAB`) keycode.
- Remove the spacemacs' code that bind `jump-forward` to `TAB`(==`C-i`)
The current spacemacs code already rebind `jump-forward` to the GUI-only
`<C-i>` keycode.
[1] 082bd65ccc/evil-maps.el (evil-maps.el-323)
[2] efaa841ca4/evil-jumper.el (L241)Fix#4505Fix#4487
Please check this, but this does the trick for me to fix#4057. The
reason I'm not sure about it is I don't know what the purpose of the
do-after-display-system-init code is. It doesn't seem necessary for me,
and I'm testing this on the GUI version.
Note that any non Emacsy command line parameter and non processed
command line parameter (that is unknown from Spacemacs) will hide the
home buffer. This should be good enough.
Fixes#4057
Add macro to wrap things that depend on the display being
initialized (and a frame active), such as getting the font. Advise the
`server-create-window-system-frame` function which is called by
emacsclient when creating a window-system frame. This is only run the
first time a frame is created, so the advice removes itself.
Fixes: syl20bnr/spacemacs#299 and syl20bnr/spacemacs#1894
(Among others)
Added dotfile variable to template and core-dotspacemacs.el
After enabling, if C-i is translated to the "key" <C-i> which allows you
to bind a separate command in the GUI like this
(define-key map [C-i] 'c-i-command)
or this
(define-key map (kbd "<C-i>") 'c-i-command)
This has the side effect of no longer making C-i default to TAB in the
GUI, but will not affect the TAB or <tab> bindings.
Removes spacemacs//handle-terminal-keys
package-refresh-packages was called every time a bootstrap package or
a theme was installed
Use configuration-layer/retrieve-package-archives to install bootstrap
packages and themes
Add a reentrance boolean to configuration-layer/retrieve-package-archives
Add force and quiet optional arguments to configuration-layer/retrieve-package-archives
Force refresh of archive when the user requests an update of packages
Add request.el to core/libs
Refactor package.el initialization in configuration-layer.el
Cosmetic improvements to loading messages
Remove redefinition of package-refresh-packages
New file core-emacs-ext.el
This is a basic monkey-patch solution but it will do the job for now.
The timeout amount is not configurable for now.
Tested on 24.5 and 24.3.1
fixes#3284
This pre-command-hook translates the special key to the corresponding
emacs function key. This effects only happens in terminal, this hook is
a no-op in GUI.
By doing this we attempt to bring more consistency between the GUI
and the terminal regarding TAB and RET keys.
spacemacs/set-key
spacemacs/set-key-for-state
These functions find normalized keys which should handle as sanely as
possible the GUI and the terminal.
See docstring of spacemacs//normalize-key for more info.
1. Make sure debug-on-error stays on
2. Force verbose loading
3. Detect long requires and loads (with --timed-requires)
4. Start profiler (with --profile)
Unfortunately spacemacs is not designed for installation
at use-package call time.
For use-package to be called a package must already be installed,
so I will continue on the initial plan, that is providing the
quelpa recipe at the <layer>-packages list level.
This is no bigdeal, this is basically moving :quelpa from
use-package to <layer>-packages variables.
Moreover it makes more sense to define package property at
declaration time instead of initialization (at least in spacemacs
world where installation is decoupled from configuration).
This has a benefit of not assuming that the user .emacs.d/ is in the
user home directory. Should continue to work as expected when this is
the case, but you could also start a fresh Emacs session like
so (assumes OSX):
open -a Emacs.app -n --args -q -l /path/to/emacs.d/init.el
So you don't have to muddle with symlinking your ~/.emacs.d or replacing
it with another just to try Spacemacs (or any other config). Note, that
this won't work with `after-init-hook` which doesn't appear to run when
Emacs is run with -q flag. As a result the `dotspacemacs/config` in your
.spacemacs won't run.
`tooltip-use-echo-area' is obsolete since 24.1; disabling `tooltip-mode'
achieves similar effect, and Tooltip mode has already been disabled in the
current code. Since Spacemacs supports Emacs 24.3 and 24.4,
`tooltip-use-echo-area' usage can be removed safely.
I have seen many "I have a problem" discussions in the Gitter chat which
starts with a barrage of questions "Which OS? Which Emacs version?",
etc., so I thought it may be useful to have one function that will
generate the info to be copy-pasted into the Gitter chat and hence both
the user and others helping in the Gitter chat can jump directly to
solving the problem instead of the support volley to figure out the
setup.
Example output:
ELISP> (spacemacs/system-info)
"OS: darwin Emacs: 24.5.1 Spacemacs: 0.103.0 Spacemacs branch: develop
Layers: ((auto-completion :variables auto-completion-enable-help-tooltip
t) better-defaults emacs-lisp git markdown org (shell :variables
shell-default-height 30 shell-default-position (quote bottom))
syntax-checking version-control c-c++ clojure dash github html osx
python semantic sql)"
References:
From
https://github.com/syl20bnr/spacemacs/issues/2033#issuecomment-113861451 :
> Also what is your emacs version and OS ?
From
https://github.com/syl20bnr/spacemacs/issues/2042#issuecomment-113861501 :
> What's your Emacs version ? I presume it comes from the semantic
layer, can you test without the semantic layer ?
Works with magit-next for now.
Tests to update and evilify functions robustness need to be improved.
Does not work 100% with magit-mode-map because it is created with
`make-keymap` and not `make-sparse-keymap` and `map-keymap` does not
seem to work with `make-keymap`.
- backup the packages to be updated
- then delete them
- the user restart emacs and spacemacs will install the last version
Fixes some update errors related to byte-compilation like the one
which affected the powerline (void variable left)
This commit also adds some page break for clarity
