Make filename-base filetype detection independent of working directory

[questionmarkexclamationpoint]

At the moment, filetype detection based on the filename is rather brittle: for regexes that rely on the path, they rely on the relative path. If the filename regex is, for instance, /privoxy\/config$/, syntax highlighting only works if your relative path includes the parent directory right before the file. So, micro ../privoxy/config, micro privoxy/config, etc. work, but micro config (where config lives in a folder named privoxy), micro privoxy/./config (convoluted but u get my drift), etc. do not.

Currently this issue affects two filetypes in particular, whose regex relies completely on the path: privoxy-config, and, specifically, weechat config files (type ini). A number of filetypes make use of path-based heuristics, however, and those heuristics break down depending upon where you happen to be when you open the file.

I've updated Header.MatchFileName (now MatchFilePath) to take the absolute path to the file (updating callers), to run the check against that, and only return true if a match exists that extends into the filename.

Note that this will both add and remove categories of matches:

• Previously, if you supplied an absolute path to micro, and your regex matched on the path but not the file, Micro would consider this a match. For instance, /some-file/ matches on /this/is/not/some-file/but/itstillmatches. This seems like unintended behavior to me, but who knows. This wacky behavior can still be achieved by using /some-file.*/, of course.
• Again, as outlined above, opening privoxy/config from within the privoxy folder (micro config) would not match, and now it does. IMO this seems like the originally intended behavior, and allows for more particular regexes.

I wound up finding this behavior while writing a syntax highlighter for Kitty config files, since I was using a regex of /kitty\/.*\.conf/ to not be overly broad, while still including every .conf file within that folder. I'm about to open a PR with that addition pending this change if that's chill : )

In any case, please let me know what you think! Very happy user of micro for many years : )

(p.s. I've never written Go before 👀 it's probably fine)

[JoeKar]

But basically all we need is to exchange b.Path with b.AbsPath in UpdateRules(), right?
Don't ask me why we rely on the relative path for so long when we allow path patterns. 🤔

[questionmarkexclamationpoint]

But basically all we need is to exchange b.Path with b.AbsPath in UpdateRules(), right? Don't ask me why we rely on the relative path for so long when we allow path patterns. 🤔

imma be honest i wanted to make the minimum change given it's a codebase i looked at for the first time yesterday, written in a language i used for the first time yesterday, and changing one parameter and the contract of a function called in two places seemed pretty low risk.

in any case, the change specifically to the MatchFileName/MatchFilesPath is warranted regardless i think, since it avoids the poteeeeential for matches on the file's ancestor dorectories without maching the file itself, which seems undesireable

lemme see what u mean about that function tho

ty for getting back so fast homie