Re: Re: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
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 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
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 09:10:59 -0700 > Cc: yanta...@posteo.net, emacs-de...@gnu.org, emacs-orgmode@gnu.org > From: Jim Porter > > On 5/7/2024 5:20 AM, Eli Zaretskii wrote: > > 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". > > 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. If enough people want the other behavior, I won't object to supporting that as well as an option.
Re: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
On 5/7/2024 5:20 AM, Eli Zaretskii wrote: 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". 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.
RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
> > 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.
Re: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
> From: Drew Adams > CC: "e...@gnu.org" , > "emacs-de...@gnu.org" > , > "emacs-orgmode@gnu.org" > Date: Tue, 7 May 2024 01:52:13 + > > 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". > 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. It just is not what you think it should be, because our considerations are different from yours.
RE: RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
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).
Re: RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
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.
RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)
> 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. (Yes, technically point is between the chars.) And with a block cursor the cursor is on the second thing, not the first. And `C-x =' describes the current "cursor position" (aka point), and it describes - wait for it - not the char before point but the char after point, IOW, colloquially the char at point. And `forward-sexp', `forward-word', `forward-thing', etc. advance just _past_ the thing. The cursor is then _not_ on the thing, and unless the thing is immediately followed by another thing, there's _no_ thing at point. Unfortunately, Emacs maintainers decided that thingatpt.el isn't useful for anything except obtaining something to use as a default value for user input. The opinion was that no one ever wants/needs to get nil, telling them that there's no thing at point. Better, they think, to always try to get a thing at point OR at (1- point). This awful Emacs behavior defeats the successive use of functions that do something with the next thing at point, in precisely the case you cited: when the next thing butts up against the previous thing. In particular, these important use cases are defeated by the behavior chosen for Emacs: 1. To find out _whether there is_, in fact, a THING at point. AT POINT - not point OR (point - 1). 2. IF there really is a THING at point, to return it (or its bounds). See bug #9300, " `bounds-of-thing-at-point' does not return nil when just after THING". ___ Library thingatpt+.el fixes this, providing more useful behavior for thing-at-point, and making more use cases possible. It also provides functions for picking up a thing that's _near_ point (where "near" can be specified). That's what Emacs _should_ do for the only use case it even cares about, which is trying to get a thing for use as a default value for input. Getting a thing near point is quite different from getting a thing _at point_. ___ https://www.emacswiki.org/emacs/download/thingatpt%2b.el
