From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Problems with info (emacs version) Date: Tue, 3 Jun 2003 08:49:18 -0500 (CDT) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200306031349.h53DnIc24803@eel.dms.auburn.edu> References: <200306020333.h523XMC23468@eel.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1054649124 32322 80.91.224.249 (3 Jun 2003 14:05:24 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 3 Jun 2003 14:05:24 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jun 03 16:05:22 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19NCO3-0008Fe-00 for ; Tue, 03 Jun 2003 16:03:39 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19NCfB-0005mO-00 for ; Tue, 03 Jun 2003 16:21:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19NCNv-0006qc-MV for emacs-devel@quimby.gnus.org; Tue, 03 Jun 2003 10:03:31 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NCKy-0005ks-R3 for emacs-devel@gnu.org; Tue, 03 Jun 2003 10:00:28 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NCKK-0005Nq-Em for emacs-devel@gnu.org; Tue, 03 Jun 2003 09:59:49 -0400 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19NCAA-0002pw-7K; Tue, 03 Jun 2003 09:49:18 -0400 Original-Received: from eel.dms.auburn.edu (eel.dms.auburn.edu [131.204.53.108]) h53DnBoc007672; Tue, 3 Jun 2003 08:49:11 -0500 (CDT) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.11.6+Sun/8.11.6) id h53DnIc24803; Tue, 3 Jun 2003 08:49:18 -0500 (CDT) X-Authentication-Warning: eel.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: jas@extundo.com In-reply-to: (message from Simon Josefsson on Tue, 03 Jun 2003 07:58:07 +0200) Original-cc: rms@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:14632 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14632 Simon Josefsson wrote: I'd say this is a bug in the mail sending part of Emacs. Message asks the user if she knows about the hidden parts. It does not seem to do that in the concrete example I gave. I am not terribly familiar with message-mode (I use mail-mode), but message-mode does not seem to check for or ask about the display property. Also, to respond to Miles, the invisibility property is already in yank-excluded-properties. There is no "invisible" text around in the example (that is there are no invisibility properties around), only text you can not see, because it has the display property. message-mode behaves the same as mail-mode in the example, without any warning, although it does seem to get the FCC correct. I should say that a proposed change by Stefan would get rid of the very concrete problem with info I showed. But even with the invisibility property, which is in yank-excluded-properties by default, problems remain when a user yanks a larger piece of text into a mail buffer or first saves the text to file, then inserts the file (which I sometimes do). The user may not carefully double check the yanked or inserted text, because he "knows" (or believes he "knows) what is in there. > Do you consider the above a "real" problem? I do. Me too, but I don't think the problem is with info. I do believe that there are two problems with info. One would be eliminated by a change proposed by Stefan. That problem is that I believe that it uses the display property in an inappropriate way. The display property is nice to make the text "appear differently" (but with the same content), to make a whitespace string display a picture and similar, but I believe that the following info-style use is inappropriate: You have a file. You want to make some text in the file invisible, but at the same time you also want to do some aligning. Hence you give the text a whitespace string as display property. The result is "visible text that you just can not see". You trick the user, you trick all Elisp code dealing with invisible text, including message mode's warning mechanism. The second claim I am making is that if you present the user with a buffer containing invisible text, you should always make sure that the user is aware of the invisible text and provide him with a convenient (even for less sophisticated users) way to make that text visible. Otherwise plenty of problems could occur. I proposed to bind a visibility toggling command to, say, `v' in info. Sincerely, Luc.