GNU bug report logs - #74132
31.0.50; thing-at-pt, ffap and Github markdown

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Madhu <enometh <at> meer.net>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 74132 <at> debbugs.gnu.org
Subject: bug#74132: 31.0.50; thing-at-pt, ffap and Github markdown
Date: Sat, 09 Nov 2024 12:29:10 +0200

> Date: Thu, 31 Oct 2024 16:06:49 +0530 (IST)
> From: Madhu <enometh <at> meer.net>
> 
> Consider the following text as is typically found on README.md
> 
> ```
> [![GitHub Releases Downloads](https://img.shields.io/github/downloads/raysan5/raylib/total)](https://github.com/raysan5/raylib/releases)
> ```
> 
> If the point is say at "r" at "raylib/releases", invoking
> (ffap-url-at-point) fails.  this eventually calls
> thing-at-point-bounds-of-url-at-point, which has hardcoded behaviour
> to, skip over "allowed characters" backwards to find the beginning of
> the bound. here it it finds the space character (in "Release
> Downloads") and the whole thing fails.
> 
> This particular failure can be addressed by supplying the lim
> paramater to the skip-chars-backward, as shown in the attached
> patch.
> 
> does this look like a problem which ought to be solved? and is this
> appropriate? (I was going to post on emacs-devel but decided to post
> to the bug list instead) -- Best Regards, Madhu
> 
> >From 5971b7c10d7c38d540fdf278a0cd559c96b10ed2 Mon Sep 17 00:00:00 2001
> From: Madhu <enometh <at> net.meer>
> Date: Thu, 31 Oct 2024 15:40:42 +0530
> Subject: [PATCH] lisp/thingatpt.el: recognize urls better in markdown text
> 
> * lisp/thingatpt.el: (thing-at-point-bounds-of-url-at-point): supply a
> LIM when calling (skip-chars-backward allowed-chars), which is the
> position where `thing-at-point-beginning-of-url-regexp' matches
> backwards
> 
> problematic url e.g.
> ```
> [![GitHub Releases Downloads](https://img.shields.io/github/downloads/raysan5/raylib/total)](https://github.com/raysan5/raylib/releases)
> ```
> If the point is in the the second url, skip-chars-backwards goes to the
> space (between s and D) and `ffap-url-at-point' eventually fails.
> but if we supply a limit with a left anchor, we work around it.

What will this do to URLs such as

  http://web.archive.org/web/20240221082647/https://www.imdb.com/

?  More generally, to any URL that has another URL embedded in it?

I'm not sure I see how to resolve this dilemma.  Stefan, any ideas?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.