From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "jporterbugs@gmail.com" <jporterbugs@gmail.com>,
"yantar92@posteo.net" <yantar92@posteo.net>,
"emacs-devel@gnu.org" <emacs-devel@gnu.org>,
"emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
Date: Tue, 7 May 2024 15:16:50 +0000 [thread overview]
Message-ID: <SJ0PR10MB5488081374CD8F92AB48DE30F3E42@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <8634qtbypq.fsf@gnu.org>
> > I hear you. The behavior should be changed so
> > that, in general, bounds-of-thing-at-point etc.
> > return nil when there is _no thing at point_,
> > including when point is after, including just
> > after, a thing but not on such a thing.
> >
> > There can be commands (and noncommand fns) that
> > return things _near_ point, not only at point.
> > And "near" can be configurable with an argument.
> >
> > In particular, they can do what the vanilla fns
> > currently do: return a thing at OR just before
> > point. But the "-at-point" functions shouldn't
> > do that. They should do what their names say.
>
> I disagree. These functions are nowadays the basis of many
> interactive features, and users are usually mightily confused by the
> fine print of what "at point" means technically in Emacs. The current
> operation is much easier for users to grasp mentally by observing the
> position of the cursor, whether it's on or just after the "thing".
Of course. IF the only use case is (as it's limited
to now) trying to get something near point, to use
as a _default value for interactive prompt and input_,
THEN there's no need for an actual at-point semantics.
No need and no advantage.
The point (sic) is that there are important, useful
_additional_ use cases, not supported by the current
ad-hoc semantics. The idea behind Thing At Point is
much more general than the single use case that the
"many interactive features" you tout boil down to.
And no, legitimate at-point semantics doesn't require
any complex mental grasping. It's in fact the current
behavior that leads to mental gyrations & puzzling,
because of the inconsistency that Jim pointed out.
The proper semantics is in fact far simpler to "grasp".
You're just _used_ to grabbing things that aren't at
point, such as a list immediately before point. Habit
can make you think things are straightforward & simple.
> > It's not hard for Emacs to still DTRT. It just
> > takes a decision and admission that the behavior
> > was misguided and unnecessarily limiting (BIG
> > time).
>
> We made the decision.
We know. It's not too late to fix things, and it's
not hard to do. What's lacking is the volition.
> It just is not what you think it should be, because
> our considerations are different from yours.
Exactly. Your considerations are limited to maximizing
the possibility of returning a thing near point - more
precisely just before point OR AT point (aka just after
it). (And as Jim pointed out, even that's not supported
consistently.)
With those blinders on, your decision makes some sense.
Take off the blinders and see there's a whole world
surrounding the narrow slice you saw looking only
straight ahead.
next prev parent reply other threads:[~2024-05-07 15:18 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-06 19:45 [PATCH] Add support for 'thing-at-point' to get URL at point Jim Porter
2023-11-06 19:56 ` Jim Porter
2023-11-06 20:11 ` Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point) Ihor Radchenko
2023-11-06 20:53 ` Jim Porter
2024-02-05 15:07 ` Ihor Radchenko
2024-02-05 22:44 ` Jim Porter
2024-02-05 22:56 ` Ihor Radchenko
2024-02-06 12:26 ` Eli Zaretskii
2024-02-06 12:38 ` Ihor Radchenko
2024-02-06 12:47 ` Eli Zaretskii
2024-04-12 12:41 ` Ihor Radchenko
2024-04-12 22:30 ` Jim Porter
2024-04-29 4:26 ` Jim Porter
2024-04-29 18:14 ` Ihor Radchenko
2024-04-30 4:42 ` Jim Porter
2024-04-30 11:39 ` Ihor Radchenko
2024-04-30 18:27 ` Jim Porter
2024-04-30 21:10 ` [External] : " Drew Adams
2024-05-07 1:08 ` Jim Porter
2024-05-07 1:52 ` Drew Adams
2024-05-07 12:20 ` Eli Zaretskii
2024-05-07 15:16 ` Drew Adams [this message]
2024-05-07 16:10 ` Jim Porter
2024-05-07 18:01 ` Eli Zaretskii
2024-05-18 8:26 ` Eli Zaretskii
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
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR10MB5488081374CD8F92AB48DE30F3E42@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=jporterbugs@gmail.com \
--cc=yantar92@posteo.net \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).