The one in line 65? There is no hyphen on line 72.

A damn. My english... I meant this character: "
It seems to start with the eval command which causes trouble for me. Maybe this can be simplified.
I will try to write a proper fix.

Sounds more like a namcap problem

The problem was the echo. Can we remove this?
---------------
for _i in ${pkgname[@]}; do _j=${_i/vim-spell-/}; eval "package_$_i() {
cd \"\$srcdir\"
install -d \"\$pkgdir\"/usr/share/vim/vimfiles/spell
install -m644 $_j* \"\$pkgdir\"/usr/share/vim/vimfiles/spell
[[ -f README_$_j.txt ]] \
&& install -Dm644 README_$_j.txt \"\$pkgdir\"/usr/share/licenses/$_i/README #\
# || echo 'No README for $_j...'
}"; done
-------------------

Which will give an invalid parsepkgbuild output:
----------------
sha256sums
source
url

No README for af...
%NAME%
vim-spell-af

%VERSION%
20150901-1
------------------

Otherwise I get with the namcap python API:
PacmanPackage({None: ['No README for af...'], 'name': 'vim-spell-af', [...] })

Maybe this also needs to be better fixed in parsepkgbuild or the namcap python part.

To fix this in namcap one could disable echo when the PKGBUILD is sourced in parsepkgbuild.sh:

# Disable echo for the sourceing of the PKGBUILD to avoid errors
echo() { :; }
printf() { :; }
source $1

And then use builtin echo for every command below that line. This works for me.

Added keenerd to the notification list for probable namcap issue.

I want to say that in the past there have been packages that used echo to create the basic metadata, but I don't see any like that at the moment.

Anyway, weird pkgbuilds are likely to be parsed weird. Using eval to generate a pkgbuild function that echos to stdout is weird. It is a bug, but given the exceptional nature of what it took to produce the error I kind of feel it isn't worth fixing.

Half of the problem can be fixed by replacing "echo" with "msg", a makepkg function that won't exist during this non-interactive use. This removes the "None: ['No README for af...'" junk. (I'm leaning towards this, because we have "msg" for a reason. And because of all the solutions it is the only one that makes the total size smaller :-)

Or namcap can be tweaked. In PacmanPackage(), changing "elif line.strip() != '':" to "elif line.strip() != '' and attrname:" ignores the malformed data and never creates a "None" field.

Can't we just fix both? The namcap fix you suggested (it wont hurt and fix possible other bugs) and the msg change or even fix the eval completely to parse this package properly?

I was under the impression that the use of makepkg functions in pkgbuilds is frowned upon and sought to be ended, no?

You're correct, polyzen.  FS#43502