Installing seq from elpa (for Magit)

[snan]

I applied this change (or rather, I customized the variable to remove the seq entry).
And now I'm trying to install seq from ELPA with straight but I don't know how to do that. I evaluated (straight-use-package 'seq) but it just said t and nothing was fetched or installed.
And elpa doesn't seem to be a valid recipe :type either.

This is all so Magit can work.

Magit peeps suggest I unload seq and require it etc etc but before that I need straight.el to installing the ELPA seq.

That's where I'm at right now, trying to figure out the right straight recipe, (straight-use-package 'seq) wasn't enough, it just returns t without fetching a package.

I tried (straight-use-package '(seq :type elpa)) but ELPA isn't a recipe type.

[progfolio]

Please provide the output of M-x straight-version and the recipes you are using.

[snan]

Yeeesss! Updating to more recent straight.el did it!

(but that caused a super weird issue: (tool-bar-mode -1) used to be the first things in my init.el but now that crashes my Emacs start up! That was the only line it complained about so I bisected my init and it turns out (tool-bar-mode -1) crashes unless it's ran after

(straight-use-package 'notmuch)
(require 'notmuch)

So presumably there's something in there that's required to make (tool-bar-mode -1) work. Too bad, because I was gonna not run notmuch on this machine, it's just a li'l writing machine and Emacs is already super slow on it.

and also super strange because I've always had (tool-bar-mode -1) before the notmuch stuff before I upgraded straight and did the elpa seq. (I tried (require 'seq) but that didn't make a difference.)

[progfolio]

but now that crashes my Emacs start up! That was the only line it complained about so I bisected my init and it turns out (tool-bar-mode -1) crashes unless it's ran after

When you say "crashes" do you mean Emacs closes entirely and you have to start it again, or do you mean an error is signaled? Try starting emacs with the --debug-init command line option, and you'll likely get a backtrace. If it's a genuine crash, you should M-x report-emacs-bug.

[snan]

The standard "something is wrong in the init so it warns and then refuses to load the rest of the init making it very difficult to fix the issue since all the normal bindings I rely on are gone" that always happens when there's someting wrong in the init.

I did try --debug-init before I went on the bisecting journey but that gave me no additional info.

Symbol's function definition is void: tool-bar mode

is all I get either way. Until I require notmuch. 🤷🏻‍♀️

[progfolio]

Based off the information given, I don't think this is a straight.el issue.
I would try asking on a more general Emacs support forum.
Be sure to include:

• The OS you are using
• The version of Emacs you are using
• Any errors being signaled.
• A minimal way of reproducing the problem without your entire config.

[snan]

It's 💯 a straight.el issue since it arose when I upgraded straight.el. Working on finding the exact thing that makes (tool-bar-mode -1) work.

I've followed includes from includes from includes from includes. Currently I'm in rmail.el as included from gnus-utils as included from mml-sec as included from I don't remember which in turn was included from notmuch.el. I'm putting in hours and hours of work chasing down the exact issue here.

Finding a minimal way to reproduce the problem is exactly what I'm working on.

[snan]

I found it after several hours of bisecting and loading and commenting and deleting but it turns out that rmail.el calls a function that's autoloaded from tool-bar.el whereas (tool-bar-mode -1) itself isn't. Kinda unfair that I'd need to load a mode just to turn it off but anyway this never happened before I upgraded straight.el 🤷🏻‍♀️

i guess I don't need to load it; I wrapped it in a when (fboundp 'tool-bar-mode) Finally have a working Emacs again 😮‍💨. I think that's what changed inbetween straight versions, Emacs no longer provides tool-bar-mode by default. And that's great. But was quite a rabbit hole to sort out.

[progfolio]

Glad you've got things working again.

I found it after several hours of bisecting and loading and commenting and deleting

A couple tips to save yourself hours of debugging in the future:

1. I requested specific info to try and help, but you never gave any of it.
   It's much harder for someone else to help without the info I mentioned here and requested here.

2. Having a hypothesis of what's causing a bug is a good start. But remember,
   correlation is not causation.

   It's 💯 a straight.el issue since it arose when I upgraded straight.el.

   Is there any other evidence you have other than "it happened after I updated"?
   Again, it's hard to help on my end due to the limited info you've provided.

   I think that's what changed inbetween straight versions, Emacs no longer provides tool-bar-mode by default.

   Did you look at the definition of tool-bar-mode (M-x find-function tool-bar-mode)?
   Directly above it is the following comment:

   ;; The autoload cookie doesn't work when preloading.
   ;; Deleting it means invoking this command won't work
   ;; when you are on a tty.  I hope that won't cause too much trouble -- rms.

   So tool-bar-mode is never autoloaded. That has nothing to do with straight.el.
   Are you using GUI Emacs or via the terminal? That's a possible cause.

3. If you're interested in knowing who is responsible for loading a package you can use the following:

   ;;(eval-after-load FEATURE-OR-FILE-NAME '(debug))
   ;; e.g. (eval-after-load 'tool-bar '(debug))

   It will give you a debugger backtrace showing you what caused the feature to be loaded.
   Alternatively you could inspect the load-history variable.

Please try the above tips first next time.

[snan]

As I said, I can't paste text from this machine and the info on which was the previous version of straight.el was lost. I upgraded to the new version. Running on a terminal, on Alpine on ARM. My normal command for finding out the OS doesn't work either since it shells out to lsb_release which this li'l dinky Alpine BusyBox iSH doesn't have apparently.

Yes, with the benefit of hindsight we now know that tool-bar-mode itself was the package that wasn't being loaded, and knowing that can look at the definition and its comments. I looked at so many function definitions tonight to get to that point. I didn't know about load-history or debug, and I'm glad I know about them now; that would've been one way to work "in the other direction", which, in this particular case, would've led me straight to the right library (tool-bar-mode itself) but I couldn't know that; I was thinking it was one of tool-bar-mode's prereqs that had changed.

Nothing was different about tool-bar-mode itself other than that I upgraded straight. Nothing else had changed. I upgraded straight.el and immediately (tool-bar-mode -1) caused the init to error out. I put the time in, in order to help straight.el because I care about it. I already had it working (just include notmuch which in turn included mm-view which in turn included mml-smime which in turn included mml-sec which in turn included gnus-util which in turn included rmail which… and rmail was an especially tricky bisect with interdependent, dynamically scoped vars so just commenting out half the defs led to more borkage so I needed to do it more carefully, but I narrowed it down to one function and there I saw that it included a function that did cause tool-bar-mode to autoload. I could've been fine with just stopping at "huh turning off the toolbar only works if I do it after I load notmuch" but I went the extra 500 miles just in order to troubleshoot straight.el more carefully because I think it's an awesome package manager that I wanted to make sure was bug free.

(And I'm still not sure what the issue is or how come tool-bar is no longer loaded by default but now thanks to this thread, this issue has more documentation for the next person that comes across something similar.)

You don't need to be mean to someone who is doing the boring heavy bisecting lifting in order to help. That's my 2 cents at least.

[progfolio]

I can't paste text from this machine

You were able to share an irrelevant screenshot.
A screenshot would've been fine as well.

the info on which was the previous version of straight.el was lost.

I did not ask for that information.
I asked for the output of straight-version, which will provide most of the info we need to help troubleshoot.

I upgraded to the new version.

This is not useful because "the new version" doesn't tell what commit you are on.
Absent that, I have no way of telling what version you're running.

Running on a terminal, on Alpine on ARM. My normal command for finding out the OS doesn't work either since it shells out to lsb_release which this li'l dinky Alpine BusyBox iSH doesn't have apparently.

Again, this info would've been provided by M-x straight-version.
The fact that you're running Emacs from the terminal is the root cause of the issue, as noted in that comment above the definition for tool-bar-mode.

I already had it working... [OMITTED]. I could've been fine with just stopping at "huh turning off the toolbar only works if I do it after I load notmuch" but I went the extra 500 miles just in order to troubleshoot straight.el more carefully because I think it's an awesome package manager that I wanted to make sure was bug free.

Again, there is no bug in straight.el here.
You have failed to show that, and I'm positive of the cause now that we know you are running Emacs from the terminal. The comment above tool-bar-mode (from a change in 2005) points out the issue.

You don't need to be mean to someone who is doing the boring heavy bisecting lifting in order to help. That's my 2 cents at least.

Obviously you're not interpreting this exchange how I am.
Let me share my perspective:

• You asked for help.
• I requested more info, which you did not provide.
• I continued trying to help despite the lack of info.
• Once it was apparent the problem was not with straight.el, I pointed you in the right direction to report the issue or get support elsewhere.
• Convinced of your convictions, you continued debugging inefficiently.
• I provided more context as to what the issue is as well as a list of pointers to avoid wasting your (and anybody else's) time.

What specifically did I do or say that was "mean"?