M-x emacs-thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > M-x emacs-thread

tak: Jan 31, 2003; lol demowned; Grimey Drawer

Just made a new helm-testing branch for my .emacs.d git repo, I'm pretty used to ido-ubiquitous-mode and ido-everywhere-mode though. I did some reading and it seems that the recommended way of doing both ido and helm is to globally enable helm and add ido wherever you prefer it. Anyone use both? Is it worth sticking with ido in general?

# ¿ Nov 7, 2014 04:44

Adbot: ADBOT LOVES YOU

# ¿ May 11, 2024 14:05

tak: Jan 31, 2003; lol demowned; Grimey Drawer

Try toggle-debug-on-error before you try the export to start the debugger when the error occurs.

The last few lines of the trace show what happened:

code:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("[012]?[0-9]:[0-5][0-9]\\(-\\([012]?[0-9]\\):\\([0-5][0-9]\\)\\)" nil)
  org-element-timestamp-parser()
  org-element-clock-parser(169440)

The top line means that the error encountered was (wrong-type-argument stringp nil) -- in other words, it expected a stringp but encountered a nil value. The source of that error was in string-match, which tried to match the regexp listed with a nil value. The nil value came from org-element-timestamp-parser(), which was called from org-element-clock-parser(169440).

If you M-x describe-function RET org-element-clock-parser, click the link to view the source of the org-element.el file where that function is defined, you can C-s and look for where the function is called. In my version of emacs it's called from line 1569 of org-element.el.

In the source of org-element-timestamp-parser (line 3563 for me), string-match with that regexp is called, and the nil value seems to be from date-start. The variable date-start was set earlier in that defun by the let* expression, in the line (date-start (match-string-no-properties 1)).

match-string-no-properties (NUM) docstring:

quote:

string of text matched by last search, without text properties. NUM specifies which parenthesized expression in the last regexp. Value is nil if NUMth pair didn't match, or there were less than NUM pairs.

So in other words, the previous regexp failed to match anything within the first pair of parentheses in the regexp, which date-start was supposed to be set to.

The difficulty is that org-element-clock-parser and org-element-timestamp-parser act on text at point, so it's difficult to debug without actively debugging it as it's running. Your best bet is to start the debugger and see if you can figure out where in your source file it's having trouble.

Hopefully that helps, I'm still fairly new to elisp so I've been trying to look through the source whenever I can.

# ¿ Nov 26, 2014 04:05

tak: Jan 31, 2003; lol demowned; Grimey Drawer

pgroce posted:

I've had shenanigans ensue when I upgrade org-mode (as a package, not the built-in version) because it byte-compiles files in a copy of Emacs where the old versions of the symbols are already loaded. This doesn't sound like the case for you, but it's worth being aware of. You should also remove any other copies that might be in the load path -- e.g., in .emacs.d/elpa, or wherever ELPA puts packages on Windows.

C-u 0 M-x byte-recompile-directory RET <path-to-elpa-dir> RET, It'll often help with odd issues like that. The C-u 0 parameter forces it to bytecompile .el files even if it doesn't already have a .elc.

pgroce posted:

Org is the reason I now only upgrade ELPA packages from a clean version of Emacs with almost nothing loaded.

Probably a good idea regardless, although I can't recall having problems like yours that weren't solved by recompiling everything.

tak fucked around with this message at 09:53 on Nov 30, 2014

# ¿ Nov 30, 2014 09:49

tak: Jan 31, 2003; lol demowned; Grimey Drawer

