Hashing the recipe makes sense and actually seems to decrease start up time (marginally) on my system. I've got a patch on my fork which does so and it seems to solve the issue with Company completion. You can try it via straight-bug-report if you like:

Tested here and indeed flex completion seems fast again! (Also, straight-bug-report is 🔥.)

I'll have to look over the transaction system more closely, but I believe these symbols may only need to last as long as a transaction. If that's true, we can unintern them at the end of a transaction as well. Will look into that ASAP.

Great, I was wondering whether straight could unintern those as well. Fewer symbols to search always helps. 😃

Thank you for looking at this!

Hashing the recipe makes sense and actually seems to decrease start up time (marginally) on my system. I've got a patch on my fork which does so and it seems to solve the issue with Company completion. You can try it via straight-bug-report if you like:

(straight-bug-report
  :user-dir "hash-transaction-symbol.straight"
  :interactive t
  :pre-bootstrap
  (setq straight-repository-user   "progfolio"
        straight-repository-branch "fix/transaction-symbols")
  :post-bootstrap
  (setq completion-styles '(flex))
  (straight-use-package 'company))

That should open a child Emacs process which will have straight and Company installed and the completion style set u properly. You can test within that environment.

I'll have to look over the transaction system more closely, but I believe these symbols may only need to last as long as a transaction. If that's true, we can unintern them at the end of a transaction as well. Will look into that ASAP.

I experience the same lag you mention w Company and Elisp buffers. Havent had a chance to look into it, but what you mention here makes sense

I'll look into this ASAP. I'm sure there's a way to avoid the long symbols.

What's wrong

I noticed very slow flex completion and I think I traced it back to very long symbols created by straight.el. For example, one such symbol:

use-package-\(:type\ git\ :flavor\ melpa\ :files\ \(\"*groovy*\.el\"\ \"groovy-mode-pkg\.el\"\)\ :host\ github\ :repo\ \"Groovy-Emacs-Modes/groovy-emacs-modes\"\ :package\ \"groovy-mode\"\ :local-repo\ \"groovy-emacs-modes\"\)-nil-nil

Directions to reproduce

<!-- Please give instructions for how to reproduce the behavior starting from an empty ~/.emacs.d. Unfortunately, I simply don't have enough time to check out your bug report unless it has clear instructions for this.

straight.el provides a macro, straight-bug-report, which can be used to easily create a minimal reproduction case in a clean Emacs environment. Please use this if possible. For instructions, see https://github.com/raxod502/straight.el#debugging and the straight-bug-report docstring.

If straight-bug-report is not available or fails you can still create a reproduction case manually. To do this, start with an empty ~/.emacs.d/init.el, add the bootstrap snippet, and then add any additional code from your init-file that's needed to set up the buggy behavior. Then include a list of steps to follow (commands to run, files to modify, whatever) after Emacs startup.

Make sure you're using the latest version of straight.el. You can do this by including (setq straight-repository-branch "develop") in your init-file before the bootstrap snippet.

Also, unless you are already quite certain that your problem is specific to straight.el, please verify that it cannot be reproduced using package.el. If you can reproduce your problem with package.el, then it's not a bug in straight.el and I can't do anything about it!

If you try these steps and can't reproduce the problem, it must be something particular to your environment or configuration. In this case, you'll have to bisect in order to figure out what is causing the problem. I won't be able to debug a problem that only happens on your computer! -->

1. Start emacs -q
2. Eval the following to install straight and set completion-styles:

(setq straight-repository-branch "develop")
(defvar bootstrap-version)
(let ((bootstrap-file
       (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
      (bootstrap-version 5))
  (unless (file-exists-p bootstrap-file)
    (with-current-buffer
        (url-retrieve-synchronously
         "https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el"
         'silent 'inhibit-cookies)
      (goto-char (point-max))
      (eval-print-last-sexp)))
  (load bootstrap-file nil 'nomessage))

(setq completion-styles '(flex))

3. <kbd>M-x</kbd> ielm <kbd>RET</kbd>
4. Eval (benchmark-run 1 (completion-all-completions "fooooooooooooooooooooooo" obarray #'fboundp 0)) to get a baseline. On my system, this completes in approximately 0.04 seconds (the first number in the list returned by benchmark-run. Feel free to increase 1 to a larger number to get it to run more times and get an average. Note that the number of os in "fooooooooooooooooooooooo" is important. I wish I was joking about that.
5. <kbd>M-x</kbd> straight-use-package <kbd>RET</kbd> groovy-mode <kbd>RET</kbd>
6. Once again eval (benchmark-run 1 (completion-all-completions "fooooooooooooooooooooooo" obarray #'fboundp 0)).

Expected result: Completes in approximately 0.04 seconds once again

Observed result: Now takes 4–8 times longer, ex. 1.75 seconds

I believe these symbols are being created here.

Note that the above call to completion-all-completions is roughly equivalent to what company-mode will do in an Elisp buffer when it's using completion-at-point to generate completion candidates. That's how I ran into this: I was getting ridiculously long pauses when writing Elisp with company-mode turned on.

I chose groovy-mode for my reproduction instructions above that's the package I hit while bisecting my init.el to find what was slowing down company-mode. I'm not sure if the flex matching gets hung up because of peculiarities of the exact strings in the groovy-mode recipe (which becomes part of that use-package-... symbol), or if it's merely the length of the symbol (which also owes to the recipe). I assume packages other than groovy-mode could cause this slowdown as well.

I find it unusual that you're creating such long symbols, but I think I get why you're doing it, and I don't really have any reason to believe that what you're doing is wrong or in any way a bad practice, so I understand if you wish to close this with something like "well don't use flex to complete Elisp symbols". But I thought you would like to know that this issue could be affecting some of your other users.

If you did want to "fix" this, maybe you could use strings for the transaction IDs? Or hash the recipe with md5 and use that? I haven't looked real hard at straight's code. (I'm afraid I'm burned out tonight from tracking down the source of this error!)

For my part, I think I'm going to try and advise something in the flex completion machinery not to even try and match symbols longer than a some length, and/or not to use flex when the pattern is longer than some length.

Version information

• Emacs version: GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin20.5.0, NS appkit-2022.50 Version 11.4 (Build 20F71)) of 2021-06-19 (I built master earlier tonight)
• Operating system: macOS 11.4 x86-64

Thank you so much for all your packages, BTW! I just realized how many I use: straight, el-patch, prescient, blackout, and ctrlf. And now I'm looking at apheleia.

Thank you. @progfolio

Declare all of the permitted special symbols used in apheleia-formatters commands.

Without this, 'customize-variable never allows settting the value of apheleia-formatters, instead reporting an error about a mismatch between the default value and the type.

Powered by straight, auctex, eglot, texlab, and company, I finally figured out a working vanilla Emacs based LaTeX document preparation system. See here for more detailed info, and the following screenshot for a rough impression:

Thank you for pointing this out.

I recently got drawn into issues with mu4e again. I've got a fix below.

I encountered this during a doom upgrade:

      > Building mu4e...
      x There was an unexpected error
        Message: error
        Data: (error . ":pre-build command error in \"mu4e\" recipe in command \"(\\\"./autogen.sh\\\")\"")
        Backtrace:
          (signal error (":pre-build command error in \"mu4e\" recipe in command \"(
          (error ":pre-build command error in %S recipe in command %S" "mu4e" "(\"./
          (condition-case err (if (cl-every #'stringp command) (if (apply #'straight
          (let ((command (car --dolist-tail--))) (condition-case err (if (cl-every #
          (while --dolist-tail-- (let ((command (car --dolist-tail--))) (condition-c
          (let ((--dolist-tail-- (if (cl-every #'listp commands) commands (list comm
          (let ((default-directory repo) (commanderror nil)) (let ((--dolist-tail-- 
          (if repo (let ((default-directory repo) (commanderror nil)) (let ((--dolis
          (let* ((commands (and t (if post post-build pre-build))) (repo (and comman
          (let* ((--cl-rest-- recipe) (pre-build (car (cdr (plist-member --cl-rest--

My mu4e is symlinked out of a nix directory. nix likes to keep everything read-only, and I see no autogen.sh to run. There are already .elc files there (I assume the nix derivation build put them there). So I disabled the pre-build step:

(package! mu4e
  :recipe (
           :local-repo "~/.nix-profile/share/emacs/site-lisp/mu4e"
           ;; pre-build must be disabled when using the nix derivation - in part
           ;; because it is alreadt built, but also because the directory is
           ;; read-only because that's how nix likes to do things.
           :pre-build ()
           )
  )

"~/.nix-profile/share/emacs/site-lisp/mu4e" comes from a symlink, which is documented earlier in this thread.

I apologize if this necro-posting is considered distasteful. My (perhaps poor) justification is that searches for pre-build issues relating to straight.el and mu4e bring me back here. Perhaps this will help someone else.

Add a command to forget a candidate. This is desirable after making a mistake.

Do you think that it is worth sorting the candidates in any particular order? Since prescient.el is already being used, a bad candidate recently used would be sorted somewhere near the top of the list, yes?