Closed WillPower3309 closed 2 years ago
Noticed that the modeline has checks for different buffer types, maybe a default value of not being displayed would work
Thanks for the report. You proposed fix might work actually. If treemacs has its own mode (I guess so), it's a matter of adding it to the nano-modeline list. But it shoudl use the default header line that seems to be wrong for some reason. Do you have any idea what could be wrong? Or, another way to debug would be to simplify the default modeline and check when it breaks.
Commenting out line 518:
(setq-default mode-line-format "")
Fixes the issue
Unsure as to why that is, as my emacs knowledge isn't too advanced, but I hope that helps
Oh, this is the mode line, not the header line actually. Even if we add a special case for treemacs-mode in nano-modeline, tit won't change the mode-line. Myabe you can try to comment the code at the bottom of nano-modeline that modify the mode-lien depending on surrounding windows.
I have the same issue and the same fix (;;(setq-default mode-line-format "")
) works for me with no noticeable side effects so far.
I pushed a change to remove a hook on the modeline that may fox the problem.
I pushed a change to remove a hook on the modeline that may fox the problem.
I'll check it out later today and confirm if it works!
Unfortunately the problem still remains
Can you call toggle-debug-on-error
and post the trace?
Debugger entered--Lisp error: (wrong-type-argument listp "")
treemacs--setup-mode-line()
#f(compiled-function () (interactive nil) #<bytecode -0xecf711466bfb1ae>)()
apply(#f(compiled-function () (interactive nil) #<bytecode -0xecf711466bfb1ae>) nil)
treemacs--mode-check-advice(#f(compiled-function () (interactive nil) #<bytecode -0xecf711466bfb1ae>))
apply(treemacs--mode-check-advice #f(compiled-function () (interactive nil) #<bytecode -0xecf711466bfb1ae>) nil)
treemacs-mode()
treemacs--init()
treemacs()
funcall-interactively(treemacs)
call-interactively(treemacs nil nil)
command-execute(treemacs)
Sorry for late answer. Can you check with the nano-modeline on ELPA?
I actually have issues with the nano-modeline from ELPA. Running M-x nano-modeline-mode
results in:
Wrong number of arguments: (3 . 4), 2
I assume I may be calling it incorrectly?
Can verify I have the most recent version 0.5 as well from M-x package-list-packages
nano-modeline 0.5 external N Λ N O modeline
Here's the log:
Debugger entered--Lisp error: (wrong-number-of-arguments (3 . 4) 2)
make-obsolete-variable(nil "Add to `nano-modeline-mode-formats' instead")
byte-code("\302\303\304\305\306\307%\210\302\310\304\311\306\303%\210\302\312\304\313\306\310%\210\302\314\304\315\306\310%\210\316\317\320\321\322DD\323\324\325\306\310&\7\210\316\326\320..." [nano-modeline-user-mode nano-modeline-user-mode-p custom-declare-group nano nil "N Λ N O" :group convenience nano-modeline "N Λ N O Modeline" nano-modeline-active "Active modeline faces.\n\nModeline is composed as:\n[..." nano-modeline-inactive "Inactive modeline faces\n\nModeline is composed as:\n..." custom-declare-variable nano-modeline-position funcall function #f(compiled-function () #<bytecode 0x1c800010b5a14>) "Default position (top or bottom)" :type (choice (const :tag "Top" top) (const :tag "Bottom" bottom)) nano-modeline-space-top #f(compiled-function () #<bytecode 0x1d81c800016ff49f>) "Space adjustment for top of modeline\nPossitive is ..." float nano-modeline-space-bottom #f(compiled-function () #<bytecode -0xcfe37fffe9016d3>) "Space adjustment for bottom of modeline\nNegative i..." custom-declare-face ((t (:inherit mode-line))) "Modeline face for active modeline" nano-modeline-active-name ((t (:inherit (mode-line bold)))) "Modeline face for active name element" nano-modeline-active-primary ((t (:inherit mode-line))) "Modeline face for active primary element" nano-modeline-active-secondary ((t (:inherit mode-line))) "Modeline face for active secondary element" nano-modeline-active-status-RO ((t (:inherit mode-line))) "Modeline face for active READ-ONLY element" nano-modeline-active-status-RW ((t (:inherit mode-line))) "Modeline face for active READ-WRITE element" nano-modeline-active-status-** ((t (:inherit mode-line))) "Modeline face for active MODIFIED element" ...] 10)
autoload-do-load((autoload "nano-modeline" "Toggle nano-modeline minor mode\n\nThis is a minor m..." t nil) nano-modeline-mode)
command-execute(nano-modeline-mode record)
execute-extended-command(nil "nano-modeline-mode" "nano-mod")
funcall-interactively(execute-extended-command nil "nano-modeline-mode" "nano-mod")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
Apologies for bringing it up here and not in the modeline repo but it's a blocker for me testing this issue on the Elpa version
Sorry for late answer. What is nano-mod
, is that one of your function? Alos, one way to test would be to open the nano-modeline.el file in an "Emacs -Q" session and to evaluate the buffer. This might avoid any interference with other packahges and could help to isolate the problem.
Very sorry for the late update, the recent Elpa version now seems to be working
When attempting to run
treemacs
with an emacs config that includes nano-modeline,Wrong type argument: listp, ""
results