Hi Ulf,
I'd say it's a bug. After a bit of back and forth with claude, the
behaviour is happening at
jspwiki-main/src/main/javascript/Wiki.Snips.JSPWiki.js, on the
linkPart3 object, more precisely on the regexp expression at match
property at line 402.
This regexp currently captures every char from cursor that is not |, ]
or newline. Whatever matches that regexp is swallowed, so that's way
it swallows the rest of the line. A quick fix would be setting the
match property to
linkPart3:{
suggest: {
lback: "\\[(?:[^\\|\\]]+\\|[^\\|\\]]+\\|)([^\\|\\[\\]\\n\\r]*)$",
match: "^[^\\|\\[\\]\\n\\r]*(?=\\])"
},
[...]
would stop this behaviour from happening, but then the popup would
need the link to be closed before it appears. Would you mind testing
this approach? sounds reasonable?
Wanting the popup to still pop when unclosed AND not delete would be a
bigger change on suggestAction (force len=0 when no terminator or
rewrok the regex to stop match at whitespace). Also keep in mind that
linkPart3 manages wiki links with three parts, something similar
happens on one part links (linkDlg, lines 427-428), and two part links
(linkPart2, lines 439-440). Deletion on these cases only happens if
you pick a suggestion
In any case, a PR would be more than welcome :-)
HTH,
juan pablo
cheers,
juan pablo
On Mon, Sep 7, 2026 at 6:40 PM Ulf Dittmer <[email protected]> wrote:
>
> Hi-
>
> I wanted to ask about something that's caused me to delete data
> inadvertently when editing a page on several occasions. If I have a line
> like
>
> This link has more details.
>
> and I want to actually make the word "link" a link, I might have this while
> editing:
>
> This [link|https://jspwiki-wiki.apache.org/|_ has more details.
>
> The underscore shows where the cursor would be. At that point pops up the
> menu with the Wikilink Attributes. I often select "Open Link in new tab" -
> which then deletes all text following the cursor positions, in this case
> "has more details". Needless to say, that's not what I want.
>
> Is that a bug or intended behavior? Either way, where would I have to look
> to change that behavior? I'm not asking for a patch, just for a pointer to
> where in the code that's happening. If it's deemed a bug, I'll be happy to
> contribute a PR.
>
> Thanks
> Ulf