especially when the given `--source` path is a relative directory.
Also, when `--source` is specified, make WorkingDir an absolute path
from the very beginning, to be consistent with the case when `--source`
is not given. Otherwise, the function name helpers.AbsPathify(), which
prepends WorkingDir to a relative path, does not really make sense.
Fixes#1721
Reduce duplication (`x + FilePathSeparator + y` a few lines away from `filepath.Join(x, y)`) and add a `GetThemeDir()` function to get the current theme's directory.
Also add a comment complaining about the `GetThemesDirPath()` function, which doesn't seem to do what its name would suggest. This might be a candidate for deprecation?
So the taxonomy `Gérard Depardieu` gives paths on the form `gerard-depardieu`.
Unfortunately this introduces two imports from the `golang.org/`, but Unicode-normalization isn't something we'd want to write from scratch.
See https://blog.golang.org/normalization
See #1180
Section names are also used as the title of the list pages, but naming section folders as `Fish and Chips` and similar didn't work very well.
This commit fixes that.
This commit also changes the title casing of the section titles. Some may argue that this is a breaking change, but the old behaviour was also pretty broken,
even for languages that use title capitalizations, as it didn't follow any particular style guide, `fish and chips` became `Fish And Chips` etc.
Now it just turns the first letter into upper case, so `Fish and Chips` will be left as `Fish and Chips`.
People wanting the good old behaviour can use the `title` template func.
Fixes#1176
Setting `RelativeURLs` to `true` will make all relative URLs in the site *really* relative.
And will do so with speed.
So:
In `/post/myblogpost.html`:
`/mycss.css` becomes `../mycss.css`
The same in `/index.html` will become:
`./mycss.css` etc.
Note that absolute URLs will not be touched (either external resources, or URLs constructed with `BaseURL`).
The speediness is about the same as before:
```
benchmark old ns/op new ns/op delta
BenchmarkAbsURL 17462 18164 +4.02%
BenchmarkAbsURLSrcset 18842 19632 +4.19%
BenchmarkXMLAbsURLSrcset 18643 19313 +3.59%
BenchmarkXMLAbsURL 9283 9656 +4.02%
benchmark old allocs new allocs delta
BenchmarkAbsURL 24 28 +16.67%
BenchmarkAbsURLSrcset 29 32 +10.34%
BenchmarkXMLAbsURLSrcset 27 30 +11.11%
BenchmarkXMLAbsURL 12 14 +16.67%
benchmark old bytes new bytes delta
BenchmarkAbsURL 3154 3404 +7.93%
BenchmarkAbsURLSrcset 2376 2573 +8.29%
BenchmarkXMLAbsURLSrcset 2569 2763 +7.55%
BenchmarkXMLAbsURL 1888 1998 +5.83%
```
Fixes#1104Fixes#622Fixes#937Fixes#157
Fixes part of issue 1030. Previously hugo only listed the content
directory as being watched. Now we list all files being watched
according to `commands.getDirList()`. We also introduce a RemoveSubpaths
function and test in the helpers module to reduce noise in the command
line output by not showing subdirectories of ones already being watched.
For example, instead of:
`Watching for changes in $HOME/blog/content`
We get:
`Watching for changes in
$HOME/blog/{data,content,layouts,static,themes/my-theme}`
As views looks like a regular template, but doesn't need a base template, we have to look inside it.
Altough really not needed by this commit, reading the full file content into memory just to do a substring search is a waste.
So this commit implements a `ReaderContains` func that in most cases should be much faster than doing an `ioutil.ReadAll` and `bytes.Contains`:
```
benchmark old ns/op new ns/op delta
BenchmarkReaderContains 78452 20260 -74.18%
benchmark old allocs new allocs delta
BenchmarkReaderContains 46 20 -56.52%
benchmark old bytes new bytes delta
BenchmarkReaderContains 46496 1258 -97.29%
```
Fixes#999
Thanks to @bep's new, brilliant helpers.Deprecated() function,
the following functions or variables are transitioned to their
new names, preserving backward compatibility for v0.14
and warning the user of upcoming obsolescence in v0.15:
* .Url → .URL (for node, menu and paginator)
* .Site.BaseUrl → .Site.BaseURL
* .Site.Indexes → .Site.Taxonomies
* .Site.Recent → .Site.Pages
* getJson → getJSON
* getCsv → getCSV
* safeHtml → safeHTML
* safeCss → safeCSS
* safeUrl → safeURL
Also fix related initialisms in strings and comments.
Continued effort in fixing #959.
Make sure that the file separator is added to the temp dir in all cases.
This prevents cache temp files being written to the root temp folder.
Fixes#910
The paths were seen as changed but not static because of the backslashes in
ev.Name. Once the backslashes were added, I discovered that the JSON
sent to livereload was invalid and failed to work because it had backslashes.
Hence the code to replace the backslashes from the path to make them work
in JSON and for the URL.
With this fix, changes to a stylesheet are shown on the page, and if it's a
single file that changed, it's reflected in the browser without reloading the whole
page.
File handling was broken on Windows. This commit contains a revision of the path handling with separation of file paths and urls where needed.
There may be remaining issues and there may be better ways to do this, but it is easier to start that refactoring job with a set of passing tests.
Fixes#687Fixes#660
FileAndExt has now be completely rewritten and now works as may
reasonably be expected. The test cases for:
ReplaceExtension
Filename
FileAndExt
now all pass.
The problem was the way path.Base was being used.
Firstly Base returns "." if the directory is empty, but it can also
return "." for the current directory, or ".." for the parent directory,
if these are the last elements in the path. Simply detecting the
presence of a "." in the returned string and truncating before the "."
does not therefore always result in a valid filename.
Secondly, Base strips any trailing slashes making is more difficult to
detect when the path does not end in a filename but in a directory name
i.e. a no filename case. Not detecting this incorrectly results in the
last directory name being returned as the filename.
The code has been updated to take account of of both situations so that:
1) An empty string for both the filename and extension is returned if the
path does not contain a filename (plus an optional extension). This
includes both the empty path case, and the ends in a directory case.
2) If the path represents a filename with an extension then both the
filename and the extension (minus any dots) are returned as non empty
strings.
3) If the path represents a filename without an extension then filename
will be returned as a non empty string (minus any dot) and the extension
will be returned as an empty string.
