[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andrew Janke
Subject: [Octave-bug-tracker] [bug #49685] Set .m file encoding on a per-directory basis
Date: Fri, 18 Sep 2020 13:03:42 -0400 (EDT)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:80.0) Gecko/20100101 Firefox/80.0

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

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:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]