Straight.el: Having trouble using my custom telephone-line mods with straight.el - help? :)

[MikeTheGreat]

First - I'm just starting to use straight.el and it looks awesome. Thank you very much for making this & sharing it!

My issue, tl;dr:
I'm not sure how to debug a problem and would love advice/help. I'm asking here because if I use straight.el the problem occurs, but if I re-evaluate the problematic macro definition _after_ loading straight.el then the problem does not occur, nor did it occur when I used package.el

My issue, in detail:
I've been using telephone-line and enjoying it. When I installed it using package.el I can get everything to work fine, including some custom code I wrote to define a new chunk of my mode line:

  (telephone-line-defsegment my-buffer-name-segment
    (telephone-line-raw mode-line-buffer-identification t)
    )

After switching to straight.el I get the following error when I try to evaluate the above form

error "Malformed arglist: (lambda (face) mode-line-buffer-identification)")
  signal(error ("Malformed arglist: (lambda (face) mode-line-buffer-identification)"))
  error("Malformed arglist: %s" (lambda (face) mode-line-buffer-identification))
  #f(compiled-function (name arglist &optional docstring decl &rest body) "Define NAME as a function.\nThe definition is (lambda ARGLIST [DOCSTRING] BODY...).\nSee also the function `interactive'.\nDECL is a declaration, optional, of the form (declare DECLS...) where\nDECLS is a list of elements of the form (PROP . VALUES).  These are\ninterpreted according to `defun-declarations-alist'.\nThe return value is undefined." #<bytecode 0x100082173>)(my-buffer-name-segment (lambda (face) mode-line-buffer-identification))
  macroexpand((telephone-line-defsegment* my-buffer-name-segment mode-line-buffer-identification) nil)
  macroexp-macroexpand((telephone-line-defsegment* my-buffer-name-segment mode-line-buffer-identification) nil)
  macroexp--expand-all((telephone-line-defsegment* my-buffer-name-segment mode-line-buffer-identification))
  macroexpand-all((telephone-line-defsegment* my-buffer-name-segment mode-line-buffer-identification))
  eval-sexp-add-defvars((telephone-line-defsegment* my-buffer-name-segment mode-line-buffer-identification))
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

Turns out telephone-line-defsegment is actually a macro.

What's weird is that if I re-evaluate the telephone-line-defsegment macro definition manually I can then go back and evaluate the my-buffer-name-segment just fine.

Because of this, I'm wondering if straight.el does anything that might impact macro definitions in the packages it loads?
Also, while I don't expect or want anyone to do this for me, would anyone have any pointers on how to go about debugging a problem like this? Any help / advice / etc would be greatly appreciated! :)

[raxod502]

I get that error with your code regardless of whether I'm using package.el or straight.el. Did you forget to update the package.el version?

[MikeTheGreat]

First, thanks for the response!

I think I've got it figured out and it's definitely an issue on my end (as I expected)

straight.el is using a newer version, and that newer version's telephone-line-defsegment macro now needs a parameter list. So instead of the older format that the package.el version expects:

  (telephone-line-defsegment my-buffer-name-segment

it now needs to be

  (telephone-line-defsegment my-buffer-name-segment ()

Part of my confusion came from using find-library. I expected it to bring me to the file that's currently in use, but that appeared to bring me to the version that was stored in my ~/.emacs.d/elpa copy of telephone-line, even though I was actually using the one in ~/.emacs.d/straight/build

Is it a 'best practice' to remove any packages that were installed via package.el?

(Thanks for closing this issue!)

[MikeTheGreat]

Er, just to clarify - I read quite clearly in your README file that straight.el & package.el don't play well together. As someone who's new-ish to emacs I assumed that removing all the package.el related stuff (such as (package-initialize)) would 'turn off' package.el while still leaving all of it's packages on disk, untouched.

The overall goal was to try out straight.el, and if it didn't work for me to then go back to package.el.

[raxod502]

By default, Emacs runs package-initialize at the end of your init-file, unless you already ran it yourself, which loads all packages currently installed by package.el. This behavior is clearly undesirable if you are not using package.el, and you can suppress it by setting the variable package-enable-at-startup to nil. However, straight.el does this automatically as soon as you run the bootstrap snippet, so it's unclear to me how your package.el packages are getting activated. I am not sure what sequence of events could cause the behavior that you describe, although I certainly have experienced M-x find-library being misleading when there are duplicate entries on the load-path.

(Are you perhaps building Emacs 27 yourself? That would explain everything, and I can elaborate on why if that's the case.)

In conclusion, you _shouldn't_ need to remove package.el packages from disk in order for straight.el to operate correctly, but apparently something went wrong in your case.