Hi guys,
I am having a bad time trying to make work the “–navigateToChanged” option.
My current command line to launch hugo is: “hugo server --watch --navigateToChanged --buildDrafts”
I am editing with nano and using firefox. But everytime I save my “.md” firefox returns to the top of the page. I am expecting that the scroll position will be placed close to the modified content, but this is not happening.
Is anyone able to light me up whats happening?
Thanks
I am expecting that the scroll position will be placed close to the modified content, but this is not happening.
I can’t say with 100% certainty, but I think navigateToChanged is at the page level, not to a scrolled position. There’s no mention of anything like that in the original announcement.
All right, then I suppose that the page should only be refreshed dinamically, without a reload() (which implies a F5 or CTRL+F5) just like in the gif animation.
This is not happening either 
Hugo Server refreshes the page always.
If it’s a markdown file you are editing, to keep the scroll position, you should try a Markdown editor with live preview like the ones provided in Atom, Hack Md etc
I know it always refreshes the page, the key part is that is very very annoying to scroll down the page on each save. Thats what I thought “navigateToChange” repairs. It is not?
Normally an external editor with live preview would be an option, but my markdowns has more than md code like hugo’s {{}} tags (highlighting stuff and more) which are not interpreted.
No. It switches to the page that was edited.
That’s why I’m looking into cleaning up my markdown from Hugo shortcodes or modifying them so they’re interpreted.
For example one thing I’ve found is that an img shortcode in the form of {{<img src="1.jpg">}} is previewed by most editors. Of course the preview is wrapped in {{}} but I can live with that.
Anyway I’ve been in your shoes and I can feel your frustration.
I see, I misunderstood that feature then. A pity.
Thanks for your fast answers mate.
You can’t easily tell what line was edited in a file real time. Hugo is just watching folders and files for navigateToChange. On Mac, editors like ByWord and I think MultiMarkdown Composer have this feature of locking the edit cursor to the preview location, but they are controlling the edit and the preview, so it’s possible to implement.
True. Very true. I forgot about that.
@Tzaoh
If you’re good with ReGex you could also in theory make a Markdown editor interpret your shortcodes.
I’ve tried this once for images. See here: Is there a way to control markdown images in Hugo? - #4 by alexandros
No, it is actually to the scrolled position if you change the current page – then it translates into window.location.reload(); – which is pretty nice when doing edits far down on a page.
And the (main) reason it wasn’t in the original announcement is because that logic was applied later.
I don’t, the browser does that for me.
I see a discussion above about scrolling to a position when navigating to another page, and that is not implemented – and a much harder problem. It should be possible to approximate by diffing old vs. new content file, but that is not on my list of priorities.
ah, right, iiuc the cursor position is maintained if the page is the same, but, not if changing pages. Yeah, I can see how diff would work for it. I’m just happy it jumps to the page I edited. I really like the feature.
Blimey. You’re right. It stays at the exact scrolled position and NOT jumping to the top.
Hey Bep, thanks for answering.
The discussion derived to other but my problem is in the SAME page.
The scroll is always set to top after editing the file, what can I do to figure out what is happening and solve it?
$ hugo version
Hugo Static Site Generator v0.31.1 linux/amd64 BuildDate: 2017-11-27T21:31:31
nano editor + firefox
Nano can create some backup file in the working folder. Wonder if that’s got anything to do with it?
Only if “–backup” is used when executing, or “set backup” is set in ~/.nanorc.
None of them are used here.
There has been reports about file watching not working on Linux, and I have done some investigating/fixes in the past on LInux. But the watching part seems to work for you … but this isn’t something I can “debug remotely” by guessing in a thread, and I don’t have time to try to spin up a Linux to reproduce this.