panic: runtime error: index out of range

[strow]

There are probably many good reasons for this error. But I wanted to introduce my use of hugo and ormode so I can understand how to port to goorgeous. I have been using hugo for 2 years with only org-mode source files. How? I just create the .html directly (yes, by hand) in emacs from the .org source file using the orgmode html exporter. It works very well, but, it is a pain in that orgmode has a different concept of "/" than hugo for the underlying filesystem. That forced me to often use absolute rather than relative links for images, etc. My guess is that most of my issues with this error is my use of embedded HTML exports in some org files, I can' imagine goorgeous will parse them. So, I am not really asking for specific help.

What I am wondering, I assume Hugo will now see an .org file and create .html. If the .html already exists (from me exporting it directly from emacs using the orgmode exporter), will hugo overwrite that file? I'm sure I can experiment with that.

I am excited to try goorgeous, and I hope it solves problems I have using ormode with Hugo, but it does make it impossible for me to use V0.19! My punishment for not doing things the "hugo" way.

[strow]

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

[curiouslychase]

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.

[curiouslychase]

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.

[strow]

Sure,

Below is a snippet.

But, I should emphasize that my .org files have a number of org-mode HTML exports, which I wouldn't expect your code to handle.

I'll try a clean setup with no html exports soon, just to be sure plain vanilla org works for me.

Thanks.

cress> hugo Started building sites ... panic: runtime error: index out of range

goroutine 118 [running]: github.com/spf13/hugo/vendor/github.com/chaseadamsio/goorgeous.OrgHeaders(0xc4201ee870, 0x31, 0x40, 0xc4204da880, 0xc4203ac978, 0xc4203ac970) /Users/bep/go/src/github.com/spf13/hugo/vendor/github.com/chaseadamsio/goorgeous/header.go:44 +0x6f8 github.com/spf13/hugo/parser.HandleOrgMetaData(0xc4201ee870, 0x31, 0x40, 0xc4202e9ce0, 0x1011fbd, 0xc4205f71f0, 0x1752287) /Users/bep/go/src/github.com/spf13/hugo/parser/frontmatter.go:197 +0x3f github.com/spf13/hugo/parser.(page).Metadata(0xc4204da840, 0x1752287, 0x1007, 0x1e00, 0x0) /Users/bep/go/src/github.com/spf13/hugo/parser/page.go:97 +0xbd github.com/spf13/hugo/hugolib.(Page).parse(0xc4205f6d80, 0x1a89560, 0xc4204f3470, 0xc420110a00, 0xc4204f4da1) /Users/bep/go/src/github.com/spf13/hugo/hugolib/page.go:1393 +0x189 github.com/spf13/hugo/hugolib.(Page).ReadFrom(0xc4205f6d80, 0x1a89560, 0xc4204f3470, 0xc4205f6d80, 0x0, 0x0) /Users/bep/go/src/github.com/spf13/hugo/hugolib/page.go:737 +0x43 github.com/spf13/hugo/hugolib.basicPageHandler.Read(0x0, 0x0, 0x0, 0xc4204f8280, 0xc420110a00, 0xc4201e8300, 0xc4204f4dbd, 0x3, 0x1006c01) /Users/bep/go/src/github.com/spf13/hugo/hugolib/handler_page.go:41 +0x8c github.com/spf13/hugo/hugolib.(orgHandler).Read(0xc4201e8300, 0xc4204f8280, 0xc420110a00, 0xc4202e9ed8, 0x158bc2f, 0xc4204f4dbd, 0x3)

:307 +0x6e github.com/spf13/hugo/hugolib.(*MetaHandle).Read(0xc4205d4a00, 0xc4204f8280, 0xc420110a00, 0xc4203b3740) /Users/bep/go/src/github.com/spf13/hugo/hugolib/handler_meta.go:51 +0x133 github.com/spf13/hugo/hugolib.readSourceFile(0xc420110a00, 0xc4204f8280, 0xc4203b3740) /Users/bep/go/src/github.com/spf13/hugo/hugolib/site.go:1239 +0x70 github.com/spf13/hugo/hugolib.sourceReader(0xc420110a00, 0xc4203b37a0, 0xc4203b3740, 0xc4203aca70) /Users/bep/go/src/github.com/spf13/hugo/hugolib/site.go:1232 +0xa8 created by github.com/spf13/hugo/hugolib.(*Site).readPagesFromSource /Users/bep/go/src/github.com/spf13/hugo/hugolib/site.go:1157 +0x24e cress> Chase Adams writes: > 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. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or mute the > thread. -- L. Larrabee Strow UMBC Physics Department Email: strow@umbc.edu Cell: 724-288-6933

[strow]

Hi,

I've done some further tests. I can get your org conversion to "complete" for some simpler files, but there are many many problems. I really do appreciate the attempt, but I really hope hugo can be modified to not wipe out my web site creation methodology.

