emenel/doomemacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
doomemacs/modules/lang/swift/config.el

37 lines
1.2 KiB
EmacsLisp
Raw Normal View History

Major optimization refactor, across the board + enable lexical-scope everywhere (lexical-binding = t): ~5-10% faster startup; ~5-20% general boost + reduce consing, function calls & garbage collection by preferring cl-loop & dolist over lambda closures (for mapc[ar], add-hook, and various cl-lib filter/map/reduce functions) -- where possible + prefer functions with dedicated opcodes, like assq (see byte-defop's in bytecomp.el for more) + prefer pcase & cond (faster) over cl-case + general refactor for code readability + ensure naming & style conventions are adhered to + appease byte-compiler by marking unused variables with underscore + defer minor mode activation to after-init, emacs-startup or window-setup hooks; a customization opportunity for users + ensures custom functionality won't interfere with startup.
2017-06-08 11:47:56 +02:00
;;; lang/swift/config.el -*- lexical-binding: t; -*-
rm module-apple, add module-{db,swift}, disable module-org, update init.el
2016-05-21 18:53:31 -04:00
lang/swift: defer set-repl-handler! call
2018-07-15 01:01:56 +02:00
(after! swift-mode
refactor(:lang): move tree-sitter init Moved add-hook calls (for tree-sitter initialization) into their respective modes' config blocks, or nearby, to be consistent with how other, similar tools (like lsp!) are initialized, and does so at runtime, rather than at expansion/compile time, which eval-when! caused.
2022-07-25 17:34:44 +02:00
(set-repl-handler! 'swift-mode #'run-swift)
refactor: deprecate featurep! for modulep! featurep! will be renamed modulep! in the future, so it's been deprecated. They have identical interfaces, and can be replaced without issue. featurep! was never quite the right name for this macro. It implied that it had some connection to featurep, which it doesn't (only that it was similar in purpose; still, Doom modules are not features). To undo such implications and be consistent with its namespace (and since we're heading into a storm of breaking changes with the v3 release anyway), now was the best opportunity to begin the transition.
2022-08-12 20:29:19 +02:00
(when (modulep! +tree-sitter)
refactor(:lang): move tree-sitter init Moved add-hook calls (for tree-sitter initialization) into their respective modes' config blocks, or nearby, to be consistent with how other, similar tools (like lsp!) are initialized, and does so at runtime, rather than at expansion/compile time, which eval-when! caused.
2022-07-25 17:34:44 +02:00
(add-hook 'swift-mode-local-vars-hook #'tree-sitter! 'append)))
Update modules/lang/*
2017-02-19 18:57:16 -05:00
Major refactor & optimization of how modules load their packages Now that we are loading package autoloads files (as part of the generated doom-package-autoload-file when running make autoloads), many :commands properties are redundant. In fact, many def-package! blocks are redundant. In some cases, we can do without a config.el file entirely, and can move into the autoloads file or rely entirely on package autoloads. Also, many settings have been moved in their module's autoloads files, which makes them available ASAP; their use no longer depends on module load order. This gained me a modest ~10% boost in startup speed.
2018-05-25 00:46:11 +02:00
:boom: Rename def-package! -> use-package! Calling this pivotal macro "def-package!" has frequently been a source of confusion. It is a thin wrapper around use-package, and it should be obvious that it is so. For this reason, and to match the naming convention used with other convenience macros/wrappers, it is now use-package!. Also changes def-package-hook! -> use-package-hook! The old macros are now marked obsolete and will be removed when straight integration is merged.
2019-07-23 12:44:03 +02:00
(use-package! flycheck-swift
refactor: deprecate featurep! for modulep! featurep! will be renamed modulep! in the future, so it's been deprecated. They have identical interfaces, and can be replaced without issue. featurep! was never quite the right name for this macro. It implied that it had some connection to featurep, which it doesn't (only that it was similar in purpose; still, Doom modules are not features). To undo such implications and be consistent with its namespace (and since we're heading into a storm of breaking changes with the v3 release anyway), now was the best opportunity to begin the transition.
2022-08-12 20:29:19 +02:00
:when (modulep! :checkers syntax)
:unless (modulep! +lsp)
Major refactor & optimization of how modules load their packages Now that we are loading package autoloads files (as part of the generated doom-package-autoload-file when running make autoloads), many :commands properties are redundant. In fact, many def-package! blocks are redundant. In some cases, we can do without a config.el file entirely, and can move into the autoloads file or rely entirely on package autoloads. Also, many settings have been moved in their module's autoloads files, which makes them available ASAP; their use no longer depends on module load order. This gained me a modest ~10% boost in startup speed.
2018-05-25 00:46:11 +02:00
:after swift-mode
:config (flycheck-swift-setup))
Update modules/lang/*
2017-02-19 18:57:16 -05:00
rm module-apple, add module-{db,swift}, disable module-org, update init.el
2016-05-21 18:53:31 -04:00
:boom: Rename def-package! -> use-package! Calling this pivotal macro "def-package!" has frequently been a source of confusion. It is a thin wrapper around use-package, and it should be obvious that it is so. For this reason, and to match the naming convention used with other convenience macros/wrappers, it is now use-package!. Also changes def-package-hook! -> use-package-hook! The old macros are now marked obsolete and will be removed when straight integration is merged.
2019-07-23 12:44:03 +02:00
(use-package! company-sourcekit
refactor: deprecate featurep! for modulep! featurep! will be renamed modulep! in the future, so it's been deprecated. They have identical interfaces, and can be replaced without issue. featurep! was never quite the right name for this macro. It implied that it had some connection to featurep, which it doesn't (only that it was similar in purpose; still, Doom modules are not features). To undo such implications and be consistent with its namespace (and since we're heading into a storm of breaking changes with the v3 release anyway), now was the best opportunity to begin the transition.
2022-08-12 20:29:19 +02:00
:when (modulep! :completion company)
:unless (modulep! +lsp)
Update modules/lang/*
2017-02-19 18:57:16 -05:00
:after swift-mode
:config
Introduce autodefs to replace some settings + :popup -> set-popup-rule! + :popups -> set-popup-rules! + :company-backend -> set-company-backend! + :evil-state -> set-evil-initial-state! I am slowly phasing out the setting system (def-setting! and set!), starting with these. What are autodefs? These are functions that are always defined, whether or not their respective modules are enabled. However, when their modules are disabled, they are replaced with macros that no-op and don't waste time evaluating their arguments. The old set! function will still work, for a while.
2018-06-15 02:58:12 +02:00
(set-company-backend! 'swift-mode '(company-sourcekit company-yasnippet)))
rm module-apple, add module-{db,swift}, disable module-org, update init.el
2016-05-21 18:53:31 -04:00
Add basic LSP support Still needs to be documented, but includes support for the following languages: + C/C++/ObjC + Go + Java + Javascript + OCaml + PHP + Python + Ruby + Scala + Swift + HTML/CSS Relevant to #460, #716, #1186
2019-02-21 16:08:27 -05:00
:boom: Rename def-package! -> use-package! Calling this pivotal macro "def-package!" has frequently been a source of confusion. It is a thin wrapper around use-package, and it should be obvious that it is so. For this reason, and to match the naming convention used with other convenience macros/wrappers, it is now use-package!. Also changes def-package-hook! -> use-package-hook! The old macros are now marked obsolete and will be removed when straight integration is merged.
2019-07-23 12:44:03 +02:00
(use-package! lsp-sourcekit
refactor: deprecate featurep! for modulep! featurep! will be renamed modulep! in the future, so it's been deprecated. They have identical interfaces, and can be replaced without issue. featurep! was never quite the right name for this macro. It implied that it had some connection to featurep, which it doesn't (only that it was similar in purpose; still, Doom modules are not features). To undo such implications and be consistent with its namespace (and since we're heading into a storm of breaking changes with the v3 release anyway), now was the best opportunity to begin the transition.
2022-08-12 20:29:19 +02:00
:when (modulep! +lsp)
Add basic LSP support Still needs to be documented, but includes support for the following languages: + C/C++/ObjC + Go + Java + Javascript + OCaml + PHP + Python + Ruby + Scala + Swift + HTML/CSS Relevant to #460, #716, #1186
2019-02-21 16:08:27 -05:00
:after swift-mode
tweak(:lang,:tools): start eglot/lsp-mode later To ensure lsp/eglot settings have precedence over local servers (e.g. cider and lookup handlers). Ref: clojure-emacs/cider#3170
2022-03-24 02:19:52 +01:00
:init (add-hook 'swift-mode-local-vars-hook #'lsp! 'append)
lang/swift: add sane sourcekit-lsp defaults
2019-10-27 12:18:13 -04:00
:config
(setq lsp-sourcekit-executable
(cl-find-if #'executable-find
Bump :lang swift swift-emacs/swift-mode@95ff004 -> swift-emacs/swift-mode@ad12a30 emacs-lsp/lsp-sourcekit@ff204ed -> emacs-lsp/lsp-sourcekit@aafa987 Adds support for sourcekit-lsp bundled with Xcode
2021-04-23 22:42:47 +09:00
(list lsp-sourcekit-executable ; 'sourcekit-lsp' by default
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/sourcekit-lsp"
"sourcekit"
"/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin/sourcekit-lsp"
"/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin/sourcekit"))))
Reference in a new issue Copy permalink