The current stable branch is 24.4.50 and unstable is 24.5.50, could it be that the documentation is for a newer version? (not sure, I'm not familiar with homebrew)

# ¿ Jan 8, 2015 00:06

tak: Jan 31, 2003; lol demowned; Grimey Drawer

Does anyone do any sort of calendar/org agenda/contacts/etc. syncing with Google accounts? Does it work well? I've been seeing mixed reports, but can't really find much recent info.

The org-caldav package apparently won't work with Google accounts much longer, since Google will soon deprecate the API they'd been using in favour of OAuth2, which apparently requires the developer to register the library with Google and give them a cell phone number or something.

# ¿ Jan 16, 2015 21:17

tak: Jan 31, 2003; lol demowned; Grimey Drawer

probably C:\Windows\system32\drivers\etc\hosts

# ¿ Jan 20, 2015 07:01

tak: Jan 31, 2003; lol demowned; Grimey Drawer

Ahh, right. Well, I'm not sure what else you could try, I don't have much experience with using plink with tramp-mode. Is using openssh for tramp-mode an option (via cygwin)? That might be easier in the end.

You should be able to put ssh.exe and cygwin1.dll in the emacs bin directory to get that to work without messing with the rest of your environment.

# ¿ Jan 20, 2015 21:36

tak: Jan 31, 2003; lol demowned; Grimey Drawer

There's no reason not to use magit for git in emacs, IMO. Take an hour or two to read through the documentation or a tutorial or two, you won't regret it. It's very nice for constructing commits hunk-by-hunk, and it gives some handy info when making commit messages that summarize the staged changes about to be committed.

edit:

Notorious b.s.d. posted:

Sadly, I don't have a minor mode to provide perl reflection.

I've been using Devel::PerlySense lately and it's (fairly) good. It doesn't really act like a standard well-behaved minor mode though -- you have to bind its prefix key globally, due to the way it sets up the keymap. Other than that it's pretty nice.

It's the only Perl emacs development environment that seems to be maintained or even working in emacs 24. It's not quite as nice as CEDET/Semantic, but it's better than nothing and does have several things that save a lot of time.

This config seems to be working OK for me (adapted from the Devel::PerlySense docs):

code:

(setq-default
 ps/key-prefix (kbd "C-o")
 ps/load-flymake nil
 ps/external-dir (shell-command-to-string "perly_sense external_dir")
 ps/enable-test-coverage-visualization nil
 ps/use-prepare-shell-command t)

(global-unset-key (kbd "C-o"))
(global-set-key (kbd "C-o C-g") nil)
(global-set-key (kbd "C-o M-g") 'ps/smart-go-to-at-point)

;; add PerlySense external emacs dir to load-path
(if (string-match "Devel.PerlySense.external" ps/external-dir)
    (progn
      (let ((ps-external-emacs-dir (expand-file-name "emacs" ps/external-dir)))
        (message "Adding PerlySense elisp directory `%s' to load-path..."
                 ps-external-emacs-dir)
        (add-to-list 'load-path ps-external-emacs-dir t)))
  (message "Could not identify PerlySense install dir. Is
           Devel::PerlySense installed properly? (`perly_sense
           external_dir' output: %s)" ps/external-dir))

(add-hook 'cperl-mode-hook
          (unless (boundp 'ps/perl-module-at-point)
            (load "perly-sense")))

tak fucked around with this message at 20:58 on Feb 22, 2015

# ¿ Feb 22, 2015 18:50

tak: Jan 31, 2003; lol demowned; Grimey Drawer

Avenging Dentist posted:

Wait. How do you close your server by accident? I've literally never had this issue (on Windows anyway). I guess we must have different configs.

Here's what I do: http://www.emacswiki.org/emacs/EmacsClient#toc16 (plus server-start in my .emacs, of course). Apparently I run the following command when double-clicking a text file in the Explorer to open it in emacs:

On emacs version<25.1 on Windows, if you close all emacs frames the server process is killed. The addition to 25.1 is that closing all frames still leaves an `emacs.exe --daemon' process open in the background, so you can just reattach to it by running emacsclient.

The --alternate-editor/-a option to emacsclient specifies a command to run if no server process is running, so killing the server doesn't prevent you from using emacsclient.exe but it does require rerunning all your init code and losing open buffers etc. if you do so.

# ¿ Mar 3, 2015 18:36

tak: Jan 31, 2003; lol demowned; Grimey Drawer

PlesantDilemma posted:

Why is it that when I scroll around in a buffer, the cursor will stay in the visible area? I'm used to modern GUI editors where the cursor stays fixed while I scroll through a file. Is there a flag or mode to get the behavior I'm used to?

Try scroll-restore.

The point will still around as you scroll -- there's no way to change that AFAIK, it's just how emacs works -- but it will move back to its original position when you scroll back.

# ¿ Apr 25, 2015 19:18

Adbot: ADBOT LOVES YOU

# ¿ May 11, 2024 14:05

tak: Jan 31, 2003; lol demowned; Grimey Drawer

It wouldn't work even if load-theme wasn't interactive. You can't bind non-interactive functions (you can only call them from other interactive functions), and global-set-key expects the binding arg to be "a keymap, a command, a keyboard macro, a symbol that leads to one of them, or nil."

That lambda would do just fine, as would the symbol of an equivalent interactive named function. I prefer the latter to avoid cluttering up e.g.helm-descbinds or which-key:

code:

(defun load-tao-yang-theme ()
  (interactive)
  (load-theme 'tao-yang))
(global-set-key (kbd "C-c a") 'load-tao-yang-theme)

# ¿ Feb 23, 2017 06:07

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > M-x emacs-thread