[Octave-bug-tracker] [bug #49685] Set .m file encoding on a per-directory basis

[Andrew Janke]

Follow-up Comment #11, bug #49685 (project octave):

> I'm unsure if the dir_encoding should also apply to any private, @class or
(nested) +namespace folders in that directory. 

I'd say yes: I'd think it should apply to the entire directory hierarchy. Who
in their right mind is going to mix different file encodings based on whether
a file is inside a package/private or not? That wouldn't work under Octave's
current behavior, so there's no back-compatibility concerns here.

> On the other hand, it's probably also conceivable that a user would like to
drop in a +namespace folder from another project that uses a different
encoding.

That's a terrible way of composing software, and something we should
discourage. ;) If you want to pull in another library, don't stick it inside
the source tree for your own library's M-code; put it in a `lib/` dir
somewhere and reference it. I realize it's something that people do with
Matlab/Octave software sometimes, because most M-code libraries are just a
pile of functions in the global namespace, so sometimes people hack it by
sticking it in a `private/`, but that's never gonna work robustly, and I'd
suggest discouraging that practice and trying to provide alternatives instead
of molding the low-level behavior of Octave to support those kludges.

(Sticking another library's files under a +package directory without
modification doesn't work, because then those functions and classes are not
referenceable by their original unqualified names, which is probably what the
library's internal code is doing. So that's not a case we need to support.)

If this is something we really want to support, I'd suggest having a
`.encoding` file in a directory that takes effect for the entire directory
subtree underneath it, which then could be overridden by an `.encoding` file
in a subdirectory. Kind of like how `.editorconfig` and `.gitignore` files can
override each other, on a subtree basis.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?49685>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/