emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Re: RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
  2024-04-30 21:10                       ` [External] : " Drew Adams
@ 2024-05-07  1:08                         ` Jim Porter
  2024-05-07  1:52                           ` Drew Adams
  0 siblings, 1 reply; 3+ messages in thread
From: Jim Porter @ 2024-05-07  1:08 UTC (permalink / raw)
  To: Drew Adams, Ihor Radchenko
  Cc: eliz@gnu.org, emacs-devel@gnu.org, emacs-orgmode@gnu.org

On 4/30/2024 2:10 PM, Drew Adams wrote:
>> I've also fixed a bug in EWW and bug-reference-mode
>> where it would return nil for (thing-at-point 'url)
>> if point was at the *end* of a URL.
> 
> By "at the end" I assume you really mean just
> _after_ a URL, i.e., no longer on/at the URL.
> 
> FWIW, that's actually _superior_ behavior.
> 
> Unfortunately however, Emacs has chosen the
> behavior you describe here:
> 
>> It's now consistent with how 'thing-at-point'
>> works by default.
> 
>> (If you have two consecutive URLs and point
>> is between them...it'll prefer the second one.)
> 
> Which is better!  It's what "at point" means.
[snip]
> See bug #9300, " `bounds-of-thing-at-point'
> does not return nil when just after THING".

I agree overall that your proposed behavior is more correct, and it's 
probably how I'd have implemented 'thing-at-point' if I were doing it 
from scratch. However, I think an even worse outcome than 
"thing-at-point looks at point or before-point" is "sometimes 
thing-at-point just looks at point, and other times it looks at point or 
before-point" (which is what it does today).

I'd even be open to something like a 'thing-at-point-is-strict' defvar 
that people could let-bind as wanted, but I'm not going to *argue* for 
that myself.

Ultimately though, this patch is really just about providing the 
necessary defcustoms for org-mode to be able to use 'thing-at-point' 
(and for Ihor to feel ok about it ;)). Changing 'thing-at-point's 
behavior should probably be handled separately, especially since there'd 
be an uphill battle to revisit the decision in bug#9300.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
  2024-05-07  1:08                         ` Jim Porter
@ 2024-05-07  1:52                           ` Drew Adams
  0 siblings, 0 replies; 3+ messages in thread
From: Drew Adams @ 2024-05-07  1:52 UTC (permalink / raw)
  To: Jim Porter, Ihor Radchenko
  Cc: eliz@gnu.org, emacs-devel@gnu.org, emacs-orgmode@gnu.org

Thanks for your reply, Jim.

> On 4/30/2024 2:10 PM, Drew Adams wrote:
> >> I've also fixed a bug in EWW and bug-reference-mode
> >> where it would return nil for (thing-at-point 'url)
> >> if point was at the *end* of a URL.
> >
> > By "at the end" I assume you really mean just
> > _after_ a URL, i.e., no longer on/at the URL.
> >
> > FWIW, that's actually _superior_ behavior.
> >
> > Unfortunately however, Emacs has chosen the
> > behavior you describe here:
> >
> >> It's now consistent with how 'thing-at-point'
> >> works by default.
> >
> >> (If you have two consecutive URLs and point
> >> is between them...it'll prefer the second one.)
> >
> > Which is better!  It's what "at point" means.
> >
> [snip]
> >
> > See bug #9300, " `bounds-of-thing-at-point'
> > does not return nil when just after THING".
> 
> I agree overall that your proposed behavior is more correct, and it's
> probably how I'd have implemented 'thing-at-point' if I were doing it
> from scratch. However, I think an even worse outcome than
> "thing-at-point looks at point or before-point" is "sometimes
> thing-at-point just looks at point, and other times it looks at point or
> before-point" (which is what it does today).

Yes, such inconsistency is arguably worse than
consistent bad behavior.  Arguably worse - and
arguably better.  (That's in the nature of
inconsistency - some will see a glass half
full; others half empty.)

> I'd even be open to something like a 'thing-at-point-is-strict' defvar
> that people could let-bind as wanted, but I'm not going to *argue* for
> that myself.
> 
> Ultimately though, this patch is really just about providing the
> necessary defcustoms for org-mode to be able to use 'thing-at-point'
> (and for Ihor to feel ok about it ;)). Changing 'thing-at-point's
> behavior should probably be handled separately, especially since there'd
> be an uphill battle to revisit the decision in bug#9300.

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.

It's important to have such functions.  It's
not just about arguing that strictly at-point
is better than at-or-just-after-point.  The
point (sic) is that currently there's _no way
to determine whether_ there's a thing at point.

That's the real problem - no test for a thing
at a given position.  That means that a whole
slew of possible applications of the feature
are impossible to realize.
___

Along with the fix for this bug, there could
also be a defvar, or even an option, that fuses
the two behaviors (at OR just before), i.e.,
that gives the current, misguided behavior, to
allow existing code or habits compatibility.

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).

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Re: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
       [not found] ` <SJ0PR10MB5488A3BE62A58A2E7BF7331CF3E52@SJ0PR10MB5488.namprd10.prod.outlook.com>
@ 2024-05-09  5:46   ` Pedro Andres Aranda Gutierrez
  0 siblings, 0 replies; 3+ messages in thread