I suspect you had to just implement the standard org syntax. Many details are not working:

1. macros, like below

   +LINK: hpub https://asl.umbc.edu/pub/strow/figs/

2. This next one is a killer. My source code has CR/LF's which you "respect", while standard orgmode exporter only responds to blank lines to create a paragraph. This is a killer!

3. Images: [[url for image]] should in-line the image. You provide just the link to the image.

4. You don't provide functionality to org keywords, like

   +TOC: headlines 2

etc. etc.

I realize doing what I want would force you to reproduce the complete org exporter, I gigantic job.

The org html exporter is very very good, and it's latex exporter is even better. The files served up by my website can be translated to latex with no change (although I cheat a lot, using directives telling org to do one thing for html export, another for latex export, mostly for figures). But, having a single source is really important.

I'd be happy to just ignore this new hugo functionality, but it makes it impossible for me to create my web site as I have done in the past. Let me explain:

Present Methodlogy:

Create legal .org files that produce good html and .tex (and from that .pdf). Then, and this is key, I export (sitting in content/) the .org to html. (I put yaml inbetween begin_export html, end_export). hugo then sees the .html file, and does all the right things, including reading and using the yaml. It works perfect. By the way exporting for each .org file is just not a big deal, the keystrokes are: Ctrl-e Ctrl-b h h Crtl-e calls the exporter Ctrl-b tells it to NOT add any orgmode html header crap h h just says produce an html file (don't try to open it, etc.)

Now, with the new org backend in hugo, I cannot use any of my earlier approach, since hugo sees the .org file and wipes out my .html file I created from emacs (in org mode).

I suggest the following (and I know nothing about hugo internals, so I do not know if these suggestions can work):

1. A config file option (config.toml for ex.) with something like

[org] invoke = false

AND, but not INSTEAD of the above (so I can try out your org backend)

if hugo sees and .org file, and there is an .html file there as well with the same prefix, DO NOTHING. That way if I don't set "invoke = false" hugo will process org files that don't have matching html files.

I'm really sorry, but I have put tons and tons of work into my website, have a REALLY FULL FEATURED capability of html and pub quality latex.

I would like to bring this up to the hugo developers, but since you are one, maybe that is not needed.

Maybe someone could do a hugo build with the invoke = false I could try?

I really don't want to be stuck using an old version of hugo forever.

Again, I appreciate your efforts!

Larrabee

Chase Adams writes:

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.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

-- L. Larrabee Strow UMBC Physics Department Email: strow@umbc.edu Cell: 724-288-6933

[curiouslychase]

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.

[strow]

Well I guess that would work but would be a real pain for me constantly moving files. I'd say that is a hack. how hard would it be to just have an option to ignore your org 2 HTML converter? That will just add a level of confusion for my group members who already struggle with Hugo and org. I just think it is wrong to break something that worked fine for years.

Larrabee

On Mon, Mar 13, 2017 at 3:15 AM Chase Adams notifications@github.com wrote:

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

— You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub https://github.com/chaseadamsio/goorgeous/issues/32#issuecomment-286031146, or mute the thread https://github.com/notifications/unsubscribe-auth/ACTPL1nl2y8M29DuBFKlonkLvJJYCOkLks5rlOz6gaJpZM4MW-EY .

--

---

L. Larrabee Strow UMBC Physics Department Email: strow@umbc.edu Phone: 724-288-6933

[strow]

If you would like access to my web site repo, I can add "chaseadamsio"?? as a collaborator to the github version of the repo (not sure if that is your github identidy). I just ask you don't publish it. This would show you a lot of legal .org files that don't render with goorgeous. Mostly look under content/asl/ for files with graphics. This might help you in further development of goorgeous. Note that most of my web site is hidden (see static/asl/.*).

Larrabee

Chase Adams writes:

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

-- L. Larrabee Strow UMBC Physics Department Email: strow@umbc.edu Cell: 724-288-6933

[curiouslychase]

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.

[curiouslychase]

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.

[strow]

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.).

[strow]

Hi,

We had a discussion a while back with regard to goorgeous breaking my workflow. (I want the .org files to be in my repo, and create .html with emacs org-mode, works very well.)

You seemed to hope that the hugo maintainers might introduce a config file flag that would tell hugo to ignore .org files.

Looks like that has not happened? Any idea if they will do this in the future?

I was quite taken aback by the attitude that since hugo is not V1.0, maintainers can do as they please to break the code.

I had such a nice way to use hugo, worked every time with beautiful html, and now I cannot upgrade.

You were quite considerate of my issues, so just hoping you might be willing to try to push them to put in this flag?

Thanks in advance,

Larrabee

Chase Adams writes:

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.

-- L. Larrabee Strow UMBC Physics Department Email: strow@umbc.edu Cell: 724-288-6933

[curiouslychase]

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

[curiouslychase]

@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.

[curiouslychase]

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.