panic: runtime error: index out of range about goorgeous HOT 15 CLOSED

I forgot to point out that most hugo error messages were indeed referring to goorgeous

from goorgeous.

Can you share a snippet of a panic you get? If your html files are in your output folder those will get overwritten but it won't be overwritten if it's in your content folder.

from goorgeous.

Also, is your Hugo source a public repo? I'm happy to help debug it so we can help others port or work around it who did the same thing.

from goorgeous.

from goorgeous.

from goorgeous.

Are your .org files in your content directory? Since they're not truly being used by Hugo and you're already doing them by hand, if you put them in another directory that Hugo doesn't watch, it won't attempt to render your org files and overwrite your intermediate or your resulting HTML. An example:

org-content/
-- *.org # files
content/
-- *.html # emacs generated html files
public/
-- *.html # final html file

This way you can generate your org-content org files to content intermediate files and hugo will process them to the public directory (or whatever your public directory is called).

Anything that goes in the contents directory of a hugo project should be considered a file that is a src file.

from goorgeous.

from goorgeous.

from goorgeous.

Hey Larrabee,

So this one thread has had me reconsidering attempting to stay in parity with org mode and instead to work on using Emacs as an exec command. I've got a working branch that I think I can PR in the next few days here: https://github.com/chaseadamsio/hugo/tree/fix-useEmacsForOrg

This will allow you to use emacs as a part of Hugo rather than a go Org port, but it won't fix the issue you're having where your .org files are getting overwritten without a config change, so I can work on that.

Best case scenario here is that you find that the new Emacs implementation fits your needs and makes it better than the workflow you have now by automating the export dispatcher you're running and potentially removing some friction from those who are struggling with hugo + org in your group.

I'd like to help you figure out a good workflow so that if you decide not to use the Emacs route that I end up requesting (I'll cc you on the PR too so you can give any feedback or concerns you have and worst case scenario we remove emacs from master and I'll just maintain my own fork because I don't like doing anything manually).

Worst case scenario, with the workflow I'm suggesting, you should only need to move files once: from content to org-content and then update your html export path to export to content. Hugo will build your public from there, so you shouldn't need to do anything.

from goorgeous.

Also, if you let me know which release type you install from if you're not comfortable installing from source, I'd be happy to generate the relevant binary/executable and put it in the releases of my hugo fork so you can test it out before I PR.

from goorgeous.

Wow, looking at this thread via github shows me my mu4e emacs-based emailer is buggering up CR/LF. Oh well.

My reaction to using Emacs as an exec is fine, it it works. But that is a tricky integration that is bound to cause issues. I am a strong believer in keeping things as simple as possible. There is nothing easer than what I do now, "C-e C-b h h" in emacs and I am done. Not sexy, but very easy. I'd be very happy to test, though.

I'm not sure of this, but updating my html export to path might also be a pain? Don't I have to do that on a directory-by-directory basis (I'm on thin ground here, need to research).

This is all great, but wouldn't a simple config to tell hugo to not use your org converter solve everything? 99.9% of users would know about it, just the few (or only) user who has been using hugo with org for years. (FYI, my web site is a lot bigger than it appears, most is hidden.)

I usually just download the hugo binary. But, I have brew set up if that is usuable? I could try to install from source (Mac OS sierra with X-code, etc.). I'm slightly competent at UNIX like installs (./configure make, finding missing libs, etc.).

from goorgeous.

from goorgeous.

@strow I'll take a stab at it Friday (first PTO in a while) and cc you on the PR.

from goorgeous.

@strow sorry for the VERY long delay, but I've overhauled Goorgeous to lex > parse > transform and I think you'll find that you won't run into these out of range issues anymore. I'm going to leave this issue open and I'll add another comment once the update is merged into Hugo, maybe you can let me know if it's working for you as it should.

from goorgeous.

So it turned out that I had a branch I was getting ready to PR into Hugo this week that fixed this, but it looks like @niklasfasching PR'ed a new org parser, so I'm closing all the issues here, deprecating and archiving goorgeous.

from goorgeous.