Re: Namespaces - summary, conclusion

[Alfred M. Szmidt]

   > > Given this is more or less the position held by Alan, Eli, Richard,
   > > Drew and João I think the chances of seeing new aliases is close to 0.
   >
   > This is not my conclusion.  I've seen several calls to move away from
   > from discussing in the abstract to discuss specific, concrete
   > examples.  I think this is a good idea, since IMHO the abstract
   > discussion is likely exhausted.
   >
   > There is always the chance that some of the proposals will be voted
   > down.  But also consider that some who have disagreed with you in the
   > abstract might be more convinced by specific, concrete proposals.

That too is my understanding of the discussion.

   So far the string- proposal got shot down entirely. The regexp one was
   initially a no-go from Alan but I then Richard kinda liked it and
   proposed adaptations.

   @Stefan Monnier: I see that you talked about `multibyte-string-p`
   already (and iirc that didn't went well. You talked earlier about
   `process-`, maybe you'd like to propose some changes there?

Personally, I think there are way too many half proposal -- by which I
mean one suggests something to see if it is OK, but without any
reasoning towards _why_ it is a good idea -- on doing way to many
changes for a very negligible benefit.

Such overwhelming changes will most surely be shot down quickly.

   I mean I'm willing to propose concrete changes but if it's not obvious
   for string- and regexp- why would it be for other topics? Let's try
   another topic just to see:

   rename-file -> file-rename
   delete-file -> file-delete
   copy-file -> file-copy

These functions are also interactive, where it is far more natural to
want to rename/delete/copy a file, than ... a file
renamed/deleted/copied.
 
   expand-file-name -> file-expand-name

You're expanding a file name, so the name seems to fit the task.