remove!: various broken code

config.org

@@ -1195,24 +1195,6 @@ If PARENTS is non-nil, the parents of the specified directory will also be creat
       "s u" #'goto-address-at-point)
 #+end_src
 
-*** ... This is Also Here
-
-I'm not even going to bother explaining this one. Emacs is just janky sometimes lol
-
-#+begin_src emacs-lisp
-(defadvice! ~/projectile-find-file (invalidate-cache &optional ff-variant)
-  :override #'projectile--find-file
-  (projectile-maybe-invalidate-cache invalidate-cache)
-  (let* ((project-root (projectile-acquire-root))
-         (file (read-file-name "Find file: " project-root project-root
-                               (confirm-nonexistent-file-or-buffer) nil
-                               ))
-         (ff (or ff-variant #'find-file)))
-    (when file
-      (funcall ff (expand-file-name file project-root))
-      (run-hooks 'projectile-find-file-hook))))
-#+end_src
-
 ** Automated Nix Builds
 
 #+call: confpkg("Nix")
@@ -2295,18 +2277,7 @@ A natural thing to do when browsing through the project tree is create a new fil
 
 *** Project Integration
 
-I often accidentally open the project tree before I've even selected a project, which I don't want because it messes up =treemacs-projectile=. Let's fix that problem:
+When I have a project open, Treemacs is flexible and allows me to open directories other than that project. This /would/ be great and convenient if it weren't for the fact that it doesn't do so very well, often completely messing up the existing project structure. This convenience function ensures that only the project directory is open.
-
-#+begin_src emacs-lisp
-(defun ~/treemacs-restrict (&rest _)
-  (unless (doom-project-p)
-    (user-error "Must be in a project to open project tree")))
-
-(advice-add #'treemacs-select-window :before #'~/treemacs-restrict)
-(advice-add #'+treemacs/toggle :before #'~/treemacs-restrict)
-#+end_src
-
-When I do have a project open, Treemacs is flexible and allows you to open directories other than that project. This /would/ be great and convenient if it weren't for the fact that it doesn't do so very well, often opening the wrong directories entirely. This convenience function ensures that only the project directory is open.
 
 #+begin_src emacs-lisp
 (defun ~/treemacs-fix-project ()
@@ -3147,40 +3118,6 @@ If nil, then `default-directory' for the org buffer is used.")
   (funcall orig-fn extension subtreep pub-dir))
 #+end_src
 
-*** Attachment Inline Previews
-
-Doom enhances Org mode's attachment system to show inline previews of attached images. However, this appears to be broken due to using outdated APIs, so we have to patch the link parameter responsible.
-
-#+begin_src emacs-lisp
-(defadvice! ~/org-image-file-data-fn (protocol link _description)
-  "Properly handle attachment links."
-  :override #'+org-image-file-data-fn
-  (setq link
-        (pcase protocol
-          ("download"
-           (expand-file-name
-            link
-            (or (if (require 'org-download nil t) org-download-image-dir)
-                (if (require 'org-attach)         org-attach-id-dir)
-                default-directory)))
-          ("attachment"
-           (require 'org-attach)
-           (org-attach-expand link))
-          (_ (expand-file-name link default-directory))))
-  (when (and (file-exists-p link)
-             (image-type-from-file-name link))
-    (with-temp-buffer
-      (set-buffer-multibyte nil)
-      (setq buffer-file-coding-system 'binary)
-      (insert-file-contents-literally link)
-      (buffer-substring-no-properties (point-min) (point-max)))))
-
-(defadvice! ~/org-init-attach-link ()
-  "Properly set attachment link's parameters."
-  :after #'+org-init-attachments-h
-  (org-link-set-parameters "attachment" :image-data-fun #'+org-image-file-data-fn))
-#+end_src
-
 *** Inline Image Previews
 
 Inline images in Org are file links pointing to images without a description. User-defined inline images can have a description, however, which makes for a disparity between file links and other links that is very counter-intuitive. We can advise the image data provider functions to fix this, and I'll add a variable to restore the default behavior if I ever want to.