1

I'm sorry to have to ask this, but lisp debugging is not one of my strengths. For some time I've been happily using Joe Bloggs's somewhat hoary but useful org-dotemacs.el system to maintain my emacs init settings across several computers. The computers are using Fedora 28.

A standard Fedora update on June 10 broke that. I suspect the offending elements were:

Upgraded emacs-1:25.3-5.fc28.x86_64                         @fedora
Upgrade        1:26.1-1.fc28.x86_64                         @updates
Upgraded emacs-common-1:25.3-5.fc28.x86_64                  @fedora
Upgrade               1:26.1-1.fc28.x86_64                  @updates
Upgraded emacs-filesystem-1:25.3-5.fc28.noarch              @fedora
Upgrade                   1:26.1-1.fc28.noarch              @updates

The emacs init-debug returns this:

    Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  looking-at(nil)
    org-heading-components()
    org-in-commented-heading-p()
    org-babel-tangle-collect-blocks(emacs-lisp)
    org-dotemacs-load-blocks(nil skip)
    org-dotemacs-load-file(nil "~/.dotemacs.org" nil)
    org-dotemacs-load-default()
    eval-buffer(#<buffer  *load*> nil "/home/michael/.emacs" nil t)  ; 
    Reading at buffer position 525
    load-with-code-conversion("/home/michael/.emacs" 
     "/home/michael/.emacs" t t)
     load("~/.emacs" t t)
     #f(compiled-function () #<bytecode 0x261c1d>)()
     command-line()
     normal-top-level()

Just naively, it looks like the problem is with the use of looking-at in the definition of org-heading-components in the file org.el. (This is org-mode version 9.1.13.)

So, back to the question: has anyone else had this problem, and does anyone have a suggestion as to how to fix it?

Improve this question

2 Answers 2

Reset to default
2

https://github.com/vapniks/org-dotemacs/pull/13/commits/836b1c4bea4e62a4d5646d0ba790e4fa5e88101e

This fixed it for me. Org-mode must explicitely be set in org-dotemacs.el.

Improve this answer
3
  • That did it! Thank you very much. It would have taken me months or years to get to that. I hope it can be committed to the master branch, if I'm using the right verb.
    – maab
    Commented Jun 23, 2018 at 11:21
  • Since this answer seems to have fixed your problem, you should accept it.
    – NickD
    Commented Sep 20, 2018 at 0:26
  • BTW, I was right in the diagnosis that org-mode is not set :-)
    – NickD
    Commented Sep 20, 2018 at 0:28
1

The problem is that the argument of the looking-at is the variable org-complex-heading-regexp which starts out nil and is then set locally in a buffer when the buffer's major mode becomes org-mode. It seems that in your case, the latter does not happen and the variable remains nil. I presume that there is a buffer for the default ~/.dotemacs.org after the failed initialization. If you switch to that buffer, does the status line indicate that the major mode is Org? If not, then that's the explanation. If yes, ah well, I tried...

If the mode is the problem, you might add

(add-to-list 'auto-mode-alist '("\\.org$" . org-mode))

to your ~/.emacs before org-dotemacs-load-default is called.

Improve this answer
3
  • Sadly, Nick, that doesn't work. Though it was a clever thought. The dotemacs.org buffer is using org mode by the time I see it, and adding the auto-mode item anyway (programming-by-sympathetic-magic on my part) doesn't work either. Sigh. BUT why looking-at is getting a nil argument is a good question.
    – maab
    Commented Jun 16, 2018 at 12:50
  • Yes, it was a shot in the dark. The only other explanation that I can think of is that the evaluation is taking place in some buffer other than the .dotemacs.org buffer with a different major mode. But I really cannot see how that would happen. If you know how to use edebug, that's where I would turn to next.
    – NickD
    Commented Jun 16, 2018 at 13:34
  • Well, so here's the fing. Looking at the buffer list, it seems .dotemacs.org gets loaded /twice/. I do not understand that. The first copy is loaded in an org mode buffer, but .dotemacs.org<2> is in a fundamental mode buffer, which gets back to your orig. theory. Twice? Is that just a side-effect of the error handling system that reloads the file where the error occurred? Or something more sinister?
    – maab
    Commented Jun 16, 2018 at 22:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.