Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong type argument: listp, nano-modeline--empty-face #59

Open
teesh3rt opened this issue Jun 13, 2023 · 15 comments
Open

Wrong type argument: listp, nano-modeline--empty-face #59

teesh3rt opened this issue Jun 13, 2023 · 15 comments

Comments

@teesh3rt
Copy link

I try to execute (nano-modeline-text-mode t), but it just shows this!:
Wrong type argument: listp, nano-modeline--empty-face
can anybody help me fix this?

@yakhni
Copy link

yakhni commented Jun 13, 2023

Facing the same issue...

@rougier
Copy link
Owner

rougier commented Jun 19, 2023

I just pushed a fix on ELPA that hopefully will solve the problem. Just wait a few minutes for ELPA to update and update the package.

@coldfish
Copy link

Version bump is not worked on my side :(

Why can't we call thenano-modeline-mode from the config any more ?

@rougier
Copy link
Owner

rougier commented Jun 19, 2023

How is it not working?

@coldfish
Copy link

Still getting the same error: (wrong-type-argument listp nano-modeline--empty-face)

Before upgrading the library, I was using this:

(use-package! nano-modeline
  :config
  (nano-modeline-mode))

@rougier
Copy link
Owner

rougier commented Jun 19, 2023

Could you try opening the nano-modeline.el file (from github) and evaluate the buffer?

@beneklins
Copy link

Using vanilla Emacs 28.2, emacs -Q, and evaluating nano-modeline.el @ a18780c, I get the error reported above. For completeness, the stack trace is

Debugger entered--Lisp error: (wrong-type-argument listp nano-modeline--empty-face)
  face-remap-set-base(header-line nano-modeline--empty-face)
  nano-modeline-header(((nano-modeline-buffer-status) " " (nano-modeline-buffer-name) " " (nano-modeline-git-info)) ((nano-modeline-cursor-position) (nano-modeline-window-dedicated)) nil)
  funcall(nano-modeline-header ((nano-modeline-buffer-status) " " (nano-modeline-buffer-name) " " (nano-modeline-git-info)) ((nano-modeline-cursor-position) (nano-modeline-window-dedicated)) nil)
  nano-modeline-prog-mode()
  run-hooks(change-major-mode-after-body-hook prog-mode-hook)
  apply(run-hooks (change-major-mode-after-body-hook prog-mode-hook))
  run-mode-hooks(prog-mode-hook)
  prog-mode()
  funcall-interactively(prog-mode)
  call-interactively(prog-mode record nil)
  command-execute(prog-mode record)
  execute-extended-command(nil "prog-mode" nil)
  funcall-interactively(execute-extended-command nil "prog-mode" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

@aaronjensen
Copy link
Contributor

emacs-mirror/emacs@7b0b279

This is fixed in later (unreleased) versions of Emacs.

I don't know if there is or what the workaround would be

@rougier
Copy link
Owner

rougier commented Jul 17, 2023

Sorry for late answer. @aaronjensen You mean the problem comes from Emacs itself?

@aaronjensen
Copy link
Contributor

Correct. They broke it somewhat recently and have fixed it, but last I checked the fix was not released.

@rougier
Copy link
Owner

rougier commented Jul 19, 2023

Better is to wait I guess. Or anyone sees a workaround?

@aaronjensen
Copy link
Contributor

The only work around I can think of would be to do pass an extra nil:

(face-remap-set-base 'header-line 'nano-modeline--empty-face nil)

This probably doesn't have much impact (I believe the nil is treated as an empty property list), it's just a hack.

@aaronjensen
Copy link
Contributor

aaronjensen commented Jul 19, 2023

Oh, and of course it's an option to provide a version of face-remap-set-base in nano and use that:

(defun nano-modeline-face-remap-set-base (face &rest specs)
  "Set the base remapping of FACE in the current buffer to SPECS.
This causes the remappings specified by `face-remap-add-relative'
to apply on top of the face specification given by SPECS.

The remaining arguments, SPECS, specify the base of the remapping.
Each one of SPECS should be either a face name or a property list
of face attribute/value pairs, like in a `face' text property.

If SPECS is empty or a single face `eq' to FACE, call `face-remap-reset-base'
to use the normal definition of FACE as the base remapping; note that
this is different from SPECS containing a single value nil, which means
not to inherit from the global definition of FACE at all."
  ;; Simplify the specs in the case where it's just a single face (and
  ;; it's not a list with just a nil).
  (while (and (consp specs) (not (null (car specs))) (null (cdr specs)))
    (setq specs (car specs)))
  (if (or (null specs)
    (eq specs face)) ; default
      ;; Set entry back to default
      (face-remap-reset-base face)
    ;; Set the base remapping
    (make-local-variable 'face-remapping-alist)
    (let ((entry (assq face face-remapping-alist)))
      (if entry
    (setcar (last entry) specs) ; overwrite existing base entry
  (push (list face specs) face-remapping-alist)))
    ;; Force redisplay of this buffer.
    (force-mode-line-update)))

Finally, per #58 , this particular technique doesn't work in all cases, so it may be worth finding a way to do the faces that doesn't require a remap.

@rougier
Copy link
Owner

rougier commented Aug 24, 2023

Back to work. What would be the limitations of the code above exactly?

@aaronjensen
Copy link
Contributor

Now that Emacs 29.1 is released this may be moot unless you want to support Emacs 28.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants