bug#13033: 24.3.50; regression: read-file-name-internal handles "~" wrong

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > It is a bug if something like `read-file-name-internal' is not
> > allowed to be called in third-party packages.
>
> Then please submit bug reports, asking for features that you cannot
> get from other APIs.

Ok, I'll remember that.  But I wouldn't be surprised if the new API
would just be a corrected and documented version of
`read-file-name-internal'.

> > At university I learned that writing software happens in a way that
> > every function should have a clear specification for what it
> > does/returns, and a documentation of this.
>
> If they didn't teach you about the difference between internal APIs
> and public APIs, then it's too bad.

Yeah, education here is quite strange and idealistic.  They even told us
that such specification and documentation would help developers
understanding the code, as well as it would help these people that maybe
want to change this code some years later.

> Nevertheless, the distinction is part of our lives.  Some languages
> have means to conceal private APIs from external applications, but C
> and Emacs Lisp don't.  So we use whatever we got; please always assume
> that there are good reasons for that.  (It is OK, of course, to
> question those reasons, but ignoring them is not wise, IMO.)

You're right, I think I question the reasons, in this case.

So, I don't think we disagree here.  IIUC, what we need for Icicles is a
completion table for filename completion that can be used as the
COLLECTION argument for `try-completion' or `all-completions'.  That is,
I guess, something like a not forbidden version of
`read-file-name-internal'.


Michael.