Repository navigation
Html tags, Images, Mathml in titles (possibly asynchronously) #388
Description
Some feeds use inline graphics in the titles. For example:
关中十八陵<img alt=[微风] src="https://h5.sinaimg.cn/m/emoticon/icon/others/w_weifeng-33be96b05d.png" style="width:1em; height:1em;" ...
It would be cool if this graphics is displayed, similar to images in article body.
Activity
minad commentedon May 20, 2026
@yantar92 Do you still want this, 6 years later? It does not seem like the best idea to me now that I know the code base. If we render each title via shr in the elfeed-search buffer, everything will get much slower and Elfeed may also start a ton of network processes. I am all for better supporting HTML in the elfeed-show buffer, but I am not in favor of doing the same in the elfeed-search buffer. I tentatively close this. Please object if you disagree.
minad commentedon May 20, 2026
Maybe your feature request was about the elfeed-show buffer all along? In this case I am all for it.
yantar92 commentedon May 20, 2026
No, it was specifically about titles. I even have a hacky code locally that "renders" html in titles.
As for slowing things down, it is certainly not a good idea to enable such feature by default or block emacs until everything renders. Rather, I was thinking about something like putting an overlay with custom rendering (or even translation) that can be done asynchronously.
minad commentedon May 20, 2026
So you meant in the search buffer? If yes, I am not fond of the idea. Look for instance at 5927e32 and the image hack - shr is not a robust library. Another example is patch #366, which more or less works, but also has problems with images which are not displayed at all in the overlays. For custom rendering we already have the
elfeed-search-print-entry-functionbut it is probably a bit too coarse grained for what you want? In any case, I consider this low priority, but this is of course just my preference. I would preferably invest time in #366, #612 or #613.minad commentedon May 20, 2026
We should also take into account how many feeds would profit from this feature. Which value do we get out of a feature and does it carry its weight?
yantar92 commentedon May 20, 2026
Many research feeds can benefit. Inline mathml staff is not uncommon there. Is it a high priority? No.
But, I'd prefer to keep it open.
yantar92 commentedon May 20, 2026
P.S. Images in feeds are not really that common. More common is html, which is not exactly this feature request. But it would take similar code to make it work I think.
yantar92 commentedon May 20, 2026
Maybe this feature request should be converted into something more generic like asynchronous title rendering + standard optional rendering function that uses shr/w3m
minad commentedon May 20, 2026
Yes, mathml seems to be a better argument, as is html formatting. Images are not such a good feature request in my eyes, since they are uncommon, and for the issues I've mentioned with shr.el - therefore the close. May I suggest you create a better issue or update this one with more details of what you want to support (bold, italic, underline, things like this should be easy)? Images and mathml are significantly harder? Of course if we find a good way to support it, why not, if it is guarded behind an option?
minad commentedon May 20, 2026
Regarding asynchronous title rendering - I am a bit skeptical. This sounds complex and slow, with rendering queue and so on. My suggestion would be to go first for something more modest and support basic html elements which are common in titles, but which could be displayed synchronously. Anyway, I think it would be great if this issue could be updated with concrete ideas - or we could turn it into a discussion until a concrete plan arises.
[-][feature request] Images in titles[/-][+]Html, Images, Mathml in titles (possibly asynchronously)[/+][-]Html, Images, Mathml in titles (possibly asynchronously)[/-][+]Html tags, Images, Mathml in titles (possibly asynchronously)[/+]