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

[Michael Heerdegen <michael_heerdegen@web.de>]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Thu, Nov 29, 2012 at 10:44 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> > In this Emacs version,
> > (read-file-name-internal "~" 'file-exists-p nil) returns "~/dradams/".
>
> read-file-name-internal's docstring clearly says:  "Internal
> subroutine for `read-file-name'.  Do not call this."

I'm not sure if I understand the implications.  I thought something like
"Do not call this." is meant for the end users, but also for developers?

Emacs is the "extensible ... editor".  It is quite difficult for any
developer to extend Emacs and contribute packages if we only allow the
use of high-level public interface functions.

I'm helping Drew to fix problems in Icicles.  It was already hard to
understand the not very lengthy documented new completion code.  But if
we are disallowed to use it, we had to stop to develop something like
Icicles.

If we start to change our habits and write Emacs in a way that essential
primitives aren't allowed to be called by developers, this is the
beginning of the end of extensibility.  It is a bug if something like
`read-file-name-internal' is not allowed to be called in third-party
packages.

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.  Ok, I'm not that much a
software developer that I would know if this is always necessary in that
strong sense.  But it would be helpful if the sources of Emacs (which is
free software that may be used and modified by anyone) would be a bit
more readable and reusable than the compiled byte-code.


Michael.