From: Drew Adams <drew.adams@oracle.com>
To: "Lars Ingebrigtsen" <larsi@gnus.org>,
"Mattias Engdegård" <mattiase@acm.org>
Cc: Stefan Kangas <stefankangas@gmail.com>, emacs-devel@gnu.org
Subject: New year - Out with the old! [was: ...Beef up the Emacs string utility set a bit]
Date: Tue, 22 Dec 2020 09:04:32 -0800 (PST) [thread overview]
Message-ID: <2f78ecd7-5846-44eb-89aa-4483503f0799@default> (raw)
Just a comment on the purported problem of Emacs
users who tend to write their own or use an
existing 3rd-party library for things like string
concatenation etc. People mention problems of
discovery, historical names that are less than
ideal or can be confusing, and so on.
I'll just mention that there can be other things
at play, and the fact that some users don't use
the predefined functions etc. isn't always or
necessarily an indication that something basic or
important is crying out to be "fixed".
Consider, as an example, the use of plain string
manipulation functions to fiddle with file and
directory names. That's a fairly common mistake
that some users make.
Instead of using what Emacs makes available for
this, and which is well and carefully documented
in (elisp) `File Names' and its subsections
(`File Name Components', `Relative File Names',
`Directory Names', `File Name Expansion', `Unique
File Names', `File Name Completion', and `Standard
File Names'), some people just blunder ahead using
general string operations. Maybe they're used to
thinking of file names as just strings, maybe they
couldn't find the file-name functions,... whatever.
Why? Whose fault is this? What, if anything
should Emacs do about it?
Maybe consider that example, when you're off
thinking about the "problems" of Emacs's appeal
to new users, discoverability, poor names, etc.
Does Emacs's "string utility" need to be "beefed
up"? Maybe, maybe not. Dunno. But perhaps
consider the context of such discussions in the
light of our file-name "utilities" situation.
Is it Emacs's "fault" that some users unwisely
use string functions to manipulate file names?
Maybe, maybe not.
Worth pondering, perhaps.
Another thing that can be involved: Emacs and
Elisp are great grounds for tinkering. And
some users (many of us) find it interesting or
enjoyable to either roll our own or be among
the first ("Look Ma!", "Tu m'as vu !") to
discover some 3rd-party library that does some
things differently or better. That then gets
compared/contrasted with what conventional,
old-school, vanilla Emacs offers. And we get
crusaders and evangelizers for "modernizing",
"innovating" etc., based sometimes on whatever
flavor they happen to favor at the moment.
I'm by no means making an argument that Emacs
and Elisp have no room for improvement. But if
someone follows these mailing lists for a few
years it becomes apparent that there's recurring
periodic "discovery", by a new crop of explorers,
of perceived HUGE weaknesses in what Emacs and
Elisp provide. And as "proof" we get anecdotes
and "surveys" that show that users - especially
new users - don't know about this or that, can't
find this or that, expect something different,
or just don't like this or that. Plus ca change...
I don't argue that such ideas or complaints are
inherently misplaced (out of familiarity with
other approaches, ignorance, or whatever).
I do think it can be good to take a somewhat
historical, more distant view, and put such
"Eureka! Emacs has huge problems!" discovery
exclamations in context.
Everyone new to Emacs finds how different it is.
That can be like discovering a new continent.
For some, it's marvelous. For others, it's just
primitive, populated by savages, a decaying
culture, or is just no longer relevant. For
some, it's a mix.
All of that's to be expected, and as expected
it continues. Check back in another 40 years. ;-)
Just one primitive observer, with one observation.
reply other threads:[~2020-12-22 17:04 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2f78ecd7-5846-44eb-89aa-4483503f0799@default \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
--cc=mattiase@acm.org \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.