Document setting of outline-minor-mode-prefix with customize-variable #11
Comments
|
Hi, Please enable debugging by running Thanks. |
|
Debugger entered--Lisp error: (wrong-type-argument keymapp nil) |
|
Hi, Thank you for your quick reply and sorry for being very unknowledgeable when it comes to debugging mode. My previous comment is the content of the backtrace after starting emacs with --debug-init |
|
Sorry, I can't do anything with that backtrace full of byte-code. Try this:
If that doesn't produce the error either, it's probably an issue with your config rather than Outshine itself. |
|
Yes. I was puzzled with all this byte-code too. Not sure where it's coming from. Thanks for the advice. Will try that. |
|
Just did and am getting the exact same backtrace (with all the crazy byte-code) :( |
|
Try this:
|
|
I am not sure what you mean by "eval the package-initialize form". I evaluated the expression: (package-initialize), which returned nil. If this is what you meant, then after evaluating (require 'org) and (require 'outshine), I get no backtrace buffer. So that would mean that the problem is on my end, somewhere (though I don't know where and I don't understand where all the byte-code is coming from). If you meant something else by "eval the package-initialize form", I apologise for my ignorance and need more details. In any case, thank you for the help. I recently moved from running emacs in Cygwin to running emacs in Arch Linux. Maybe something went wrong in the encoding somewhere? But I could use outshine without any issue after the switch, until the new org release (or until the day of the release, if there is no connection). And I have no issue with any other package. And there is nothing in my init file that looks suspicious. My machine is set on utf8-unix. Anyway, I now suspect the problem is in my settings somewhere. But everything else is running without any problem and outshine was running just fine too on my new Arch setup, so I am very confused. |
What I mean is, evaluate the forms that set up the package system, e.g. on mine they look like this: (require 'package)
(setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/")
("melpa" . "https://melpa.org/packages/")))
(package-initialize)
This is important information. I'm guessing you don't have a package installed that installs the Emacs Lisp source files, so all the backtrace has to go on for some code is the byte-compiled files. I don't know what the package is called on Arch; on Debian/Ubuntu it's, e.g.
Were you able to actually use Outshine after that? If so, then yes, I think the problem is in your config, and to fix that you should strip out all of your Outshine-related config and add it back piece-by-piece until you find what breaks it. (You could also try using the |
Oh, I see. Thank you for the additional info.
I did some research, but I haven't been able to find anything on Arch Linux that looks like an equivalent. My backtrace buffer always gets full of byte-codes, whatever the message, so there is clearly something going on there that I will have to work on and keep trying to figure out... at least you pointed me in a starting direction, so thank you.
If I remove all the outshine related lines of my init file, start emacs, then eval In any case, thanks a lot for your time. I really appreciate. I still have my outshine issue (and have now realised that I also have an issue with my backtrace buffer), but I learnt something and it is a starting point to more exploring. Sorry also for questioning the package when the problem was on my end. |
I'm guessing that it's something in your Org config then, or perhaps something related to outline-minor-mode. If you can get the backtraces working without the byte-code, it should be possible to track it down. For the backtrace/byte-code issue, I think if you post on emacs.stackexchange.com or on reddit.com/r/emacs someone will be able to help.
Not at all. :) These are very complex systems with many moving parts, and it's always possible that an update in one has broken something in another. I'm really just the caretaker of this package; I can track down problems and fix them if something breaks, but I don't have a good grasp of how it all fits together, because I haven't worked with it very long. Let me know if you figure out the problem. It might need to be documented somewhere. :) |
|
I got it. I didn't use The problem was the variable Your help was key in figuring this out, so thank you once more. Now, I will try to tackle the backtrace encoding issue. |
|
From https://emacs.stackexchange.com/questions/33748/elisp-backtrace-print-garbage-messages, it seems that it might be a widespread problem? You might be in luck that Debian has a package to go around this nicely. From the same link: "If you reevaluate the definition of a Lisp function and don't byte-compile it, you won't see its bytecode in the backtrace". And I will dig into https://debbugs.gnu.org/cgi/bugreport.cgi?bug=6991 and try to find something that works for me. I will also keep looking for an equivalent to your Debian package to install the Emacs Lisp source files on Arch Linux. |
|
Or maybe I will explore Thanks again! |
That makes sense, since it showed up in the backtrace. I wouldn't think that Org would change that, but I guess you could grep the Org source code if you're interested. There are also some comments about For Arch, according to the list of files at https://www.archlinux.org/packages/extra/x86_64/emacs/ (expand the list at the bottom), the source files are included in the package (the I don't think Slime is relevant here; that's for using Common Lisp in Emacs. Good job digging through all this and figuring it out! :) I'm going to leave this open for now. There might be an issue with the outline-minor-mode-prefix that we need to look into for newer Emacs or Org versions. |
alphapapa
changed the title
Oh, indeed... *blush* |
|
@prosoitos Does the issue still appear? |
|
Sorry for my slow reply! I never tried remapping |
|
I also came across the same issue on Spacemacs. It was indeed being caused due to |
|
I also came across this. I found that something was triggering the autoload of |
Thanks. What version of Emacs and of Org did that happen on? |
alphapapa
changed the title
|
emacs 26.3 and Org |
|
BTW I also found that debugging when the autoload happened was tricky because |
After 2 years of using outshine all the time without issue (and I love it! thanks for maintaining it!!), I suddenly started to get:
"Wrong type argument: keymapp, nil"
on startup since the new org mode release (Org 9.1.6, Jan 2018). There may not be any connection, but it started just after the org update.
Removing any outshine entry from my init file allows to start emacs without issue. I am not sure how to get started understanding what is going on... I could downgrade to the previous org release to go around the issue, but I'd prefer to keep up to date with org though. Thanks for suggestions.
Note: I am using emacs 25.3-2 on Arch Linux with all packages up to date. And here is the outshine section of my init file (which I haven't changed in ages and worked just fine till now):
;; ** outshine project
;; *** outorg
(require 'outorg)
;; *** outshine
(require 'outshine)
;; **** Set outline minor mode automatically in some major modes
(add-hook 'emacs-lisp-mode-hook 'outline-minor-mode)
(add-hook 'ess-mode-hook 'outline-minor-mode)
(add-hook 'LaTex-mode-hook 'outline-minor-mode)
(add-hook 'sh-mode-hook 'outline-minor-mode)
;; **** use outshine functions in outline minor mode
(add-hook 'outline-minor-mode-hook 'outshine-hook-function)
;; **** outshine speed commands
(setq outshine-use-speed-commands t)
Plus a bunch of keybindings remapping (but removing those had no effect on the issue, so they should not be causing any problem).
The text was updated successfully, but these errors were encountered: