From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: display-completion-list should not strip text properties Date: Thu, 6 Sep 2007 09:35:46 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1189096716 3868 80.91.229.12 (6 Sep 2007 16:38:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Sep 2007 16:38:36 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 06 18:38:36 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1ITKNI-0005qp-2K for ged-emacs-devel@m.gmane.org; Thu, 06 Sep 2007 18:38:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ITKNF-0006Rz-Vi for ged-emacs-devel@m.gmane.org; Thu, 06 Sep 2007 12:38:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ITKLM-00050H-QI for emacs-devel@gnu.org; Thu, 06 Sep 2007 12:36:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ITKLI-0004uq-T0 for emacs-devel@gnu.org; Thu, 06 Sep 2007 12:36:35 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ITKLI-0004uZ-Cb for emacs-devel@gnu.org; Thu, 06 Sep 2007 12:36:32 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ITKLH-0007s6-TA for emacs-devel@gnu.org; Thu, 06 Sep 2007 12:36:32 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l86GaTJL007000 for ; Thu, 6 Sep 2007 11:36:29 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l86GaRe1023692 for ; Thu, 6 Sep 2007 10:36:28 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-203.us.oracle.com by acsmt351.oracle.com with ESMTP id 3189172961189096543; Thu, 06 Sep 2007 09:35:43 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Detected-Kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:77995 Archived-At: > > Why do we need to put properties other that the `face' property > > in doc strings? There are already ways to make links. > > To include graphics in Help, for one thing. > > Is that really something we should get into? > I think we should not. Why not? Help, and documentation generally, often call upon graphics to aid communication. Just having the possibility to include graphics does not, of course, mean that it's a good idea to stuff tons of screenshots, icons, and other graphics into help. But having the possibility means that when it is appropriate to add a graphic you can do so easily. > That doesn't mean I am opposed to including some feature that would > make it possible. I would not be against that if it were clean, not a > lot of work, etc. But it is not a goal. Johan's one-line fix (which you have now OK'd - thanks) makes it possible and easy to do so for variables. The same is not true for functions (defun), however. I think it would be worthwhile to ease doing this for both variables and functions by supporting some simplifying syntactic sugar (I proposed some). I have no idea how much work would be involved in implementing that support.