From: Pedro Andres Aranda Gutierrez @ 2024-05-09  5:46 UTC (permalink / raw)
  To: Drew Adams, Org Mode List

[-- Attachment #1: Type: text/plain, Size: 3231 bytes --]

H, Drew
Hmmm... thanks for the clarification. That's going to be extremely helpful
once I'm back on track after the "grading season" ;-) All this started, at
least for me, when I was trying to write a simple interactive function to
copy the contents of the cell the point is in to the kill-ring (and
eventually to the clipboard). I eventually came up with a simple solution.
This make org-mode tables very comfortable for longer Web formularies with
complex data, like bank accounts.

Best, /PA

On Wed, 8 May 2024 at 20:14, Drew Adams <drew.adams@oracle.com> wrote:

> >> At the risk of veering off-topic (I mainly care about adding
> >> 'bounds-of-thing-at-point-provider-alist' and
> >> 'forward-thing-provider-alist'), would adding a new optional STRICT
> >> argument to 'thing-at-point' and friends be an ok resolution for
> >> everyone? This argument would enable Drew's proposed behavior. That way,
> >> users get all the nice behavior by default just like today, and
> >> programmers who require strict correctness in their code also have an
> >> option.
> >
> > 1+ if STRICT means thing starting at point
> > and without it we may need to look for the
> > beginning of the thing (lazy point setting)....
>
> Why "starting" at point?  STRICT shouldn't mean
> checking whether a THING starts at point.
>
> The "strict" behavior that's needed is checking
> _whether_ there is a THING at point, that is,
> checking whether the char at point (which really
> means just after point) is on/inside a THING.
>
> That's for `bounds-of-thing-at-point' etc.  For
> thing-at-point etc., IF there's a THING at point
> then that THING is the non-nil value returned.
>
> In terms of implementation, I suggest you take
> a look at the code in thingatpt+.el.  Look at
> functions `tap-bounds-of-thing-at-point' and
> `tap-thing-at-point'.  Just remove the `tap-'
> prefix for code that DTRT.  The file Commentary
> explains things in detail.
>
> My code adds an optional arg SYNTAX-TABLE, but
> you need not bother with that.  Elisp now has
> `with-syntax-table', which can be used as a
> workaround if there's no such argument.
>
> In the end, `bounds-of-thing-at-point' and
> `thing-at-point' should return nil if there's
> no THING at the char at point.
>
> For "lax" behavior that corresponds to the
> current vanilla behavior, if the strict
> behavior would return nil then they return
> what the strict behavior would return at
> (1- point).
>
> But really such a lax behavior is pretty lame.
> What's needed, for trying to grab a THING near
> point is not just checking backward one char
> but checking backward, forward, up, and down
> N chars, where N determines what "near" means.
>
> thingatpt+.el provides two user options,
> `tap-near-point-x-distance' and
> `tap-near-point-y-distance', the max number of
> chars from point to check for a THING (for X:
> left and right, for Y: up and down).  Setting
> the Y value to zero constrains search to the
> same line as point.
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 4197 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-05-09  5:48 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <CAO48Bk97scjnRwHTegBHDQC61E0EOtgvZaKLsz27qYyvamL2Aw@mail.gmail.com>
     [not found] ` <SJ0PR10MB5488A3BE62A58A2E7BF7331CF3E52@SJ0PR10MB5488.namprd10.prod.outlook.com>
2024-05-09  5:46   ` Re: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point) Pedro Andres Aranda Gutierrez
2023-11-06 19:45 [PATCH] Add support for 'thing-at-point' to get URL at point 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-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

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).